Re: [new] net/epic5 - irc client with pledge/unveil
Omar Polo wrote:
> Mikhail wrote:
> > On Mon, Jun 06, 2022 at 10:39:52AM +0100, Stuart Henderson wrote:
> > > On 2022/06/06 11:12, Omar Polo wrote:
> > > > some tweaks are needed:
> > >
> > > I agree with all your tweaks. Generally ok to import (as long as
> > > MAINTAINER really is correct). The pledge/unveil stuff mentioned in
> > > README does not really nice though, this is not something users should
> > > have to fiddle with for basic operation, I would drop that section from
> > > the readme and leave it for advanced users to find for themselves if
> > > they want to be responsible for keeping it up to date/fixing things.
> >
> > I've applied tweaks from Omar, added epicrc.sample to files/ and install
> > it to ${PREFIX}/share/epic5/script instead of embedding in README, also
> > removed pledge/unveil example from this file as Stuart suggested, left
> > only a note, that further information about the syscalls usage is in
> > UPDATES document.
>
> I think that now it's perfect :)
>
> > Regarding maintainer - Joey will be the "official" one, so the variable
> > is set correctly, but we both will take care of this port.
>
> if you want you can also add more than one person in the MAINTAINER
> line; it's not extremely common but not so rare either to have more than
> one maintainer per package (see for example net/tdesktop, it's the first
> one that comes to mind.) not saying you must, it's just an option in
> case you didn't know.
>
> I'd wait a confirmation from Joey thought, as far as i can see they
> haven't posted anything to this thread yet.
I missed the previous mail from Joey, so I just imported it, thanks!
Re: [new] net/epic5 - irc client with pledge/unveil
Mikhail wrote:
> On Mon, Jun 06, 2022 at 10:39:52AM +0100, Stuart Henderson wrote:
> > On 2022/06/06 11:12, Omar Polo wrote:
> > > some tweaks are needed:
> >
> > I agree with all your tweaks. Generally ok to import (as long as
> > MAINTAINER really is correct). The pledge/unveil stuff mentioned in
> > README does not really nice though, this is not something users should
> > have to fiddle with for basic operation, I would drop that section from
> > the readme and leave it for advanced users to find for themselves if
> > they want to be responsible for keeping it up to date/fixing things.
>
> I've applied tweaks from Omar, added epicrc.sample to files/ and install
> it to ${PREFIX}/share/epic5/script instead of embedding in README, also
> removed pledge/unveil example from this file as Stuart suggested, left
> only a note, that further information about the syscalls usage is in
> UPDATES document.
I think that now it's perfect :)
> Regarding maintainer - Joey will be the "official" one, so the variable
> is set correctly, but we both will take care of this port.
if you want you can also add more than one person in the MAINTAINER
line; it's not extremely common but not so rare either to have more than
one maintainer per package (see for example net/tdesktop, it's the first
one that comes to mind.) not saying you must, it's just an option in
case you didn't know.
I'd wait a confirmation from Joey thought, as far as i can see they
haven't posted anything to this thread yet.
> Appreciated for the review.
Cheers,
Omar Polo
Re: [new] net/epic5 - irc client with pledge/unveil
On Mon, Jun 06, 2022 at 10:39:52AM +0100, Stuart Henderson wrote:
> On 2022/06/06 11:12, Omar Polo wrote:
> > some tweaks are needed:
>
> I agree with all your tweaks. Generally ok to import (as long as
> MAINTAINER really is correct). The pledge/unveil stuff mentioned in
> README does not really nice though, this is not something users should
> have to fiddle with for basic operation, I would drop that section from
> the readme and leave it for advanced users to find for themselves if
> they want to be responsible for keeping it up to date/fixing things.
I've applied tweaks from Omar, added epicrc.sample to files/ and install
it to ${PREFIX}/share/epic5/script instead of embedding in README, also
removed pledge/unveil example from this file as Stuart suggested, left
only a note, that further information about the syscalls usage is in
UPDATES document.
Regarding maintainer - Joey will be the "official" one, so the variable
is set correctly, but we both will take care of this port.
Appreciated for the review.
epic5.tar.gz
Description: application/tar-gz
Re: [new] net/epic5 - irc client with pledge/unveil
On 2022/06/06 11:12, Omar Polo wrote: > some tweaks are needed: I agree with all your tweaks. Generally ok to import (as long as MAINTAINER really is correct). The pledge/unveil stuff mentioned in README does not really nice though, this is not something users should have to fiddle with for basic operation, I would drop that section from the readme and leave it for advanced users to find for themselves if they want to be responsible for keeping it up to date/fixing things.
Re: [new] net/epic5 - irc client with pledge/unveil
Hello,
Mikhail wrote:
> On Sat, May 28, 2022 at 04:58:59PM +0300, Mikhail wrote:
> > On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote:
> > > Friendly weekly ping.
> >
> > New version 2.1.10 has been released, new port is attached. The
> > developer has made changes, which allows to build epic5 with -O2,
> > INSTALL document also updated, I've been testing this for several weeks
> > and there were no crashes.
>
> 2.1.11 version is attached, also friendly weekly ping
some tweaks are needed:
- set PATCHORIG: currently there aren't patches, but there is a file
(scripts/reconnect.orig) which can cause issue if we ever need to
patch something here.
- the python flavors is missing `intl pthread util' as WANTLIB
- (nitpick/opinable) I'd drop COMMIT_ID: it's used in only one PLIST
entry and it's probably more work to sync it than accepting that every
update will have (at least) a one-line change to the plist.
- (nitpicking) pkg/README' box around the title should be 80 characters
long, as per README.template
- use ${TRUEPREFIX} in pkg/README, LOCALBASE is for "where other ports
are installed"
- is the MAINTAINER right? (sorry for the question but it's not the
email address you're using to ping, so...) it should be *your* email
address if you want to maintain it, otherwise drop it.
with these fixed (see diff against your makefile below and updated
tarball attached) it's ok op@ to import. (the maintainer is still to
fix)
one suggestion thought: what about adding a sample epicrc in
files/epicrc and installing it somewhere? Then the pkg/README could
just say 'copy ${TRUEPREFIX}/share/epic5/epicrc (or even
overwriting/extending upstream' epicrc.example with the OpenBSD-specific
stuff.)
(i don't really like how pledge and unveil are to be called from user
configuration by the way :/)
--- Makefile.orig Mon Jun 6 10:48:57 2022
+++ MakefileMon Jun 6 10:57:55 2022
@@ -1,7 +1,6 @@
COMMENT= enhanced programmable ircII client 5th generation
VERSION= 2.1.11
-COMMIT_ID= 2071
DISTNAME= epic5-${VERSION}
CATEGORIES=net
HOMEPAGE= http://www.epicsol.org/
@@ -24,26 +23,21 @@
--without-python \
--without-libarchive
-# Developers suggest to have python flavor, because its support is
-# planned to evolve
FLAVORS= python
-
FLAVOR?=
+
.if ${FLAVOR:Mpython}
MODULES+= lang/python
CONFIGURE_ARGS+= --with-python
LIB_DEPENDS+= ${MODPY_LIB_DEPENDS}
-WANTLIB+= ${MODPY_WANTLIB}
+WANTLIB+= ${MODPY_WANTLIB} intl pthread util
.endif
-# Currently doesn't work because of some problems with 'stringify.c'
-#SEPARATE_BUILD= Yes
-
NO_TEST= Yes
-SUBST_VARS=COMMIT_ID
+# scripts/reconnect.orig
+PATCHORIG= .orig.port
-# UPDATES document contain info about recent changes and novelties
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/epic5/
${INSTALL_DATA} ${WRKSRC}/UPDATES ${PREFIX}/share/doc/epic5/
epic5.tar.gz
Description: GNU Zip compressed data
Re: [new] net/epic5 - irc client with pledge/unveil
On Sat, May 28, 2022 at 04:58:59PM +0300, Mikhail wrote:
> On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote:
> > Friendly weekly ping.
>
> New version 2.1.10 has been released, new port is attached. The
> developer has made changes, which allows to build epic5 with -O2,
> INSTALL document also updated, I've been testing this for several weeks
> and there were no crashes.
2.1.11 version is attached, also friendly weekly ping
ChangeLog:
* Always call alists 'alist's instead of 'array's
* Add a #define UINTMAX_HEX_FORMAT for pointers
* Change (List)s to have a data pointer rather than inheritance
* This removes a major remaining type punning issue
* Remove '_window_list_end' from screens. Determine it on the fly.
* Add get_screen_bottom_window() to replace '_window_list_end'
* Change (Crypt) from a (List) type to a data object for List
* Change various crypt.c functions to take a straight (List).
* Change various crypt.c functions to create and store a (Crypt) in (List)
* Make (WNickList) private to window.c, use ordinary (List)s ordinarily
* Change window's 'waiting_chans' and 'nicks' ordinary (List)s
* Add ARAs - "automatically resizable arrays"; directly addressable arrays
* Comment out bucket_(var|cmd)_alias and bucket_builtin_* to avoid warnings
* Except bucket_builtin_variables() which is the only one actually used!
* Convert (Ignore) from a (List) type to a data object for List
* If a panic() happens during shutdown, then just go ahead and exit.
* Convert (Binding) from a (List) type to a data object for List
* Convert (Logfile) to use a plain old (List) to hold target names.
* Rename 'invislble_list' to '_invisible_list' for future deprecation
* Make everything using invisible list go through a function.
* Split 'delete_window' into 'unlink_window' and 'delete_window_contents'
* And make those two take refnums instead of a window ptr.
* /fe ("" .) foo {echo $foo} with /xdebug dword (rb ce)
* Fix /window swap_others (skered)
* Un-break $unveil() with no arguments (rb zlonix)
* Remove configure checks for sysctlbyname(),
* Fix warnings from raspbian (rb zlonix)
* Don't include (not used) (rb zlonix)
* Do #define _GNU_SOURCE 1 for slackware (BAH!)
* Begin untangling the "signed pointer mess"
* Generally this means:
* - (char *), not (unsigned char *) is the "generic type" in C params
* - Pointer parameters have to have *equivalent* types, not just *compatible*
types.
* - The type of "a bunch of bytes" is always (char *), not (unsigned char *)
* - Even though (char *) is not 8 bit clean.
* - Type type of literals is always (char *), not (unsigned char *)
* - So don't use (unsigned char *) for params unless the thing is NOT a BoBs.
* - So DO use (char *) and cast it on both sides of the call.
* - Don't have (const unsigned char **) params to modify a pointer
* - Prefer (const unsigned char *) and return a (ptrdiff_t)
* Change (Crypt) 'passwd' to unsigned because OpenSSL wants it that way.
* Eliminate all warnings from -Wpointer-sign
* - Mostly by eliminating nearly all uses of (unsigned char *)
* Eliminate all warnings from -Wunused
* - But not from -Wno-unused-functions or -Wno-unused-parameter
* Remove many spurious casts to and from (void *) (c99-ism)
* Fix warnings found by wider testing
epic5.tar.gz
Description: application/tar-gz
Re: [new] net/epic5 - irc client with pledge/unveil
On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote: > Friendly weekly ping. New version 2.1.10 has been released, new port is attached. The developer has made changes, which allows to build epic5 with -O2, INSTALL document also updated, I've been testing this for several weeks and there were no crashes. epic5.tar.gz Description: application/tar-gz
Re: [new] net/epic5 - irc client with pledge/unveil
Just confirming as well that I've tested this port on amd64 (although on a VM) and it works fine. I've used epic5 basically since it started (and epic4 before that) and have never had any problems on amd64 hardware real or virtualized. Sent: Sunday, April 24, 2022 at 3:53 PM From: "Ryan Freeman" To: "Mikhail" Cc: ports@openbsd.org, "Joey Beach" Subject: Re: [new] net/epic5 - irc client with pledge/unveil Hello, On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote: > Friendly weekly ping. > Tested the port on my amd64 laptop, builds and runs just fine. I have had epic5 on another machine for over a decade now and have never really had any issues. I won't weigh in on the optimization part but the package at least works good. Thanks! -Ryan > On Mon, Apr 18, 2022 at 10:15:47AM +0300, Mikhail wrote: > > On Sat, Apr 16, 2022 at 07:18:47AM -0600, Daniel Dickman wrote: > > > > > > > > > > On Apr 14, 2022, at 11:49 AM, Stuart Henderson > > > > wrote: > > > > > > > > My thinking is that, if the code has behaviour which is considered > > > > undefined by the C standard assumed by the compiler, no level of > > > > optimization is safe. Maybe now you get lucky and -O works (on whichever > > > > architecture you've tested) but I don't think it's reasonable to assume > > > > that this is the case everywhere, or will be the case following compiler > > > > updates. > > > > > > I haven't looked very deeply at epic but if the note is referring to > > > strict aliasing then I would follow the advice about sticking to -O. > > > > > > John Regehr wrote up a nice piece on this a few years ago: > > > > > > https://blog.regehr.org/archives/1307 > > > > We have a decade or even more when we didn't hear any random crashes > > reports with '-O', and FreeBSD has it as a default flag. > > > > Epic developer takes crash reports seriously, when I had "openbsd only > > crash" he helped me with it. Also, he wasn't against adding unveil and > > pledge. > > > > Anyway, if there is a proposition not to take any risk - probably it > > worth it, performance isn't critical thing for an IRC client. > > >
Re: [new] net/epic5 - irc client with pledge/unveil
Friendly weekly ping. On Mon, Apr 18, 2022 at 10:15:47AM +0300, Mikhail wrote: > On Sat, Apr 16, 2022 at 07:18:47AM -0600, Daniel Dickman wrote: > > > > > > > On Apr 14, 2022, at 11:49 AM, Stuart Henderson > > > wrote: > > > > > > My thinking is that, if the code has behaviour which is considered > > > undefined by the C standard assumed by the compiler, no level of > > > optimization is safe. Maybe now you get lucky and -O works (on whichever > > > architecture you've tested) but I don't think it's reasonable to assume > > > that this is the case everywhere, or will be the case following compiler > > > updates. > > > > I haven't looked very deeply at epic but if the note is referring to > > strict aliasing then I would follow the advice about sticking to -O. > > > > John Regehr wrote up a nice piece on this a few years ago: > > > > https://blog.regehr.org/archives/1307 > > We have a decade or even more when we didn't hear any random crashes > reports with '-O', and FreeBSD has it as a default flag. > > Epic developer takes crash reports seriously, when I had "openbsd only > crash" he helped me with it. Also, he wasn't against adding unveil and > pledge. > > Anyway, if there is a proposition not to take any risk - probably it > worth it, performance isn't critical thing for an IRC client. >
Re: [new] net/epic5 - irc client with pledge/unveil
On Sat, Apr 16, 2022 at 07:18:47AM -0600, Daniel Dickman wrote: > > > > On Apr 14, 2022, at 11:49 AM, Stuart Henderson wrote: > > > > My thinking is that, if the code has behaviour which is considered > > undefined by the C standard assumed by the compiler, no level of > > optimization is safe. Maybe now you get lucky and -O works (on whichever > > architecture you've tested) but I don't think it's reasonable to assume > > that this is the case everywhere, or will be the case following compiler > > updates. > > I haven't looked very deeply at epic but if the note is referring to > strict aliasing then I would follow the advice about sticking to -O. > > John Regehr wrote up a nice piece on this a few years ago: > > https://blog.regehr.org/archives/1307 We have a decade or even more when we didn't hear any random crashes reports with '-O', and FreeBSD has it as a default flag. Epic developer takes crash reports seriously, when I had "openbsd only crash" he helped me with it. Also, he wasn't against adding unveil and pledge. Anyway, if there is a proposition not to take any risk - probably it worth it, performance isn't critical thing for an IRC client.
Re: [new] net/epic5 - irc client with pledge/unveil
On Sat, Apr 16, 2022 at 11:05:53AM +0100, Stuart Henderson wrote: > You know you can just do "CFLAGS += -O0" rather than this? Fixed, new archive attached. > It really seems strange though, are any other OS packages of epic4/5 built > that way? At least FreeBSD builds epic5 with substitute of CFLAGS: https://github.com/freebsd/freebsd-ports/blob/main/irc/epic5/Makefile#L16 Debian seem not to change default user CFLAGS. epic5.tar.gz Description: application/tar-gz
Re: [new] net/epic5 - irc client with pledge/unveil
> On Apr 14, 2022, at 11:49 AM, Stuart Henderson wrote: > > My thinking is that, if the code has behaviour which is considered > undefined by the C standard assumed by the compiler, no level of > optimization is safe. Maybe now you get lucky and -O works (on whichever > architecture you've tested) but I don't think it's reasonable to assume > that this is the case everywhere, or will be the case following compiler > updates. I haven't looked very deeply at epic but if the note is referring to strict aliasing then I would follow the advice about sticking to -O. John Regehr wrote up a nice piece on this a few years ago: https://blog.regehr.org/archives/1307 > > (Of course on many OpenBSD architectures the relevant compiler is not > GCC anyway). >
Re: [new] net/epic5 - irc client with pledge/unveil
You know you can just do "CFLAGS += -O0" rather than this?
It really seems strange though, are any other OS packages of epic4/5 built
that way?
--
Sent from a phone, apologies for poor formatting.
On 16 April 2022 08:13:12 Mikhail wrote:
On Thu, Apr 14, 2022 at 06:49:12PM +0100, Stuart Henderson wrote:
On 2022/04/08 22:14, Mikhail wrote:
> On Fri, Apr 08, 2022 at 08:03:14PM +0100, Stuart Henderson wrote:
> > It's too late for 7.1 release.
> >
> > Re: the -O2 issue, does setting -std=c89 fix the problem?
>
> I think epic developers won't take the risk, the software has very old
> history and we didn't receive any random crashes reports while being
> simply with '-O' (epic4 and epic5 are still actively maintained, all
> efforts are on the later, though).
>
> I've plans to submit net/epic5 port, because it has gained pledge/unveil
> support, does -O will be considered as an issue by committers?
- don't set MODPY_MAJOR_VERSION
Thanks for review. Fixed.
- my previous comments about the CFLAGS handing stand:
# You must not try to compile epic with "gcc -O2" because -O2 will
# generate bad code that leads to random crashes. When you use -O2, gcc
# assumes the source is conformant to ISO C99's requirements about
# alias-safety, and EPIC, being a C90 program, does not conform, so the
# result is undefined behavior (which means it crashes randomly.)
CFLAGS:=${CFLAGS:C/-O2/-O/g}
--snip--
My thinking is that, if the code has behaviour which is considered
undefined by the C standard assumed by the compiler, no level of
optimization is safe. Maybe now you get lucky and -O works (on whichever
architecture you've tested) but I don't think it's reasonable to assume
that this is the case everywhere, or will be the case following compiler
updates.
(Of course on many OpenBSD architectures the relevant compiler is not
GCC anyway).
--snip--
I've changed -O to -O0.
and your proposal doesn't work if the user builds from ports with CFLAGS=-O3
Such change has to go to net/epic4 too, because currently it builds with
-O2, so I added such lines to Makefile:
CFLAGS:=${CFLAGS:C/-O1/-O0/g}
CFLAGS:=${CFLAGS:C/-O2/-O0/g}
CFLAGS:=${CFLAGS:C/-O3/-O0/g}
CFLAGS:=${CFLAGS:C/-O4/-O0/g}
CFLAGS:=${CFLAGS:C/-Ofast/-O0/g}
CFLAGS:=${CFLAGS:C/-Os/-O0/g}
CFLAGS:=${CFLAGS:C/-Oz/-O0/g}
New tgz is attached.
Re: [new] net/epic5 - irc client with pledge/unveil
On Thu, Apr 14, 2022 at 06:49:12PM +0100, Stuart Henderson wrote:
> On 2022/04/08 22:14, Mikhail wrote:
> > On Fri, Apr 08, 2022 at 08:03:14PM +0100, Stuart Henderson wrote:
> > > It's too late for 7.1 release.
> > >
> > > Re: the -O2 issue, does setting -std=c89 fix the problem?
> >
> > I think epic developers won't take the risk, the software has very old
> > history and we didn't receive any random crashes reports while being
> > simply with '-O' (epic4 and epic5 are still actively maintained, all
> > efforts are on the later, though).
> >
> > I've plans to submit net/epic5 port, because it has gained pledge/unveil
> > support, does -O will be considered as an issue by committers?
>
> - don't set MODPY_MAJOR_VERSION
Thanks for review. Fixed.
> - my previous comments about the CFLAGS handing stand:
>
> # You must not try to compile epic with "gcc -O2" because -O2 will
> # generate bad code that leads to random crashes. When you use -O2, gcc
> # assumes the source is conformant to ISO C99's requirements about
> # alias-safety, and EPIC, being a C90 program, does not conform, so the
> # result is undefined behavior (which means it crashes randomly.)
> CFLAGS:=${CFLAGS:C/-O2/-O/g}
>
> --snip--
> My thinking is that, if the code has behaviour which is considered
> undefined by the C standard assumed by the compiler, no level of
> optimization is safe. Maybe now you get lucky and -O works (on whichever
> architecture you've tested) but I don't think it's reasonable to assume
> that this is the case everywhere, or will be the case following compiler
> updates.
>
> (Of course on many OpenBSD architectures the relevant compiler is not
> GCC anyway).
> --snip--
I've changed -O to -O0.
> and your proposal doesn't work if the user builds from ports with CFLAGS=-O3
Such change has to go to net/epic4 too, because currently it builds with
-O2, so I added such lines to Makefile:
CFLAGS:=${CFLAGS:C/-O1/-O0/g}
CFLAGS:=${CFLAGS:C/-O2/-O0/g}
CFLAGS:=${CFLAGS:C/-O3/-O0/g}
CFLAGS:=${CFLAGS:C/-O4/-O0/g}
CFLAGS:=${CFLAGS:C/-Ofast/-O0/g}
CFLAGS:=${CFLAGS:C/-Os/-O0/g}
CFLAGS:=${CFLAGS:C/-Oz/-O0/g}
New tgz is attached.
epic5.tar.gz
Description: application/gzip
Re: [new] net/epic5 - irc client with pledge/unveil
On 2022/04/14 08:03, Mikhail wrote:
> Hello, this is proposal to add net/epic5 irc client to the ports tree,
> currently we have net/epic4, but it's previous generation of the client,
> all development activity and users long ago had moved to epic5.
>
> The client distinguishes itself by extremely high ability to customize
> IRC experience with ircII scripting language.
>
> EPIC5 also has gained pledge/unveil support in master branch recently,
> the patches are included in current port, because next software update
> won't be released soon.
>
> More info about the software and pledge/unveil usage is in pkg/README.
>
> The port will be maintained by me and Joey (cc'ed).
>
> Comments, suggestions and testing are welcome.
Date: Fri, 8 Apr 2022 20:41:26 +0100
From: Stuart Henderson
To: Mikhail
Cc: Christian Weisgerber
Subject: Re: Ports tree close to lock
Message-ID:
References:
<1800a8f2150.2869.545c230b3f27d53b49609e7db7068...@spacehopper.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
On 2022/04/08 22:14, Mikhail wrote:
> On Fri, Apr 08, 2022 at 08:03:14PM +0100, Stuart Henderson wrote:
> > It's too late for 7.1 release.
> >
> > Re: the -O2 issue, does setting -std=c89 fix the problem?
>
> I think epic developers won't take the risk, the software has very old
> history and we didn't receive any random crashes reports while being
> simply with '-O' (epic4 and epic5 are still actively maintained, all
> efforts are on the later, though).
>
> I've plans to submit net/epic5 port, because it has gained pledge/unveil
> support, does -O will be considered as an issue by committers?
- don't set MODPY_MAJOR_VERSION
- my previous comments about the CFLAGS handing stand:
# You must not try to compile epic with "gcc -O2" because -O2 will
# generate bad code that leads to random crashes. When you use -O2, gcc
# assumes the source is conformant to ISO C99's requirements about
# alias-safety, and EPIC, being a C90 program, does not conform, so the
# result is undefined behavior (which means it crashes randomly.)
CFLAGS:=${CFLAGS:C/-O2/-O/g}
--snip--
My thinking is that, if the code has behaviour which is considered
undefined by the C standard assumed by the compiler, no level of
optimization is safe. Maybe now you get lucky and -O works (on whichever
architecture you've tested) but I don't think it's reasonable to assume
that this is the case everywhere, or will be the case following compiler
updates.
(Of course on many OpenBSD architectures the relevant compiler is not
GCC anyway).
--snip--
and your proposal doesn't work if the user builds from ports with CFLAGS=-O3
[new] net/epic5 - irc client with pledge/unveil
Hello, this is proposal to add net/epic5 irc client to the ports tree, currently we have net/epic4, but it's previous generation of the client, all development activity and users long ago had moved to epic5. The client distinguishes itself by extremely high ability to customize IRC experience with ircII scripting language. EPIC5 also has gained pledge/unveil support in master branch recently, the patches are included in current port, because next software update won't be released soon. More info about the software and pledge/unveil usage is in pkg/README. The port will be maintained by me and Joey (cc'ed). Comments, suggestions and testing are welcome. epic5.tar.gz Description: application/tar-gz
[new] net/epic5
Here is a port of epic5, an irc client. Should we have both epic4 and epic5, or just create a new net/epic? review and comments? Thanks, David epic5.tar.gz Description: application/tar-gz
Re: [NEW] net/epic5
On Tuesday 09 August 2011 00:36:01 David Hill wrote: > Here is a port for epic5, the IRC client. I use it locally, but others > have wanted a copy of it. > > I am sure it needs editing.. > > - David Hi, there's net/epic4 already, is it still useful? Why not make an update, and put it into net/epic ? -- Antti Harri
[NEW] net/epic5
Here is a port for epic5, the IRC client. I use it locally, but others have wanted a copy of it. I am sure it needs editing.. - David epic5.tar.gz Description: application/tar-gz
