-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAlxT66MACgkQLell7WOC
XJNpjg/9HdSPrklj1nfIScyB8gAlFbA9clz4O36o5lQFXMZ05gst59QISrV8ZC5B
f/yK2v0hQdZbV1BKbvAEFrQirwjU4dNO0ZQ4C55nTHk65a4Yd8apjTiUT6Jkp4iG
b+j48lqDhyCsfg1jX8yery3kQ/OaCxvoZvXyXZx7k/+fT+BthufFiKNFXyEWltrE
ap/3ZBvOZwqN+NBXyk5J1DiXPxegq/YPwYm7DJ/uUg73KWQNoPdxtEJrmp7p65RW
heFesJoMGf/f7oocW7Yw+Vezn/P5/lJSrbOB2xw2HaXloChazsYjZPfqPP7b8UPi
10qITIz4NmWa4ebvDRKu1/ceWlX6zm+hx8J3Dpitf7Osabd/Ox3oQKXLzhxMVV2E
fB1uvQDZay05PFGdB4uBnChrJjBXPL9n8o9s8ke8WZc68llqagMEvol6AKmKf/cq
8Ka8oZc0Hoit6sAna1IiqX6f8vXKkeqtVFWOBOiBYOM/UR1kc5r1nwo0LdTxNWdB
O3e7DqmfOFdpPMGR6KUb3vlVoBcHvJEuDIjbQA03uidSFIQkN4FM1/ttYr/aZqif
r6JSjSGNnMKJaJfxrl9KHd/xQMAITjolfB1MXiIUz4ClH/NKB2Xvr7uuQP7ZptDK
sj0OGRrMEtYtI/eqYRHbspnev5+D9rmbu632QArVVgbTXHWN6Qs=
=nZEf
-----END PGP SIGNATURE-----
Friendly ping.
On 1/27/19 12:18 AM, manphiz@gmail.com wrote:
> Hi,
>
> Trying to compile mutt,-gpgme but stuck on textproc/aspell/core build
> faliure due the following error:
>
> --------8<--------
> /usr/bin/ld: BFD 2.17 internal error, aborting at
> /usr/src/gnu/usr.bin/binutils-2.17/bfd/elfxx-mips.c line 4797 in
> mips_elf_create_dynamic_relocation
>
> /usr/bin/ld: Please report this bug.
>
> collect2: error: ld returned 1 exit status
> --------8<--------
>
> The full build log is also attached. Please advice on how to fix. Thanks.
>
Thursday, January 31, 2019
Re: sparc64 and C++ exceptions
On Fri, Feb 01, 2019 at 01:44:07AM +0000, Tinker wrote:
> On Friday, February 1, 2019 1:24 AM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
> >
> > > On 2019/01/31 01:12, Tinker wrote:
> > >
> > > > Reading your log file
> > > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > > , there is mentioning of libestdc++ in there.
> > >
> > > That doesn't use g++ from base though, only the ports version.
> > > I went through all C++ ports not on the direct path to building gcc
> > > and added a COMPILER line so they are built with ports gcc.
> >
> > Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> > building ports gcc on sparc64 with a diff that could fix things.
> > Specifically, the stack frames on OpenBSD are different compared to
> > other systems since we have stackghost.
> >
> > See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
> >
> > -Otto
>
> Wait, the system g++ uses one stack frame format and the ports eg++
> uses another one, this is how it is and has been for a long time?
No. You're jumping to conclusions.
-Otto
>
> If so no wonder that g++ and eg++ produced incompatible binaries.
>
> So right now you are doing the historic maneuver of making g++ and
> eg++-produced binaries compatible?
>
> Also how does LLVM play in here.
>
> Can you please confirm how it is?
>
> On Friday, February 1, 2019 1:24 AM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
> >
> > > On 2019/01/31 01:12, Tinker wrote:
> > >
> > > > Reading your log file
> > > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > > , there is mentioning of libestdc++ in there.
> > >
> > > That doesn't use g++ from base though, only the ports version.
> > > I went through all C++ ports not on the direct path to building gcc
> > > and added a COMPILER line so they are built with ports gcc.
> >
> > Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> > building ports gcc on sparc64 with a diff that could fix things.
> > Specifically, the stack frames on OpenBSD are different compared to
> > other systems since we have stackghost.
> >
> > See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
> >
> > -Otto
>
> Wait, the system g++ uses one stack frame format and the ports eg++
> uses another one, this is how it is and has been for a long time?
No. You're jumping to conclusions.
-Otto
>
> If so no wonder that g++ and eg++ produced incompatible binaries.
>
> So right now you are doing the historic maneuver of making g++ and
> eg++-produced binaries compatible?
>
> Also how does LLVM play in here.
>
> Can you please confirm how it is?
>
Re: sparc64 and C++ exceptions
On Fri, Feb 01, 2019 at 01:40:24AM +0000, Tinker wrote:
> On Thursday, January 31, 2019 2:00 PM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 01:12:10AM +0000, Tinker wrote:
> >
> > > Hi Otto and Jeremie,
> > > I think I have the answer to your particular question, and it's
> > > platform-independent:
> > > Reading your log file
> > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > , there is mentioning of libestdc++ in there.
> > > Please be aware that a program that links to both libstdc++ and
> > > libestdc++ will likely crash, and in my experience exception handling
> > > gone-haywire is a typical form of such a crash.
> >
> > That does not explain my simple test case I posted erlier, where
> > mixing of libs does not play a roll at all.
> >
> > -Otto
>
> Wait clarify, what exact test case?
>
Read a few posts back.
-Otto
> On Thursday, January 31, 2019 2:00 PM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 01:12:10AM +0000, Tinker wrote:
> >
> > > Hi Otto and Jeremie,
> > > I think I have the answer to your particular question, and it's
> > > platform-independent:
> > > Reading your log file
> > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > , there is mentioning of libestdc++ in there.
> > > Please be aware that a program that links to both libstdc++ and
> > > libestdc++ will likely crash, and in my experience exception handling
> > > gone-haywire is a typical form of such a crash.
> >
> > That does not explain my simple test case I posted erlier, where
> > mixing of libs does not play a roll at all.
> >
> > -Otto
>
> Wait clarify, what exact test case?
>
Read a few posts back.
-Otto
is pfsync loosing data on reboot?
Hi folks,
I have a question about pfsync protocol in a master-backup firewall
configuration (OpenBSD 6.3 and 6.4):
If I reboot (let's say) the backup host, will it receive the whole
set of state information again, when it gets back online?
Hopefully I am not too blind to see, but pfsync(4) doesn't tell.
Every helpful comment is highly appreciated.
Harri
I have a question about pfsync protocol in a master-backup firewall
configuration (OpenBSD 6.3 and 6.4):
If I reboot (let's say) the backup host, will it receive the whole
set of state information again, when it gets back online?
Hopefully I am not too blind to see, but pfsync(4) doesn't tell.
Every helpful comment is highly appreciated.
Harri
[UPDATE] textproc/unrtf =>0.21.10
Updated from 0.21.9 plus fixed formatting of Makefile and DESCR.
Also bumped automake version to 1.15.
Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/unrtf/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile 9 Apr 2016 20:14:49 -0000 1.16
+++ Makefile 1 Feb 2019 04:04:05 -0000
@@ -1,33 +1,33 @@
# $OpenBSD: Makefile,v 1.16 2016/04/09 20:14:49 naddy Exp $
-COMMENT= RTF document converter
+COMMENT = RTF document converter
-DISTNAME= unrtf-0.21.9
-CATEGORIES= textproc
+DISTNAME = unrtf-0.21.10
+CATEGORIES = textproc
-HOMEPAGE= https://www.gnu.org/software/unrtf/unrtf.html
+HOMEPAGE = https://www.gnu.org/software/unrtf/unrtf.html
-MASTER_SITES= ${MASTER_SITE_GNU:=unrtf/}
+MASTER_SITES = ${MASTER_SITE_GNU:=unrtf/}
# GPLv3+
-PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += c iconv
+WANTLIB += c iconv
-LIB_DEPENDS= converters/libiconv
+LIB_DEPENDS = converters/libiconv
-CONFIGURE_STYLE= gnu
+CONFIGURE_STYLE = gnu
-CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib -liconv"
+CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
+ LDFLAGS="-L${LOCALBASE}/lib -liconv"
# rm/bootstrap are only done because of symlinks to /usr/share/auto*
# in ${WRKSRC}/config for missing/etc.
#
-BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \
- ${MODGNU_AUTOMAKE_DEPENDS}
-AUTOCONF_VERSION= 2.69
-AUTOMAKE_VERSION= 1.13
+BUILD_DEPENDS = ${MODGNU_AUTOCONF_DEPENDS} \
+ ${MODGNU_AUTOMAKE_DEPENDS}
+AUTOCONF_VERSION = 2.69
+AUTOMAKE_VERSION = 1.15
post-patch:
rm ${WRKSRC}/config/*
Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/unrtf/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- distinfo 27 Apr 2015 18:20:47 -0000 1.6
+++ distinfo 1 Feb 2019 04:04:05 -0000
@@ -1,2 +1,2 @@
-SHA256 (unrtf-0.21.9.tar.gz) = IqN4JvltdU4zX7afgDbAaMAN0B7p7dlGGjbfAIX7jd0=
-SIZE (unrtf-0.21.9.tar.gz) = 828590
+SHA256 (unrtf-0.21.10.tar.gz) =
tJ8gIR+mn/+X1C1ueCpi1+LaZwsGSVHxS7/5aMk3NK4=
+SIZE (unrtf-0.21.10.tar.gz) = 812696
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/textproc/unrtf/pkg/DESCR,v
retrieving revision 1.2
diff -u -p -u -r1.2 DESCR
--- pkg/DESCR 15 Dec 2003 21:55:32 -0000 1.2
+++ pkg/DESCR 1 Feb 2019 04:04:05 -0000
@@ -1,2 +1,3 @@
-unrtf is an application to display and convert Rich Text Format files to
-HTML, LaTeX, PostScript, plaintext or plaintext with VT100 codes.
+unrtf is an application to display and convert Rich Text Format
+files to HTML, LaTeX, PostScript, plaintext or plaintext with VT100
+codes.
Also bumped automake version to 1.15.
Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/unrtf/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile 9 Apr 2016 20:14:49 -0000 1.16
+++ Makefile 1 Feb 2019 04:04:05 -0000
@@ -1,33 +1,33 @@
# $OpenBSD: Makefile,v 1.16 2016/04/09 20:14:49 naddy Exp $
-COMMENT= RTF document converter
+COMMENT = RTF document converter
-DISTNAME= unrtf-0.21.9
-CATEGORIES= textproc
+DISTNAME = unrtf-0.21.10
+CATEGORIES = textproc
-HOMEPAGE= https://www.gnu.org/software/unrtf/unrtf.html
+HOMEPAGE = https://www.gnu.org/software/unrtf/unrtf.html
-MASTER_SITES= ${MASTER_SITE_GNU:=unrtf/}
+MASTER_SITES = ${MASTER_SITE_GNU:=unrtf/}
# GPLv3+
-PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += c iconv
+WANTLIB += c iconv
-LIB_DEPENDS= converters/libiconv
+LIB_DEPENDS = converters/libiconv
-CONFIGURE_STYLE= gnu
+CONFIGURE_STYLE = gnu
-CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib -liconv"
+CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
+ LDFLAGS="-L${LOCALBASE}/lib -liconv"
# rm/bootstrap are only done because of symlinks to /usr/share/auto*
# in ${WRKSRC}/config for missing/etc.
#
-BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \
- ${MODGNU_AUTOMAKE_DEPENDS}
-AUTOCONF_VERSION= 2.69
-AUTOMAKE_VERSION= 1.13
+BUILD_DEPENDS = ${MODGNU_AUTOCONF_DEPENDS} \
+ ${MODGNU_AUTOMAKE_DEPENDS}
+AUTOCONF_VERSION = 2.69
+AUTOMAKE_VERSION = 1.15
post-patch:
rm ${WRKSRC}/config/*
Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/unrtf/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- distinfo 27 Apr 2015 18:20:47 -0000 1.6
+++ distinfo 1 Feb 2019 04:04:05 -0000
@@ -1,2 +1,2 @@
-SHA256 (unrtf-0.21.9.tar.gz) = IqN4JvltdU4zX7afgDbAaMAN0B7p7dlGGjbfAIX7jd0=
-SIZE (unrtf-0.21.9.tar.gz) = 828590
+SHA256 (unrtf-0.21.10.tar.gz) =
tJ8gIR+mn/+X1C1ueCpi1+LaZwsGSVHxS7/5aMk3NK4=
+SIZE (unrtf-0.21.10.tar.gz) = 812696
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/textproc/unrtf/pkg/DESCR,v
retrieving revision 1.2
diff -u -p -u -r1.2 DESCR
--- pkg/DESCR 15 Dec 2003 21:55:32 -0000 1.2
+++ pkg/DESCR 1 Feb 2019 04:04:05 -0000
@@ -1,2 +1,3 @@
-unrtf is an application to display and convert Rich Text Format files to
-HTML, LaTeX, PostScript, plaintext or plaintext with VT100 codes.
+unrtf is an application to display and convert Rich Text Format
+files to HTML, LaTeX, PostScript, plaintext or plaintext with VT100
+codes.
[UPDATE]mail/ruby-mini_mime =>1.0.1
Simple diff below.
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mini_mime/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 Makefile
--- Makefile 9 Aug 2018 22:39:51 -0000 1.1.1.1
+++ Makefile 1 Feb 2019 03:29:30 -0000
@@ -2,10 +2,10 @@
COMMENT= minimal mime type implementation
-DISTNAME= mini_mime-1.0.0
+DISTNAME= mini_mime-1.0.1
CATEGORIES= mail
-HOMEPAGE= https://github.com/discourse/mini_mime
+HOMEPAGE= https://github.com/discourse/mini_mime/
# MIT
PERMIT_PACKAGE_CDROM= Yes
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mini_mime/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 distinfo
--- distinfo 9 Aug 2018 22:39:51 -0000 1.1.1.1
+++ distinfo 1 Feb 2019 03:29:30 -0000
@@ -1,2 +1,2 @@
-SHA256 (mini_mime-1.0.0.gem) = iBXqSziAnEiOFB9r6lEo9fjkl05iE13HNNVhheWmkNM=
-SIZE (mini_mime-1.0.0.gem) = 32768
+SHA256 (mini_mime-1.0.1.gem) = oyWwx6AkJyCmJPRxSRgfOHO0+BZjyzRq2p8eNDDUl+A=
+SIZE (mini_mime-1.0.1.gem) = 33280
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mini_mime/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 Makefile
--- Makefile 9 Aug 2018 22:39:51 -0000 1.1.1.1
+++ Makefile 1 Feb 2019 03:29:30 -0000
@@ -2,10 +2,10 @@
COMMENT= minimal mime type implementation
-DISTNAME= mini_mime-1.0.0
+DISTNAME= mini_mime-1.0.1
CATEGORIES= mail
-HOMEPAGE= https://github.com/discourse/mini_mime
+HOMEPAGE= https://github.com/discourse/mini_mime/
# MIT
PERMIT_PACKAGE_CDROM= Yes
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mini_mime/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 distinfo
--- distinfo 9 Aug 2018 22:39:51 -0000 1.1.1.1
+++ distinfo 1 Feb 2019 03:29:30 -0000
@@ -1,2 +1,2 @@
-SHA256 (mini_mime-1.0.0.gem) = iBXqSziAnEiOFB9r6lEo9fjkl05iE13HNNVhheWmkNM=
-SIZE (mini_mime-1.0.0.gem) = 32768
+SHA256 (mini_mime-1.0.1.gem) = oyWwx6AkJyCmJPRxSRgfOHO0+BZjyzRq2p8eNDDUl+A=
+SIZE (mini_mime-1.0.1.gem) = 33280
[update] www/luakit to 2.1
Hello!
This diff does a few things:
- Bump epoch because upstream has actual releases now.
- Regen WANTLIB.
- Stop trying to run tests that don't exist.
- Fix MAKE_FLAGS and include html docs.
Tests fine for me on amd64. OK?
Cheers,
Aaron
diff --git a/www/luakit/Makefile b/www/luakit/Makefile
index 4f5da1da286..338d2365aa9 100644
--- a/www/luakit/Makefile
+++ b/www/luakit/Makefile
@@ -6,11 +6,10 @@ COMMENT = fast, small, webkit based browser written in lua
# Date of the most recent upstream commit.
GH_ACCOUNT = luakit
-GH_TAGNAME = 2017.08.10
+GH_TAGNAME = 2.1
GH_PROJECT = luakit
-REVISION = 0
-EPOCH = 0
+EPOCH = 1
CATEGORIES = www
@@ -29,11 +28,14 @@ WANTLIB += ${COMPILER_LIBCXX}
WANTLIB += atk-1.0 c cairo cairo-gobject gdk-3 gdk_pixbuf-2.0
WANTLIB += gio-2.0 glib-2.0 gobject-2.0 gthread-2.0 gtk-3 intl
WANTLIB += javascriptcoregtk-4.0 luajit-5.1 pango-1.0 pangocairo-1.0
-WANTLIB += pthread soup-2.4 sqlite3 webkit2gtk-4.0
+WANTLIB += soup-2.4 sqlite3 webkit2gtk-4.0
MODULES = lang/lua
-BUILD_DEPENDS = devel/help2man
+NO_TEST = Yes
+
+BUILD_DEPENDS = devel/help2man \
+ devel/luafs
RUN_DEPENDS = devel/desktop-file-utils \
devel/luafs \
@@ -47,11 +49,12 @@ RUN_DEPENDS += multimedia/gstreamer1/plugins-good \
multimedia/gstreamer1/plugins-libav
MAKE_FLAGS += LUA_BIN_NAME=${MODLUA_BIN} \
- MANPREFIX=${DESTDIR}/${PREFIX}/man \
- PIXMAPDIR=${DESTDIR}/${PREFIX}/share/pixmaps/ \
- APPDIR=${DESTDIR}/${PREFIX}/share/applications/ \
+ XDGPREFIX=${PREFIX}/share/examples \
+ DOCDIR=${PREFIX}/share/doc/luakit \
+ MANPREFIX=${PREFIX}/man \
+ PIXMAPDIR=${PREFIX}/share/pixmaps/ \
+ APPDIR=${PREFIX}/share/applications/ \
PREFIX=${PREFIX} \
- XDGPREFIX=${DESTDIR}/${PREFIX}/share/examples/ \
DEVELOPMENT_PATHS=0
.include <bsd.port.mk>
diff --git a/www/luakit/distinfo b/www/luakit/distinfo
index 2e264a77bce..d6d192e0ee5 100644
--- a/www/luakit/distinfo
+++ b/www/luakit/distinfo
@@ -1,2 +1,2 @@
-SHA256 (luakit-2017.08.10.tar.gz) = I9mLa1G2bIW2gjzSh+Fh4Qk7gGOfBvHamwpykLCFnTc=
-SIZE (luakit-2017.08.10.tar.gz) = 399564
+SHA256 (luakit-2.1.tar.gz) = 7L+iMxZxL0RHFDh7L/2EZibatuQLRE0970R1wUXVbyY=
+SIZE (luakit-2.1.tar.gz) = 485605
diff --git a/www/luakit/patches/patch-Makefile b/www/luakit/patches/patch-Makefile
index dda67d82dcc..631c2a7c79d 100644
--- a/www/luakit/patches/patch-Makefile
+++ b/www/luakit/patches/patch-Makefile
@@ -2,16 +2,7 @@ $OpenBSD: patch-Makefile,v 1.3 2017/07/26 14:19:45 abieber Exp $
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -17,7 +17,7 @@ EXT_OBJS = $(foreach obj,$(EXT_SRCS:.c=.o),$(obj))
- # Must be kept in sync with doc/docgen.ld
- DOC_SRCS = $(filter-out lib/markdown.lua,$(shell for d in doc/luadoc lib common/clib; do find $$d -type f; done)) tests/lib.lua
-
--all: options newline luakit luakit.1.gz luakit.so apidoc
-+all: options newline luakit luakit.1 luakit.so
-
- options:
- @echo luakit build options:
-@@ -50,21 +50,21 @@ buildopts.h: buildopts.h.in
+@@ -56,21 +56,21 @@ buildopts.h: buildopts.h.in
$(filter-out $(EXT_OBJS),$(OBJS)) $(EXT_OBJS): $(HEADS) config.mk
$(filter-out $(EXT_OBJS),$(OBJS)) : %.o : %.c
@@ -33,40 +24,16 @@ Index: Makefile
luakit.so: $(EXT_OBJS)
- @echo $(CC) -o $@ $(EXT_OBJS)
-+ @echo $(CC) -o $@ $(EXT_OBJS) $(LDFLAGS)
++ @echo $(CC) -o $@ $(EXT_OBJS) -shared $(LDFLAGS)
@$(CC) -o $@ $(EXT_OBJS) -shared $(LDFLAGS)
luakit.1: luakit.1.in
-@@ -86,16 +86,12 @@ doc: buildopts.h $(THEAD) $(TSRC)
- doxygen -s doc/luakit.doxygen
-
- clean:
-- rm -rf doc/apidocs doc/html luakit $(OBJS) $(EXT_OBJS) $(TSRC) $(THEAD) buildopts.h luakit.1 luakit.1.gz luakit.so
-+ rm -rf doc/html luakit $(OBJS) $(EXT_OBJS) $(TSRC) $(THEAD) buildopts.h luakit.1 luakit.1.gz luakit.so
-
- install: all
- install -d $(INSTALLDIR)/share/luakit/
- install -d $(DOCDIR) $(DOCDIR)/classes $(DOCDIR)/modules $(DOCDIR)/pages
- install -m644 README.md AUTHORS COPYING.GPLv3 $(DOCDIR)
-- install -m644 doc/apidocs/classes/* $(DOCDIR)/classes
-- install -m644 doc/apidocs/modules/* $(DOCDIR)/modules
-- install -m644 doc/apidocs/pages/* $(DOCDIR)/pages
-- install -m644 doc/apidocs/*.html $(DOCDIR)
- install -d $(INSTALLDIR)/share/luakit/lib $(INSTALLDIR)/share/luakit/lib/lousy $(INSTALLDIR)/share/luakit/lib/lousy/widget
- install -m644 lib/*.* $(INSTALLDIR)/share/luakit/lib
- install -m644 lib/lousy/*.* $(INSTALLDIR)/share/luakit/lib/lousy
-@@ -110,7 +106,7 @@ install: all
- install -d $(APPDIR)
- install -m644 extras/luakit.desktop $(APPDIR)
- install -d $(MANPREFIX)/man1/
-- install -m644 luakit.1.gz $(MANPREFIX)/man1/
-+ install -m644 luakit.1 $(MANPREFIX)/man1/
+@@ -115,7 +115,7 @@ install: all
+ install -d $(DESTDIR)$(APPDIR)
+ install -m644 extras/luakit.desktop $(DESTDIR)$(APPDIR)
+ install -d $(DESTDIR)$(MANPREFIX)/man1/
+- install -m644 luakit.1.gz $(DESTDIR)$(MANPREFIX)/man1/
++ install -m644 luakit.1 $(DESTDIR)$(MANPREFIX)/man1/
mkdir -p resources
- find resources -type d -exec install -d $(INSTALLDIR)/share/luakit/'{}' \;
- find resources -type f -exec sh -c 'f="{}"; install -m644 "$$f" "$(INSTALLDIR)/share/luakit/$$(dirname $$f)"' \;
-@@ -127,4 +123,4 @@ run-tests: luakit luakit.so tests/util.so
- @$(LUA_BIN_NAME) tests/run_test.lua
-
- newline: options;@echo
--.PHONY: all clean options install newline apidoc doc default
-+.PHONY: all clean options install newline doc default
+ find resources -type d -exec install -d $(DESTDIR)$(PREFIX)/share/luakit/'{}' \;
+ find resources -type f -exec sh -c 'f="{}"; install -m644 "$$f" "$(DESTDIR)$(PREFIX)/share/luakit/$$(dirname $$f)"' \;
diff --git a/www/luakit/patches/patch-config_globals_lua b/www/luakit/patches/patch-config_globals_lua
deleted file mode 100644
index 58153ec6c9c..00000000000
--- a/www/luakit/patches/patch-config_globals_lua
+++ /dev/null
@@ -1,14 +0,0 @@
-$OpenBSD: patch-config_globals_lua,v 1.1 2017/08/12 19:28:43 abieber Exp $
-
-Index: config/globals.lua
---- config/globals.lua.orig
-+++ config/globals.lua
-@@ -31,7 +31,7 @@ globals.search_engines = {
- }
-
- -- Set google as fallback search engine
--globals.search_engines.default = globals.search_engines.google
-+globals.search_engines.default = globals.search_engines.duckduckgo
- -- Use this instead to disable auto-searching
- --search_engines.default = "%s"
-
diff --git a/www/luakit/pkg/PLIST b/www/luakit/pkg/PLIST
index c9c1d6f0ee3..b09964a217e 100644
--- a/www/luakit/pkg/PLIST
+++ b/www/luakit/pkg/PLIST
@@ -1,35 +1,144 @@
@comment $OpenBSD: PLIST,v 1.6 2018/06/27 21:04:05 espie Exp $
@bin bin/luakit
+lib/luakit/
+lib/luakit/luakit.so
@man man/man1/luakit.1
share/applications/luakit.desktop
+share/doc/luakit/
+share/doc/luakit/AUTHORS
+share/doc/luakit/COPYING.GPLv3
+share/doc/luakit/README.md
+share/doc/luakit/classes/
+share/doc/luakit/classes/dom_document.html
+share/doc/luakit/classes/dom_element.html
+share/doc/luakit/classes/download.html
+share/doc/luakit/classes/page.html
+share/doc/luakit/classes/regex.html
+share/doc/luakit/classes/sqlite3.html
+share/doc/luakit/classes/stylesheet.html
+share/doc/luakit/classes/timer.html
+share/doc/luakit/classes/widget.html
+share/doc/luakit/classes/widget:box.html
+share/doc/luakit/classes/widget:drawing_area.html
+share/doc/luakit/classes/widget:entry.html
+share/doc/luakit/classes/widget:event_box.html
+share/doc/luakit/classes/widget:image.html
+share/doc/luakit/classes/widget:label.html
+share/doc/luakit/classes/widget:notebook.html
+share/doc/luakit/classes/widget:overlay.html
+share/doc/luakit/classes/widget:paned.html
+share/doc/luakit/classes/widget:scrolled.html
+share/doc/luakit/classes/widget:socket.html
+share/doc/luakit/classes/widget:spinner.html
+share/doc/luakit/classes/widget:webview.html
+share/doc/luakit/classes/widget:window.html
+share/doc/luakit/index.html
+share/doc/luakit/modules/
+share/doc/luakit/modules/adblock.html
+share/doc/luakit/modules/adblock_chrome.html
+share/doc/luakit/modules/binds.html
+share/doc/luakit/modules/binds_chrome.html
+share/doc/luakit/modules/bookmarks.html
+share/doc/luakit/modules/bookmarks_chrome.html
+share/doc/luakit/modules/chrome.html
+share/doc/luakit/modules/cmdhist.html
+share/doc/luakit/modules/completion.html
+share/doc/luakit/modules/domain_props.html
+share/doc/luakit/modules/downloads.html
+share/doc/luakit/modules/downloads_chrome.html
+share/doc/luakit/modules/editor.html
+share/doc/luakit/modules/error_page.html
+share/doc/luakit/modules/follow.html
+share/doc/luakit/modules/follow_selected.html
+share/doc/luakit/modules/formfiller.html
+share/doc/luakit/modules/go_input.html
+share/doc/luakit/modules/go_next_prev.html
+share/doc/luakit/modules/go_up.html
+share/doc/luakit/modules/help_chrome.html
+share/doc/luakit/modules/hide_scrollbars.html
+share/doc/luakit/modules/history.html
+share/doc/luakit/modules/history_chrome.html
+share/doc/luakit/modules/image_css.html
+share/doc/luakit/modules/introspector_chrome.html
+share/doc/luakit/modules/ipc.html
+share/doc/luakit/modules/keysym.html
+share/doc/luakit/modules/log_chrome.html
+share/doc/luakit/modules/lousy.bind.html
+share/doc/luakit/modules/lousy.load.html
+share/doc/luakit/modules/lousy.mode.html
+share/doc/luakit/modules/lousy.pickle.html
+share/doc/luakit/modules/lousy.signal.html
+share/doc/luakit/modules/lousy.theme.html
+share/doc/luakit/modules/lousy.uri.html
+share/doc/luakit/modules/lousy.util.html
+share/doc/luakit/modules/lousy.widget.buf.html
+share/doc/luakit/modules/lousy.widget.common.html
+share/doc/luakit/modules/lousy.widget.hist.html
+share/doc/luakit/modules/lousy.widget.html
+share/doc/luakit/modules/lousy.widget.menu.html
+share/doc/luakit/modules/lousy.widget.progress.html
+share/doc/luakit/modules/lousy.widget.scroll.html
+share/doc/luakit/modules/lousy.widget.ssl.html
+share/doc/luakit/modules/lousy.widget.tab.html
+share/doc/luakit/modules/lousy.widget.tabi.html
+share/doc/luakit/modules/lousy.widget.tablist.html
+share/doc/luakit/modules/lousy.widget.uri.html
+share/doc/luakit/modules/lousy.widget.zoom.html
+share/doc/luakit/modules/luakit.html
+share/doc/luakit/modules/luakit.unique.html
+share/doc/luakit/modules/modes.html
+share/doc/luakit/modules/msg.html
+share/doc/luakit/modules/newtab_chrome.html
+share/doc/luakit/modules/noscript.html
+share/doc/luakit/modules/open_editor.html
+share/doc/luakit/modules/proxy.html
+share/doc/luakit/modules/quickmarks.html
+share/doc/luakit/modules/readline.html
+share/doc/luakit/modules/referer_control_wm.html
+share/doc/luakit/modules/search.html
+share/doc/luakit/modules/select.html
+share/doc/luakit/modules/select_wm.html
+share/doc/luakit/modules/session.html
+share/doc/luakit/modules/settings.html
+share/doc/luakit/modules/settings_chrome.html
+share/doc/luakit/modules/soup.html
+share/doc/luakit/modules/styles.html
+share/doc/luakit/modules/tab_favicons.html
+share/doc/luakit/modules/tabhistory.html
+share/doc/luakit/modules/taborder.html
+share/doc/luakit/modules/tests.lib.html
+share/doc/luakit/modules/undoclose.html
+share/doc/luakit/modules/unique_instance.html
+share/doc/luakit/modules/userscripts.html
+share/doc/luakit/modules/utf8.html
+share/doc/luakit/modules/vertical_tabs.html
+share/doc/luakit/modules/view_source.html
+share/doc/luakit/modules/viewpdf.html
+share/doc/luakit/modules/webinspector.html
+share/doc/luakit/modules/webview.html
+share/doc/luakit/modules/window.html
+share/doc/luakit/modules/xdg.html
+share/doc/luakit/pages/
+share/doc/luakit/pages/01-authors.html
+share/doc/luakit/pages/02-faq.html
+share/doc/luakit/pages/03-quick-start-guide.html
+share/doc/luakit/pages/04-migration-guide.html
+share/doc/luakit/pages/05-configuration.html
+share/doc/luakit/pages/06-tests.html
+share/doc/luakit/pages/07-build-debian-package.html
share/examples/luakit/
-@sample ${SYSCONFDIR}/xdg/
@sample ${SYSCONFDIR}/xdg/luakit/
-share/examples/luakit/globals.lua
-@sample ${SYSCONFDIR}/xdg/luakit/globals.lua
share/examples/luakit/rc.lua
@sample ${SYSCONFDIR}/xdg/luakit/rc.lua
share/examples/luakit/theme.lua
@sample ${SYSCONFDIR}/xdg/luakit/theme.lua
-share/examples/luakit/webview.lua
-@sample ${SYSCONFDIR}/xdg/luakit/webview.lua
-share/examples/luakit/webview_wm.lua
-@sample ${SYSCONFDIR}/xdg/luakit/webview_wm.lua
-share/examples/luakit/window.lua
-@sample ${SYSCONFDIR}/xdg/luakit/window.lua
share/luakit/
-share/luakit/doc/
-share/luakit/doc/AUTHORS
-share/luakit/doc/COPYING.GPLv3
-share/luakit/doc/README.md
-share/luakit/doc/classes/
-share/luakit/doc/modules/
-share/luakit/doc/pages/
share/luakit/lib/
share/luakit/lib/adblock.lua
share/luakit/lib/adblock_chrome.lua
share/luakit/lib/adblock_wm.lua
share/luakit/lib/binds.lua
+share/luakit/lib/binds_chrome.lua
share/luakit/lib/bookmarks.lua
share/luakit/lib/bookmarks_chrome.lua
share/luakit/lib/chrome.lua
@@ -58,7 +167,7 @@ share/luakit/lib/history_chrome.lua
share/luakit/lib/image_css.lua
share/luakit/lib/image_css_wm.lua
share/luakit/lib/introspector_chrome.lua
-share/luakit/lib/jquery.min.js
+share/luakit/lib/keysym.lua
share/luakit/lib/log_chrome.lua
share/luakit/lib/lousy/
share/luakit/lib/lousy/bind.lua
@@ -91,22 +200,28 @@ share/luakit/lib/noscript.lua
share/luakit/lib/open_editor.lua
share/luakit/lib/proxy.lua
share/luakit/lib/quickmarks.lua
+share/luakit/lib/readline.lua
share/luakit/lib/referer_control_wm.lua
share/luakit/lib/search.lua
share/luakit/lib/select.lua
share/luakit/lib/select_wm.lua
share/luakit/lib/session.lua
+share/luakit/lib/settings.lua
+share/luakit/lib/settings_chrome.lua
share/luakit/lib/styles.lua
share/luakit/lib/tab_favicons.lua
share/luakit/lib/tabhistory.lua
share/luakit/lib/taborder.lua
share/luakit/lib/undoclose.lua
+share/luakit/lib/unique_instance.lua
share/luakit/lib/userscripts.lua
share/luakit/lib/vertical_tabs.lua
share/luakit/lib/view_source.lua
share/luakit/lib/viewpdf.lua
share/luakit/lib/webinspector.lua
-share/luakit/luakit.so
+share/luakit/lib/webview.lua
+share/luakit/lib/webview_wm.lua
+share/luakit/lib/window.lua
share/luakit/resources/
share/luakit/resources/icons/
share/luakit/resources/icons/COPYING
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
This diff does a few things:
- Bump epoch because upstream has actual releases now.
- Regen WANTLIB.
- Stop trying to run tests that don't exist.
- Fix MAKE_FLAGS and include html docs.
Tests fine for me on amd64. OK?
Cheers,
Aaron
diff --git a/www/luakit/Makefile b/www/luakit/Makefile
index 4f5da1da286..338d2365aa9 100644
--- a/www/luakit/Makefile
+++ b/www/luakit/Makefile
@@ -6,11 +6,10 @@ COMMENT = fast, small, webkit based browser written in lua
# Date of the most recent upstream commit.
GH_ACCOUNT = luakit
-GH_TAGNAME = 2017.08.10
+GH_TAGNAME = 2.1
GH_PROJECT = luakit
-REVISION = 0
-EPOCH = 0
+EPOCH = 1
CATEGORIES = www
@@ -29,11 +28,14 @@ WANTLIB += ${COMPILER_LIBCXX}
WANTLIB += atk-1.0 c cairo cairo-gobject gdk-3 gdk_pixbuf-2.0
WANTLIB += gio-2.0 glib-2.0 gobject-2.0 gthread-2.0 gtk-3 intl
WANTLIB += javascriptcoregtk-4.0 luajit-5.1 pango-1.0 pangocairo-1.0
-WANTLIB += pthread soup-2.4 sqlite3 webkit2gtk-4.0
+WANTLIB += soup-2.4 sqlite3 webkit2gtk-4.0
MODULES = lang/lua
-BUILD_DEPENDS = devel/help2man
+NO_TEST = Yes
+
+BUILD_DEPENDS = devel/help2man \
+ devel/luafs
RUN_DEPENDS = devel/desktop-file-utils \
devel/luafs \
@@ -47,11 +49,12 @@ RUN_DEPENDS += multimedia/gstreamer1/plugins-good \
multimedia/gstreamer1/plugins-libav
MAKE_FLAGS += LUA_BIN_NAME=${MODLUA_BIN} \
- MANPREFIX=${DESTDIR}/${PREFIX}/man \
- PIXMAPDIR=${DESTDIR}/${PREFIX}/share/pixmaps/ \
- APPDIR=${DESTDIR}/${PREFIX}/share/applications/ \
+ XDGPREFIX=${PREFIX}/share/examples \
+ DOCDIR=${PREFIX}/share/doc/luakit \
+ MANPREFIX=${PREFIX}/man \
+ PIXMAPDIR=${PREFIX}/share/pixmaps/ \
+ APPDIR=${PREFIX}/share/applications/ \
PREFIX=${PREFIX} \
- XDGPREFIX=${DESTDIR}/${PREFIX}/share/examples/ \
DEVELOPMENT_PATHS=0
.include <bsd.port.mk>
diff --git a/www/luakit/distinfo b/www/luakit/distinfo
index 2e264a77bce..d6d192e0ee5 100644
--- a/www/luakit/distinfo
+++ b/www/luakit/distinfo
@@ -1,2 +1,2 @@
-SHA256 (luakit-2017.08.10.tar.gz) = I9mLa1G2bIW2gjzSh+Fh4Qk7gGOfBvHamwpykLCFnTc=
-SIZE (luakit-2017.08.10.tar.gz) = 399564
+SHA256 (luakit-2.1.tar.gz) = 7L+iMxZxL0RHFDh7L/2EZibatuQLRE0970R1wUXVbyY=
+SIZE (luakit-2.1.tar.gz) = 485605
diff --git a/www/luakit/patches/patch-Makefile b/www/luakit/patches/patch-Makefile
index dda67d82dcc..631c2a7c79d 100644
--- a/www/luakit/patches/patch-Makefile
+++ b/www/luakit/patches/patch-Makefile
@@ -2,16 +2,7 @@ $OpenBSD: patch-Makefile,v 1.3 2017/07/26 14:19:45 abieber Exp $
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -17,7 +17,7 @@ EXT_OBJS = $(foreach obj,$(EXT_SRCS:.c=.o),$(obj))
- # Must be kept in sync with doc/docgen.ld
- DOC_SRCS = $(filter-out lib/markdown.lua,$(shell for d in doc/luadoc lib common/clib; do find $$d -type f; done)) tests/lib.lua
-
--all: options newline luakit luakit.1.gz luakit.so apidoc
-+all: options newline luakit luakit.1 luakit.so
-
- options:
- @echo luakit build options:
-@@ -50,21 +50,21 @@ buildopts.h: buildopts.h.in
+@@ -56,21 +56,21 @@ buildopts.h: buildopts.h.in
$(filter-out $(EXT_OBJS),$(OBJS)) $(EXT_OBJS): $(HEADS) config.mk
$(filter-out $(EXT_OBJS),$(OBJS)) : %.o : %.c
@@ -33,40 +24,16 @@ Index: Makefile
luakit.so: $(EXT_OBJS)
- @echo $(CC) -o $@ $(EXT_OBJS)
-+ @echo $(CC) -o $@ $(EXT_OBJS) $(LDFLAGS)
++ @echo $(CC) -o $@ $(EXT_OBJS) -shared $(LDFLAGS)
@$(CC) -o $@ $(EXT_OBJS) -shared $(LDFLAGS)
luakit.1: luakit.1.in
-@@ -86,16 +86,12 @@ doc: buildopts.h $(THEAD) $(TSRC)
- doxygen -s doc/luakit.doxygen
-
- clean:
-- rm -rf doc/apidocs doc/html luakit $(OBJS) $(EXT_OBJS) $(TSRC) $(THEAD) buildopts.h luakit.1 luakit.1.gz luakit.so
-+ rm -rf doc/html luakit $(OBJS) $(EXT_OBJS) $(TSRC) $(THEAD) buildopts.h luakit.1 luakit.1.gz luakit.so
-
- install: all
- install -d $(INSTALLDIR)/share/luakit/
- install -d $(DOCDIR) $(DOCDIR)/classes $(DOCDIR)/modules $(DOCDIR)/pages
- install -m644 README.md AUTHORS COPYING.GPLv3 $(DOCDIR)
-- install -m644 doc/apidocs/classes/* $(DOCDIR)/classes
-- install -m644 doc/apidocs/modules/* $(DOCDIR)/modules
-- install -m644 doc/apidocs/pages/* $(DOCDIR)/pages
-- install -m644 doc/apidocs/*.html $(DOCDIR)
- install -d $(INSTALLDIR)/share/luakit/lib $(INSTALLDIR)/share/luakit/lib/lousy $(INSTALLDIR)/share/luakit/lib/lousy/widget
- install -m644 lib/*.* $(INSTALLDIR)/share/luakit/lib
- install -m644 lib/lousy/*.* $(INSTALLDIR)/share/luakit/lib/lousy
-@@ -110,7 +106,7 @@ install: all
- install -d $(APPDIR)
- install -m644 extras/luakit.desktop $(APPDIR)
- install -d $(MANPREFIX)/man1/
-- install -m644 luakit.1.gz $(MANPREFIX)/man1/
-+ install -m644 luakit.1 $(MANPREFIX)/man1/
+@@ -115,7 +115,7 @@ install: all
+ install -d $(DESTDIR)$(APPDIR)
+ install -m644 extras/luakit.desktop $(DESTDIR)$(APPDIR)
+ install -d $(DESTDIR)$(MANPREFIX)/man1/
+- install -m644 luakit.1.gz $(DESTDIR)$(MANPREFIX)/man1/
++ install -m644 luakit.1 $(DESTDIR)$(MANPREFIX)/man1/
mkdir -p resources
- find resources -type d -exec install -d $(INSTALLDIR)/share/luakit/'{}' \;
- find resources -type f -exec sh -c 'f="{}"; install -m644 "$$f" "$(INSTALLDIR)/share/luakit/$$(dirname $$f)"' \;
-@@ -127,4 +123,4 @@ run-tests: luakit luakit.so tests/util.so
- @$(LUA_BIN_NAME) tests/run_test.lua
-
- newline: options;@echo
--.PHONY: all clean options install newline apidoc doc default
-+.PHONY: all clean options install newline doc default
+ find resources -type d -exec install -d $(DESTDIR)$(PREFIX)/share/luakit/'{}' \;
+ find resources -type f -exec sh -c 'f="{}"; install -m644 "$$f" "$(DESTDIR)$(PREFIX)/share/luakit/$$(dirname $$f)"' \;
diff --git a/www/luakit/patches/patch-config_globals_lua b/www/luakit/patches/patch-config_globals_lua
deleted file mode 100644
index 58153ec6c9c..00000000000
--- a/www/luakit/patches/patch-config_globals_lua
+++ /dev/null
@@ -1,14 +0,0 @@
-$OpenBSD: patch-config_globals_lua,v 1.1 2017/08/12 19:28:43 abieber Exp $
-
-Index: config/globals.lua
---- config/globals.lua.orig
-+++ config/globals.lua
-@@ -31,7 +31,7 @@ globals.search_engines = {
- }
-
- -- Set google as fallback search engine
--globals.search_engines.default = globals.search_engines.google
-+globals.search_engines.default = globals.search_engines.duckduckgo
- -- Use this instead to disable auto-searching
- --search_engines.default = "%s"
-
diff --git a/www/luakit/pkg/PLIST b/www/luakit/pkg/PLIST
index c9c1d6f0ee3..b09964a217e 100644
--- a/www/luakit/pkg/PLIST
+++ b/www/luakit/pkg/PLIST
@@ -1,35 +1,144 @@
@comment $OpenBSD: PLIST,v 1.6 2018/06/27 21:04:05 espie Exp $
@bin bin/luakit
+lib/luakit/
+lib/luakit/luakit.so
@man man/man1/luakit.1
share/applications/luakit.desktop
+share/doc/luakit/
+share/doc/luakit/AUTHORS
+share/doc/luakit/COPYING.GPLv3
+share/doc/luakit/README.md
+share/doc/luakit/classes/
+share/doc/luakit/classes/dom_document.html
+share/doc/luakit/classes/dom_element.html
+share/doc/luakit/classes/download.html
+share/doc/luakit/classes/page.html
+share/doc/luakit/classes/regex.html
+share/doc/luakit/classes/sqlite3.html
+share/doc/luakit/classes/stylesheet.html
+share/doc/luakit/classes/timer.html
+share/doc/luakit/classes/widget.html
+share/doc/luakit/classes/widget:box.html
+share/doc/luakit/classes/widget:drawing_area.html
+share/doc/luakit/classes/widget:entry.html
+share/doc/luakit/classes/widget:event_box.html
+share/doc/luakit/classes/widget:image.html
+share/doc/luakit/classes/widget:label.html
+share/doc/luakit/classes/widget:notebook.html
+share/doc/luakit/classes/widget:overlay.html
+share/doc/luakit/classes/widget:paned.html
+share/doc/luakit/classes/widget:scrolled.html
+share/doc/luakit/classes/widget:socket.html
+share/doc/luakit/classes/widget:spinner.html
+share/doc/luakit/classes/widget:webview.html
+share/doc/luakit/classes/widget:window.html
+share/doc/luakit/index.html
+share/doc/luakit/modules/
+share/doc/luakit/modules/adblock.html
+share/doc/luakit/modules/adblock_chrome.html
+share/doc/luakit/modules/binds.html
+share/doc/luakit/modules/binds_chrome.html
+share/doc/luakit/modules/bookmarks.html
+share/doc/luakit/modules/bookmarks_chrome.html
+share/doc/luakit/modules/chrome.html
+share/doc/luakit/modules/cmdhist.html
+share/doc/luakit/modules/completion.html
+share/doc/luakit/modules/domain_props.html
+share/doc/luakit/modules/downloads.html
+share/doc/luakit/modules/downloads_chrome.html
+share/doc/luakit/modules/editor.html
+share/doc/luakit/modules/error_page.html
+share/doc/luakit/modules/follow.html
+share/doc/luakit/modules/follow_selected.html
+share/doc/luakit/modules/formfiller.html
+share/doc/luakit/modules/go_input.html
+share/doc/luakit/modules/go_next_prev.html
+share/doc/luakit/modules/go_up.html
+share/doc/luakit/modules/help_chrome.html
+share/doc/luakit/modules/hide_scrollbars.html
+share/doc/luakit/modules/history.html
+share/doc/luakit/modules/history_chrome.html
+share/doc/luakit/modules/image_css.html
+share/doc/luakit/modules/introspector_chrome.html
+share/doc/luakit/modules/ipc.html
+share/doc/luakit/modules/keysym.html
+share/doc/luakit/modules/log_chrome.html
+share/doc/luakit/modules/lousy.bind.html
+share/doc/luakit/modules/lousy.load.html
+share/doc/luakit/modules/lousy.mode.html
+share/doc/luakit/modules/lousy.pickle.html
+share/doc/luakit/modules/lousy.signal.html
+share/doc/luakit/modules/lousy.theme.html
+share/doc/luakit/modules/lousy.uri.html
+share/doc/luakit/modules/lousy.util.html
+share/doc/luakit/modules/lousy.widget.buf.html
+share/doc/luakit/modules/lousy.widget.common.html
+share/doc/luakit/modules/lousy.widget.hist.html
+share/doc/luakit/modules/lousy.widget.html
+share/doc/luakit/modules/lousy.widget.menu.html
+share/doc/luakit/modules/lousy.widget.progress.html
+share/doc/luakit/modules/lousy.widget.scroll.html
+share/doc/luakit/modules/lousy.widget.ssl.html
+share/doc/luakit/modules/lousy.widget.tab.html
+share/doc/luakit/modules/lousy.widget.tabi.html
+share/doc/luakit/modules/lousy.widget.tablist.html
+share/doc/luakit/modules/lousy.widget.uri.html
+share/doc/luakit/modules/lousy.widget.zoom.html
+share/doc/luakit/modules/luakit.html
+share/doc/luakit/modules/luakit.unique.html
+share/doc/luakit/modules/modes.html
+share/doc/luakit/modules/msg.html
+share/doc/luakit/modules/newtab_chrome.html
+share/doc/luakit/modules/noscript.html
+share/doc/luakit/modules/open_editor.html
+share/doc/luakit/modules/proxy.html
+share/doc/luakit/modules/quickmarks.html
+share/doc/luakit/modules/readline.html
+share/doc/luakit/modules/referer_control_wm.html
+share/doc/luakit/modules/search.html
+share/doc/luakit/modules/select.html
+share/doc/luakit/modules/select_wm.html
+share/doc/luakit/modules/session.html
+share/doc/luakit/modules/settings.html
+share/doc/luakit/modules/settings_chrome.html
+share/doc/luakit/modules/soup.html
+share/doc/luakit/modules/styles.html
+share/doc/luakit/modules/tab_favicons.html
+share/doc/luakit/modules/tabhistory.html
+share/doc/luakit/modules/taborder.html
+share/doc/luakit/modules/tests.lib.html
+share/doc/luakit/modules/undoclose.html
+share/doc/luakit/modules/unique_instance.html
+share/doc/luakit/modules/userscripts.html
+share/doc/luakit/modules/utf8.html
+share/doc/luakit/modules/vertical_tabs.html
+share/doc/luakit/modules/view_source.html
+share/doc/luakit/modules/viewpdf.html
+share/doc/luakit/modules/webinspector.html
+share/doc/luakit/modules/webview.html
+share/doc/luakit/modules/window.html
+share/doc/luakit/modules/xdg.html
+share/doc/luakit/pages/
+share/doc/luakit/pages/01-authors.html
+share/doc/luakit/pages/02-faq.html
+share/doc/luakit/pages/03-quick-start-guide.html
+share/doc/luakit/pages/04-migration-guide.html
+share/doc/luakit/pages/05-configuration.html
+share/doc/luakit/pages/06-tests.html
+share/doc/luakit/pages/07-build-debian-package.html
share/examples/luakit/
-@sample ${SYSCONFDIR}/xdg/
@sample ${SYSCONFDIR}/xdg/luakit/
-share/examples/luakit/globals.lua
-@sample ${SYSCONFDIR}/xdg/luakit/globals.lua
share/examples/luakit/rc.lua
@sample ${SYSCONFDIR}/xdg/luakit/rc.lua
share/examples/luakit/theme.lua
@sample ${SYSCONFDIR}/xdg/luakit/theme.lua
-share/examples/luakit/webview.lua
-@sample ${SYSCONFDIR}/xdg/luakit/webview.lua
-share/examples/luakit/webview_wm.lua
-@sample ${SYSCONFDIR}/xdg/luakit/webview_wm.lua
-share/examples/luakit/window.lua
-@sample ${SYSCONFDIR}/xdg/luakit/window.lua
share/luakit/
-share/luakit/doc/
-share/luakit/doc/AUTHORS
-share/luakit/doc/COPYING.GPLv3
-share/luakit/doc/README.md
-share/luakit/doc/classes/
-share/luakit/doc/modules/
-share/luakit/doc/pages/
share/luakit/lib/
share/luakit/lib/adblock.lua
share/luakit/lib/adblock_chrome.lua
share/luakit/lib/adblock_wm.lua
share/luakit/lib/binds.lua
+share/luakit/lib/binds_chrome.lua
share/luakit/lib/bookmarks.lua
share/luakit/lib/bookmarks_chrome.lua
share/luakit/lib/chrome.lua
@@ -58,7 +167,7 @@ share/luakit/lib/history_chrome.lua
share/luakit/lib/image_css.lua
share/luakit/lib/image_css_wm.lua
share/luakit/lib/introspector_chrome.lua
-share/luakit/lib/jquery.min.js
+share/luakit/lib/keysym.lua
share/luakit/lib/log_chrome.lua
share/luakit/lib/lousy/
share/luakit/lib/lousy/bind.lua
@@ -91,22 +200,28 @@ share/luakit/lib/noscript.lua
share/luakit/lib/open_editor.lua
share/luakit/lib/proxy.lua
share/luakit/lib/quickmarks.lua
+share/luakit/lib/readline.lua
share/luakit/lib/referer_control_wm.lua
share/luakit/lib/search.lua
share/luakit/lib/select.lua
share/luakit/lib/select_wm.lua
share/luakit/lib/session.lua
+share/luakit/lib/settings.lua
+share/luakit/lib/settings_chrome.lua
share/luakit/lib/styles.lua
share/luakit/lib/tab_favicons.lua
share/luakit/lib/tabhistory.lua
share/luakit/lib/taborder.lua
share/luakit/lib/undoclose.lua
+share/luakit/lib/unique_instance.lua
share/luakit/lib/userscripts.lua
share/luakit/lib/vertical_tabs.lua
share/luakit/lib/view_source.lua
share/luakit/lib/viewpdf.lua
share/luakit/lib/webinspector.lua
-share/luakit/luakit.so
+share/luakit/lib/webview.lua
+share/luakit/lib/webview_wm.lua
+share/luakit/lib/window.lua
share/luakit/resources/
share/luakit/resources/icons/
share/luakit/resources/icons/COPYING
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: sparc64 and C++ exceptions
Tinker <t1nkr@protonmail.ch> wrote:
> On Friday, February 1, 2019 1:24 AM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
> >
> > > On 2019/01/31 01:12, Tinker wrote:
> > >
> > > > Reading your log file
> > > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > > , there is mentioning of libestdc++ in there.
> > >
> > > That doesn't use g++ from base though, only the ports version.
> > > I went through all C++ ports not on the direct path to building gcc
> > > and added a COMPILER line so they are built with ports gcc.
> >
> > Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> > building ports gcc on sparc64 with a diff that could fix things.
> > Specifically, the stack frames on OpenBSD are different compared to
> > other systems since we have stackghost.
> >
> > See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
> >
> > -Otto
>
> Wait, the system g++ uses one stack frame format and the ports eg++
> uses another one, this is how it is and has been for a long time?
>
> If so no wonder that g++ and eg++ produced incompatible binaries.
>
> So right now you are doing the historic maneuver of making g++ and
> eg++-produced binaries compatible?
>
> Also how does LLVM play in here.
>
> Can you please confirm how it is?
Reading skills are mandatory.
Otto is attacking a different problem first.
You are welcome to attack the problem that worries you independently.
It is a bit impolite to park your concerns on someone else's plate.
Does this make sense?
> On Friday, February 1, 2019 1:24 AM, Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
> >
> > > On 2019/01/31 01:12, Tinker wrote:
> > >
> > > > Reading your log file
> > > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > > , there is mentioning of libestdc++ in there.
> > >
> > > That doesn't use g++ from base though, only the ports version.
> > > I went through all C++ ports not on the direct path to building gcc
> > > and added a COMPILER line so they are built with ports gcc.
> >
> > Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> > building ports gcc on sparc64 with a diff that could fix things.
> > Specifically, the stack frames on OpenBSD are different compared to
> > other systems since we have stackghost.
> >
> > See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
> >
> > -Otto
>
> Wait, the system g++ uses one stack frame format and the ports eg++
> uses another one, this is how it is and has been for a long time?
>
> If so no wonder that g++ and eg++ produced incompatible binaries.
>
> So right now you are doing the historic maneuver of making g++ and
> eg++-produced binaries compatible?
>
> Also how does LLVM play in here.
>
> Can you please confirm how it is?
Reading skills are mandatory.
Otto is attacking a different problem first.
You are welcome to attack the problem that worries you independently.
It is a bit impolite to park your concerns on someone else's plate.
Does this make sense?
Re: sparc64 and C++ exceptions
On Friday, February 1, 2019 1:24 AM, Otto Moerbeek <otto@drijf.net> wrote:
> On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
>
> > On 2019/01/31 01:12, Tinker wrote:
> >
> > > Reading your log file
> > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > , there is mentioning of libestdc++ in there.
> >
> > That doesn't use g++ from base though, only the ports version.
> > I went through all C++ ports not on the direct path to building gcc
> > and added a COMPILER line so they are built with ports gcc.
>
> Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> building ports gcc on sparc64 with a diff that could fix things.
> Specifically, the stack frames on OpenBSD are different compared to
> other systems since we have stackghost.
>
> See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
>
> -Otto
Wait, the system g++ uses one stack frame format and the ports eg++
uses another one, this is how it is and has been for a long time?
If so no wonder that g++ and eg++ produced incompatible binaries.
So right now you are doing the historic maneuver of making g++ and
eg++-produced binaries compatible?
Also how does LLVM play in here.
Can you please confirm how it is?
> On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
>
> > On 2019/01/31 01:12, Tinker wrote:
> >
> > > Reading your log file
> > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > , there is mentioning of libestdc++ in there.
> >
> > That doesn't use g++ from base though, only the ports version.
> > I went through all C++ ports not on the direct path to building gcc
> > and added a COMPILER line so they are built with ports gcc.
>
> Meanwhile, kettenis@ mentioned the probably cause. I'm currently
> building ports gcc on sparc64 with a diff that could fix things.
> Specifically, the stack frames on OpenBSD are different compared to
> other systems since we have stackghost.
>
> See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
>
> -Otto
Wait, the system g++ uses one stack frame format and the ports eg++
uses another one, this is how it is and has been for a long time?
If so no wonder that g++ and eg++ produced incompatible binaries.
So right now you are doing the historic maneuver of making g++ and
eg++-produced binaries compatible?
Also how does LLVM play in here.
Can you please confirm how it is?
Re: sparc64 and C++ exceptions
On Thursday, January 31, 2019 2:00 PM, Otto Moerbeek <otto@drijf.net> wrote:
> On Thu, Jan 31, 2019 at 01:12:10AM +0000, Tinker wrote:
>
> > Hi Otto and Jeremie,
> > I think I have the answer to your particular question, and it's
> > platform-independent:
> > Reading your log file
> > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > , there is mentioning of libestdc++ in there.
> > Please be aware that a program that links to both libstdc++ and
> > libestdc++ will likely crash, and in my experience exception handling
> > gone-haywire is a typical form of such a crash.
>
> That does not explain my simple test case I posted erlier, where
> mixing of libs does not play a roll at all.
>
> -Otto
Wait clarify, what exact test case?
> On Thu, Jan 31, 2019 at 01:12:10AM +0000, Tinker wrote:
>
> > Hi Otto and Jeremie,
> > I think I have the answer to your particular question, and it's
> > platform-independent:
> > Reading your log file
> > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > , there is mentioning of libestdc++ in there.
> > Please be aware that a program that links to both libstdc++ and
> > libestdc++ will likely crash, and in my experience exception handling
> > gone-haywire is a typical form of such a crash.
>
> That does not explain my simple test case I posted erlier, where
> mixing of libs does not play a roll at all.
>
> -Otto
Wait clarify, what exact test case?
Re: Use xenodm like startx?
Thu, 31 Jan 2019 17:33:01 +0100 Freddy Fisker <ff@freddyfisker.dk>
> Hi
>
> I am using the Xfce desktop, and the only thing I am doing is making the
>
> file with:
>
> $ echo xfce4-session > ~/.xinitrc
>
Hi Freddy,
Alright, I was running startx pretty happily with an .xinitrc to set up
programs started, terminal positions & everything, then along comes the
notorious fix and now, it's renamed to .xsession, and xenodm starts it.
But now I have to log twice to the console and then again log in to the
X display manager, which I totally don't like having to do, a nuisance.
The console is used ironically to setup & add ssh agent keys, before X.
So that the agent could persist and be used regardless of the X server.
With the help of the tips from this thread, now it's back to manual log
at the console and running the x alias to start the session. All good.
https://man.openbsd.org/xenodm#RESOURCES
DisplayManager.*.autoLogin
DisplayManager.*.terminateServer
The only issue is, these sets of complexities called xenodm, needlessly
just because people want to log in a Windows graphical display manager.
I just have no use for this login manager stuff, and never had any use,
of desktop environments complex dysfunctional distro style all mixed up
graphical 'experience'. Plain cwm, simplest X setup and it just works.
It would be nicer if we could run X with a session file WITHOUT xenodm.
Not sure your suggested xinit is not a fall through of the setuid bug..
2018-10-26 setuid bit removed from /usr/X11R6/bin/Xorg
The Xorg binary is no longer installed setuid.
So startx(1) can no longer be used by non-root users.
The xenodm(1) display manager has to be used.
Kind regards,
Anton Lazarov
>
> And then starting the Xfce desktop with the command:
>
> $ xinit
>
>
> Best regards
> Freddy Fisker
>
>
> On Thursday, 31 January 2019 16:55:20 CET, lists@wrant.com wrote:
> > Thu, 31 Jan 2019 12:23:08 +0100 Freddy Fisker <ff@freddyfisker.dk>
> >> Hi
> >>
> >> I have never used the startx command. I use the xinit command
> >> together with
> >> the ~/.xinitrc file.
> >
> > Hi Freddy,
> >
> > Are you referring to a recent OpenBSD, or some other customised variant?
> > If that's a bypass of the recent security fixes don't bother responding.
> > I'm only interested how it solves or improves on-demand X session model.
> >
> > Kind regards,
> > Anton Lazarov
> >
> >> Best regards
> >> Freddy Fisker
> >>
> >>
> >> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote: ...
> >
> >
> >
>
> Hi
>
> I am using the Xfce desktop, and the only thing I am doing is making the
>
> file with:
>
> $ echo xfce4-session > ~/.xinitrc
>
Hi Freddy,
Alright, I was running startx pretty happily with an .xinitrc to set up
programs started, terminal positions & everything, then along comes the
notorious fix and now, it's renamed to .xsession, and xenodm starts it.
But now I have to log twice to the console and then again log in to the
X display manager, which I totally don't like having to do, a nuisance.
The console is used ironically to setup & add ssh agent keys, before X.
So that the agent could persist and be used regardless of the X server.
With the help of the tips from this thread, now it's back to manual log
at the console and running the x alias to start the session. All good.
https://man.openbsd.org/xenodm#RESOURCES
DisplayManager.*.autoLogin
DisplayManager.*.terminateServer
The only issue is, these sets of complexities called xenodm, needlessly
just because people want to log in a Windows graphical display manager.
I just have no use for this login manager stuff, and never had any use,
of desktop environments complex dysfunctional distro style all mixed up
graphical 'experience'. Plain cwm, simplest X setup and it just works.
It would be nicer if we could run X with a session file WITHOUT xenodm.
Not sure your suggested xinit is not a fall through of the setuid bug..
2018-10-26 setuid bit removed from /usr/X11R6/bin/Xorg
The Xorg binary is no longer installed setuid.
So startx(1) can no longer be used by non-root users.
The xenodm(1) display manager has to be used.
Kind regards,
Anton Lazarov
>
> And then starting the Xfce desktop with the command:
>
> $ xinit
>
>
> Best regards
> Freddy Fisker
>
>
> On Thursday, 31 January 2019 16:55:20 CET, lists@wrant.com wrote:
> > Thu, 31 Jan 2019 12:23:08 +0100 Freddy Fisker <ff@freddyfisker.dk>
> >> Hi
> >>
> >> I have never used the startx command. I use the xinit command
> >> together with
> >> the ~/.xinitrc file.
> >
> > Hi Freddy,
> >
> > Are you referring to a recent OpenBSD, or some other customised variant?
> > If that's a bypass of the recent security fixes don't bother responding.
> > I'm only interested how it solves or improves on-demand X session model.
> >
> > Kind regards,
> > Anton Lazarov
> >
> >> Best regards
> >> Freddy Fisker
> >>
> >>
> >> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote: ...
> >
> >
> >
>
Re: [UPDATE] mail/ruby-mime-types-data
ping.
George Rosamond:
> update to 3.2018.0812.
>
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ Makefile 10 Dec 2018 03:46:14 -0000
@@ -2,7 +2,7 @@
COMMENT= MIME types data for Ruby
-DISTNAME= mime-types-data-3.2016.0521
+DISTNAME= mime-types-data-3.2018.0812
CATEGORIES= mail
HOMEPAGE= https://github.com/mime-types/mime-types-data/
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ distinfo 10 Dec 2018 03:46:14 -0000
@@ -1,2 +1,2 @@
-SHA256 (mime-types-data-3.2016.0521.gem) =
dUK8z/BtcMStlNHPELfaxr2JlYNW5dDX9kRxaMgZvhI=
-SIZE (mime-types-data-3.2016.0521.gem) = 101888
+SHA256 (mime-types-data-3.2018.0812.gem) =
rEVTKIIldWlw8HOXmP8PERaYjVbgrBWlJVU+wRW4mx8=
+SIZE (mime-types-data-3.2018.0812.gem) = 157184
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ pkg/DESCR 10 Dec 2018 03:46:14 -0000
@@ -1,4 +1,5 @@
-mime-types-data provides a registry for information about MIME media type
-definitions. It can be used with the Ruby mime-types library or other
software
-to determine defined filename extensions for MIME types, or to use filename
-extensions to look up the likely MIME type definitions.
+mime-types-data provides a registry for information about MIME media
+type definitions. It can be used with the Ruby mime-types library
+or other software to determine defined filename extensions for MIME
+types, or to use filename extensions to look up the likely MIME
+type definitions.
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ pkg/PLIST 10 Dec 2018 03:46:14 -0000
@@ -23,4 +23,18 @@ ${GEM_LIB}/gems/${DISTNAME}/lib/mime/
${GEM_LIB}/gems/${DISTNAME}/lib/mime-types-data.rb
${GEM_LIB}/gems/${DISTNAME}/lib/mime/types/
${GEM_LIB}/gems/${DISTNAME}/lib/mime/types/data.rb
+${GEM_LIB}/gems/${DISTNAME}/types/
+${GEM_LIB}/gems/${DISTNAME}/types/application.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/audio.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/chemical.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/conference.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/drawing.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/font.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/image.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/message.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/model.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/multipart.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/text.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/video.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/world.yaml
${GEM_LIB}/specifications/${DISTNAME}.gemspec
George Rosamond:
> update to 3.2018.0812.
>
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ Makefile 10 Dec 2018 03:46:14 -0000
@@ -2,7 +2,7 @@
COMMENT= MIME types data for Ruby
-DISTNAME= mime-types-data-3.2016.0521
+DISTNAME= mime-types-data-3.2018.0812
CATEGORIES= mail
HOMEPAGE= https://github.com/mime-types/mime-types-data/
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ distinfo 10 Dec 2018 03:46:14 -0000
@@ -1,2 +1,2 @@
-SHA256 (mime-types-data-3.2016.0521.gem) =
dUK8z/BtcMStlNHPELfaxr2JlYNW5dDX9kRxaMgZvhI=
-SIZE (mime-types-data-3.2016.0521.gem) = 101888
+SHA256 (mime-types-data-3.2018.0812.gem) =
rEVTKIIldWlw8HOXmP8PERaYjVbgrBWlJVU+wRW4mx8=
+SIZE (mime-types-data-3.2018.0812.gem) = 157184
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ pkg/DESCR 10 Dec 2018 03:46:14 -0000
@@ -1,4 +1,5 @@
-mime-types-data provides a registry for information about MIME media type
-definitions. It can be used with the Ruby mime-types library or other
software
-to determine defined filename extensions for MIME types, or to use filename
-extensions to look up the likely MIME type definitions.
+mime-types-data provides a registry for information about MIME media
+type definitions. It can be used with the Ruby mime-types library
+or other software to determine defined filename extensions for MIME
+types, or to use filename extensions to look up the likely MIME
+type definitions.
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types-data/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 2 Nov 2016 19:29:32 -0000 1.1.1.1
+++ pkg/PLIST 10 Dec 2018 03:46:14 -0000
@@ -23,4 +23,18 @@ ${GEM_LIB}/gems/${DISTNAME}/lib/mime/
${GEM_LIB}/gems/${DISTNAME}/lib/mime-types-data.rb
${GEM_LIB}/gems/${DISTNAME}/lib/mime/types/
${GEM_LIB}/gems/${DISTNAME}/lib/mime/types/data.rb
+${GEM_LIB}/gems/${DISTNAME}/types/
+${GEM_LIB}/gems/${DISTNAME}/types/application.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/audio.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/chemical.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/conference.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/drawing.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/font.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/image.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/message.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/model.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/multipart.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/text.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/video.yaml
+${GEM_LIB}/gems/${DISTNAME}/types/world.yaml
${GEM_LIB}/specifications/${DISTNAME}.gemspec
Re: [UPDATE] mail/ruby-mime-types =>3.2.2
Resubmitting.
George Rosamond:
> Update to 3.2.2 from 3.1 attached
>
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile 2 Nov 2016 19:31:33 -0000 1.13
+++ Makefile 10 Dec 2018 03:31:50 -0000
@@ -2,7 +2,7 @@
COMMENT= MIME type library for Ruby
-DISTNAME= mime-types-3.1
+DISTNAME= mime-types-3.2.2
CATEGORIES= mail
HOMEPAGE= https://github.com/mime-types/ruby-mime-types/
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo 2 Nov 2016 19:31:33 -0000 1.5
+++ distinfo 10 Dec 2018 03:31:50 -0000
@@ -1,2 +1,2 @@
-SHA256 (mime-types-3.1.gem) = dZSTIcP1XmYY0FlgFgWYQcJhaDQuwe5OZBBTu2b6BwE=
-SIZE (mime-types-3.1.gem) = 42496
+SHA256 (mime-types-3.2.2.gem) =
k/MI8LZ1SwylDdGYK4F/ZbiUb2o0vT22vT2KUmXwXTo=
+SIZE (mime-types-3.2.2.gem) = 35840
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 19 Apr 2008 18:00:45 -0000 1.1.1.1
+++ pkg/DESCR 10 Dec 2018 03:31:50 -0000
@@ -1,3 +1,3 @@
-This library allows for the identification of a file's likely MIME content
-type. The identification of MIME content type is based on a file's filename
-extensions.
+This library allows for the identification of a file's likely MIME
+content type. The identification of MIME content type is based on
+a file's filename extensions.
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 2 Nov 2016 19:31:33 -0000 1.4
+++ pkg/PLIST 10 Dec 2018 03:31:50 -0000
@@ -1,10 +1,10 @@
@comment $OpenBSD: PLIST,v 1.4 2016/11/02 19:31:33 jeremy Exp $
${GEM_LIB}/cache/${DISTNAME}.gem
${GEM_LIB}/gems/${DISTNAME}/
-${GEM_LIB}/gems/${DISTNAME}/Code-of-Conduct.rdoc
-${GEM_LIB}/gems/${DISTNAME}/Contributing.rdoc
-${GEM_LIB}/gems/${DISTNAME}/History.rdoc
-${GEM_LIB}/gems/${DISTNAME}/Licence.rdoc
+${GEM_LIB}/gems/${DISTNAME}/Code-of-Conduct.md
+${GEM_LIB}/gems/${DISTNAME}/Contributing.md
+${GEM_LIB}/gems/${DISTNAME}/History.md
+${GEM_LIB}/gems/${DISTNAME}/Licence.md
${GEM_LIB}/gems/${DISTNAME}/Manifest.txt
${GEM_LIB}/gems/${DISTNAME}/README.rdoc
${GEM_LIB}/gems/${DISTNAME}/Rakefile
George Rosamond:
> Update to 3.2.2 from 3.1 attached
>
Index: Makefile
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile 2 Nov 2016 19:31:33 -0000 1.13
+++ Makefile 10 Dec 2018 03:31:50 -0000
@@ -2,7 +2,7 @@
COMMENT= MIME type library for Ruby
-DISTNAME= mime-types-3.1
+DISTNAME= mime-types-3.2.2
CATEGORIES= mail
HOMEPAGE= https://github.com/mime-types/ruby-mime-types/
Index: distinfo
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo 2 Nov 2016 19:31:33 -0000 1.5
+++ distinfo 10 Dec 2018 03:31:50 -0000
@@ -1,2 +1,2 @@
-SHA256 (mime-types-3.1.gem) = dZSTIcP1XmYY0FlgFgWYQcJhaDQuwe5OZBBTu2b6BwE=
-SIZE (mime-types-3.1.gem) = 42496
+SHA256 (mime-types-3.2.2.gem) =
k/MI8LZ1SwylDdGYK4F/ZbiUb2o0vT22vT2KUmXwXTo=
+SIZE (mime-types-3.2.2.gem) = 35840
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 19 Apr 2008 18:00:45 -0000 1.1.1.1
+++ pkg/DESCR 10 Dec 2018 03:31:50 -0000
@@ -1,3 +1,3 @@
-This library allows for the identification of a file's likely MIME content
-type. The identification of MIME content type is based on a file's filename
-extensions.
+This library allows for the identification of a file's likely MIME
+content type. The identification of MIME content type is based on
+a file's filename extensions.
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/mail/ruby-mime-types/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 2 Nov 2016 19:31:33 -0000 1.4
+++ pkg/PLIST 10 Dec 2018 03:31:50 -0000
@@ -1,10 +1,10 @@
@comment $OpenBSD: PLIST,v 1.4 2016/11/02 19:31:33 jeremy Exp $
${GEM_LIB}/cache/${DISTNAME}.gem
${GEM_LIB}/gems/${DISTNAME}/
-${GEM_LIB}/gems/${DISTNAME}/Code-of-Conduct.rdoc
-${GEM_LIB}/gems/${DISTNAME}/Contributing.rdoc
-${GEM_LIB}/gems/${DISTNAME}/History.rdoc
-${GEM_LIB}/gems/${DISTNAME}/Licence.rdoc
+${GEM_LIB}/gems/${DISTNAME}/Code-of-Conduct.md
+${GEM_LIB}/gems/${DISTNAME}/Contributing.md
+${GEM_LIB}/gems/${DISTNAME}/History.md
+${GEM_LIB}/gems/${DISTNAME}/Licence.md
${GEM_LIB}/gems/${DISTNAME}/Manifest.txt
${GEM_LIB}/gems/${DISTNAME}/README.rdoc
${GEM_LIB}/gems/${DISTNAME}/Rakefile
Re: [SOLVED] Re: apu2 em0/dhclient problems
Edgar Pettijohn [edgar@pettijohn-web.com] wrote:
>
> Don't know why it works, but em1 works. I guess I'll rewrite my config files.
>
This shouldn't be an acceptable solution to you. Unless the port is physically
damaged, you should figure out what's going on. Tcpdump is a great start.
Chris
>
> Don't know why it works, but em1 works. I guess I'll rewrite my config files.
>
This shouldn't be an acceptable solution to you. Unless the port is physically
damaged, you should figure out what's going on. Tcpdump is a great start.
Chris
devel/llvm powerpc bugs
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.207
diff -u -p -r1.207 Makefile
--- Makefile 28 Jan 2019 15:34:22 -0000 1.207
+++ Makefile 31 Jan 2019 22:16:07 -0000
@@ -20,7 +20,7 @@ PKGSPEC-main = llvm-=${LLVM_V}
PKGNAME-main = llvm-${LLVM_V}
PKGNAME-python = py-llvm-${LLVM_V}
PKGNAME-lldb = lldb-${LLVM_V}
-REVISION-main = 0
+REVISION-main = 1
CATEGORIES = devel
DISTFILES = llvm-${LLVM_V}.src${EXTRACT_SUFX} \
cfe-${LLVM_V}.src${EXTRACT_SUFX} \
Index: patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
===================================================================
RCS file: patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
diff -N patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp 31 Jan 2019 22:16:07 -0000
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+[PowerPC] When optimizing, don't load or store a misaligned float.
+Such misalignment causes SIGBUS in OpenBSD.
+
+Index: lib/Target/PowerPC/PPCISelLowering.cpp
+--- lib/Target/PowerPC/PPCISelLowering.cpp.orig
++++ lib/Target/PowerPC/PPCISelLowering.cpp
+@@ -13918,7 +13918,8 @@ bool PPCTargetLowering::allowsMisalignedMemoryAccesses
+ }
+ }
+
+- if (VT == MVT::ppcf128)
++ // f32 and f64 must have 4-byte alignment.
++ if (VT == MVT::f32 || VT == MVT::f64 || VT == MVT::ppcf128)
+ return false;
+
+ if (Fast)
Index: patches/patch-tools_clang_lib_Basic_Targets_PPC_h
===================================================================
RCS file: patches/patch-tools_clang_lib_Basic_Targets_PPC_h
diff -N patches/patch-tools_clang_lib_Basic_Targets_PPC_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-tools_clang_lib_Basic_Targets_PPC_h 31 Jan 2019 22:16:07 -0000
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+[PowerPC] sizeof(long double) should be 8, not 16.
+
+Index: tools/clang/lib/Basic/Targets/PPC.h
+--- tools/clang/lib/Basic/Targets/PPC.h.orig
++++ tools/clang/lib/Basic/Targets/PPC.h
+@@ -328,9 +328,15 @@ class LLVM_LIBRARY_VISIBILITY PPC32TargetInfo : public
+ break;
+ }
+
+- if (getTriple().getOS() == llvm::Triple::FreeBSD) {
++ switch (getTriple().getOS()) {
++ case llvm::Triple::FreeBSD:
++ case llvm::Triple::NetBSD:
++ case llvm::Triple::OpenBSD:
+ LongDoubleWidth = LongDoubleAlign = 64;
+ LongDoubleFormat = &llvm::APFloat::IEEEdouble();
++ break;
++ default:
++ break;
+ }
+
+ // PPC32 supports atomics up to 4 bytes.
My OpenBSD/macppc machine has built devel/llvm 7.0.1p0, but a pair of
bugs in clang 6 are still in clang 7. A moment ago, I reported these
bugs to llvm:
- https://bugs.llvm.org/show_bug.cgi?id=40553
wrong sizeof(long double) in 32-bit PowerPC NetBSD, OpenBSD
- https://bugs.llvm.org/show_bug.cgi?id=40554
misaligned float in PowerPC code causes SIGBUS in OpenBSD/macppc
Each report includes an example program that reproduces the bug, and
a patch that tries to fix it. The long double bug is breaking
graphics/kdiagram on powerpc. (Most C++ ports use ports-gcc, but
x11/qt5/qt5.port.mk prefers ports-clang before ports-gcc, so ports
using Qt5 may suffer from clang bugs.)
I am now using the attached diff in devel/llvm. I have packaged
kdiagram with this. My REVISION-main bump (from 0 to 1) conflicts
with recent changes in CVS. My patches might not be correct; someone
who knows llvm might be able to write better patches.
I am using lang/gcc/8 as my ports-gcc; I have edited
- infrastructure/mk/gcc4.port.mk to use MODGCC4_VERSION?=8
- devel/llvm/Makefile to use GCC_VER = 8.2.0
These edits are not in the attached diff.
--
George Koehler <kernigh@gmail.com>
===================================================================
RCS file: /cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.207
diff -u -p -r1.207 Makefile
--- Makefile 28 Jan 2019 15:34:22 -0000 1.207
+++ Makefile 31 Jan 2019 22:16:07 -0000
@@ -20,7 +20,7 @@ PKGSPEC-main = llvm-=${LLVM_V}
PKGNAME-main = llvm-${LLVM_V}
PKGNAME-python = py-llvm-${LLVM_V}
PKGNAME-lldb = lldb-${LLVM_V}
-REVISION-main = 0
+REVISION-main = 1
CATEGORIES = devel
DISTFILES = llvm-${LLVM_V}.src${EXTRACT_SUFX} \
cfe-${LLVM_V}.src${EXTRACT_SUFX} \
Index: patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
===================================================================
RCS file: patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
diff -N patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-lib_Target_PowerPC_PPCISelLowering_cpp 31 Jan 2019 22:16:07 -0000
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+[PowerPC] When optimizing, don't load or store a misaligned float.
+Such misalignment causes SIGBUS in OpenBSD.
+
+Index: lib/Target/PowerPC/PPCISelLowering.cpp
+--- lib/Target/PowerPC/PPCISelLowering.cpp.orig
++++ lib/Target/PowerPC/PPCISelLowering.cpp
+@@ -13918,7 +13918,8 @@ bool PPCTargetLowering::allowsMisalignedMemoryAccesses
+ }
+ }
+
+- if (VT == MVT::ppcf128)
++ // f32 and f64 must have 4-byte alignment.
++ if (VT == MVT::f32 || VT == MVT::f64 || VT == MVT::ppcf128)
+ return false;
+
+ if (Fast)
Index: patches/patch-tools_clang_lib_Basic_Targets_PPC_h
===================================================================
RCS file: patches/patch-tools_clang_lib_Basic_Targets_PPC_h
diff -N patches/patch-tools_clang_lib_Basic_Targets_PPC_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-tools_clang_lib_Basic_Targets_PPC_h 31 Jan 2019 22:16:07 -0000
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+[PowerPC] sizeof(long double) should be 8, not 16.
+
+Index: tools/clang/lib/Basic/Targets/PPC.h
+--- tools/clang/lib/Basic/Targets/PPC.h.orig
++++ tools/clang/lib/Basic/Targets/PPC.h
+@@ -328,9 +328,15 @@ class LLVM_LIBRARY_VISIBILITY PPC32TargetInfo : public
+ break;
+ }
+
+- if (getTriple().getOS() == llvm::Triple::FreeBSD) {
++ switch (getTriple().getOS()) {
++ case llvm::Triple::FreeBSD:
++ case llvm::Triple::NetBSD:
++ case llvm::Triple::OpenBSD:
+ LongDoubleWidth = LongDoubleAlign = 64;
+ LongDoubleFormat = &llvm::APFloat::IEEEdouble();
++ break;
++ default:
++ break;
+ }
+
+ // PPC32 supports atomics up to 4 bytes.
My OpenBSD/macppc machine has built devel/llvm 7.0.1p0, but a pair of
bugs in clang 6 are still in clang 7. A moment ago, I reported these
bugs to llvm:
- https://bugs.llvm.org/show_bug.cgi?id=40553
wrong sizeof(long double) in 32-bit PowerPC NetBSD, OpenBSD
- https://bugs.llvm.org/show_bug.cgi?id=40554
misaligned float in PowerPC code causes SIGBUS in OpenBSD/macppc
Each report includes an example program that reproduces the bug, and
a patch that tries to fix it. The long double bug is breaking
graphics/kdiagram on powerpc. (Most C++ ports use ports-gcc, but
x11/qt5/qt5.port.mk prefers ports-clang before ports-gcc, so ports
using Qt5 may suffer from clang bugs.)
I am now using the attached diff in devel/llvm. I have packaged
kdiagram with this. My REVISION-main bump (from 0 to 1) conflicts
with recent changes in CVS. My patches might not be correct; someone
who knows llvm might be able to write better patches.
I am using lang/gcc/8 as my ports-gcc; I have edited
- infrastructure/mk/gcc4.port.mk to use MODGCC4_VERSION?=8
- devel/llvm/Makefile to use GCC_VER = 8.2.0
These edits are not in the attached diff.
--
George Koehler <kernigh@gmail.com>
Re: [UPDATE]: shells/yash 2.44 (2017-01-17) -> 2.48 (2018-12-22)
Andreas Kusalananda Kähäri:
> You'll find a patch for an update to the shells/yash port attached.
Thank you. The way upstream publishes new releases doesn't work
with portroach and, honestly, I had forgotten about the port.
> (BTW, there's an earlier srand() call in the same file, but maybe
> this should not be changed to srand_deterministic()?)
In the upstream code, there are two srand() calls, corresponding
to two different uses of the RANDOM variable. By default, $RANDOM
expands to a truly random number. We initialize this use with
srand(). However, RANDOM can also be set to a value, which then
serves as a seed for a deterministic pseudo-random sequence by
subsequent $RANDOM references. We initialize this second use with
srand_deterministic().
You did not try to run the regression tests. I have, and now I'm
looking into the failures...
--
Christian "naddy" Weisgerber naddy@mips.inka.de
> You'll find a patch for an update to the shells/yash port attached.
Thank you. The way upstream publishes new releases doesn't work
with portroach and, honestly, I had forgotten about the port.
> (BTW, there's an earlier srand() call in the same file, but maybe
> this should not be changed to srand_deterministic()?)
In the upstream code, there are two srand() calls, corresponding
to two different uses of the RANDOM variable. By default, $RANDOM
expands to a truly random number. We initialize this use with
srand(). However, RANDOM can also be set to a value, which then
serves as a seed for a deterministic pseudo-random sequence by
subsequent $RANDOM references. We initialize this second use with
srand_deterministic().
You did not try to run the regression tests. I have, and now I'm
looking into the failures...
--
Christian "naddy" Weisgerber naddy@mips.inka.de
Re: Getting traffic from rdomain X to talk to a daemon in default rdomain 0
Jiri B(jirib79@gmail.com) on 2019.01.31 22:23:34 +0100:
> Hello,
>
> I'm trying to isolate an app running on OpenBSD on network level and thus I
> have started
> the app in a specific rdomain.
>
> I can successfully make traffic from the rdomain to reach Internet:
>
> pass out quick on rdomain 1 to any nat-to (egress) rtable 0
that rule is only evaluated when the packes pass through a network
interface.
> But I cannot figure out how to make the app in this rdomain 1 to communicate
> which daemons in default rdomain (0).
>
> With above rule I would see something like this on lo0 (rdomain0):
>
> Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+ NS? .(17)
>
> Tested with route -T 1 exec dig @199.195.x.x www.openbsd.org.
> It seems it does not know how to send back replies ?
yes, because rdomain 0 does not have a route to what network you have in
rdomain 1.
Btw. its hard to talk about this without you giving the actual networks and
IPs used.
> Without 'nat-to (egress)' the replies would be just send via default gw in
> rdomain 0:
>
> mx1# tcpdump -i vio0 -n -e -ttt icmp
> tcpdump: listening on vio0, link-type EN10MB
> Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
> 199.195.x.x > 172.16.1.2: icmp: echo reply
>
> (172.16.1.2 was the IP in rdomain 1)
>
> Any idea what would be PF rule to make this working - ie. make an app in
> rdomain X talk to daemons in rdomain 0.
>
> I also tried to use pair interfaces but I failed too.
Try this:
# set up two connected pair interfaces:
ifconfig pair8 inet 192.168.2.8/24 rdomain 8
ifconfig pair1 inet 192.168.2.1/24 rdomain 0
ifconfig pair1 patch pair8
# they now can ping each other:
ping 192.168.2.8
route -T 8 exec ping 192.168.2.1
# my em0 interface in rdomain 0 has the IP 192.168.1.52:
em0: flags=208847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500
lladdr 44:c6:86:5a:c2:f7
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 192.168.1.52 netmask 0xffffff00 broadcast 192.168.1.255
# add a route to 192.168.1.52 to rdomain 8:
route -T 8 add 192.168.1.52 192.168.2.1
route -T 8 exec ping 192.168.1.52
# the traffic back from rdomain 0 to rdomain 8 works now, because packets
# are send with source ip 192.168.2.8, and rdomain 0 has a route to that IP
# through pair1.
Now run your service on 192.168.1.52.
/Benno
> Hello,
>
> I'm trying to isolate an app running on OpenBSD on network level and thus I
> have started
> the app in a specific rdomain.
>
> I can successfully make traffic from the rdomain to reach Internet:
>
> pass out quick on rdomain 1 to any nat-to (egress) rtable 0
that rule is only evaluated when the packes pass through a network
interface.
> But I cannot figure out how to make the app in this rdomain 1 to communicate
> which daemons in default rdomain (0).
>
> With above rule I would see something like this on lo0 (rdomain0):
>
> Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+ NS? .(17)
>
> Tested with route -T 1 exec dig @199.195.x.x www.openbsd.org.
> It seems it does not know how to send back replies ?
yes, because rdomain 0 does not have a route to what network you have in
rdomain 1.
Btw. its hard to talk about this without you giving the actual networks and
IPs used.
> Without 'nat-to (egress)' the replies would be just send via default gw in
> rdomain 0:
>
> mx1# tcpdump -i vio0 -n -e -ttt icmp
> tcpdump: listening on vio0, link-type EN10MB
> Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
> 199.195.x.x > 172.16.1.2: icmp: echo reply
>
> (172.16.1.2 was the IP in rdomain 1)
>
> Any idea what would be PF rule to make this working - ie. make an app in
> rdomain X talk to daemons in rdomain 0.
>
> I also tried to use pair interfaces but I failed too.
Try this:
# set up two connected pair interfaces:
ifconfig pair8 inet 192.168.2.8/24 rdomain 8
ifconfig pair1 inet 192.168.2.1/24 rdomain 0
ifconfig pair1 patch pair8
# they now can ping each other:
ping 192.168.2.8
route -T 8 exec ping 192.168.2.1
# my em0 interface in rdomain 0 has the IP 192.168.1.52:
em0: flags=208847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500
lladdr 44:c6:86:5a:c2:f7
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 192.168.1.52 netmask 0xffffff00 broadcast 192.168.1.255
# add a route to 192.168.1.52 to rdomain 8:
route -T 8 add 192.168.1.52 192.168.2.1
route -T 8 exec ping 192.168.1.52
# the traffic back from rdomain 0 to rdomain 8 works now, because packets
# are send with source ip 192.168.2.8, and rdomain 0 has a route to that IP
# through pair1.
Now run your service on 192.168.1.52.
/Benno
UPDATE: www/py-repoze-profile 1.4 -> 2.3
Index: Makefile
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile 7 Jan 2016 21:35:29 -0000 1.12
+++ Makefile 31 Jan 2019 22:07:35 -0000
@@ -2,10 +2,9 @@
COMMENT = aggregate profiling for wsgi requests
-MODPY_EGG_VERSION = 1.4
+MODPY_EGG_VERSION = 2.3
DISTNAME = repoze.profile-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:S/./-/}
-REVISION = 2
CATEGORIES = www devel
@@ -14,16 +13,32 @@ PERMIT_PACKAGE_CDROM = Yes
MODPY_PI = Yes
-RUN_DEPENDS = devel/py-pyprof2calltree
-TEST_DEPENDS = ${RUN_DEPENDS}
-
MODULES = lang/python
MODPY_SETUPTOOLS = Yes
+FLAVORS = python3
+FLAVOR ?=
+
+
+.if !${FLAVOR:Mpython3}
+RUN_DEPENDS += devel/py-pyprof2calltree
+TEST_DEPENDS += ${RUN_DEPENDS}
+.endif
+
+
+DOCSRC = ${WRKSRC}/docs
+
+MAKE_ENV += PYTHONPATH=${WRKSRC} \
+ SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
+
+
+post-build:
+ cd ${DOCSRC} && ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} man
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-repoze-profile
- ${INSTALL_DATA} ${WRKSRC}/README.txt \
- ${PREFIX}/share/doc/py-repoze-profile
+ ${INSTALL_MAN} ${DOCSRC}/_build/man/repozeprofile.1 \
+ ${PREFIX}/man/man1/repozeprofile${MODPY_BIN_SUFFIX}.1
+
.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 18 Jan 2015 03:15:49 -0000 1.4
+++ distinfo 31 Jan 2019 22:07:35 -0000
@@ -1,2 +1,2 @@
-SHA256 (repoze.profile-1.4.tar.gz) = vkWjQw2zpvPXNzKvfAF/L4DJqyFgvrbEl2PMJskRTVE=
-SIZE (repoze.profile-1.4.tar.gz) = 136458
+SHA256 (repoze.profile-2.3.tar.gz) = oT4BpA+HgNTERXWBWb4ZG70U9FBAxJiI+yM1/v/9W44=
+SIZE (repoze.profile-2.3.tar.gz) = 141341
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 22 Apr 2012 09:21:18 -0000 1.2
+++ pkg/PLIST 31 Jan 2019 22:07:35 -0000
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.2 2012/04/22 09:21:18 jasper Exp $
+@comment $OpenBSD: PLIST,v$
lib/python${MODPY_VERSION}/site-packages/repoze/
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}-nspkg.pth
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
@@ -12,13 +12,15 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/repoze/profile/
lib/python${MODPY_VERSION}/site-packages/repoze/profile/__init__.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}decorator.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}profiler.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}tests.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/repoze/profile/compat.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/compat.pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/decorator.py
lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.html
lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.pyc
lib/python${MODPY_VERSION}/site-packages/repoze/profile/tests.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/tests.pyc
-share/doc/${MODPY_PY_PREFIX}repoze-profile/
-share/doc/${MODPY_PY_PREFIX}repoze-profile/README.txt
+@man man/man1/repozeprofile${MODPY_BIN_SUFFIX}.1
Potential update for py-repoze-profile. The current release adds a
decorator for profiling individual functions and a python 3 version.
Passes its regression tests. Nothing depends on this port. Additional
testing/comments welcome.
Thanks,
Pamela
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile 7 Jan 2016 21:35:29 -0000 1.12
+++ Makefile 31 Jan 2019 22:07:35 -0000
@@ -2,10 +2,9 @@
COMMENT = aggregate profiling for wsgi requests
-MODPY_EGG_VERSION = 1.4
+MODPY_EGG_VERSION = 2.3
DISTNAME = repoze.profile-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:S/./-/}
-REVISION = 2
CATEGORIES = www devel
@@ -14,16 +13,32 @@ PERMIT_PACKAGE_CDROM = Yes
MODPY_PI = Yes
-RUN_DEPENDS = devel/py-pyprof2calltree
-TEST_DEPENDS = ${RUN_DEPENDS}
-
MODULES = lang/python
MODPY_SETUPTOOLS = Yes
+FLAVORS = python3
+FLAVOR ?=
+
+
+.if !${FLAVOR:Mpython3}
+RUN_DEPENDS += devel/py-pyprof2calltree
+TEST_DEPENDS += ${RUN_DEPENDS}
+.endif
+
+
+DOCSRC = ${WRKSRC}/docs
+
+MAKE_ENV += PYTHONPATH=${WRKSRC} \
+ SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
+
+
+post-build:
+ cd ${DOCSRC} && ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} man
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-repoze-profile
- ${INSTALL_DATA} ${WRKSRC}/README.txt \
- ${PREFIX}/share/doc/py-repoze-profile
+ ${INSTALL_MAN} ${DOCSRC}/_build/man/repozeprofile.1 \
+ ${PREFIX}/man/man1/repozeprofile${MODPY_BIN_SUFFIX}.1
+
.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 18 Jan 2015 03:15:49 -0000 1.4
+++ distinfo 31 Jan 2019 22:07:35 -0000
@@ -1,2 +1,2 @@
-SHA256 (repoze.profile-1.4.tar.gz) = vkWjQw2zpvPXNzKvfAF/L4DJqyFgvrbEl2PMJskRTVE=
-SIZE (repoze.profile-1.4.tar.gz) = 136458
+SHA256 (repoze.profile-2.3.tar.gz) = oT4BpA+HgNTERXWBWb4ZG70U9FBAxJiI+yM1/v/9W44=
+SIZE (repoze.profile-2.3.tar.gz) = 141341
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/www/py-repoze-profile/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 22 Apr 2012 09:21:18 -0000 1.2
+++ pkg/PLIST 31 Jan 2019 22:07:35 -0000
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.2 2012/04/22 09:21:18 jasper Exp $
+@comment $OpenBSD: PLIST,v$
lib/python${MODPY_VERSION}/site-packages/repoze/
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}-nspkg.pth
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
@@ -12,13 +12,15 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/repoze.profile-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/repoze/profile/
lib/python${MODPY_VERSION}/site-packages/repoze/profile/__init__.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}decorator.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}profiler.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/${MODPY_PYCACHE}tests.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/repoze/profile/compat.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/compat.pyc
+lib/python${MODPY_VERSION}/site-packages/repoze/profile/decorator.py
lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.html
lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/profiler.pyc
lib/python${MODPY_VERSION}/site-packages/repoze/profile/tests.py
-lib/python${MODPY_VERSION}/site-packages/repoze/profile/tests.pyc
-share/doc/${MODPY_PY_PREFIX}repoze-profile/
-share/doc/${MODPY_PY_PREFIX}repoze-profile/README.txt
+@man man/man1/repozeprofile${MODPY_BIN_SUFFIX}.1
Potential update for py-repoze-profile. The current release adds a
decorator for profiling individual functions and a python 3 version.
Passes its regression tests. Nothing depends on this port. Additional
testing/comments welcome.
Thanks,
Pamela
UPDATE: devel/py-pyprof2calltree 1.3.2 -> 1.4.4
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 29 Sep 2015 10:52:11 -0000 1.11
+++ Makefile 31 Jan 2019 02:36:25 -0000
@@ -2,14 +2,13 @@
COMMENT = help visualize profiling data collected with the cProfile
-MODPY_EGG_VERSION = 1.3.2
+MODPY_EGG_VERSION = 1.4.4
DISTNAME = pyprof2calltree-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 0
CATEGORIES = devel
-HOMEPAGE = http://www.bitbucket.org/ogrisel/pyprof2calltree/
+HOMEPAGE = https://github.com/pwaller/pyprof2calltree
# BSD-derived
PERMIT_PACKAGE_CDROM = Yes
@@ -20,9 +19,15 @@ MODULES = lang/python
MODPY_SETUPTOOLS = Yes
+FLAVORS = python3
+FLAVOR ?=
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-pyprof2calltree
- ${INSTALL_DATA} ${WRKSRC}/README.txt \
- ${PREFIX}/share/doc/py-pyprof2calltree
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/${MODPY_PY_PREFIX}pyprof2calltree
+ ${INSTALL_DATA} ${WRKSRC}/README.rst \
+ ${PREFIX}/share/doc/${MODPY_PY_PREFIX}pyprof2calltree
+ for i in ${PREFIX}/bin/*; do \
+ mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
+ done
.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 19 Sep 2015 08:27:56 -0000 1.4
+++ distinfo 31 Jan 2019 02:36:25 -0000
@@ -1,2 +1,2 @@
-SHA256 (pyprof2calltree-1.3.2.tar.gz) = KOrIkmLQ7dhu4ldNJNGEDLyi1O1qHefh2PwF8w6lois=
-SIZE (pyprof2calltree-1.3.2.tar.gz) = 6609
+SHA256 (pyprof2calltree-1.4.4.tar.gz) = nsLU1wqhyz4uZahEUkfrMsHvKJu71kg3xj4JlCQfkOo=
+SIZE (pyprof2calltree-1.4.4.tar.gz) = 10061
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 19 Sep 2015 08:27:56 -0000 1.3
+++ pkg/PLIST 31 Jan 2019 02:36:25 -0000
@@ -1,5 +1,6 @@
-@comment $OpenBSD: PLIST,v 1.3 2015/09/19 08:27:56 benoit Exp $
-bin/pyprof2calltree
+@comment $OpenBSD: PLIST,v$
+bin/pyprof2calltree${MODPY_BIN_SUFFIX}
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}pyprof2calltree.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
@@ -8,6 +9,5 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree.py
-lib/python${MODPY_VERSION}/site-packages/pyprof2calltree.pyc
share/doc/${MODPY_PY_PREFIX}pyprof2calltree/
-share/doc/${MODPY_PY_PREFIX}pyprof2calltree/README.txt
+share/doc/${MODPY_PY_PREFIX}pyprof2calltree/README.rst
Attached is a proposed updated to pyprof2calltree. It adds a python 3
flavor and updates the now-defunct homepage. Moving to the current
release adds some bug fixes and new tests, which it passes.
This is a dependency for py-repoze-profile (on py2). A proposed update
to that port also follows.
Thanks,
Pamela
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 29 Sep 2015 10:52:11 -0000 1.11
+++ Makefile 31 Jan 2019 02:36:25 -0000
@@ -2,14 +2,13 @@
COMMENT = help visualize profiling data collected with the cProfile
-MODPY_EGG_VERSION = 1.3.2
+MODPY_EGG_VERSION = 1.4.4
DISTNAME = pyprof2calltree-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 0
CATEGORIES = devel
-HOMEPAGE = http://www.bitbucket.org/ogrisel/pyprof2calltree/
+HOMEPAGE = https://github.com/pwaller/pyprof2calltree
# BSD-derived
PERMIT_PACKAGE_CDROM = Yes
@@ -20,9 +19,15 @@ MODULES = lang/python
MODPY_SETUPTOOLS = Yes
+FLAVORS = python3
+FLAVOR ?=
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-pyprof2calltree
- ${INSTALL_DATA} ${WRKSRC}/README.txt \
- ${PREFIX}/share/doc/py-pyprof2calltree
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/${MODPY_PY_PREFIX}pyprof2calltree
+ ${INSTALL_DATA} ${WRKSRC}/README.rst \
+ ${PREFIX}/share/doc/${MODPY_PY_PREFIX}pyprof2calltree
+ for i in ${PREFIX}/bin/*; do \
+ mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
+ done
.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 19 Sep 2015 08:27:56 -0000 1.4
+++ distinfo 31 Jan 2019 02:36:25 -0000
@@ -1,2 +1,2 @@
-SHA256 (pyprof2calltree-1.3.2.tar.gz) = KOrIkmLQ7dhu4ldNJNGEDLyi1O1qHefh2PwF8w6lois=
-SIZE (pyprof2calltree-1.3.2.tar.gz) = 6609
+SHA256 (pyprof2calltree-1.4.4.tar.gz) = nsLU1wqhyz4uZahEUkfrMsHvKJu71kg3xj4JlCQfkOo=
+SIZE (pyprof2calltree-1.4.4.tar.gz) = 10061
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/py-pyprof2calltree/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 19 Sep 2015 08:27:56 -0000 1.3
+++ pkg/PLIST 31 Jan 2019 02:36:25 -0000
@@ -1,5 +1,6 @@
-@comment $OpenBSD: PLIST,v 1.3 2015/09/19 08:27:56 benoit Exp $
-bin/pyprof2calltree
+@comment $OpenBSD: PLIST,v$
+bin/pyprof2calltree${MODPY_BIN_SUFFIX}
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}pyprof2calltree.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
@@ -8,6 +9,5 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/pyprof2calltree.py
-lib/python${MODPY_VERSION}/site-packages/pyprof2calltree.pyc
share/doc/${MODPY_PY_PREFIX}pyprof2calltree/
-share/doc/${MODPY_PY_PREFIX}pyprof2calltree/README.txt
+share/doc/${MODPY_PY_PREFIX}pyprof2calltree/README.rst
Attached is a proposed updated to pyprof2calltree. It adds a python 3
flavor and updates the now-defunct homepage. Moving to the current
release adds some bug fixes and new tests, which it passes.
This is a dependency for py-repoze-profile (on py2). A proposed update
to that port also follows.
Thanks,
Pamela
Re: Questions about Carp / PF / PFSync
Charles Amstutz(charlesa@binary.net) on 2019.01.30 23:16:17 +0000:
> Hello
>
> We are running into an issue with a lot of dropped packets where states are failing to be created. We have noticed that it coincides with a fair amount of congestion, around 10-15/s according to 'pfctl -si'.
>
> We finally tried disabling our Carp Interfaces (we are using carp for failover) and the problem seems to completely go away. We have 53 carp interfaces on these two boxes and are just looking for some input on what might be causing an issue like this, where having carp interfaces enabled is causing such high congestion.
>
> We are running OpenBSD 6.4.
>
> Thanks,
Set sysctl net.inet.carp.log=7 (and activate carp again).
What does it show (in /var/log/messages)?
Also, whats the output of
sysctl net.inet.ip.ifq.drops
sysctl net.inet6.ip6.ifq.drops
netstat -m
pfctl -vsi
?
> Hello
>
> We are running into an issue with a lot of dropped packets where states are failing to be created. We have noticed that it coincides with a fair amount of congestion, around 10-15/s according to 'pfctl -si'.
>
> We finally tried disabling our Carp Interfaces (we are using carp for failover) and the problem seems to completely go away. We have 53 carp interfaces on these two boxes and are just looking for some input on what might be causing an issue like this, where having carp interfaces enabled is causing such high congestion.
>
> We are running OpenBSD 6.4.
>
> Thanks,
Set sysctl net.inet.carp.log=7 (and activate carp again).
What does it show (in /var/log/messages)?
Also, whats the output of
sysctl net.inet.ip.ifq.drops
sysctl net.inet6.ip6.ifq.drops
netstat -m
pfctl -vsi
?
Re: [NEW] x11/jgmenu with fixes
Hi
Thanks for you e-mail. I've just up-versioned to v2.0
https://github.com/johanmalm/jgmenu/blob/master/docs/relnotes/2.0.txt
I believe I've cleared all the issues you raised.
util.c: remove strcat() (commit 38e4e11a)
xsettings.c:231: use snprintf() (commit 26ea4c2d)
Replace "tar -T" in init module. It's not POSIX (commit 4ad9fcff)
Fix xdg segfault (commit 38668235)
Retire xdg module (commit b2dade4f)
jgmenu-pmenu.py: 437 KeyError for `Name_markup` (commit 3b4ba92)
Remove ff-bookmarks (commit 42a1d68c)
If xsettings is running but does not contain Gtk/FontName or
Net/IconThemeName, we get "fatal: icon theme has to be set before
icon_load()" (commit 38e4e11a)
Johan
On 1/2/19, Stuart Henderson <stu@spacehopper.org> wrote:
> On 2019/01/01 13:29, Heppler, J. Scott wrote:
>> Attached is the latest release of jgmenu. Upstream addressed multiple
>> issues
>> that Stuart Henderson brought up and now tests on their own install of
>> OpenBSD.
>>
>> https://marc.info/?l=openbsd-ports&m=154275564823284&w=2
>>
>> I started a new thread as the port version and pkg/README were updated.
>>
>> In x11/openbox, I've tested lx and ob menu generation. pmenu, lx and xdg
>> work
>> in the base fvwm, cwm and twm. ff-bookmarks also worked but may be
>> removed
>> upstream in the future.
>>
>> Additional testing, comments and consideration for adding to ports
>> appreciated.
>> --
>> J. Scott Heppler
>
> Cleaned up version attached. "jgmenu init" uses gnu-specific tar
> things so I've added it as a dependency. This one is OK sthen@
> if somebody would like to import it.
>
> There is still a coredump if I have xsettingsd running with my
> usual config:
>
> $ cat .xsettingsd
> Net/ThemeName "Adwaita"
>
> but that's probably uncommon enough that I don't think it should
> block import.
>
>
Thanks for you e-mail. I've just up-versioned to v2.0
https://github.com/johanmalm/jgmenu/blob/master/docs/relnotes/2.0.txt
I believe I've cleared all the issues you raised.
util.c: remove strcat() (commit 38e4e11a)
xsettings.c:231: use snprintf() (commit 26ea4c2d)
Replace "tar -T" in init module. It's not POSIX (commit 4ad9fcff)
Fix xdg segfault (commit 38668235)
Retire xdg module (commit b2dade4f)
jgmenu-pmenu.py: 437 KeyError for `Name_markup` (commit 3b4ba92)
Remove ff-bookmarks (commit 42a1d68c)
If xsettings is running but does not contain Gtk/FontName or
Net/IconThemeName, we get "fatal: icon theme has to be set before
icon_load()" (commit 38e4e11a)
Johan
On 1/2/19, Stuart Henderson <stu@spacehopper.org> wrote:
> On 2019/01/01 13:29, Heppler, J. Scott wrote:
>> Attached is the latest release of jgmenu. Upstream addressed multiple
>> issues
>> that Stuart Henderson brought up and now tests on their own install of
>> OpenBSD.
>>
>> https://marc.info/?l=openbsd-ports&m=154275564823284&w=2
>>
>> I started a new thread as the port version and pkg/README were updated.
>>
>> In x11/openbox, I've tested lx and ob menu generation. pmenu, lx and xdg
>> work
>> in the base fvwm, cwm and twm. ff-bookmarks also worked but may be
>> removed
>> upstream in the future.
>>
>> Additional testing, comments and consideration for adding to ports
>> appreciated.
>> --
>> J. Scott Heppler
>
> Cleaned up version attached. "jgmenu init" uses gnu-specific tar
> things so I've added it as a dependency. This one is OK sthen@
> if somebody would like to import it.
>
> There is still a coredump if I have xsettingsd running with my
> usual config:
>
> $ cat .xsettingsd
> Net/ThemeName "Adwaita"
>
> but that's probably uncommon enough that I don't think it should
> block import.
>
>
Getting traffic from rdomain X to talk to a daemon in default rdomain 0
Hello,
I'm trying to isolate an app running on OpenBSD on network level and thus I
have started
the app in a specific rdomain.
I can successfully make traffic from the rdomain to reach Internet:
pass out quick on rdomain 1 to any nat-to (egress) rtable 0
But I cannot figure out how to make the app in this rdomain 1 to communicate
which daemons in default rdomain (0).
With above rule I would see something like this on lo0 (rdomain0):
Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+ NS? .(17)
Tested with route -T 1 exec dig @199.195.x.x www.openbsd.org.
It seems it does not know how to send back replies ?
Without 'nat-to (egress)' the replies would be just send via default gw in
rdomain 0:
mx1# tcpdump -i vio0 -n -e -ttt icmp
tcpdump: listening on vio0, link-type EN10MB
Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
199.195.x.x > 172.16.1.2: icmp: echo reply
(172.16.1.2 was the IP in rdomain 1)
Any idea what would be PF rule to make this working - ie. make an app in
rdomain X talk to daemons in rdomain 0.
I also tried to use pair interfaces but I failed too.
Jiri
I'm trying to isolate an app running on OpenBSD on network level and thus I
have started
the app in a specific rdomain.
I can successfully make traffic from the rdomain to reach Internet:
pass out quick on rdomain 1 to any nat-to (egress) rtable 0
But I cannot figure out how to make the app in this rdomain 1 to communicate
which daemons in default rdomain (0).
With above rule I would see something like this on lo0 (rdomain0):
Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+ NS? .(17)
Tested with route -T 1 exec dig @199.195.x.x www.openbsd.org.
It seems it does not know how to send back replies ?
Without 'nat-to (egress)' the replies would be just send via default gw in
rdomain 0:
mx1# tcpdump -i vio0 -n -e -ttt icmp
tcpdump: listening on vio0, link-type EN10MB
Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
199.195.x.x > 172.16.1.2: icmp: echo reply
(172.16.1.2 was the IP in rdomain 1)
Any idea what would be PF rule to make this working - ie. make an app in
rdomain X talk to daemons in rdomain 0.
I also tried to use pair interfaces but I failed too.
Jiri
Re: [NEW] net/thingsd 1.0
On Thu, Jan 24, 2019 at 09:05:32PM +0000, Stuart Henderson wrote:
> On 2019/01/24 11:47, Tracey Emery wrote:
> > On Thu, Jan 24, 2019 at 09:39:51AM -0700, Tracey Emery wrote:
> > > On Wed, Jan 23, 2019 at 09:43:10PM +0000, Stuart Henderson wrote:
> > > > On 2019/01/17 09:39, Tracey Emery wrote:
> > > > > Hello,
> > > > >
> > > > > This is a new port request and a replacement for a formerly requested port,
> > > > > which should be disregarded (net/busybeed).
> > > > >
> > > > > thingsd has been completely refactored and cleaned up from the original
> > > > > busybeed, and now uses libevent from base.
> > > > >
> > > > > Description:
> > > > > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > > > > processes to communicate with an array of serial and IoT things. At its core,
> > > > > thingsd is primarily a packet repeater in that it waits for packets to swap
> > > > > between subscriber clients and things. However, thingsd also provides password
> > > > > control over those connections, including client limits.
> > > >
> > > > It probably makes sense to talk in DESCR about what protocols/devices are supported ..
> > >
> > > Howdy, is this what you're looking for? Does it make sense? Suggestions?
> > >
> > > Thanks,
> > > Tracey
> > >
> > > --- DESCR.orig Thu Jan 24 09:17:15 2019
> > > +++ DESCR Thu Jan 24 09:33:52 2019
> > > @@ -1,5 +1,16 @@
> > > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > > processes to communicate with an array of serial and IoT things. At its core,
> > > -thingsd is primarily a packet repeater in that it waits for packets to swap
> > > -between subscriber clients and things. However, thingsd also provides password
> > > -control over those connections, including client limits.
> > > +thingsd is primarily a data aggregator and repeater, in that it waits for
> > > +packets to swap between subscriber clients and things. However, thingsd also
> > > +provides password control over those connections, including client limits.
> > > +
> > > +On the client side, thingsd sets up TCP/IP sockets to transmit packets from
> > > +things, and vice versa. On the server side, thingsd can connect to any serial
> > > +device which has a viable file descriptor, create a persistent connection to
> > > +the IP address of a device transmitting packets on the same network, or setup a
> > > +UDP listener on the network to receive broadcasted packets. Devices tested
> > > +include: ESP8266/ESP32 modules, on both the serial and network sides, XBee
> > > +Series 2 coordinators connected in a mesh network, and NF24 devices. To
> > > +transmit to an IP address, which does not allow persistence, thingsd will
> > > +create an ad hoc connection, transmit a packet, and detach. The thingsd proxy
> > > +daemon is agnostic about packet data.
> >
> > I think the first sentence, second paragraph, makes more sense in this one.
> >
> > --- DESCR.orig Thu Jan 24 09:17:15 2019
> > +++ DESCR Thu Jan 24 11:44:44 2019
> > @@ -1,5 +1,16 @@
> > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > processes to communicate with an array of serial and IoT things. At its core,
> > -thingsd is primarily a packet repeater in that it waits for packets to swap
> > -between subscriber clients and things. However, thingsd also provides password
> > -control over those connections, including client limits.
> > +thingsd is primarily a data aggregator and repeater, in that it waits for
> > +packets to swap between subscriber clients and things. However, thingsd also
> > +provides password control over those connections, including client limits.
> > +
> > +On the client side, thingsd sets up TCP/IP sockets to transmit packets to and
> > +from things. On the server side, thingsd can connect to any serial device which
> > +has a viable file descriptor, create a persistent connection to the IP address
> > +of a device transmitting packets on the same network, or setup a UDP listener
> > +on the network to receive broadcasted packets. Devices tested include:
> > +ESP8266/ESP32 modules, on both the serial and network sides, XBee Series 2
> > +coordinators connected in a mesh network, and NF24 devices. To transmit to an
> > +IP address, which does not allow persistence, thingsd will create an ad hoc
> > +connection, transmit a packet, and detach. The thingsd proxy daemon is agnostic
> > +about packet data.
> >
>
> Thanks, yes that makes a lot more sense.
Attached is a newer version of thingsd, bumping to v1.2.
Changelog:
* Implement TLS for thing sockets
* Make description more descriptive
* Remove thingsctl installation until released
* Update all man files
* Add C example for TLS client
Thanks,
Tracey
> On 2019/01/24 11:47, Tracey Emery wrote:
> > On Thu, Jan 24, 2019 at 09:39:51AM -0700, Tracey Emery wrote:
> > > On Wed, Jan 23, 2019 at 09:43:10PM +0000, Stuart Henderson wrote:
> > > > On 2019/01/17 09:39, Tracey Emery wrote:
> > > > > Hello,
> > > > >
> > > > > This is a new port request and a replacement for a formerly requested port,
> > > > > which should be disregarded (net/busybeed).
> > > > >
> > > > > thingsd has been completely refactored and cleaned up from the original
> > > > > busybeed, and now uses libevent from base.
> > > > >
> > > > > Description:
> > > > > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > > > > processes to communicate with an array of serial and IoT things. At its core,
> > > > > thingsd is primarily a packet repeater in that it waits for packets to swap
> > > > > between subscriber clients and things. However, thingsd also provides password
> > > > > control over those connections, including client limits.
> > > >
> > > > It probably makes sense to talk in DESCR about what protocols/devices are supported ..
> > >
> > > Howdy, is this what you're looking for? Does it make sense? Suggestions?
> > >
> > > Thanks,
> > > Tracey
> > >
> > > --- DESCR.orig Thu Jan 24 09:17:15 2019
> > > +++ DESCR Thu Jan 24 09:33:52 2019
> > > @@ -1,5 +1,16 @@
> > > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > > processes to communicate with an array of serial and IoT things. At its core,
> > > -thingsd is primarily a packet repeater in that it waits for packets to swap
> > > -between subscriber clients and things. However, thingsd also provides password
> > > -control over those connections, including client limits.
> > > +thingsd is primarily a data aggregator and repeater, in that it waits for
> > > +packets to swap between subscriber clients and things. However, thingsd also
> > > +provides password control over those connections, including client limits.
> > > +
> > > +On the client side, thingsd sets up TCP/IP sockets to transmit packets from
> > > +things, and vice versa. On the server side, thingsd can connect to any serial
> > > +device which has a viable file descriptor, create a persistent connection to
> > > +the IP address of a device transmitting packets on the same network, or setup a
> > > +UDP listener on the network to receive broadcasted packets. Devices tested
> > > +include: ESP8266/ESP32 modules, on both the serial and network sides, XBee
> > > +Series 2 coordinators connected in a mesh network, and NF24 devices. To
> > > +transmit to an IP address, which does not allow persistence, thingsd will
> > > +create an ad hoc connection, transmit a packet, and detach. The thingsd proxy
> > > +daemon is agnostic about packet data.
> >
> > I think the first sentence, second paragraph, makes more sense in this one.
> >
> > --- DESCR.orig Thu Jan 24 09:17:15 2019
> > +++ DESCR Thu Jan 24 11:44:44 2019
> > @@ -1,5 +1,16 @@
> > The thingsd OpenBSD proxy daemon provides a mechanism for clients and client
> > processes to communicate with an array of serial and IoT things. At its core,
> > -thingsd is primarily a packet repeater in that it waits for packets to swap
> > -between subscriber clients and things. However, thingsd also provides password
> > -control over those connections, including client limits.
> > +thingsd is primarily a data aggregator and repeater, in that it waits for
> > +packets to swap between subscriber clients and things. However, thingsd also
> > +provides password control over those connections, including client limits.
> > +
> > +On the client side, thingsd sets up TCP/IP sockets to transmit packets to and
> > +from things. On the server side, thingsd can connect to any serial device which
> > +has a viable file descriptor, create a persistent connection to the IP address
> > +of a device transmitting packets on the same network, or setup a UDP listener
> > +on the network to receive broadcasted packets. Devices tested include:
> > +ESP8266/ESP32 modules, on both the serial and network sides, XBee Series 2
> > +coordinators connected in a mesh network, and NF24 devices. To transmit to an
> > +IP address, which does not allow persistence, thingsd will create an ad hoc
> > +connection, transmit a packet, and detach. The thingsd proxy daemon is agnostic
> > +about packet data.
> >
>
> Thanks, yes that makes a lot more sense.
Attached is a newer version of thingsd, bumping to v1.2.
Changelog:
* Implement TLS for thing sockets
* Make description more descriptive
* Remove thingsctl installation until released
* Update all man files
* Add C example for TLS client
Thanks,
Tracey
Re: UPDATE: net/kismet
Hi,
On Wed, Jan 30, 2019 at 11:01:39PM +0100, Sebastian Reitenbach wrote:
> This updates our ancient Kismet to the 2016-07-R1 release.
I can give it a try next monday.
Ciao,
Kili
On Wed, Jan 30, 2019 at 11:01:39PM +0100, Sebastian Reitenbach wrote:
> This updates our ancient Kismet to the 2016-07-R1 release.
I can give it a try next monday.
Ciao,
Kili
Re: dwm and chromium
On 2019/01/31 19:21, Klemens Nanni wrote:
> On Tue, Jan 29, 2019 at 10:44:55PM -0500, Ted Unangst wrote:
> > It annoys me that chrome doesn't start on screen 9 like firefox does.
> > (Especially since it takes a few seconds to start, so I'm always surprised
> > when the window finally appears and disrupts my current screen.)
> > Easily fixed.
> Which rules to add to or remove from upstream's set as well as the
> specified tags have great potential for bike shedding.
Like: why would you want both browsers opening on the same screen? ;-)
> Since dwm is designed to be patched and recompiled for personal taste,
> I tend to avoid such changes in our port and leave them to users.
>
> On the other hand, the firefox rule has been there for ages and doing
> the same with chromium makes sense consistency wise.
>
> That said, no objections from me, but please refrain from further
> config patches or send them directly upstream.
>
> Does that make sense?
>
> On Tue, Jan 29, 2019 at 10:44:55PM -0500, Ted Unangst wrote:
> > It annoys me that chrome doesn't start on screen 9 like firefox does.
> > (Especially since it takes a few seconds to start, so I'm always surprised
> > when the window finally appears and disrupts my current screen.)
> > Easily fixed.
> Which rules to add to or remove from upstream's set as well as the
> specified tags have great potential for bike shedding.
Like: why would you want both browsers opening on the same screen? ;-)
> Since dwm is designed to be patched and recompiled for personal taste,
> I tend to avoid such changes in our port and leave them to users.
>
> On the other hand, the firefox rule has been there for ages and doing
> the same with chromium makes sense consistency wise.
>
> That said, no objections from me, but please refrain from further
> config patches or send them directly upstream.
>
> Does that make sense?
>
Re: dwm and chromium
On Thu, Jan 31, 2019 at 08:02:07PM +0100, Solene Rapenne wrote:
> Should we add Iridium too then to stay consistent with chromium and
> firefox?
They're the same: see `xprop WM_CLASS', then click on both an Iridium
and Chromium window.
WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"
> Should we add Iridium too then to stay consistent with chromium and
> firefox?
They're the same: see `xprop WM_CLASS', then click on both an Iridium
and Chromium window.
WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"
Re: dwm and chromium
On Thu, Jan 31, 2019 at 07:21:48PM +0100, Klemens Nanni wrote:
> On Tue, Jan 29, 2019 at 10:44:55PM -0500, Ted Unangst wrote:
> > It annoys me that chrome doesn't start on screen 9 like firefox does.
> > (Especially since it takes a few seconds to start, so I'm always surprised
> > when the window finally appears and disrupts my current screen.)
> > Easily fixed.
> Which rules to add to or remove from upstream's set as well as the
> specified tags have great potential for bike shedding.
>
> Since dwm is designed to be patched and recompiled for personal taste,
> I tend to avoid such changes in our port and leave them to users.
>
> On the other hand, the firefox rule has been there for ages and doing
> the same with chromium makes sense consistency wise.
>
> That said, no objections from me, but please refrain from further
> config patches or send them directly upstream.
>
> Does that make sense?
>
Should we add Iridium too then to stay consistent with chromium and
firefox? From statistics[1] of my small samples (17 amd64 6.4-current
machines), I see 5 iridium, 7 chromium and 13 firefox installed.
[1] https://pkgstat-openbsd.perso.pw/index.php?osversion=6.4-current&arch=amd64
> On Tue, Jan 29, 2019 at 10:44:55PM -0500, Ted Unangst wrote:
> > It annoys me that chrome doesn't start on screen 9 like firefox does.
> > (Especially since it takes a few seconds to start, so I'm always surprised
> > when the window finally appears and disrupts my current screen.)
> > Easily fixed.
> Which rules to add to or remove from upstream's set as well as the
> specified tags have great potential for bike shedding.
>
> Since dwm is designed to be patched and recompiled for personal taste,
> I tend to avoid such changes in our port and leave them to users.
>
> On the other hand, the firefox rule has been there for ages and doing
> the same with chromium makes sense consistency wise.
>
> That said, no objections from me, but please refrain from further
> config patches or send them directly upstream.
>
> Does that make sense?
>
Should we add Iridium too then to stay consistent with chromium and
firefox? From statistics[1] of my small samples (17 amd64 6.4-current
machines), I see 5 iridium, 7 chromium and 13 firefox installed.
[1] https://pkgstat-openbsd.perso.pw/index.php?osversion=6.4-current&arch=amd64
Re: Use xenodm like startx?
My .xsession looks like this:
userresources=$HOME/.Xresources
if [ -f "$userresources" ]; then
/usr/X11R6/bin/xrdb -merge "$userresources"
fi
export ENV='$HOME/.kshrc'
# See /usr/local/share/doc/pkg-readmes/dbus
# if dbus is installed, start its daemon
if [ -x /usr/local/bin/dbus-launch -a -z "${DBUS_SESSION_BUS_ADDRESS}"
]; then
eval `dbus-launch --sh-syntax --exit-with-x11`
fi
# I like my cursor bigger, needs adwaita-icon-theme port
export XCURSOR_PATH="/usr/local/share/icons"
export XCURSOR_THEME=Adwaita
export XCURSOR_SIZE=32
numlockx on &
exec icewm-session
On 1/31/19 10:36 AM, trondd wrote:
> On Thu, January 31, 2019 5:57 am, John Ankarström wrote:
>>> Only thing I never figured out is how to make X and xenodm shutdown when
>>> I
>>> exit my window manager.
>> This too makes me feel like xenodm is far too complex for what I want.
>>
> It's not an issue of complexity. It's a different tool that does a
> different thing. Bending it to work like something it's not will
> inherently have caveats.
>
> The thing is, what we had before was a trivial privilege escalation.
> Sometimes you just have to adapt a little and you can benefit greatly from
> improvements.
>
> Tim.
>
userresources=$HOME/.Xresources
if [ -f "$userresources" ]; then
/usr/X11R6/bin/xrdb -merge "$userresources"
fi
export ENV='$HOME/.kshrc'
# See /usr/local/share/doc/pkg-readmes/dbus
# if dbus is installed, start its daemon
if [ -x /usr/local/bin/dbus-launch -a -z "${DBUS_SESSION_BUS_ADDRESS}"
]; then
eval `dbus-launch --sh-syntax --exit-with-x11`
fi
# I like my cursor bigger, needs adwaita-icon-theme port
export XCURSOR_PATH="/usr/local/share/icons"
export XCURSOR_THEME=Adwaita
export XCURSOR_SIZE=32
numlockx on &
exec icewm-session
On 1/31/19 10:36 AM, trondd wrote:
> On Thu, January 31, 2019 5:57 am, John Ankarström wrote:
>>> Only thing I never figured out is how to make X and xenodm shutdown when
>>> I
>>> exit my window manager.
>> This too makes me feel like xenodm is far too complex for what I want.
>>
> It's not an issue of complexity. It's a different tool that does a
> different thing. Bending it to work like something it's not will
> inherently have caveats.
>
> The thing is, what we had before was a trivial privilege escalation.
> Sometimes you just have to adapt a little and you can benefit greatly from
> improvements.
>
> Tim.
>
Re: dwm and chromium
On Tue, Jan 29, 2019 at 10:44:55PM -0500, Ted Unangst wrote:
> It annoys me that chrome doesn't start on screen 9 like firefox does.
> (Especially since it takes a few seconds to start, so I'm always surprised
> when the window finally appears and disrupts my current screen.)
> Easily fixed.
Which rules to add to or remove from upstream's set as well as the
specified tags have great potential for bike shedding.
Since dwm is designed to be patched and recompiled for personal taste,
I tend to avoid such changes in our port and leave them to users.
On the other hand, the firefox rule has been there for ages and doing
the same with chromium makes sense consistency wise.
That said, no objections from me, but please refrain from further
config patches or send them directly upstream.
Does that make sense?
> It annoys me that chrome doesn't start on screen 9 like firefox does.
> (Especially since it takes a few seconds to start, so I'm always surprised
> when the window finally appears and disrupts my current screen.)
> Easily fixed.
Which rules to add to or remove from upstream's set as well as the
specified tags have great potential for bike shedding.
Since dwm is designed to be patched and recompiled for personal taste,
I tend to avoid such changes in our port and leave them to users.
On the other hand, the firefox rule has been there for ages and doing
the same with chromium makes sense consistency wise.
That said, no objections from me, but please refrain from further
config patches or send them directly upstream.
Does that make sense?
Re: update pcre2 MASTER_SITES
On Thu, Jan 31 2019, Stuart Henderson <stu@spacehopper.org> wrote:
> On 2019/01/31 18:35, Jeremie Courreges-Anglas wrote:
>> > What does 3.0 mean in "0.1 # 3.0" mean?
>>
>> It's what would have been used by the build system if we had not
>> overriden the version number in ports.
>>
>> > I see that 0.1 is major.minor.
>> > ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
>> > this only useful in initially drafting a new port and not so much in
>> > updating a port?
>>
>> It's not even useful when starting a port, since we completely ignore
>> upstream's choices and start at 0.0. I try to update those markers when
>> I can, but I think it's usually a lost cause. Some upstreams don't
>> properly bump the major/minor when due, and some upstreams bump the
>> major/minor even when not needed. So a porter has to make her own
>> checks anyway, and the marker has little value.
>
> In cases where the upstream does follow the rules, a bump there can be a
> useful indication that they've changed something which the porter might
> not have noticed (it's fairly common for people to take shortcuts and
> just check for new/removed symbols rather than looking at headers..)
> So I do try to keep these up to date.
I just doubt that people who like shortcuts and don't do a thorough
symbols + includes check will notice a change in shared_libs.log, but
YMMV. :)
Here's a proposal to unbreak the test. The idea is not to add yet
another hardcoded, os-specific workaround in that script, but to run all
tests even if that means a TEST_DEPENDS. I won't insist if people
prefer another approach, though.
ok?
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/pcre2/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 31 Jan 2019 17:40:30 -0000 1.8
+++ Makefile 31 Jan 2019 17:59:52 -0000
@@ -25,6 +25,7 @@ PERMIT_PACKAGE_CDROM = Yes
WANTLIB += bz2 c curses readline z
LIB_DEPENDS = archivers/bzip2
+TEST_DEPENDS = textproc/gsed
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS = --enable-pcre2-16 \
Index: patches/patch-RunGrepTest
===================================================================
RCS file: patches/patch-RunGrepTest
diff -N patches/patch-RunGrepTest
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-RunGrepTest 31 Jan 2019 17:59:53 -0000
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Our sed(1) doesn't cope with NUL bytes and \x00-style notation.
+
+Index: RunGrepTest
+--- RunGrepTest.orig
++++ RunGrepTest
+@@ -723,7 +723,7 @@ printf '%c--------------------------- Test N7 --------
+ uname=`uname`
+ if [ "$uname" != "SunOS" -a "$uname" != "Darwin" ] ; then
+ printf 'abc\0def' >testNinputgrep
+- $valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep | sed 's/\x00/ZERO/' >>testtrygrep
++ $valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep | gsed 's/\x00/ZERO/' >>testtrygrep
+ echo "" >>testtrygrep
+ else
+ echo '1:abcZERO2:def' >>testtrygrep
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> On 2019/01/31 18:35, Jeremie Courreges-Anglas wrote:
>> > What does 3.0 mean in "0.1 # 3.0" mean?
>>
>> It's what would have been used by the build system if we had not
>> overriden the version number in ports.
>>
>> > I see that 0.1 is major.minor.
>> > ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
>> > this only useful in initially drafting a new port and not so much in
>> > updating a port?
>>
>> It's not even useful when starting a port, since we completely ignore
>> upstream's choices and start at 0.0. I try to update those markers when
>> I can, but I think it's usually a lost cause. Some upstreams don't
>> properly bump the major/minor when due, and some upstreams bump the
>> major/minor even when not needed. So a porter has to make her own
>> checks anyway, and the marker has little value.
>
> In cases where the upstream does follow the rules, a bump there can be a
> useful indication that they've changed something which the porter might
> not have noticed (it's fairly common for people to take shortcuts and
> just check for new/removed symbols rather than looking at headers..)
> So I do try to keep these up to date.
I just doubt that people who like shortcuts and don't do a thorough
symbols + includes check will notice a change in shared_libs.log, but
YMMV. :)
Here's a proposal to unbreak the test. The idea is not to add yet
another hardcoded, os-specific workaround in that script, but to run all
tests even if that means a TEST_DEPENDS. I won't insist if people
prefer another approach, though.
ok?
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/pcre2/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 31 Jan 2019 17:40:30 -0000 1.8
+++ Makefile 31 Jan 2019 17:59:52 -0000
@@ -25,6 +25,7 @@ PERMIT_PACKAGE_CDROM = Yes
WANTLIB += bz2 c curses readline z
LIB_DEPENDS = archivers/bzip2
+TEST_DEPENDS = textproc/gsed
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS = --enable-pcre2-16 \
Index: patches/patch-RunGrepTest
===================================================================
RCS file: patches/patch-RunGrepTest
diff -N patches/patch-RunGrepTest
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-RunGrepTest 31 Jan 2019 17:59:53 -0000
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Our sed(1) doesn't cope with NUL bytes and \x00-style notation.
+
+Index: RunGrepTest
+--- RunGrepTest.orig
++++ RunGrepTest
+@@ -723,7 +723,7 @@ printf '%c--------------------------- Test N7 --------
+ uname=`uname`
+ if [ "$uname" != "SunOS" -a "$uname" != "Darwin" ] ; then
+ printf 'abc\0def' >testNinputgrep
+- $valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep | sed 's/\x00/ZERO/' >>testtrygrep
++ $valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep | gsed 's/\x00/ZERO/' >>testtrygrep
+ echo "" >>testtrygrep
+ else
+ echo '1:abcZERO2:def' >>testtrygrep
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: update pcre2 MASTER_SITES
On 2019/01/31 18:35, Jeremie Courreges-Anglas wrote:
> > What does 3.0 mean in "0.1 # 3.0" mean?
>
> It's what would have been used by the build system if we had not
> overriden the version number in ports.
>
> > I see that 0.1 is major.minor.
> > ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
> > this only useful in initially drafting a new port and not so much in
> > updating a port?
>
> It's not even useful when starting a port, since we completely ignore
> upstream's choices and start at 0.0. I try to update those markers when
> I can, but I think it's usually a lost cause. Some upstreams don't
> properly bump the major/minor when due, and some upstreams bump the
> major/minor even when not needed. So a porter has to make her own
> checks anyway, and the marker has little value.
In cases where the upstream does follow the rules, a bump there can be a
useful indication that they've changed something which the porter might
not have noticed (it's fairly common for people to take shortcuts and
just check for new/removed symbols rather than looking at headers..)
So I do try to keep these up to date.
> > What does 3.0 mean in "0.1 # 3.0" mean?
>
> It's what would have been used by the build system if we had not
> overriden the version number in ports.
>
> > I see that 0.1 is major.minor.
> > ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
> > this only useful in initially drafting a new port and not so much in
> > updating a port?
>
> It's not even useful when starting a port, since we completely ignore
> upstream's choices and start at 0.0. I try to update those markers when
> I can, but I think it's usually a lost cause. Some upstreams don't
> properly bump the major/minor when due, and some upstreams bump the
> major/minor even when not needed. So a porter has to make her own
> checks anyway, and the marker has little value.
In cases where the upstream does follow the rules, a bump there can be a
useful indication that they've changed something which the porter might
not have noticed (it's fairly common for people to take shortcuts and
just check for new/removed symbols rather than looking at headers..)
So I do try to keep these up to date.
Re: update pcre2 MASTER_SITES
On Sat, Jan 26 2019, Nam Nguyen <namn@berkeley.edu> wrote:
>> Upstream still has FTP so please leave the ftp:// URL in so that "make
>> peek-ftp" works.
> OK I left ftp://.
>
>> Have you looked at the update to 10.32?
> Here is my attempt. I am new to ports, so I need help with respect to
> understanding bumping major.minor of shared libraries.
>
> The API has remained the same. No functions were added or removed.
>
> I included some interesting snippets from the changelog and looked out
> for reasons to bump the major, primarily "valid calling sequences are no
> longer valid."
>
> Only items #21 and #39 seem like they might qualify (as in something
> that used to work before but no longer works). However, these seem so
> insignificant (and based on CVS history) that I believe this should be
> minor bumps across the board?
Unless I missed something you didn't mention a reason to even bump the
minor. No symbols have beed added/removed, no structures or function
signatures have been changed. *But* there are new error codes exposed
in pcre2.h, so technically some consumers might depend on it, thus
I think a minor bump makes sense.
> What does 3.0 mean in "0.1 # 3.0" mean?
It's what would have been used by the build system if we had not
overriden the version number in ports.
> I see that 0.1 is major.minor.
> ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
> this only useful in initially drafting a new port and not so much in
> updating a port?
It's not even useful when starting a port, since we completely ignore
upstream's choices and start at 0.0. I try to update those markers when
I can, but I think it's usually a lost cause. Some upstreams don't
properly bump the major/minor when due, and some upstreams bump the
major/minor even when not needed. So a porter has to make her own
checks anyway, and the marker has little value.
The test suite (RunGrepTest) could be tweaked to either use gsed(1) or
work around the failing test, but that can be done later. With
a patched RunGrepTest, tests already pass on amd64 with 10.31, and also
pass on amd64 and sparc64 with 10.32.
I'm going to commit this, minus one nit below (no need to resend a diff),
> For testing, I built the new wget against pcre2 and downloaded an
> OpenBSD install64.iso.
>
> Changelog: https://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=1001
> ----8<------------------------------------------------------------
> 1. When matching using the the REG_STARTEND feature of the POSIX API with a
> non-zero starting offset, unset capturing groups with lower numbers than a
> group that did capture something were not being correctly returned as "unset"
> (that is, with offset values of -1).
>
> 21. In both pcre2test and pcre2_substitute(), with global matching, a pattern
> that matched an empty string, but never at the starting match offset, was not
> handled in a Perl-compatible way. The pattern /(<?=\G.)/ is an example of such
> a pattern. Because \G is in a lookbehind assertion, there has to be a
> "bumpalong" before there can be a match. The automatic "advance by one
> character after an empty string match" rule is therefore inappropriate. A more
> complicated algorithm has now been implemented.
>
> 35. In a pattern such as /[^\x{100}-\x{ffff}]*[\x80-\xff]/ which has a repeated
> negative class with no characters less than 0x100 followed by a positive class
> with only characters less than 0x100, the first class was incorrectly being
> auto-possessified, causing incorrect match failures.
>
> 39. If the only branch in a conditional subpattern was anchored, the whole
> subpattern was treated as anchored, when it should not have been, since the
> assumed empty second branch cannot be anchored. Demonstrated by test patterns
> such as /(?(1)^())b/ or /(?(?=^))b/.
>
> 40. A repeated conditional subpattern that could match an empty string was
> always assumed to be unanchored. Now it it checked just like any other
> repeated conditional subpattern, and can be found to be anchored if the minimum
> quantifier is one or more. I can't see much use for a repeated anchored
> pattern, but the behaviour is now consistent.
> ----8<------------------------------------------------------------
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile 14 Nov 2018 20:48:21 -0000 1.7
> +++ Makefile 26 Jan 2019 22:58:51 -0000
> @@ -2,20 +2,23 @@
>
> COMMENT = perl-compatible regular expression library, version 2
>
> -DISTNAME = pcre2-10.31
> +DISTNAME = pcre2-10.32
> REVISION = 0
REVISION should be dropped when performing an update.
>
> -SHARED_LIBS += pcre2-16 0.1 # 3.0
> -SHARED_LIBS += pcre2-32 0.1 # 3.0
> -SHARED_LIBS += pcre2-8 0.2 # 3.0
> -SHARED_LIBS += pcre2-posix 0.1 # 0.1
> +SHARED_LIBS += pcre2-16 0.2 # 3.0
> +SHARED_LIBS += pcre2-32 0.2 # 3.0
> +SHARED_LIBS += pcre2-8 0.3 # 3.0
> +SHARED_LIBS += pcre2-posix 0.2 # 0.1
>
> CATEGORIES = devel
>
> -MASTER_SITES = http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> +MASTER_SITES = https://ftp.pcre.org/pub/pcre/ \
> + ${MASTER_SITE_SOURCEFORGE:=pcre/} \
> + http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
>
> -HOMEPAGE = http://www.pcre.org/
> +HOMEPAGE = https://www.pcre.org/
> +MAINTAINER = Nam Nguyen <namn@berkeley.edu>
>
> # BSD
> PERMIT_PACKAGE_CDROM = Yes
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 26 Apr 2018 13:06:01 -0000 1.3
> +++ distinfo 26 Jan 2019 22:58:51 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (pcre2-10.31.tar.gz) = 4R69md0jp7zMkSfZXZl4EBtfPPCm59JaGxyhZalxZsQ=
> -SIZE (pcre2-10.31.tar.gz) = 2130574
> +SHA256 (pcre2-10.32.tar.gz) = nKm+cuGgTyK+MIMjyqjAbr0MUe/pnuESeBhsr7xP468=
> +SIZE (pcre2-10.32.tar.gz) = 2169349
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>> Upstream still has FTP so please leave the ftp:// URL in so that "make
>> peek-ftp" works.
> OK I left ftp://.
>
>> Have you looked at the update to 10.32?
> Here is my attempt. I am new to ports, so I need help with respect to
> understanding bumping major.minor of shared libraries.
>
> The API has remained the same. No functions were added or removed.
>
> I included some interesting snippets from the changelog and looked out
> for reasons to bump the major, primarily "valid calling sequences are no
> longer valid."
>
> Only items #21 and #39 seem like they might qualify (as in something
> that used to work before but no longer works). However, these seem so
> insignificant (and based on CVS history) that I believe this should be
> minor bumps across the board?
Unless I missed something you didn't mention a reason to even bump the
minor. No symbols have beed added/removed, no structures or function
signatures have been changed. *But* there are new error codes exposed
in pcre2.h, so technically some consumers might depend on it, thus
I think a minor bump makes sense.
> What does 3.0 mean in "0.1 # 3.0" mean?
It's what would have been used by the build system if we had not
overriden the version number in ports.
> I see that 0.1 is major.minor.
> ${WRKBUILD}/shared_libs.log can be included in the port's Makefile. Is
> this only useful in initially drafting a new port and not so much in
> updating a port?
It's not even useful when starting a port, since we completely ignore
upstream's choices and start at 0.0. I try to update those markers when
I can, but I think it's usually a lost cause. Some upstreams don't
properly bump the major/minor when due, and some upstreams bump the
major/minor even when not needed. So a porter has to make her own
checks anyway, and the marker has little value.
The test suite (RunGrepTest) could be tweaked to either use gsed(1) or
work around the failing test, but that can be done later. With
a patched RunGrepTest, tests already pass on amd64 with 10.31, and also
pass on amd64 and sparc64 with 10.32.
I'm going to commit this, minus one nit below (no need to resend a diff),
> For testing, I built the new wget against pcre2 and downloaded an
> OpenBSD install64.iso.
>
> Changelog: https://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=1001
> ----8<------------------------------------------------------------
> 1. When matching using the the REG_STARTEND feature of the POSIX API with a
> non-zero starting offset, unset capturing groups with lower numbers than a
> group that did capture something were not being correctly returned as "unset"
> (that is, with offset values of -1).
>
> 21. In both pcre2test and pcre2_substitute(), with global matching, a pattern
> that matched an empty string, but never at the starting match offset, was not
> handled in a Perl-compatible way. The pattern /(<?=\G.)/ is an example of such
> a pattern. Because \G is in a lookbehind assertion, there has to be a
> "bumpalong" before there can be a match. The automatic "advance by one
> character after an empty string match" rule is therefore inappropriate. A more
> complicated algorithm has now been implemented.
>
> 35. In a pattern such as /[^\x{100}-\x{ffff}]*[\x80-\xff]/ which has a repeated
> negative class with no characters less than 0x100 followed by a positive class
> with only characters less than 0x100, the first class was incorrectly being
> auto-possessified, causing incorrect match failures.
>
> 39. If the only branch in a conditional subpattern was anchored, the whole
> subpattern was treated as anchored, when it should not have been, since the
> assumed empty second branch cannot be anchored. Demonstrated by test patterns
> such as /(?(1)^())b/ or /(?(?=^))b/.
>
> 40. A repeated conditional subpattern that could match an empty string was
> always assumed to be unanchored. Now it it checked just like any other
> repeated conditional subpattern, and can be found to be anchored if the minimum
> quantifier is one or more. I can't see much use for a repeated anchored
> pattern, but the behaviour is now consistent.
> ----8<------------------------------------------------------------
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile 14 Nov 2018 20:48:21 -0000 1.7
> +++ Makefile 26 Jan 2019 22:58:51 -0000
> @@ -2,20 +2,23 @@
>
> COMMENT = perl-compatible regular expression library, version 2
>
> -DISTNAME = pcre2-10.31
> +DISTNAME = pcre2-10.32
> REVISION = 0
REVISION should be dropped when performing an update.
>
> -SHARED_LIBS += pcre2-16 0.1 # 3.0
> -SHARED_LIBS += pcre2-32 0.1 # 3.0
> -SHARED_LIBS += pcre2-8 0.2 # 3.0
> -SHARED_LIBS += pcre2-posix 0.1 # 0.1
> +SHARED_LIBS += pcre2-16 0.2 # 3.0
> +SHARED_LIBS += pcre2-32 0.2 # 3.0
> +SHARED_LIBS += pcre2-8 0.3 # 3.0
> +SHARED_LIBS += pcre2-posix 0.2 # 0.1
>
> CATEGORIES = devel
>
> -MASTER_SITES = http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> +MASTER_SITES = https://ftp.pcre.org/pub/pcre/ \
> + ${MASTER_SITE_SOURCEFORGE:=pcre/} \
> + http://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
>
> -HOMEPAGE = http://www.pcre.org/
> +HOMEPAGE = https://www.pcre.org/
> +MAINTAINER = Nam Nguyen <namn@berkeley.edu>
>
> # BSD
> PERMIT_PACKAGE_CDROM = Yes
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/devel/pcre2/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 26 Apr 2018 13:06:01 -0000 1.3
> +++ distinfo 26 Jan 2019 22:58:51 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (pcre2-10.31.tar.gz) = 4R69md0jp7zMkSfZXZl4EBtfPPCm59JaGxyhZalxZsQ=
> -SIZE (pcre2-10.31.tar.gz) = 2130574
> +SHA256 (pcre2-10.32.tar.gz) = nKm+cuGgTyK+MIMjyqjAbr0MUe/pnuESeBhsr7xP468=
> +SIZE (pcre2-10.32.tar.gz) = 2169349
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: aarch64: use gcc8 as ports-gcc
On 2019/01/31 11:28, Peter Hessler wrote:
> On 2019 Jan 04 (Fri) at 17:57:54 +0100 (+0100), Pascal Stumpf wrote:
> :This switches aarch64 to use GCC 8.2.0 as default. Doesn't do any harm
> :because this is the first GCC port that works there.
> :
> :We still need to decide whether to hook up gcc8 on all archs or aarch64
> :only ...
> :
>
> Hook up gcc8 on all arches, it doesn't make sense not to.
OK provided that there is no problem building any of the hooked up
versions with 4.9 installed (and vice-versa).
> :
> :Index: gcc4.port.mk
> :===================================================================
> :RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
> :retrieving revision 1.12
> :diff -u -p -r1.12 gcc4.port.mk
> :--- gcc4.port.mk 8 Mar 2016 16:46:05 -0000 1.12
> :+++ gcc4.port.mk 4 Jan 2019 16:02:48 -0000
> :@@ -1,2 +1,6 @@
> :+.if ${MACHINE_ARCH} == "aarch64"
> :+MODGCC4_VERSION?=8
> :+.else
> : MODGCC4_VERSION?=4.9
> :+.endif
> : .include "${PORTSDIR}/lang/gcc/${MODGCC4_VERSION}/gcc4.port.mk"
> :
>
> I have this applied locally on my bulk builds for the last 3-4 builds.
>
> OK
>
>
> --
> Finagle's Creed:
> Science is true. Don't be misled by facts.
>
I think we should just switch all arches. There may be some new failures,
but these arches aren't in great shape anyway and equally it's likely
to fix some things (we currently have problems on gcc arches with ports
depending on ICU due to the mixture of default C++ standards which
I am expecting to be helped by this move as gcc 6.1+ uses c++14 by
default).
Switching all arches will however require bumps for ports using gcc.
> On 2019 Jan 04 (Fri) at 17:57:54 +0100 (+0100), Pascal Stumpf wrote:
> :This switches aarch64 to use GCC 8.2.0 as default. Doesn't do any harm
> :because this is the first GCC port that works there.
> :
> :We still need to decide whether to hook up gcc8 on all archs or aarch64
> :only ...
> :
>
> Hook up gcc8 on all arches, it doesn't make sense not to.
OK provided that there is no problem building any of the hooked up
versions with 4.9 installed (and vice-versa).
> :
> :Index: gcc4.port.mk
> :===================================================================
> :RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
> :retrieving revision 1.12
> :diff -u -p -r1.12 gcc4.port.mk
> :--- gcc4.port.mk 8 Mar 2016 16:46:05 -0000 1.12
> :+++ gcc4.port.mk 4 Jan 2019 16:02:48 -0000
> :@@ -1,2 +1,6 @@
> :+.if ${MACHINE_ARCH} == "aarch64"
> :+MODGCC4_VERSION?=8
> :+.else
> : MODGCC4_VERSION?=4.9
> :+.endif
> : .include "${PORTSDIR}/lang/gcc/${MODGCC4_VERSION}/gcc4.port.mk"
> :
>
> I have this applied locally on my bulk builds for the last 3-4 builds.
>
> OK
>
>
> --
> Finagle's Creed:
> Science is true. Don't be misled by facts.
>
I think we should just switch all arches. There may be some new failures,
but these arches aren't in great shape anyway and equally it's likely
to fix some things (we currently have problems on gcc arches with ports
depending on ICU due to the mixture of default C++ standards which
I am expecting to be helped by this move as gcc 6.1+ uses c++14 by
default).
Switching all arches will however require bumps for ports using gcc.
Re: sparc64 and C++ exceptions
On Thu, Jan 31, 2019 at 05:17:33PM +0000, Stuart Henderson wrote:
> On 2019/01/31 01:12, Tinker wrote:
> > Reading your log file
> > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > , there is mentioning of libestdc++ in there.
>
> That doesn't use g++ from base though, only the ports version.
> I went through all C++ ports not on the direct path to building gcc
> and added a COMPILER line so they are built with ports gcc.
>
Meanwhile, kettenis@ mentioned the probably cause. I'm currently
building ports gcc on sparc64 with a diff that could fix things.
Specifically, the stack frames on OpenBSD are different compared to
other systems since we have stackghost.
See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
-Otto
> On 2019/01/31 01:12, Tinker wrote:
> > Reading your log file
> > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > , there is mentioning of libestdc++ in there.
>
> That doesn't use g++ from base though, only the ports version.
> I went through all C++ ports not on the direct path to building gcc
> and added a COMPILER line so they are built with ports gcc.
>
Meanwhile, kettenis@ mentioned the probably cause. I'm currently
building ports gcc on sparc64 with a diff that could fix things.
Specifically, the stack frames on OpenBSD are different compared to
other systems since we have stackghost.
See http://projects.cerias.purdue.edu/stackghost/stackghost/stackghost.html
-Otto
Re: sparc64 and C++ exceptions
On 2019/01/31 01:12, Tinker wrote:
> Reading your log file
> http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> , there is mentioning of libestdc++ in there.
That doesn't use g++ from base though, only the ports version.
I went through all C++ ports not on the direct path to building gcc
and added a COMPILER line so they are built with ports gcc.
> Reading your log file
> http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> , there is mentioning of libestdc++ in there.
That doesn't use g++ from base though, only the ports version.
I went through all C++ ports not on the direct path to building gcc
and added a COMPILER line so they are built with ports gcc.
Re: Use xenodm like startx?
Hi
I am using the Xfce desktop, and the only thing I am doing is making the
file with:
$ echo xfce4-session > ~/.xinitrc
And then starting the Xfce desktop with the command:
$ xinit
Best regards
Freddy Fisker
On Thursday, 31 January 2019 16:55:20 CET, lists@wrant.com wrote:
> Thu, 31 Jan 2019 12:23:08 +0100 Freddy Fisker <ff@freddyfisker.dk>
>> Hi
>>
>> I have never used the startx command. I use the xinit command
>> together with
>> the ~/.xinitrc file.
>
> Hi Freddy,
>
> Are you referring to a recent OpenBSD, or some other customised variant?
> If that's a bypass of the recent security fixes don't bother responding.
> I'm only interested how it solves or improves on-demand X session model.
>
> Kind regards,
> Anton Lazarov
>
>> Best regards
>> Freddy Fisker
>>
>>
>> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote: ...
>
>
>
I am using the Xfce desktop, and the only thing I am doing is making the
file with:
$ echo xfce4-session > ~/.xinitrc
And then starting the Xfce desktop with the command:
$ xinit
Best regards
Freddy Fisker
On Thursday, 31 January 2019 16:55:20 CET, lists@wrant.com wrote:
> Thu, 31 Jan 2019 12:23:08 +0100 Freddy Fisker <ff@freddyfisker.dk>
>> Hi
>>
>> I have never used the startx command. I use the xinit command
>> together with
>> the ~/.xinitrc file.
>
> Hi Freddy,
>
> Are you referring to a recent OpenBSD, or some other customised variant?
> If that's a bypass of the recent security fixes don't bother responding.
> I'm only interested how it solves or improves on-demand X session model.
>
> Kind regards,
> Anton Lazarov
>
>> Best regards
>> Freddy Fisker
>>
>>
>> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote: ...
>
>
>
Re: dwm and chromium
+1 fwiw I have this change locally.
On Tue, 29 Jan 2019 at 20:46, Ted Unangst <tedu@tedunangst.com> wrote:
> It annoys me that chrome doesn't start on screen 9 like firefox does.
> (Especially since it takes a few seconds to start, so I'm always surprised
> when the window finally appears and disrupts my current screen.)
> Easily fixed.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/x11/dwm/Makefile,v
> retrieving revision 1.30
> diff -u -p -r1.30 Makefile
> --- Makefile 3 Jun 2018 16:57:11 -0000 1.30
> +++ Makefile 30 Jan 2019 03:43:52 -0000
> @@ -4,7 +4,7 @@ COMMENT= dynamic window manager
>
> V= 6.1
> DISTNAME= dwm-${V}
> -REVISION= 2
> +REVISION= 3
>
> CATEGORIES= x11
>
> Index: patches/patch-config_def_h
> ===================================================================
> RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
> retrieving revision 1.12
> diff -u -p -r1.12 patch-config_def_h
> --- patches/patch-config_def_h 24 Oct 2016 22:46:54 -0000 1.12
> +++ patches/patch-config_def_h 30 Jan 2019 03:43:52 -0000
> @@ -25,10 +25,11 @@ $OpenBSD: patch-config_def_h,v 1.12 2016
> static const unsigned int borderpx = 1; /* border pixel of
> windows */
> static const unsigned int snap = 32; /* snap pixel */
> static const int showbar = 1; /* 0 means no bar */
> -@@ -27,6 +27,8 @@ static const Rule rules[] = {
> +@@ -27,6 +27,9 @@ static const Rule rules[] = {
> /* class instance title tags mask isfloating
> monitor */
> { "Gimp", NULL, NULL, 0, 1,
> -1 },
> { "Firefox", NULL, NULL, 1 << 8, 0,
> -1 },
> ++ { "Chromium", NULL, NULL, 1 << 8, 0,
> -1 },
> + { "Xonix", NULL, NULL, 0, 1,
> -1 },
> + { NULL, NULL, "glxgears", 0, 1,
> -1 },
> };
>
>
On Tue, 29 Jan 2019 at 20:46, Ted Unangst <tedu@tedunangst.com> wrote:
> It annoys me that chrome doesn't start on screen 9 like firefox does.
> (Especially since it takes a few seconds to start, so I'm always surprised
> when the window finally appears and disrupts my current screen.)
> Easily fixed.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/x11/dwm/Makefile,v
> retrieving revision 1.30
> diff -u -p -r1.30 Makefile
> --- Makefile 3 Jun 2018 16:57:11 -0000 1.30
> +++ Makefile 30 Jan 2019 03:43:52 -0000
> @@ -4,7 +4,7 @@ COMMENT= dynamic window manager
>
> V= 6.1
> DISTNAME= dwm-${V}
> -REVISION= 2
> +REVISION= 3
>
> CATEGORIES= x11
>
> Index: patches/patch-config_def_h
> ===================================================================
> RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
> retrieving revision 1.12
> diff -u -p -r1.12 patch-config_def_h
> --- patches/patch-config_def_h 24 Oct 2016 22:46:54 -0000 1.12
> +++ patches/patch-config_def_h 30 Jan 2019 03:43:52 -0000
> @@ -25,10 +25,11 @@ $OpenBSD: patch-config_def_h,v 1.12 2016
> static const unsigned int borderpx = 1; /* border pixel of
> windows */
> static const unsigned int snap = 32; /* snap pixel */
> static const int showbar = 1; /* 0 means no bar */
> -@@ -27,6 +27,8 @@ static const Rule rules[] = {
> +@@ -27,6 +27,9 @@ static const Rule rules[] = {
> /* class instance title tags mask isfloating
> monitor */
> { "Gimp", NULL, NULL, 0, 1,
> -1 },
> { "Firefox", NULL, NULL, 1 << 8, 0,
> -1 },
> ++ { "Chromium", NULL, NULL, 1 << 8, 0,
> -1 },
> + { "Xonix", NULL, NULL, 0, 1,
> -1 },
> + { NULL, NULL, "glxgears", 0, 1,
> -1 },
> };
>
>
Re: Use xenodm like startx?
Thu, 31 Jan 2019 12:23:08 +0100 Freddy Fisker <ff@freddyfisker.dk>
> Hi
>
> I have never used the startx command. I use the xinit command together with
> the ~/.xinitrc file.
Hi Freddy,
Are you referring to a recent OpenBSD, or some other customised variant?
If that's a bypass of the recent security fixes don't bother responding.
I'm only interested how it solves or improves on-demand X session model.
Kind regards,
Anton Lazarov
> Best regards
> Freddy Fisker
>
>
> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote:
> > trondd <trondd@kagu-tsuchi.com> wrote:
> >> It's not really that complicated. The bare minimum is to copy your
> >> .xinitrc to .xsession and then just run xenodm on demand with doas. All
> >> the configs already exist in /etc/X11/xenodm. Nothing requires you to run
> >> it at startup.
> >>
> >> Here's what I've done: ...
> >
> > Hm. Thank you. This works, except the environment in which I
> > run xenodm is lost. For example, I have ENV=~/.kshrc in my
> > ~/.profile, but this isn't inherited to X11 ... I guess I should
> > add these things to my .xsession, but then I'll have it in two
> > places instead of once.
> >
> >> Only thing I never figured out is how to make X and xenodm shutdown when I
> >> exit my window manager.
> >
> > This too makes me feel like xenodm is far too complex for what I want.
> >
> >
> >
>
> Hi
>
> I have never used the startx command. I use the xinit command together with
> the ~/.xinitrc file.
Hi Freddy,
Are you referring to a recent OpenBSD, or some other customised variant?
If that's a bypass of the recent security fixes don't bother responding.
I'm only interested how it solves or improves on-demand X session model.
Kind regards,
Anton Lazarov
> Best regards
> Freddy Fisker
>
>
> On Thursday, 31 January 2019 11:57:12 CET, John Ankarström wrote:
> > trondd <trondd@kagu-tsuchi.com> wrote:
> >> It's not really that complicated. The bare minimum is to copy your
> >> .xinitrc to .xsession and then just run xenodm on demand with doas. All
> >> the configs already exist in /etc/X11/xenodm. Nothing requires you to run
> >> it at startup.
> >>
> >> Here's what I've done: ...
> >
> > Hm. Thank you. This works, except the environment in which I
> > run xenodm is lost. For example, I have ENV=~/.kshrc in my
> > ~/.profile, but this isn't inherited to X11 ... I guess I should
> > add these things to my .xsession, but then I'll have it in two
> > places instead of once.
> >
> >> Only thing I never figured out is how to make X and xenodm shutdown when I
> >> exit my window manager.
> >
> > This too makes me feel like xenodm is far too complex for what I want.
> >
> >
> >
>
Re: Use xenodm like startx?
On Thu, January 31, 2019 5:57 am, John Ankarström wrote:
>
>> Only thing I never figured out is how to make X and xenodm shutdown when
>> I
>> exit my window manager.
>
> This too makes me feel like xenodm is far too complex for what I want.
>
It's not an issue of complexity. It's a different tool that does a
different thing. Bending it to work like something it's not will
inherently have caveats.
The thing is, what we had before was a trivial privilege escalation.
Sometimes you just have to adapt a little and you can benefit greatly from
improvements.
Tim.
>
>> Only thing I never figured out is how to make X and xenodm shutdown when
>> I
>> exit my window manager.
>
> This too makes me feel like xenodm is far too complex for what I want.
>
It's not an issue of complexity. It's a different tool that does a
different thing. Bending it to work like something it's not will
inherently have caveats.
The thing is, what we had before was a trivial privilege escalation.
Sometimes you just have to adapt a little and you can benefit greatly from
improvements.
Tim.
Re: Use xenodm like startx?
On Thu, January 31, 2019 7:35 am, Bruno Flueckiger wrote:
>
> Add the following line to /etc/X11/xenodm/xenodm-config:
>
> DisplayManager.*.terminateServer: true
>
> Cheers,
> Bruno
>
That doesn't work how you think it does. It does shut down the X server
after quitting a window manager but then xenodm will restart X and log you
right back in. That option is there is prevent resource leaks between X
sessions.
Tim.
>
> Add the following line to /etc/X11/xenodm/xenodm-config:
>
> DisplayManager.*.terminateServer: true
>
> Cheers,
> Bruno
>
That doesn't work how you think it does. It does shut down the X server
after quitting a window manager but then xenodm will restart X and log you
right back in. That option is there is prevent resource leaks between X
sessions.
Tim.
Get great HSE Training in Manchester this March
|
Manage Preferences | Delete profile
Email was sent to bobbysellars573.spamhere@blogger.com
Health and Safety Executive - 5N1 Redgrave Court, Merton Road, Bootle, Merseyside L20 7HS
Subscribe to:
Posts (Atom)