lwm

2017-03-03 Thread mitchell wodach
Is anyone working on porting lwm? if the community wants it I will start working on a port for it. http://www.jfc.org.uk/software/lwm.html Best regards, Mitchell

Re: lang/mruby: Fix debug mode build

2017-03-03 Thread Jeremie Courreges-Anglas
Jeremy Evans writes: > This updates lang/mruby to disable use of debug mode (still the > default in the upstream build). It also only builds a single > configuration, instead of 3 separate configurations. This cuts > the build time to about a third of the previous build time, making > it much f

Re: Ports with hardcoded "gcc", "g++"

2017-03-03 Thread Aaron Bieber
On Thu, Mar 02, 2017 at 01:11:05PM +, Christian Weisgerber wrote: > Updated list: > > archivers/hs-zlib Matthias Kilian > databases/hs-postgresql-libpq David Schaefer > devel/boost Brad Smith > devel/cil The OpenBSD ports mailing-list > devel/hs-bytestring-m

Re: OpenBSD::*.pod

2017-03-03 Thread Ingo Schwarze
Hi, Alexander Bluhm wrote on Fri, Mar 03, 2017 at 11:29:07AM -0700: > CVSROOT: /cvs > Module name: src > Changes by: bl...@cvs.openbsd.org 2017/03/03 11:29:07 > > Modified files: > usr.sbin/pkg_add/pod: OpenBSD::PackingElement.pod > > Log message: > Remove a "=over 4" after the

Re: Ports with hardcoded "gcc", "g++"

2017-03-03 Thread Jeremie Courreges-Anglas
Solène Rapenne writes: > Le 2017-02-26 16:00, Christian Weisgerber a écrit : >> Here is a first batch of ports that fail to build without "gcc" or >> "g++" being present. More will come to light eventually. At the >> moment, failing dependencies prevent about a third of the ports >> tree from b

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
On Fri, Mar 3, 2017 at 1:04 PM, Stuart Henderson wrote: > On 2017/03/03 11:34, sven falempin wrote: >> About Bison, this is how it fails: >> >> checking for bison... yacc >> checking for ranlib... (cached) ranlib >> checking for GNU M4 that supports accurate traces... configure: error: >> no accep

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
On Fri, Mar 3, 2017 at 1:04 PM, Stuart Henderson wrote: > On 2017/03/03 11:34, sven falempin wrote: >> About Bison, this is how it fails: >> >> checking for bison... yacc >> checking for ranlib... (cached) ranlib >> checking for GNU M4 that supports accurate traces... configure: error: >> no accep

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread Stuart Henderson
On 2017/03/03 11:34, sven falempin wrote: > About Bison, this is how it fails: > > checking for bison... yacc > checking for ranlib... (cached) ranlib > checking for GNU M4 that supports accurate traces... configure: error: > no acceptable m4 could be found in $PATH. > GNU M4 1.4.6 or later is req

Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-03 Thread Marc Espie
On Thu, Mar 02, 2017 at 10:03:29PM +0100, Karel Gardas wrote: > On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian > wrote: > > Also, I've no idea wether --with-clang=${CC} will work after the > > switch to clang. On the other hand, the diff is just a workaround, > > > +MODGHC_SETUP_CONF_ARGS +=

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
About Bison, this is how it fails: checking for bison... yacc checking for ranlib... (cached) ranlib checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. GNU M4 1.4.15 use

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
On Fri, Mar 3, 2017 at 10:49 AM, Aaron Bieber wrote: > On Fri, Mar 03, 2017 at 10:42:03AM -0500, sven falempin wrote: >> On Fri, Mar 3, 2017 at 10:32 AM, sven falempin >> wrote: >> >> > xterm.js is a modern implementation for tty in browser. >> > >> > https://github.com/tsl0922/ttyd provides a ba

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread Aaron Bieber
On Fri, Mar 03, 2017 at 10:42:03AM -0500, sven falempin wrote: > On Fri, Mar 3, 2017 at 10:32 AM, sven falempin > wrote: > > > xterm.js is a modern implementation for tty in browser. > > > > https://github.com/tsl0922/ttyd provides a backend in c to use with > > xterm.js. > > > > A few patches ar

Re: Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
On Fri, Mar 3, 2017 at 10:32 AM, sven falempin wrote: > xterm.js is a modern implementation for tty in browser. > > https://github.com/tsl0922/ttyd provides a backend in c to use with > xterm.js. > > A few patches are needed for openbsd compilation (thus i am not sure why > cmake > is used if put

Packaging ttyd a tty over http backend

2017-03-03 Thread sven falempin
xterm.js is a modern implementation for tty in browser. https://github.com/tsl0922/ttyd provides a backend in c to use with xterm.js. A few patches are needed for openbsd compilation (thus i am not sure why cmake is used if putting c99 is such a hassle ) I wanted to make a real complete package

Re: possible chromium regression on -current (caused by llvm)

2017-03-03 Thread Robert Nagy
The issue is caused by the llvm update most probably, reverting back to llvm-3.9.1p0 fixes the issue, so it's either the update or a commit after that. http://nerd.hu/chromium-56.0.2924.87p0.tgz for amd64 using llvm-3.9.1p0 On (2017-03-03 23:27), Jonathan Gray wrote: > On Thu, Mar 02, 2017 at 10:

Re: possible chromium regression on -current

2017-03-03 Thread Jonathan Gray
On Thu, Mar 02, 2017 at 10:48:55PM +1100, Jonathan Gray wrote: > On Thu, Mar 02, 2017 at 11:24:13AM +, Stuart Henderson wrote: > > On 2017/03/02 22:12, Jonathan Gray wrote: > > > On Wed, Feb 22, 2017 at 11:35:24AM +, Dimitris Papastamos wrote: > > > > Hi everyone, > > > > > > > > I think a

Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-03 Thread David Coppa
On Thu, Mar 2, 2017 at 11:35 PM, Matthias Kilian wrote: > On Thu, Mar 02, 2017 at 09:23:25PM +0100, Matthias Kilian wrote: >> Running an update bulk build with the diff below now for ghc-7.10.3, >> to see wether it helps... however, all the hs-ports in my tree are still >> updated for ghc-8.0.1, s