pidgin-facebookchat broken
Facebook officially dropped XMPP support a while ago and effectively broke it two weeks ago: https://developer.pidgin.im/ticket/16701 Our pidgin-facebookchat port uses an API even older than the XMPP one. The URL listed: https://code.google.com/p/pidgin-facebookchat/ redirects to the new plugin: https://github.com/jgeboski/purple-facebook which is being implemented as a Pidgin GSoC project. It's already functional and reasonably stable, so it could be ported. I don't have a Facebook account and I'm not interested in maintaining it. (I am a Pidgin GSoC student, though, which is why I'm the one reporting this.) I also got confirmation from the author of the current plugin that ours is broken. The tl;dr is that it should be deleted and optionally replaced.
Imapfilter cert location
This should be /etc/ssl/cert.pem for us, no? https://github.com/lefcha/imapfilter/blob/master/src/imapfilter.c#L55 Related ticket here: https://github.com/lefcha/imapfilter/issues/94 I get that ticket's error on the current port (2.6.1) for one of the three IMAP domains I filter. Using '-t /etc/ssl/cert.pem' fixes it.
Re: Imapfilter cert location
On Sat, Jul 18, 2015 at 10:50:12PM +0100, Stuart Henderson wrote: > On 2015/07/18 16:51, Michael McConville wrote: > > This should be /etc/ssl/cert.pem for us, no? > > > > https://github.com/lefcha/imapfilter/blob/master/src/imapfilter.c#L55 > > > > Related ticket here: > > > > https://github.com/lefcha/imapfilter/issues/94 > > > > I get that ticket's error on the current port (2.6.1) for one of the > > three IMAP domains I filter. Using '-t /etc/ssl/cert.pem' fixes it. > > > > Yep, that looks correct. Do you have a diff for the port? Here it is. Tested, fixed the issue for me. I'll mention it on their issue tracker if/when it's committed. Index: patches/patch-src_imapfilter_c === RCS file: /cvs/ports/mail/imapfilter/patches/patch-src_imapfilter_c,v retrieving revision 1.1 diff -u -p -r1.1 patch-src_imapfilter_c --- patches/patch-src_imapfilter_c 18 Jul 2015 04:51:29 - 1.1 +++ patches/patch-src_imapfilter_c 18 Jul 2015 22:34:38 - @@ -1,6 +1,6 @@ $OpenBSD: patch-src_imapfilter_c,v 1.1 2015/07/18 04:51:29 sthen Exp $ src/imapfilter.c.orig Fri Jul 17 22:23:22 2015 -+++ src/imapfilter.c Fri Jul 17 22:25:40 2015 +--- src/imapfilter.c.orig Mon Jun 29 02:33:17 2015 src/imapfilter.c Sat Jul 18 18:34:04 2015 @@ -21,7 +21,10 @@ extern buffer ibuf, obuf, nbuf, cbuf; @@ -13,6 +13,15 @@ $OpenBSD: patch-src_imapfilter_c,v 1.1 2 #if OPENSSL_VERSION_NUMBER >= 0x01000100fL extern SSL_CTX *tls11ctx, *tls12ctx; #endif +@@ -52,7 +55,7 @@ main(int argc, char *argv[]) + opts.config = NULL; + opts.oneline = NULL; + opts.debug = NULL; +- opts.truststore = "/etc/ssl/certs"; ++ opts.truststore = "/etc/ssl/cert.pem"; + + env.home = NULL; + env.pathmax = -1; @@ -109,7 +112,9 @@ main(int argc, char *argv[]) SSL_library_init();
Re: Security testing tools
On Fri, Jul 24, 2015 at 04:20:17PM -0400, Bryan C. Everly wrote: > Recently I came to the realization that, while OpenBSD is a > security-oriented operating system, many of the security professionals > out there were using Kali Linux for their work doing penetration > testing of networks and applications. > > I think the reason for this is that very few of the security-oriented > testing tools were available in ports/packages within OpenBSD. This is partly because some of these tools are themselves security problems. The Wireshark port was removed from the tree in 2004 because it had such a bad record and was only replaced a year ago. That said, they could therefore benefit from OpenBSD's exploit mitigations. The few times I used Kali Linux I noticed that many of the tools seemed to make hard-coded Linuxy assumptions about interfaces etc. Have you had problems with that?
Python 2.7 update error
I'm on yesterday's AMD64 snapshot and just updated my packages. Did anyone else see this? --- -python-2.7.10 --- Couldn't delete /usr/local/lib/python2.7/email/mime/__init__.pyc (bad checksum) Files kept as partial-python-2.7.10 package
GPlugin WIP
This is very much a work in progress, but I thought I should share: http://git.sccs.swarthmore.edu/web/mmcconv1/gplugin-openbsd-port/tree/ I still need to fill in the shared libs, dependencies, PLIST, etc. It builds, but I need to test whether it runs properly (which means getting Pidgin 3 working). I'm about to submit the first Lua CMake patch hunk upstream. The other two hunks seem OpenBSD-specific. GPlugin will be a dependency for Pidgin 3 when it's released.
Building ports with the Clang static analyzer
I've been having trouble with this. It's probably because the port I'm
testing (my WIP of Pidgin 3) uses autogen.sh for both configuration and
compilation.
I've tried the obvious way ('scan-build make build'). In that case I
only get a report for the autogen.sh test programs, although the main
compilation also uses the static analyzer. I've also tried using a
couple different env vars to prepend scan-build, but they caused errors.
Any tips?
htop
I'm trying to port htop to OpenBSD. They recently made it portable and added FreeBSD and Darwin WIPs, so it's manageable. Some of the FreeBSD code is directly usable or tweakable. I've been hacking on it for an hour and I have load average, ncpu, and uptime working. It builds fine when the FreeBSD config/make sections are simply copied. Let me know if you're interested in helping.
Re: htop
Jiri B wrote: > On Wed, Sep 02, 2015 at 07:33:39PM -0400, Michael McConville wrote: > > I'm trying to port htop to OpenBSD. They recently made it portable > > and added FreeBSD and Darwin WIPs, so it's manageable. > > > > Some of the FreeBSD code is directly usable or tweakable. I've been > > hacking on it for an hour and I have load average, ncpu, and uptime > > working. It builds fine when the FreeBSD config/make sections are > > simply copied. > > > > Let me know if you're interested in helping. > > Doesn't it depend on procfs? The interface lets you gather data pretty much however you want to. I'm planning on just using whatever top(1) does when possible.
Re: htop
Edd Barrett wrote:
> On Wed, Sep 02, 2015 at 07:33:39PM -0400, Michael McConville wrote:
> > Let me know if you're interested in helping.
>
> I would happily help testing of this.
Below is a messy preliminary diff.
I think I have the following working:
* load averages
* uptime
* CPU utilization
* memory (but not yet buffers or cached)
* swap
That leaves processes and buffered and cached memory.
Here's the main repo:
https://github.com/hishamhm/htop
diff --git a/Makefile.am b/Makefile.am
index 8fa3819..b54b9a9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,6 +51,14 @@ myhtopplatheaders = freebsd/Platform.h
freebsd/FreeBSDProcessList.h \
freebsd/FreeBSDProcess.h freebsd/FreeBSDCRT.h freebsd/Battery.h
endif
+if HTOP_OPENBSD
+myhtopplatsources = openbsd/Platform.c openbsd/OpenBSDProcessList.c \
+openbsd/OpenBSDProcess.c openbsd/OpenBSDCRT.c openbsd/Battery.c
+
+myhtopplatheaders = openbsd/Platform.h openbsd/OpenBSDProcessList.h \
+openbsd/OpenBSDProcess.h openbsd/OpenBSDCRT.h openbsd/Battery.h
+endif
+
if HTOP_DARWIN
htop_LDFLAGS += -framework IOKit -framework CoreFoundation
myhtopplatsources = darwin/Platform.c darwin/DarwinProcess.c \
diff --git a/configure.ac b/configure.ac
index 13b09a6..f865cbf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,6 +33,9 @@ case "$target" in
*freebsd*)
my_htop_platform=freebsd
;;
+*openbsd*)
+ my_htop_platform=openbsd
+ ;;
*darwin*)
my_htop_platform=darwin
;;
@@ -168,6 +171,10 @@ if test "$my_htop_platform" = "freebsd"; then
AC_CHECK_LIB([kvm], [kvm_open], [], [missing_libraries="$missing_libraries
libkvm"])
fi
+if test "$my_htop_platform" = "openbsd"; then
+ AC_CHECK_LIB([kvm], [kvm_open], [], [missing_libraries="$missing_libraries
libkvm"])
+fi
+
AC_ARG_ENABLE(native_affinity, [AC_HELP_STRING([--enable-native-affinity],
[enable native sched_setaffinity and sched_getaffinity for affinity support,
disables hwloc])], ,enable_native_affinity="yes")
if test "x$enable_native_affinity" = xyes -a "x$cross_compiling" = xno; then
AC_MSG_CHECKING([for usable sched_setaffinity])
@@ -211,6 +218,7 @@ AC_DEFINE_UNQUOTED(COPYRIGHT, "(C) 2004-$year Hisham
Muhammad", [Copyright messa
# --
AM_CONDITIONAL([HTOP_LINUX], [test "$my_htop_platform" = linux])
AM_CONDITIONAL([HTOP_FREEBSD], [test "$my_htop_platform" = freebsd])
+AM_CONDITIONAL([HTOP_OPENBSD], [test "$my_htop_platform" = openbsd])
AM_CONDITIONAL([HTOP_DARWIN], [test "$my_htop_platform" = darwin])
AM_CONDITIONAL([HTOP_UNSUPPORTED], [test "$my_htop_platform" = unsupported])
AC_SUBST(my_htop_platform)
diff --git a/openbsd/Battery.c b/openbsd/Battery.c
new file mode 100644
index 000..37ac815
--- /dev/null
+++ b/openbsd/Battery.c
@@ -0,0 +1,15 @@
+/*
+htop - openbsd/Battery.c
+(C) 2015 Hisham H. Muhammad
+Released under the GNU GPL, see the COPYING file
+in the source distribution for its full text.
+*/
+
+#include "BatteryMeter.h"
+
+void Battery_getData(double* level, ACPresence* isOnAC) {
+ // TODO
+ *level = -1;
+ *isOnAC = AC_ERROR;
+}
+
diff --git a/openbsd/Battery.h b/openbsd/Battery.h
new file mode 100644
index 000..8ec41e3
--- /dev/null
+++ b/openbsd/Battery.h
@@ -0,0 +1,15 @@
+/* Do not edit this file. It was automatically generated. */
+
+#ifndef HEADER_Battery
+#define HEADER_Battery
+/*
+htop - openbsd/Battery.h
+(C) 2015 Hisham H. Muhammad
+Released under the GNU GPL, see the COPYING file
+in the source distribution for its full text.
+*/
+
+void Battery_getData(double* level, ACPresence* isOnAC);
+
+
+#endif
diff --git a/openbsd/OpenBSDCRT.c b/openbsd/OpenBSDCRT.c
new file mode 100644
index 000..c4e65ee
--- /dev/null
+++ b/openbsd/OpenBSDCRT.c
@@ -0,0 +1,21 @@
+/*
+htop - UnsupportedCRT.c
+(C) 2014 Hisham H. Muhammad
+Released under the GNU GPL, see the COPYING file
+in the source distribution for its full text.
+*/
+
+#include "config.h"
+#include "CRT.h"
+#include
+#include
+
+void CRT_handleSIGSEGV(int sgn) {
+ (void) sgn;
+ CRT_done();
+ fprintf(stderr, "\n\nhtop " VERSION " aborting.\n");
+ fprintf(stderr, "\nUnfortunately, you seem to be using an unsupported
platform!");
+ fprintf(stderr, "\nPlease contact your platform package mantainer!\n\n");
+ abort();
+}
+
diff --git a/openbsd/OpenBSDCRT.h b/openbsd/OpenBSDCRT.h
new file mode 100644
index 000..3c808ca
--- /dev/null
+++ b/openbsd/OpenBSDCRT.h
@@ -0,0 +1,15 @@
+/* Do not edit this file. It was automatically generated. */
+
+#ifndef HEADER_UnsupportedCRT
+#define HEADER_UnsupportedCRT
+/*
+htop - UnsupportedCRT.h
+(C) 2014 Hisham H. Muhammad
+Released under the GNU GPL, see the COPYING file
+in the source distributi
Re: Ports broken after l2k15
Christian Weisgerber wrote: > The latest amd64 package build has revealed a number of ports that are > broken after the l2k15 hackathon. > > A number of ports use SHA-0. It doesn't look like important > functionality, more like, let's support it because OpenSSL offers it: > > [...] > security/john-jumbo > [...] This may actually be a functionality loss for john. It bruteforces encrypted or hashed passwords, so it supports old and weird algorithms. Maybe it can pull SHA-0 from a package. Or maybe no one needs to bruteforce anything that uses SHA-0 and SHA-0 support can be patched out without complaint. We could also talk to upstream about adding a preproc condition.
Re: htop
Edd Barrett wrote: > On Wed, Sep 02, 2015 at 07:33:39PM -0400, Michael McConville wrote: > > Let me know if you're interested in helping. > > I would happily help testing of this. Here's my fork: https://github.com/mmcco/htop And my pull request: https://github.com/hishamhm/htop/pull/274 It's an alpha that I hacked together in spare hours, so don't expect miracles. However, I think everything on the default screen is working now. It'll probably be merged soon. I used code and logic from top(1) and ps(1) when possible, so thanks to the people who wrote and maintain those. I gave them credit in the code as well.
Re: Abiword pasting issue
Alan Corey wrote: > In OpenBSD 5.2 (and 5.0, 4.7, 4.3) I've written a lot of emails in > Abiword (and saved to files, etc) then pasted into gmail (web client > in Firefox) to send. > > In OpenBSD 5.7 when I paste question marks replace the entire message like > > It looks like Abiword's using a character set Firefox doesn't > recognize. The email sends like that too, it's just question marks on > the receiving end. ASCII 0x3F. > > I can write in Libre Office and paste into Firefox, that's normal. > OpenBSD 5.8 uses the same Abiword version (3.01) so I assume it will > work the same way. I don't see any option in Abiword to change > character sets other than font, that doesn't help. If I paste into > Firefox anywhere (search box, URL window), I get question marks. Very > disappointing to see Abiword's now mixed up with Gnome, that may be at > the root of the problem. > > I can't seem to copy from Abiword and paste into Libre Office Writer > either. Pasting into the Joe editor gives question marks. I've had problems with Abiword character encodings in the past. The example I remember is the Unicode in the scale bars. Can you: env | egrep '(LANG|LC_)' And reply with the results?
Re: Abiword pasting issue
Michael McConville wrote: > Alan Corey wrote: > > In OpenBSD 5.2 (and 5.0, 4.7, 4.3) I've written a lot of emails in > > Abiword (and saved to files, etc) then pasted into gmail (web client > > in Firefox) to send. > > > > In OpenBSD 5.7 when I paste question marks replace the entire message like > > > > It looks like Abiword's using a character set Firefox doesn't > > recognize. The email sends like that too, it's just question marks on > > the receiving end. ASCII 0x3F. > > > > I can write in Libre Office and paste into Firefox, that's normal. > > OpenBSD 5.8 uses the same Abiword version (3.01) so I assume it will > > work the same way. I don't see any option in Abiword to change > > character sets other than font, that doesn't help. If I paste into > > Firefox anywhere (search box, URL window), I get question marks. Very > > disappointing to see Abiword's now mixed up with Gnome, that may be at > > the root of the problem. > > > > I can't seem to copy from Abiword and paste into Libre Office Writer > > either. Pasting into the Joe editor gives question marks. > > I've had problems with Abiword character encodings in the past. The > example I remember is the Unicode in the scale bars. > > Can you: > > env | egrep '(LANG|LC_)' > > And reply with the results? (Or, preferably, just use the 'locale' command.)
Re: Abiword pasting issue
Alan Corey wrote: > Bingo, could that be because I use tcsh and probably switched to it > before I installed Abiword? > > locale says: > > LANG= > LC_COLLATE="C" > LC_CTYPE="C" > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_MESSAGES="C" > LC_ALL= Does adding this to ~/.xsession (if you use xdm) or ~/.xinitrc (if you use startx) change anything? > export LC_CTYPE="en_US.UTF-8"
Re: archivers/xz: pledge
Stuart Henderson wrote:
> On 2015/10/21 17:36, Christian Weisgerber wrote:
> > This re-adds pledge() support for xz and xzdec. For multi-threading,
> > you'll need a really -current kernel since the required __tfork()
> > handling was only added last weekend.
> >
> > Please try to break it. ;-)
>
> from src/xz/args.c:
>
> case 'T':
> // The max is from src/liblzma/common/common.h.
> hardware_threads_set(str_to_uint64("threads",
> optarg, 0, 16384));
> break;
>
> So using 'xz -T0' asks it to auto-detect the number of threads to use;
> in this case it calls lzma_cputhreads() which calls tuklib_cpucores()
> which does sysctl(6.3,...
>
> Do we want to add that to the always-permitted sysctls? It's used by
> top(1) and also for sysconf(_SC_NPROCESSORS_CONF).
For what it's worth, I think every Go program reads hw.ncpu to determine
how many threads to run with. I suspect other languages use this
approach too.
This change seems like a good idea to me.
> Index: kern_pledge.c
> ===
> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 kern_pledge.c
> --- kern_pledge.c 20 Oct 2015 18:04:03 - 1.62
> +++ kern_pledge.c 22 Oct 2015 22:01:12 -
> @@ -899,6 +899,9 @@ pledge_sysctl_check(struct proc *p, int
> if (miblen == 2 && /* getpagesize() */
> mib[0] == CTL_HW && mib[1] == HW_PAGESIZE)
> return (0);
> + if (miblen == 2 && /* hw.ncpu */
> + mib[0] == CTL_HW && mib[1] == HW_NCPU)
> + return (0);
> if (miblen == 2 && /* setproctitle() */
> mib[0] == CTL_VM && mib[1] == VM_PSSTRINGS)
> return (0);
>
Re: porting xmpp-client (or go software)
Daniel Jakots wrote: > Hi, > > I'm looking forward to package agl's xmpp-client. I already installed > it with `go get` but I'd prefer to have a package. > > In my $GOPATH/src, I have > > . > |-- github.com > | `-- agl > | |-- xmpp > | `-- xmpp-client > `-- golang.org > `-- x > |-- crypto > [...] > `-- net > |-- context > [...] > |-- spdy > |-- webdav > `-- websocket > > I saw that there is already net/go-websocket so I guess I have also to > create net/go-context and so on, same thing from crypto (the full tree > is attached fyi), am I right? Indeed you are. I had a private discussion with a few porters about this recently. Also, check out the tool godep for situations like this. Very useful.
Re: porting xmpp-client (or go software)
Michael McConville wrote: > Daniel Jakots wrote: > > Hi, > > > > I'm looking forward to package agl's xmpp-client. I already installed > > it with `go get` but I'd prefer to have a package. > > > > [...] > > > > I saw that there is already net/go-websocket so I guess I have also to > > create net/go-context and so on, same thing from crypto (the full tree > > is attached fyi), am I right? > > Indeed you are. I had a private discussion with a few porters about this > recently. > > Also, check out the tool godep for situations like this. Very useful. On a related note, here's the list of Go sub-repository packages, which "are part of the Go Project but outside the main Go tree". https://godoc.org/-/subrepo It'd be really useful for someone to write a script that packages and updates these. It's on my to-do list. If/when Go catches on, this'll become a p5-* situation.
Re: [update] lang/rust 1.4.0
Sebastien Marie wrote:
> Hi,
>
> Here a patch for updating lang/rust to latest stable version: 1.4.0
>
> Testing would be welcome.
>
> An intermittent failure on `net::addr::tests::to_socket_addr_str_bad'
> test is possible. It isn't a regress (this problem seems to be present
> long time ago), but I would like to investigate it a bit with people
> that are able to reproduce it (my buildhost don't trigger it).
Built fine for me, after a couple laptop deaths from going >100°C. It's
hard to find a big stress-tester program to build without Cargo. Does
anyone have suggestions?
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/rust/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 22 Sep 2015 08:11:24 - 1.10
> +++ Makefile 29 Oct 2015 05:09:39 -
> @@ -7,8 +7,8 @@ PKG_ARCH-doc =*
> COMMENT-main = compiler for Rust Language
> COMMENT-doc =html documentation for rustc
>
> -V = 1.3.0
> -RUST_HASH = 198068b3
> +V = 1.4.0
> +RUST_HASH = 1bf6e69c
> DISTNAME = rustc-${V}-src
>
> SUBST_VARS +=RUST_HASH
> @@ -20,7 +20,7 @@ PKGNAME-doc = rust-doc-${V}
> MULTI_PACKAGES = -main -doc
>
> # the snapshot version should be the version in src/snapshots.txt
> -SNAPSHOT-amd64 =
> rust-stage0-2015-07-26-a5c12f4-openbsd-x86_64-8b21d574a65c38e7c7b08d675d8a44cec214.tar.bz2
> +SNAPSHOT-amd64 =
> rust-stage0-2015-08-11-1af31d4-openbsd-x86_64-9cae790c4ca19b1b29a048605ce249fe1c20a498.tar.bz2
>
> CATEGORIES = lang
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/rust/distinfo,v
> retrieving revision 1.6
> diff -u -p -r1.6 distinfo
> --- distinfo 22 Sep 2015 08:11:24 - 1.6
> +++ distinfo 29 Oct 2015 05:09:39 -
> @@ -1,4 +1,4 @@
> -SHA256
> (rust/rust-stage0-2015-07-26-a5c12f4-openbsd-x86_64-8b21d574a65c38e7c7b08d675d8a44cec214.tar.bz2)
> = jAqcLs1YeRZ8W6jBtX6dK9Tk/zOJaTEWo4bo8YkC8Ok=
> -SHA256 (rust/rustc-1.3.0-src.tar.gz) =
> 6gLXvJ595bi+P+azfqmyvYI/mlMsjkxH0C838k/6MSY=
> -SIZE
> (rust/rust-stage0-2015-07-26-a5c12f4-openbsd-x86_64-8b21d574a65c38e7c7b08d675d8a44cec214.tar.bz2)
> = 19831265
> -SIZE (rust/rustc-1.3.0-src.tar.gz) = 24308223
> +SHA256
> (rust/rust-stage0-2015-08-11-1af31d4-openbsd-x86_64-9cae790c4ca19b1b29a048605ce249fe1c20a498.tar.bz2)
> = SV8nV81ML4Z1aK3BSyfykjMtIcBS6I+4zX9HYKkbeTk=
> +SHA256 (rust/rustc-1.4.0-src.tar.gz) =
> HA39zlyF2AmPzrua3xSThHq0DB36qMyZevCbLvCqghE=
> +SIZE
> (rust/rust-stage0-2015-08-11-1af31d4-openbsd-x86_64-9cae790c4ca19b1b29a048605ce249fe1c20a498.tar.bz2)
> = 19863445
> +SIZE (rust/rustc-1.4.0-src.tar.gz) = 24537507
> Index: pkg/PLIST-doc
> ===
> RCS file: /cvs/ports/lang/rust/pkg/PLIST-doc,v
> retrieving revision 1.6
> diff -u -p -r1.6 PLIST-doc
> --- pkg/PLIST-doc 22 Sep 2015 08:11:24 - 1.6
> +++ pkg/PLIST-doc 29 Oct 2015 05:09:50 -
> @@ -10,16 +10,12 @@ share/doc/rust/html/SourceSerifPro-Bold.
> share/doc/rust/html/SourceSerifPro-Regular.woff
> share/doc/rust/html/alloc/
> share/doc/rust/html/alloc/arc/
> -share/doc/rust/html/alloc/arc/fn.get_mut.html
> -share/doc/rust/html/alloc/arc/fn.strong_count.html
> -share/doc/rust/html/alloc/arc/fn.weak_count.html
> share/doc/rust/html/alloc/arc/index.html
> share/doc/rust/html/alloc/arc/sidebar-items.js
> share/doc/rust/html/alloc/arc/struct.Arc.html
> share/doc/rust/html/alloc/arc/struct.Weak.html
> share/doc/rust/html/alloc/boxed/
> share/doc/rust/html/alloc/boxed/constant.HEAP.html
> -share/doc/rust/html/alloc/boxed/fn.into_raw.html
> share/doc/rust/html/alloc/boxed/index.html
> share/doc/rust/html/alloc/boxed/sidebar-items.js
> share/doc/rust/html/alloc/boxed/struct.Box.html
> @@ -33,7 +29,6 @@ share/doc/rust/html/alloc/heap/fn.alloca
> share/doc/rust/html/alloc/heap/fn.deallocate.html
> share/doc/rust/html/alloc/heap/fn.reallocate.html
> share/doc/rust/html/alloc/heap/fn.reallocate_inplace.html
> -share/doc/rust/html/alloc/heap/fn.stats_print.html
> share/doc/rust/html/alloc/heap/fn.usable_size.html
> share/doc/rust/html/alloc/heap/index.html
> share/doc/rust/html/alloc/heap/sidebar-items.js
> @@ -43,11 +38,6 @@ share/doc/rust/html/alloc/raw_vec/index.
> share/doc/rust/html/alloc/raw_vec/sidebar-items.js
> share/doc/rust/html/alloc/raw_vec/struct.RawVec.html
> share/doc/rust/html/alloc/rc/
> -share/doc/rust/html/alloc/rc/fn.get_mut.html
> -share/doc/rust/html/alloc/rc/fn.is_unique.html
> -share/doc/rust/html/alloc/rc/fn.strong_count.html
> -share/doc/rust/html/alloc/rc/fn.try_unwrap.html
> -share/doc/rust/html/alloc/rc/fn.weak_count.html
> share/doc/rust/html/alloc/rc/index.html
> share/doc/rust/html/alloc/rc/sidebar-items.js
> share/doc/rust/html/a
Deleting . on removal
When running pkg_delete -a, I got this: > libev-4.20: ok > Read shared items: ok > --- -libev-4.20 --- > Error deleting directory lib/qt4: No such file or directory > Error deleting directory lib: No such file or directory > Error deleting directory .: Device busy I'm assuming that's not supposed to happen?
[update] Imapfilter 2.6.3
They added some new SSL conditions that don't compile. I took the simple route in the attached patches and defaulted to SSL23. That uses the best available cipher, right? This approach is a little iffy because I think it ignores the user's cipher prefs. I wanted to get a working WiP so that people could review it because I haven't worked with SSL/TLS APIs before. What's attached builds and runs fine for me. imapfilter.tgz Description: application/tar-gz
Re: update: devel/llvm
Pascal Stumpf wrote: > mmc@ reminded me that I had been slacking on getting this into the tree. > > This patch updates LLVM to version 3.7, using GCC from ports as a > compiler, and using its headers and libstdc++ at runtime. The downside > is, of course, that everything compiled with clang++ will now depend on > libstdc++ from ports. But until we have libc++, there is really nothing > else we can do. Having a modern LLVM with a complete C++11 featureset > is more important. > > Works on amd64, i386 and sparc64. powerpc and mips64 are still WIP, > both upstream and portwise. > > The patch below is only the update itself. This also needs patches to > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++ > logic. I will send these shortly. I've been running this for weeks and have used it for some big builds. No apparent problems. ok mmcc@
Re: update: devel/llvm
Stuart Henderson wrote: > On 2015/11/11 10:26, Michael McConville wrote: > > Pascal Stumpf wrote: > > > mmc@ reminded me that I had been slacking on getting this into the tree. > > > > > > This patch updates LLVM to version 3.7, using GCC from ports as a > > > compiler, and using its headers and libstdc++ at runtime. The downside > > > is, of course, that everything compiled with clang++ will now depend on > > > libstdc++ from ports. But until we have libc++, there is really nothing > > > else we can do. Having a modern LLVM with a complete C++11 featureset > > > is more important. > > > > > > Works on amd64, i386 and sparc64. powerpc and mips64 are still WIP, > > > both upstream and portwise. > > > > > > The patch below is only the update itself. This also needs patches to > > > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++ > > > logic. I will send these shortly. > > > > I've been running this for weeks and have used it for some big builds. > > No apparent problems. ok mmcc@ > > > > What testing has been done so far in the ports tree? IIRC, I built Landry's Firefox beta with it. I also use scan-build often.
Re: yubikey ports
Stuart Henderson wrote: > Currently these are scattered all over the place. I'd like to move > them all to subdirs of security/yubico: Sounds like a good idea to me. I remember this being annoying when I got my YubiKey. Will test build soon.
Re: [NEW] misc/sent
Joerg Jung wrote: > Hi, > > please find attached a port for the new suckless presentation tool sent. > > OK to import? > > Regards, > Joerg Nifty, and WFM. I've been looking for exactly this kind of presentation tool. Thanks. > $ cat pkg/DESCR > > Simple plaintext presentation tool. > > sent does not need latex, libreoffice or any other fancy file format, it uses > plaintext files and png images. Currently every paragraph represents a slide > in > the presentation. Especially for presentations using the Takahashi method this > is very nice and allows you to write down the presentation for a quick > lightning > talk within a few minutes. > > The presentation is displayed in a simple X11 window colored black on white > for > maximum contrast even if the sun shines directly onto the projected image. The > content of each slide is automatically scaled to fit the window so you don't > have to worry about alignment. Instead you can really concentrate on the > content.
Re: net/tor - add Flavor
Uwe Werler wrote:
> Hello list,
>
> I'd like to add a Flavor to tor which allows Tor2webMode:
This seems like a rare enough use-case that it probably isn't worth a
flavor. It also runs the risk that people will think "Tor2web" is what
they need (plausible, based on the name) and thereby deanonymize
themselves.
> --- net/tor/Makefile.orig Fri Nov 13 05:25:33 2015
> +++ net/tor/MakefileFri Nov 13 04:26:09 2015
> @@ -12,6 +12,9 @@
> # BSD
> PERMIT_PACKAGE_CDROM= Yes
>
> +PSEUDO_FLAVORS = tor2web
> +FLAVOR ?=
> +
> WANTLIB += c crypto event m pthread ssl z
>
> MASTER_SITES= https://www.torproject.org/dist/
> @@ -22,6 +25,11 @@
> # anyway on FRAME_GROWS_DOWN archs.
> CONFIGURE_ARGS=--with-ssl-dir=/usr \
> --disable-gcc-hardening
> +
> +.if ${FLAVOR:L:Mtor2web}
> +CONFIGURE_ARGS += --enable-tor2web-mode
> +.endif
> +
> CONFIGURE_ENV+=ac_cv_member_struct_ssl_method_st_get_cipher_by_char=no
>
> DB_DIR=/var/tor
>
> ##
>
> --- net/tor/pkg/DESCR.orig Fri Nov 13 05:16:53 2015
> +++ net/tor/pkg/DESCR Fri Nov 13 05:22:06 2015
> @@ -1,2 +1,6 @@
> Tor is a connection-based low-latency anonymous communication system that
> protects TCP streams: web browsing, instant messaging, irc, ssh, etc.
> +
> +In Tor2webMode Tor connects to hidden services non-anonymously but faster.
> +It's useful only when running a tor2web Hidden Service web proxy or to
> connect
> +directly to a Hidden Service without the need of client anonymity.
>
> ##
>
> Regards Uwe
>
> --
>
Re: net/tor - add Flavor
Uwe Werler wrote: > On Fri, Nov 13, 2015 at 05:37:12PM -0500, Michael McConville wrote: > > Uwe Werler wrote: > > > Hello list, > > > > > > I'd like to add a Flavor to tor which allows Tor2webMode: > > > > This seems like a rare enough use-case that it probably isn't worth a > > flavor. It also runs the risk that people will think "Tor2web" is what > > they need (plausible, based on the name) and thereby deanonymize > > themselves. > > Mmh, 1. it's not enabled per default and 2. only connections to hidden > services are allowed so You can't exit from within the tor network. Will people be prompted with the choice when they install tor with pkg_add? That's what I'm concerned about. Also, bsd.port.mk(5) says of PSEUDO_FLAVORS: > Its only use should be for disabling part of a multi-packages build Am I misunderstanding, or should it be replaced with FLAVORS here?
Re: net/tor - add Flavor
Uwe Werler wrote: > On Sun, Nov 15, 2015 at 08:15:57PM +0100, Stefan Sperling wrote: > > On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: > > > But treating this as "extremely dangerous" without offering a path > > > forward means that people need to "roll their own" approaches when > > > faced with related needs. > > > > The way forward is use tor properly to access hidden services. > > > > tor2web was conceived in 2008 to make it easier for whistleblowers > > to use tor instead of nothing. Unfortunately in 2015 whistleblowers > > have very good reasons to use something better than tor2web. > > what do You mean with "use something better"? I'm really interested in > Your suggestion. I think this discussion is getting outside the scope of this mailing list. tor-t...@lists.torproject.org is probably a better place for it.
Re: NEW: www/tbb - Tor Browser Bundle
[trimming history] attila wrote: > > In the interests of simplicity and efficacy the tarball can be found > > here: http://bits.haqistan.net/~attila/tbb.tgz > > I've updated http://bits.haqistan.net/~attila/tbb.tgz with the > just-completed update to Tor Browser 4.5.3. Tested on amd64. > >>> > >>> I brought the ports up to the current version, which is now 5.0.3. > >>> I've also solved my attachment woes; updated ports attached (URL above > >>> has new bits as well). Tested on amd64. There are packages available > >>> for testing at: > >>> http://mirrors.nycbug.org/pub/snapshots/packages/amd64/ > >>> The README file there might be helpful if you want to test. > >>> > >>> FWIW, the GH repository is: https://github.com/torbsd/openbsd-ports > >>> YMMV. > >> > >> Re-reupdate & re-reping: > >> > >> Thanks to Daniel Jakots for pointing out that the inter-package > >> dependencies were all balled up and led to problems. Updated ports > >> attached with better deps, updated packages for testing available at > >> the nycbug URL, above. > > > > Re*ping. I know some people have been using the packages we put up > > for testing purposes. I also know this is potentially sort of a > > controversial (set of) port(s) and that everyone is busy but if anyone > > could be troubled to take a look and give some feedback that would > > be great. > > > > Attaching the latest version of the ports for completeness. > > Ping. I've been running this as my primary browser for a couple weeks and it's working perfectly. I don't know enough about Mozilla porting practices or port infrastructure to comment on the technique used, but this is definitely stable enough to get committed. So, tentative ok mmcc@, but it should definitely be ok'd by an experienced porter before being committed.
Re: NEW: www/tbb - Tor Browser Bundle
Dmitrij D. Czarkoff wrote: > I don't like pkgpaths www/tbb/noscript and www/tbb/https-everywhere: > these extensions are not tbb-specific. I think they are. IIUC, those have changes specific to the TBB. Other browsers use the stock versions provided by their addon source.
[update] devel/afl 1.95b
ok? Index: Makefile === RCS file: /cvs/ports/devel/afl/Makefile,v retrieving revision 1.20 diff -u -p -r1.20 Makefile --- Makefile23 Sep 2015 13:30:42 - 1.20 +++ Makefile16 Nov 2015 18:36:10 - @@ -3,7 +3,7 @@ ONLY_FOR_ARCHS= i386 amd64 COMMENT= instrumented fuzzer -DISTNAME= afl-1.94b +DISTNAME= afl-1.95b EXTRACT_SUFX= .tgz CATEGORIES=devel Index: distinfo === RCS file: /cvs/ports/devel/afl/distinfo,v retrieving revision 1.20 diff -u -p -r1.20 distinfo --- distinfo23 Sep 2015 13:30:42 - 1.20 +++ distinfo16 Nov 2015 18:36:10 - @@ -1,2 +1,2 @@ -SHA256 (afl-1.94b.tgz) = F1cf8SetEN7GinQzgOyO/d9UHB9RRVXYqMY0qcb3ZrA= -SIZE (afl-1.94b.tgz) = 804169 +SHA256 (afl-1.95b.tgz) = IexruMGC/YIdJci2coP4GmMsT3RBnJ21/sATXdDJrio= +SIZE (afl-1.95b.tgz) = 804542
Imapfilter cert validation
5.8's imapfilter is version 2.6.1. This commit is the only change between that and 2.6.2: https://github.com/lefcha/imapfilter/commit/0526dee062c28257a14f2ed7afca49a9a384e4aa Definitely security-relevant, but I'm not sure how bad bugs need to be to warrant backporting. The -current version is 2.6.3. Should it be committed to 5.8?
Re: [NEW] misc/sent
Their public dev list is hack...@suckless.org. It's probably worth
letting them know.
Thanks.
Matthieu Herrb wrote:
> On Fri, Nov 13, 2015 at 10:30:32PM +0100, Joerg Jung wrote:
> > Hi,
> >
> > please find attached a port for the new suckless presentation tool sent.
> >
> > OK to import?
>
> hmm this code is of low quality for a tool released in 2015.
>
> http://marc.infœ?t=14477246942&r=1&w=2
>
> As part of the xorg security team I looked at this to see of libXft is
> responsible. I found that
>
> sent /etc/passwd
>
> will crash because 71 lines (on my machine) don't fit in a single
> slide and the code that looks for a small enough font is buggy. It
> uses an unsigned 'j' variable in a loop that says (getfontsize()
> sent.c:321) :
>
> for (j = NUMFONTSCALES - 1; j >= 0; j--) {
>
> so this will happily lead to huge j values, later used as indexes in
> an array...
>
> Even with that fixed, the same getfontsize() function won't be able to
> handle the lack of an appropriate font and reference font[-1] with joy
> and fireworks.
>
> Later in the oss-sec thread someone noticed that 'sent empty' with
> empty beeing a 0-length file will also produce a memory access
> error. Indeed with malloc.conf -> J it happily dereferences a
> 0xd0d0d0d0d0d0d0 pointer since there is not such input as line[0] if
> the file is empty.
>
> I looked at this to check if there are bugs in Xft, not as as
> potential user of misc/sent. So I won't bother trying to fix it,
> sorry.
>
> >
> > Regards,
> > Joerg
> >
> >
> > $ cat pkg/DESCR
> >
> > Simple plaintext presentation tool.
> >
> > sent does not need latex, libreoffice or any other fancy file format, it
> > uses
> > plaintext files and png images. Currently every paragraph represents a
> > slide in
> > the presentation. Especially for presentations using the Takahashi method
> > this
> > is very nice and allows you to write down the presentation for a quick
> > lightning
> > talk within a few minutes.
> >
> > The presentation is displayed in a simple X11 window colored black on white
> > for
> > maximum contrast even if the sun shines directly onto the projected image.
> > The
> > content of each slide is automatically scaled to fit the window so you don't
> > have to worry about alignment. Instead you can really concentrate on the
> > content.
[UPDATE] misc/zzuf 0.14
Apparently this is their first release in >5 years.
The website says that development is done on GitHub and links to this
repo. The 0.14 release is only on GitHub.
They use MAP_POPULATE, which is a Linuxism, in an mmap() test call. I
removed it but I'm not sure what the file tests for. Could this
interfere?
Also, wouldn't this be better put in the security or devel category?
It fails one test. I'm not sure whether this matters. Any experienced
zzuf users out there?
Index: Makefile
===
RCS file: /cvs/ports/misc/zzuf/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile21 Mar 2013 08:46:33 - 1.11
+++ Makefile18 Nov 2015 05:34:03 -
@@ -2,10 +2,11 @@
COMMENT= transparent application input fuzzer
-DISTNAME= zzuf-0.13
-REVISION= 2
+VERSION= 0.14
+DISTNAME= zzuf-${VERSION}
CATEGORIES=misc
-MASTER_SITES= http://libcaca.zoy.org/files/zzuf/
+
+MASTER_SITES=
https://github.com/samhocevar/zzuf/releases/download/v${VERSION}/
# WTFPL
PERMIT_PACKAGE_CDROM= Yes
@@ -14,12 +15,5 @@ WANTLIB= c m
CONFIGURE_STYLE= gnu
USE_GROFF= Yes
-
-pre-configure:
- perl -pi -e 's/zzcat/zzufcat/g' ${WRKSRC}/doc/zzcat.1.in
-
-post-install:
- cd ${PREFIX}/bin && mv zzcat zzufcat
- cd ${PREFIX}/man/man1 && mv zzcat.1 zzufcat.1
.include
Index: distinfo
===
RCS file: /cvs/ports/misc/zzuf/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo18 Jan 2015 03:14:34 - 1.6
+++ distinfo18 Nov 2015 05:34:03 -
@@ -1,2 +1,2 @@
-SHA256 (zzuf-0.13.tar.gz) = CELFSFIgKMPg2cnPfQn2MgtmHzOCS7bfGcogmFG99ic=
-SIZE (zzuf-0.13.tar.gz) = 461498
+SHA256 (zzuf-0.14.tar.gz) = KRtB1Trm33XQ0rSg+qMzrfxKArnKhwa+5H73vmV5Zs4=
+SIZE (zzuf-0.14.tar.gz) = 469885
Index: patches/patch-src_libzzuf_lib-stream_c
===
RCS file: patches/patch-src_libzzuf_lib-stream_c
diff -N patches/patch-src_libzzuf_lib-stream_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libzzuf_lib-stream_c 18 Nov 2015 05:34:03 -
@@ -0,0 +1,16 @@
+A simple missing semicolon. Fixed upstream by commit 9eb78c6:
+
+
https://github.com/samhocevar/zzuf/commit/9eb78c602c1ef292cb5d94e6dad5d3d2c4215786
+
+$OpenBSD$
+--- src/libzzuf/lib-stream.c.orig Tue Nov 17 23:58:02 2015
src/libzzuf/lib-stream.c Tue Nov 17 23:58:29 2015
+@@ -1052,7 +1052,7 @@ char *NEW(fgetln)(FILE *stream, size_t *len)
+
+ fuzz->tmp[i] = (char)(unsigned char)chr;
+ }
+-while (fuzz->tmp[i++] != '\n')
++while (fuzz->tmp[i++] != '\n');
+
+ *len = i;
+ char *ret = fuzz->tmp;
Index: patches/patch-src_md5_c
===
RCS file: patches/patch-src_md5_c
diff -N patches/patch-src_md5_c
--- patches/patch-src_md5_c 14 Jul 2014 08:07:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_md5_c,v 1.1 2014/07/14 08:07:37 espie Exp $
src/md5.c.orig Mon Jul 14 09:43:54 2014
-+++ src/md5.c Mon Jul 14 09:44:40 2014
-@@ -24,6 +24,10 @@
- #endif
- #if defined HAVE_ENDIAN_H
- # include
-+# if !defined(__BYTE_ORDER)
-+# define __BYTE_ORDER BYTE_ORDER
-+# define __LITTLE_ENDIAN LITTLE_ENDIAN
-+# endif
- #endif
- #include
- #include
Index: patches/patch-src_util_md5_c
===
RCS file: patches/patch-src_util_md5_c
diff -N patches/patch-src_util_md5_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_util_md5_c18 Nov 2015 05:34:03 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+--- src/util/md5.c.origSat May 30 10:30:00 2015
src/util/md5.c Wed Nov 18 00:05:36 2015
+@@ -24,6 +24,10 @@
+ #endif
+ #if defined HAVE_ENDIAN_H
+ # include
++# if !defined(__BYTE_ORDER)
++# define __BYTE_ORDER BYTE_ORDER
++# define __LITTLE_ENDIAN LITTLE_ENDIAN
++# endif
+ #endif
+ #include
+ #include
Index: patches/patch-test_bug-mmap_c
===
RCS file: patches/patch-test_bug-mmap_c
diff -N patches/patch-test_bug-mmap_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-test_bug-mmap_c 18 Nov 2015 05:34:03 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+--- test/bug-mmap.c.orig Wed Nov 18 00:14:02 2015
test/bug-mmap.cWed Nov 18 00:14:26 2015
+@@ -13,8 +13,6 @@
+
+ #include "config.h"
+
+-#define _BSD_SOURCE 1 /* for MAP_POPULATE */
+-
+ #if HAVE_SYS_MMAN_H
+ # include
+ #endif
+@@ -35,7 +33,7 @@ int main(void)
+ #if defined _SC_PAGE_SIZE
+ int fd = open("/etc/hosts", O_RDONLY);
+ mmap(0, sysconf(_SC_PAGE_SIZE) * 2, PROT_READ,
+- MAP_PRI
Re: [UPDATE] misc/zzuf 0.14
Michael McConville wrote:
> Apparently this is their first release in >5 years.
>
> The website says that development is done on GitHub and links to this
> repo. The 0.14 release is only on GitHub.
>
> They use MAP_POPULATE, which is a Linuxism, in an mmap() test call. I
> removed it but I'm not sure what the file tests for. Could this
> interfere?
>
> Also, wouldn't this be better put in the security or devel category?
>
> It fails one test. I'm not sure whether this matters. Any experienced
> zzuf users out there?
Upstream surrounded the mmap test in an #ifdef MAP_POPULATE since the
last release, effectively disabling it, so I opted for that instead.
zhuk suggested that USE_GROFF may be unnecessary and it builds without
it, but I'll leave it in for now because sthen had concerns about the
man page formatting.
I got an ok from zhuk@. Any objections?
Index: Makefile
===
RCS file: /cvs/ports/misc/zzuf/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile21 Mar 2013 08:46:33 - 1.11
+++ Makefile18 Nov 2015 21:43:36 -
@@ -2,10 +2,11 @@
COMMENT= transparent application input fuzzer
-DISTNAME= zzuf-0.13
-REVISION= 2
+VERSION= 0.14
+DISTNAME= zzuf-${VERSION}
CATEGORIES=misc
-MASTER_SITES= http://libcaca.zoy.org/files/zzuf/
+
+MASTER_SITES=
https://github.com/samhocevar/zzuf/releases/download/v${VERSION}/
# WTFPL
PERMIT_PACKAGE_CDROM= Yes
@@ -14,12 +15,5 @@ WANTLIB= c m
CONFIGURE_STYLE= gnu
USE_GROFF= Yes
-
-pre-configure:
- perl -pi -e 's/zzcat/zzufcat/g' ${WRKSRC}/doc/zzcat.1.in
-
-post-install:
- cd ${PREFIX}/bin && mv zzcat zzufcat
- cd ${PREFIX}/man/man1 && mv zzcat.1 zzufcat.1
.include
Index: distinfo
===
RCS file: /cvs/ports/misc/zzuf/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo18 Jan 2015 03:14:34 - 1.6
+++ distinfo18 Nov 2015 21:43:36 -
@@ -1,2 +1,2 @@
-SHA256 (zzuf-0.13.tar.gz) = CELFSFIgKMPg2cnPfQn2MgtmHzOCS7bfGcogmFG99ic=
-SIZE (zzuf-0.13.tar.gz) = 461498
+SHA256 (zzuf-0.14.tar.gz) = KRtB1Trm33XQ0rSg+qMzrfxKArnKhwa+5H73vmV5Zs4=
+SIZE (zzuf-0.14.tar.gz) = 469885
Index: patches/patch-src_libzzuf_lib-stream_c
===
RCS file: patches/patch-src_libzzuf_lib-stream_c
diff -N patches/patch-src_libzzuf_lib-stream_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libzzuf_lib-stream_c 18 Nov 2015 21:43:36 -
@@ -0,0 +1,16 @@
+A simple missing semicolon. Fixed upstream by commit 9eb78c6:
+
+
https://github.com/samhocevar/zzuf/commit/9eb78c602c1ef292cb5d94e6dad5d3d2c4215786
+
+$OpenBSD$
+--- src/libzzuf/lib-stream.c.orig Tue Nov 17 23:58:02 2015
src/libzzuf/lib-stream.c Tue Nov 17 23:58:29 2015
+@@ -1052,7 +1052,7 @@ char *NEW(fgetln)(FILE *stream, size_t *len)
+
+ fuzz->tmp[i] = (char)(unsigned char)chr;
+ }
+-while (fuzz->tmp[i++] != '\n')
++while (fuzz->tmp[i++] != '\n');
+
+ *len = i;
+ char *ret = fuzz->tmp;
Index: patches/patch-src_md5_c
===
RCS file: patches/patch-src_md5_c
diff -N patches/patch-src_md5_c
--- patches/patch-src_md5_c 14 Jul 2014 08:07:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_md5_c,v 1.1 2014/07/14 08:07:37 espie Exp $
src/md5.c.orig Mon Jul 14 09:43:54 2014
-+++ src/md5.c Mon Jul 14 09:44:40 2014
-@@ -24,6 +24,10 @@
- #endif
- #if defined HAVE_ENDIAN_H
- # include
-+# if !defined(__BYTE_ORDER)
-+# define __BYTE_ORDER BYTE_ORDER
-+# define __LITTLE_ENDIAN LITTLE_ENDIAN
-+# endif
- #endif
- #include
- #include
Index: patches/patch-src_util_md5_c
===
RCS file: patches/patch-src_util_md5_c
diff -N patches/patch-src_util_md5_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_util_md5_c18 Nov 2015 21:43:36 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+--- src/util/md5.c.origSat May 30 10:30:00 2015
src/util/md5.c Wed Nov 18 00:05:36 2015
+@@ -24,6 +24,10 @@
+ #endif
+ #if defined HAVE_ENDIAN_H
+ # include
++# if !defined(__BYTE_ORDER)
++# define __BYTE_ORDER BYTE_ORDER
++# define __LITTLE_ENDIAN LITTLE_ENDIAN
++# endif
+ #endif
+ #include
+ #include
Index: patches/patch-test_bug-mmap_c
===
RCS file: patches/patch-test_bug-mmap_c
diff -N patches/patch-test_bug-mmap_c
--- /dev/null 1 Jan 1970 00:00:00 -
Re: update misc/sent 0.2
Joerg Jung wrote: > please find below an update to sent 0.2. > This release fixes several serious segfaults and issues. > > OK? Works for me. ok mmcc@ It's too bad that they put big gray borders around PNGs now, though... > Index: Makefile > === > RCS file: /cvs/ports/misc/sent/Makefile,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 Makefile > --- Makefile 14 Nov 2015 19:38:55 - 1.1.1.1 > +++ Makefile 25 Nov 2015 11:41:25 - > @@ -2,7 +2,7 @@ > > COMMENT= simple plaintext presentation tool > > -DISTNAME=sent-0.1 > +DISTNAME=sent-0.2 > > CATEGORIES= misc productivity > > Index: distinfo > === > RCS file: /cvs/ports/misc/sent/distinfo,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 distinfo > --- distinfo 14 Nov 2015 19:38:55 - 1.1.1.1 > +++ distinfo 25 Nov 2015 11:41:25 - > @@ -1,2 +1,2 @@ > -SHA256 (sent-0.1.tar.gz) = n2qlu+r4O7WEqD9DcJ3rHCnODTiNCzr1sMxgEPHA0CU= > -SIZE (sent-0.1.tar.gz) = 13837 > +SHA256 (sent-0.2.tar.gz) = U7lh+dkqJ3pkCN9wJbSm3q5rZVp5c4PJNEIpDkU5EHY= > +SIZE (sent-0.2.tar.gz) = 13479 >
[update] fonts/hack-fonts 2.010 -> 2.018
And add myself as maintainer.
ok?
Index: Makefile
===
RCS file: /cvs/ports/fonts/hack-fonts/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile25 Sep 2015 12:50:07 - 1.2
+++ Makefile30 Nov 2015 03:04:59 -
@@ -4,12 +4,13 @@ PKG_ARCH =*
COMMENT = typeface designed for source code
-V =2.010
-REVISION = 0
+V =2.018
DISTNAME = Hack-v${V:S/./_/}-otf
PKGNAME = hack-fonts-$V
CATEGORIES = fonts
HOMEPAGE = http://sourcefoundry.org/hack/
+
+MAINTAINER = Michael McConville
# SIL Open Font License v1.1
PERMIT_PACKAGE_CDROM = Yes
Index: distinfo
===
RCS file: /cvs/ports/fonts/hack-fonts/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo2 Sep 2015 08:51:42 - 1.1.1.1
+++ distinfo30 Nov 2015 03:04:59 -
@@ -1,2 +1,2 @@
-SHA256 (Hack-v2_010-otf.zip) = 3nV7LdG2ODUF/x5zhF20gtzPdWGhEz/l53bgL4K/Xp0=
-SIZE (Hack-v2_010-otf.zip) = 450300
+SHA256 (Hack-v2_018-otf.zip) = Q99xiVy4tbDhTyiAqM4mFwZNzDbPIp5WgvHgZROkYEY=
+SIZE (Hack-v2_018-otf.zip) = 466060
Index: pkg/PLIST
===
RCS file: /cvs/ports/fonts/hack-fonts/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 2 Sep 2015 08:51:42 - 1.1.1.1
+++ pkg/PLIST 30 Nov 2015 03:04:59 -
@@ -2,6 +2,6 @@
share/fonts/
@fontdir share/fonts/Hack/
share/fonts/Hack/Hack-Bold.otf
-share/fonts/Hack/Hack-BoldOblique.otf
+share/fonts/Hack/Hack-BoldItalic.otf
+share/fonts/Hack/Hack-Italic.otf
share/fonts/Hack/Hack-Regular.otf
-share/fonts/Hack/Hack-RegularOblique.otf
security/keepassx broken?
Is the KeepassX GUI broken for anyone else? It hasn't worked for me on -current since I updated my packages yesterday.
Re: Update: cmake-3.4.0
David Coppa wrote: > Hi all! > > Here's the update to CMake-3.4.0. > > Please test it or (even better) put it into your next bulk build. I tried building the LLVM development head with this. It died 53% in for (I think) LLVM-related reasons. So, this looks good to me so far. I agree that waiting for a bulk build would be best, though.
Re: [patch] bsd.port.mk.5: there is no lang/gcc/4.2 anymore
Daniel Bolgheroni wrote: > Hi, > > lang/gcc/4.2 got removed from ports. > > Alternative: suggest x11/gnome/gvfs? > > ok? Wouldn't changing 4.2 to 4.9 be an easier change? This is a useful fix, though. > Index: bsd.port.mk.5 > === > RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v > retrieving revision 1.428 > diff -u -p -r1.428 bsd.port.mk.5 > --- bsd.port.mk.5 23 Nov 2015 10:01:45 - 1.428 > +++ bsd.port.mk.5 6 Dec 2015 15:31:31 - > @@ -3638,10 +3638,8 @@ should be built: > .Ed > .Pp > The > -.Pa lang/gcc/4.2 > -or > .Pa print/poppler > -ports should provide examples of proper use. > +port should provide an example of proper use. > .Pp > Note that > .Xr dpb 1 > -- > db >
Re: lang/go-bootstrap
Stuart Henderson wrote:
> Slight problem with the go update, it breaks build of some ports using
> the go module:
>
> textproc/go-xlsx
> net/go-websocket
> devel/go-check-v1
> devel/go-tools
I'm working on an update for go-tools.
We have a manual install command for cover and vet, but the binaries
moved from $MODGO_TOOLS to the main binary dir. Not sure if we still
need them to be be under $MODGO_TOOLS anymore. The below diff leaves a
copy in both dirs.
Also, make update-plist isn't recognizing the rc script for me. It says:
> make-plist: Bogus element outside of every prefix: /etc/rc.d/godoc
Index: Makefile
===
RCS file: /cvs/ports/devel/go-tools/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Aug 2015 20:15:41 - 1.3
+++ Makefile6 Dec 2015 18:46:56 -
@@ -3,9 +3,8 @@
COMMENT = various tools for the Go programming language
GH_ACCOUNT = golang
GH_PROJECT = tools
-GH_COMMIT =27e692e6ec36d8f48be794f32553e1400c70dbf2
-DISTNAME = go-tools-1.4.20150206
-REVISION = 1
+GH_TAGNAME = release-branch.go1.5
+DISTNAME = go-tools-1.5
CATEGORIES = devel
HOMEPAGE = http://golang.org/
@@ -50,7 +49,7 @@ post-patch:
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/${MODGO_TOOLS}
.for tool in vet cover
- ${INSTALL_PROGRAM} ${WRKDIR}/${MODGO_TOOLS}/${tool} \
+ ${INSTALL_PROGRAM} ${WRKDIR}/go/bin/${tool} \
${PREFIX}/${MODGO_TOOLS}/${tool}
.endfor
Index: distinfo
===
RCS file: /cvs/ports/devel/go-tools/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo8 Jun 2015 09:41:03 - 1.1.1.1
+++ distinfo6 Dec 2015 18:46:56 -
@@ -1,2 +1,2 @@
-SHA256 (go-tools-1.4.20150206.tar.gz) =
TeD9TrQh23FPay1LlAvHUTuTmEb7ZxsWx/okCb3vf+g=
-SIZE (go-tools-1.4.20150206.tar.gz) = 1625310
+SHA256 (go-tools-1.5.tar.gz) = DYZjGq7I0MLKcFbgLIov39ocwqbqPXPI8YU++CyM3ic=
+SIZE (go-tools-1.5.tar.gz) = 1634851
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/go-tools/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 11 Aug 2015 20:15:41 - 1.3
+++ pkg/PLIST 6 Dec 2015 18:46:56 -
@@ -1,9 +1,7 @@
-@comment $OpenBSD: PLIST,v 1.3 2015/08/11 20:15:41 jasper Exp $
-@pkgpath devel/gocover
-@pkgpath textproc/godoc
-@conflict stress-*
+@comment $OpenBSD$
@bin bin/benchcmp
@bin bin/callgraph
+@bin bin/cover
@bin bin/digraph
@bin bin/eg
@bin bin/fiximports
@@ -17,6 +15,6 @@
@bin bin/ssadump
@bin bin/stress
@bin bin/stringer
+@bin bin/vet
@bin ${MODGO_TOOLS}/cover
@bin ${MODGO_TOOLS}/vet
-@rcscript ${RCDIR}/godoc
Re: lang/go-bootstrap
Michael McConville wrote:
> Stuart Henderson wrote:
> > Slight problem with the go update, it breaks build of some ports using
> > the go module:
> >
> > textproc/go-xlsx
> > net/go-websocket
> > devel/go-check-v1
> > devel/go-tools
>
> I'm working on an update for go-tools.
>
> We have a manual install command for cover and vet, but the binaries
> moved from $MODGO_TOOLS to the main binary dir. Not sure if we still
> need them to be be under $MODGO_TOOLS anymore. The below diff leaves a
> copy in both dirs.
>
> Also, make update-plist isn't recognizing the rc script for me. It says:
>
> > make-plist: Bogus element outside of every prefix: /etc/rc.d/godoc
I just realized that that tag doesn't make sense to use here. It's a
shame that they don't use releases. We'll have to pick a daily tag to
use, as was the case before.
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/go-tools/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 11 Aug 2015 20:15:41 - 1.3
> +++ Makefile 6 Dec 2015 18:46:56 -
> @@ -3,9 +3,8 @@
> COMMENT =various tools for the Go programming language
> GH_ACCOUNT = golang
> GH_PROJECT = tools
> -GH_COMMIT = 27e692e6ec36d8f48be794f32553e1400c70dbf2
> -DISTNAME = go-tools-1.4.20150206
> -REVISION = 1
> +GH_TAGNAME = release-branch.go1.5
> +DISTNAME = go-tools-1.5
> CATEGORIES = devel
> HOMEPAGE = http://golang.org/
>
> @@ -50,7 +49,7 @@ post-patch:
> post-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/${MODGO_TOOLS}
> .for tool in vet cover
> - ${INSTALL_PROGRAM} ${WRKDIR}/${MODGO_TOOLS}/${tool} \
> + ${INSTALL_PROGRAM} ${WRKDIR}/go/bin/${tool} \
> ${PREFIX}/${MODGO_TOOLS}/${tool}
> .endfor
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/go-tools/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 8 Jun 2015 09:41:03 - 1.1.1.1
> +++ distinfo 6 Dec 2015 18:46:56 -
> @@ -1,2 +1,2 @@
> -SHA256 (go-tools-1.4.20150206.tar.gz) =
> TeD9TrQh23FPay1LlAvHUTuTmEb7ZxsWx/okCb3vf+g=
> -SIZE (go-tools-1.4.20150206.tar.gz) = 1625310
> +SHA256 (go-tools-1.5.tar.gz) = DYZjGq7I0MLKcFbgLIov39ocwqbqPXPI8YU++CyM3ic=
> +SIZE (go-tools-1.5.tar.gz) = 1634851
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/go-tools/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- pkg/PLIST 11 Aug 2015 20:15:41 - 1.3
> +++ pkg/PLIST 6 Dec 2015 18:46:56 -
> @@ -1,9 +1,7 @@
> -@comment $OpenBSD: PLIST,v 1.3 2015/08/11 20:15:41 jasper Exp $
> -@pkgpath devel/gocover
> -@pkgpath textproc/godoc
> -@conflict stress-*
> +@comment $OpenBSD$
> @bin bin/benchcmp
> @bin bin/callgraph
> +@bin bin/cover
> @bin bin/digraph
> @bin bin/eg
> @bin bin/fiximports
> @@ -17,6 +15,6 @@
> @bin bin/ssadump
> @bin bin/stress
> @bin bin/stringer
> +@bin bin/vet
> @bin ${MODGO_TOOLS}/cover
> @bin ${MODGO_TOOLS}/vet
> -@rcscript ${RCDIR}/godoc
>
Re: lang/go-bootstrap
Michael McConville wrote: > Michael McConville wrote: > > Stuart Henderson wrote: > > > Slight problem with the go update, it breaks build of some ports using > > > the go module: > > > > > > textproc/go-xlsx > > > net/go-websocket > > > devel/go-check-v1 > > > devel/go-tools > > > > I'm working on an update for go-tools. I'll save the rest of my layman's analysis, but basically the root of the failure is this import: > ./api.go:13: import > /home/build/go-tools/go/pkg/openbsd_amd64/golang.org/x/tools/container/intsets.a: > not a package file This causes golang.org/x/tools/go/pointer to fail, which propagates up. I'm not yet sure how OpenBSD-specific this is. Maybe someone more actively involved with Go can point me in the right direction.
Re: lang/go-bootstrap
Joel Sing wrote: > Thanks for clarlifying - we could still implement 'go get -d' as a way > of getting sources, but it would be more work than it is likely worth > (and there are also some issues surrounding which versions of the > dependencies get fetched). > > I'll rework go.port.mk and the relevant packages using > /usr/local/go-pkg. Just to clarify, is /usr/local/go-pkg (or whatever else we end up calling the dir) going to be added to the default $GOPATH as a patch? Will it be suggested to the user in a post-install message? Or is this only for the port system, and users won't have access to the port dependencies?
Re: UPDATE: security/keepassx (keepassx 2.0)
Rafael Sadowski wrote: > > Are you sure you need ports gcc ? > > > Yes I'm sure. C++11. Okay, it's optional but default on. Yeah, my initial reaction that we should check the code carefully before disabling C++11. Seems like it might expose some poorly tested paths. And I don't know whether that's worth it.
Re: UPDATE: devel/afl-1.96b
Gleydson Soares wrote: > The following updates devel/afl to 1.96b. > builds and runs fine on both (amd64/i386), regress seems happy too. > OK? Looks good, and works for me. ok mmcc@ > Index: Makefile > === > RCS file: /cvs/ports/devel/afl/Makefile,v > retrieving revision 1.21 > diff -u -p -r1.21 Makefile > --- Makefile 25 Nov 2015 02:27:12 - 1.21 > +++ Makefile 16 Dec 2015 19:56:53 - > @@ -3,7 +3,7 @@ > ONLY_FOR_ARCHS= i386 amd64 > > COMMENT= instrumented fuzzer > -DISTNAME=afl-1.95b > +DISTNAME=afl-1.96b > EXTRACT_SUFX=.tgz > CATEGORIES= devel > > Index: distinfo > === > RCS file: /cvs/ports/devel/afl/distinfo,v > retrieving revision 1.21 > diff -u -p -r1.21 distinfo > --- distinfo 25 Nov 2015 02:27:12 - 1.21 > +++ distinfo 16 Dec 2015 19:56:53 - > @@ -1,2 +1,2 @@ > -SHA256 (afl-1.95b.tgz) = IexruMGC/YIdJci2coP4GmMsT3RBnJ21/sATXdDJrio= > -SIZE (afl-1.95b.tgz) = 804542 > +SHA256 (afl-1.96b.tgz) = A76wb4mT3LN9NI5T2hnKnQZMg/ztydh7C1Bsc8MQ8nw= > +SIZE (afl-1.96b.tgz) = 804864 > Index: patches/patch-Makefile > === > RCS file: /cvs/ports/devel/afl/patches/patch-Makefile,v > retrieving revision 1.15 > diff -u -p -r1.15 patch-Makefile > --- patches/patch-Makefile25 Nov 2015 02:27:12 - 1.15 > +++ patches/patch-Makefile16 Dec 2015 19:56:53 - > @@ -1,7 +1,7 @@ > $OpenBSD: patch-Makefile,v 1.15 2015/11/25 02:27:12 gsoares Exp $ > Makefile.origThu Nov 12 23:58:12 2015 > -+++ Makefile Tue Nov 24 09:56:32 2015 > -@@ -18,7 +18,7 @@ VERSION = 1.95b > +--- Makefile.origWed Dec 16 01:24:06 2015 > Makefile Wed Dec 16 16:55:42 2015 > +@@ -18,7 +18,7 @@ VERSION = 1.96b > > PREFIX ?= /usr/local > BIN_PATH= $(PREFIX)/bin >
Re: UPDATE: security/keepassx (keepassx 2.0)
Rafael Sadowski wrote: > Dear keepassx users and port veterans, > > after long workdays before the Xmas break, here is a new updated diff > with your hints: > > - add DWITH_CXX11=no > - fix WANTLIB > - fix and add LIB_DEPENDS > - SHARED_ONLY tagged > - fix PLIST > - add gtk-update-icon-cache (advice from portcheck) > > Okay? (Okay from steven@ to update keepassx -- not for the patch (at the > moment)) Builds and runs fine for me. ok mmcc@ I get this to stderr whenever opening a db: > setNativeLocks failed: Resource temporarily unavailable > setNativeLocks failed: Resource temporarily unavailable I'd assume they're falling back to some platform-naive file-locking technique that doesn't work on OpenBSD. I don't have time to look at the moment. It doesn't interfere with anything for me, though.
Re: UPDATE: www/youtube-dl
Giovanni Bechis wrote:
> Update to today's version.
> Please commit.
> Cheers
> Giovanni
Done. Thanks!
> Index: Makefile
> ===
> RCS file: /var/cvs/ports/www/youtube-dl/Makefile,v
> retrieving revision 1.147
> diff -u -p -r1.147 Makefile
> --- Makefile 11 Dec 2015 06:38:49 - 1.147
> +++ Makefile 23 Dec 2015 19:04:41 -
> @@ -2,7 +2,7 @@
>
> COMMENT =CLI program to download videos from YouTube and other sites
>
> -VERSION =2015.12.10
> +VERSION =2015.12.23
> MODPY_EGG_VERSION = ${VERSION:S/.0/./}
>
> DISTNAME = youtube-dl-${VERSION}
> Index: distinfo
> ===
> RCS file: /var/cvs/ports/www/youtube-dl/distinfo,v
> retrieving revision 1.135
> diff -u -p -r1.135 distinfo
> --- distinfo 11 Dec 2015 06:38:49 - 1.135
> +++ distinfo 23 Dec 2015 19:04:48 -
> @@ -1,2 +1,2 @@
> -SHA256 (youtube-dl-2015.12.10.tar.gz) =
> WFeAWEX4tT5VLWi6ZeuMuaIzJcRXs6SxR7WfBMN31bw=
> -SIZE (youtube-dl-2015.12.10.tar.gz) = 1830382
> +SHA256 (youtube-dl-2015.12.23.tar.gz) =
> /nCIl5x465AMPbEQpXeGagHh3VN83dolJYiT8Jn/+bo=
> +SIZE (youtube-dl-2015.12.23.tar.gz) = 1850244
> Index: pkg/PLIST
> ===
> RCS file: /var/cvs/ports/www/youtube-dl/pkg/PLIST,v
> retrieving revision 1.91
> diff -u -p -r1.91 PLIST
> --- pkg/PLIST 9 Dec 2015 21:32:40 - 1.91
> +++ pkg/PLIST 23 Dec 2015 19:05:03 -
> @@ -57,8 +57,6 @@ lib/python${MODPY_VERSION}/site-packages
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/adobetv.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/adultswim.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/adultswim.pyc
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/aftenposten.py
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/aftenposten.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/aftonbladet.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/aftonbladet.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/airmozilla.py
> @@ -69,6 +67,8 @@ lib/python${MODPY_VERSION}/site-packages
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/allocine.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/alphaporno.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/alphaporno.pyc
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/amp.py
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/amp.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/anitube.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/anitube.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/anysex.py
> @@ -117,10 +117,10 @@ lib/python${MODPY_VERSION}/site-packages
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bild.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bilibili.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bilibili.pyc
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bleacherreport.py
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bleacherreport.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/blinkx.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/blinkx.pyc
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bliptv.py
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bliptv.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bloomberg.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bloomberg.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/bpb.py
> @@ -139,8 +139,6 @@ lib/python${MODPY_VERSION}/site-packages
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/c56.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/camdemy.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/camdemy.pyc
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canal13cl.py
> -lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canal13cl.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalc2.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalc2.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalplus.py
> @@ -343,6 +341,8 @@ lib/python${MODPY_VERSION}/site-packages
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/freespeech.pyc
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/freevideo.py
> lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/freevideo.pyc
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/funimation.py
> +lib/python${MODPY_VERSION}/site-packages/youtube_d
gplugin WIP
How close is this to being committable? I don't think GPlugin is actually used by anything yet, but it's going to be required by future Pidgin releases, so it's useful for testing. I suspect that it needs SHARED_ONLY. I remember having Lua support working a few months ago, but I can't get one of the cmake checks working even with lua-lgi's LD_PRELOAD hack (see lua-lgi's DESCR for details). I disabled it for now. gplugin.tgz Description: application/tar-gz
Re: UPDATE: graphics/sxiv 1.3.2
Michael Reed wrote:
> The maintainer [Matthew Via] who said I could send this patch here
> as he hasn't the time to review it, given the holidays.
>
> sxiv 1.3.2 was recently released[1] and it seems to work fine during
> basic usage.
>
> The patches I added were very minor:
> - the paths to `key-handler` and `image-info` weren't accurate
> - `pkg/DESCR` was slightly out of date with the the description
> used in sxiv's README.md (missing a reference to libexif)
>
> Regards,
> Michael Reed
>
> [1]: https://github.com/muennich/sxiv/releases/tag/v1.3.2
Looks good to me. Thanks! I'll commit soon if there are no objections.
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/sxiv/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile 23 May 2015 16:34:40 - 1.7
> +++ Makefile 24 Dec 2015 01:15:23 -
> @@ -4,7 +4,7 @@ COMMENT = simple (or small or suckless)
>
> GH_PROJECT= sxiv
> GH_ACCOUNT= muennich
> -GH_TAGNAME= v1.3.1
> +GH_TAGNAME= v1.3.2
> DISTNAME=${GH_PROJECT}-${GH_TAGNAME:S/v//}
>
> CATEGORIES = graphics x11
> Index: distinfo
> ===
> RCS file: /cvs/ports/graphics/sxiv/distinfo,v
> retrieving revision 1.4
> diff -u -p -r1.4 distinfo
> --- distinfo 16 Apr 2015 10:27:26 - 1.4
> +++ distinfo 24 Dec 2015 01:15:23 -
> @@ -1,2 +1,2 @@
> -SHA256 (sxiv-1.3.1.tar.gz) = mjChsDbhwXISEoVUcJ2j8tZdO+rvLgpzCXr141zxHQ4=
> -SIZE (sxiv-1.3.1.tar.gz) = 47171
> +SHA256 (sxiv-1.3.2.tar.gz) = n1No3o8PV+eOvgLLUxoxEHqZPydpzsUbzI1w9cZotlM=
> +SIZE (sxiv-1.3.2.tar.gz) = 46560
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/graphics/sxiv/patches/patch-Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-Makefile
> --- patches/patch-Makefile16 Apr 2015 10:27:26 - 1.3
> +++ patches/patch-Makefile24 Dec 2015 01:15:23 -
> @@ -1,7 +1,23 @@
> $OpenBSD: patch-Makefile,v 1.3 2015/04/16 10:27:26 jung Exp $
> Makefile.origSun Nov 16 21:38:30 2014
> -+++ Makefile Wed Apr 15 23:09:54 2015
> -@@ -19,7 +19,7 @@ $(OBJ): Makefile
> +--- Makefile.origSun Dec 20 07:21:25 2015
> Makefile Wed Dec 23 20:01:02 2015
> +@@ -11,11 +11,11 @@ LIBS := -lX11 -lImlib2
> +
> + # optional dependencies:
> + # giflib: gif animations
> +-CPPFLAGS += -DHAVE_GIFLIB
> +-LIBS += -lgif
> ++CPPFLAGS += -DHAVE_GIFLIB
> ++LIBS += -lgif
> + # libexif: jpeg auto-orientation, exif thumbnails
> +-CPPFLAGS += -DHAVE_LIBEXIF
> +-LIBS += -lexif
> ++CPPFLAGS += -DHAVE_LIBEXIF
> ++LIBS += -lexif
> +
> +
> + .PHONY: clean install uninstall
> +@@ -30,7 +30,7 @@ $(OBJ): Makefile
>
> -include $(DEP)
>
> @@ -10,7 +26,7 @@ $OpenBSD: patch-Makefile,v 1.3 2015/04/1
> $(CC) $(CFLAGS) $(CPPFLAGS) -DVERSION=\"$(VERSION)\" -MMD -MP -c -o $@
> $<
>
> config.h:
> -@@ -32,15 +32,15 @@ clean:
> +@@ -43,15 +43,15 @@ clean:
> rm -f $(OBJ) $(DEP) sxiv
>
> install: all
> Index: patches/patch-sxiv_1
> ===
> RCS file: patches/patch-sxiv_1
> diff -N patches/patch-sxiv_1
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-sxiv_1 24 Dec 2015 01:15:23 -
> @@ -0,0 +1,21 @@
> +$OpenBSD$
> +--- sxiv.1.orig Sun Dec 20 07:21:25 2015
> sxiv.1 Wed Dec 23 20:11:36 2015
> +@@ -354,7 +354,7 @@ image gets loaded. The path of this script is
> + and the first argument to this script is the path of the loaded image.
> + .P
> + There is also an example script installed together with sxiv as
> +-.IR PREFIX/share/sxiv/exec/image-info .
> ++.IR PREFIX/share/examples/sxiv/image-info .
> + .SH EXTERNAL KEY HANDLER
> + Additional external keyboard commands can be defined using a handler program
> + located in
> +@@ -372,7 +372,7 @@ where C/M/S indicate Ctrl/Meta(Alt)/Shift modifier sta
> + keysym as listed in /usr/include/X11/keysymdef.h without the "XK_" prefix.
> +
> + There is also an example script installed together with sxiv as
> +-.IR PREFIX/share/sxiv/exec/key-handler .
> ++.IR PREFIX/share/examples/sxiv/key-handler .
> + .SH THUMBNAIL CACHING
> + sxiv stores all thumbnails under
> + .IR $XDG_CACHE_HOME/sxiv/ .
> Index: pkg/DESCR
> ===
> RCS file: /cvs/ports/graphics/sxiv/pkg/DESCR,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 DESCR
> --- pkg/DESCR 27 Feb 2012 08:45:50 - 1.1.1.1
> +++ pkg/DESCR 24 Dec 2015 01:15:23 -
> @@ -1,7 +1,7 @@
> sxiv is an alternative to feh and qiv. Its only dependencies besides
> -xlib are imlib2 and giflib. The primary goal for writing sxiv is to
> -create an image viewer, which only has the most basic features required
> -for fast image viewing (the ones I want). It has vi key bindings and
> -works nicely
Firefox PDF rendering
Is there a reason why Firefox often has ugly typography in PDFs generated by LaTeX and the like? Most specifically, the t's are often very fat. Here's an example: http://www.sccs.swarthmore.edu/~mmcconv1/dump/firefox-pdf.png IIRC, it's this way on some Linux distros too, so maybe it's unavoidable. Is there any way around it?
Re: gplugin WIP
Stuart Henderson wrote:
> On 2015/12/23 20:18, Michael McConville wrote:
> > How close is this to being committable?
> >
> > I don't think GPlugin is actually used by anything yet, but it's going
> > to be required by future Pidgin releases, so it's useful for testing.
> >
> > I suspect that it needs SHARED_ONLY.
> >
> > I remember having Lua support working a few months ago, but I can't get
> > one of the cmake checks working even with lua-lgi's LD_PRELOAD hack (see
> > lua-lgi's DESCR for details). I disabled it for now.
>
> From a quick read: yes to SHARED_ONLY, it's not going to do
> anything without the .so module - set it in Makefile, rm PLIST and
> PFRAG.shared and regenerate. Manual path should be ${PREFIX}/man
> not ${PREFIX}/share/man, and should use MODULES=lang/python with
> MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}, and you probably need
> to explicitly set CONFIGURE_STYLE=cmake to go with that as it's
> bodged in python.port.mk.
Thanks. My second attempt is attached.
gplugin.tgz
Description: application/tar-gz
[update] Imapfilter 2.6.3 -> 2.6.4
Does the new Makefile patch make sense? This commit:
https://github.com/lefcha/imapfilter/commit/d30f8b7007c21aa2c0716d9125d393fca5039a53
Was giving me "bogus element outside of every prefix" errors during make
make-plist.
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile7 Nov 2015 01:18:17 - 1.19
+++ Makefile6 Jan 2016 06:16:42 -
@@ -2,7 +2,7 @@
COMMENT= remote IMAP filtering utility
-V= 2.6.3
+V= 2.6.4
DISTNAME= imapfilter-${V}
REVISION= 0
Index: distinfo
===
RCS file: /cvs/ports/mail/imapfilter/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo4 Nov 2015 17:51:18 - 1.10
+++ distinfo6 Jan 2016 06:16:42 -
@@ -1,2 +1,2 @@
-SHA256 (imapfilter-2.6.3.tar.gz) = EXSGLW1cpJiyWnixJ8Jba/vUwM7DD439S2sQ+GlM0kQ=
-SIZE (imapfilter-2.6.3.tar.gz) = 55757
+SHA256 (imapfilter-2.6.4.tar.gz) = qyn6qxWluaxha/ymURTFBno6JrezLipwwy6xKsHxbB4=
+SIZE (imapfilter-2.6.4.tar.gz) = 56920
Index: patches/patch-src_Makefile
===
RCS file: patches/patch-src_Makefile
diff -N patches/patch-src_Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_Makefile 6 Jan 2016 06:16:42 -
@@ -0,0 +1,22 @@
+$OpenBSD$
+--- src/Makefile.orig Mon Dec 7 18:47:44 2015
src/Makefile Wed Jan 6 01:09:00 2016
+@@ -1,5 +1,5 @@
+-DESTDIR ?=
+-PREFIX ?= /usr/local
++DESTDIR =
++PREFIX = /usr/local
+ BINDIR = $(PREFIX)/bin
+ SHAREDIR = $(PREFIX)/share/imapfilter
+ MANDIR = $(PREFIX)/man
+$OpenBSD$
+--- src/Makefile.orig Mon Dec 7 18:47:44 2015
src/Makefile Wed Jan 6 01:09:00 2016
+@@ -1,5 +1,5 @@
+-DESTDIR ?=
+-PREFIX ?= /usr/local
++DESTDIR =
++PREFIX = /usr/local
+ BINDIR = $(PREFIX)/bin
+ SHAREDIR = $(PREFIX)/share/imapfilter
+ MANDIR = $(PREFIX)/man
Re: [update] Imapfilter 2.6.3 -> 2.6.4
Stuart Henderson wrote:
> On 2016/01/06 08:23, Joerg Jung wrote:
> >
> > > Am 06.01.2016 um 07:19 schrieb Michael McConville :
> > >
> > > Does the new Makefile patch make sense? This commit:
> > >
> > > https://github.com/lefcha/imapfilter/commit/d30f8b7007c21aa2c0716d9125d393fca5039a53
> > >
> > > Was giving me "bogus element outside of every prefix" errors during make
> > > make-plist.
>
> just add PREFIX="${TRUEPREFIX}" to MAKE_FLAGS
>
> > Also, I think you can drop the REVISION on version bump.
>
> +1
Thanks for the input.
ok?
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile7 Nov 2015 01:18:17 - 1.19
+++ Makefile7 Jan 2016 05:01:17 -
@@ -2,9 +2,8 @@
COMMENT= remote IMAP filtering utility
-V= 2.6.3
+V= 2.6.4
DISTNAME= imapfilter-${V}
-REVISION= 0
GH_TAGNAME=v${V}
GH_ACCOUNT=lefcha
@@ -26,6 +25,7 @@ LIB_DEPENDS= devel/pcre \
${MODLUA_LIB_DEPENDS}
MAKE_FLAGS=CC="${CC}" \
+ PREFIX="${TRUEPREFIX}" \
LIBLUA="${MODLUA_LIB}" \
MYCFLAGS="${CFLAGS} -I${LOCALBASE}/include
-I${MODLUA_INCL_DIR}" \
MYLDFLAGS="-L${LOCALBASE}/lib"
Index: distinfo
===
RCS file: /cvs/ports/mail/imapfilter/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo4 Nov 2015 17:51:18 - 1.10
+++ distinfo7 Jan 2016 05:01:17 -
@@ -1,2 +1,2 @@
-SHA256 (imapfilter-2.6.3.tar.gz) = EXSGLW1cpJiyWnixJ8Jba/vUwM7DD439S2sQ+GlM0kQ=
-SIZE (imapfilter-2.6.3.tar.gz) = 55757
+SHA256 (imapfilter-2.6.4.tar.gz) = qyn6qxWluaxha/ymURTFBno6JrezLipwwy6xKsHxbB4=
+SIZE (imapfilter-2.6.4.tar.gz) = 56920
www/sthttpd rc.d script
Here's a draft of an rc.d script for sthttpd, written with help from
Stuart. A few things to note:
The binary is named thttpd, so I used that for the script name too. For
those not familiar, sthttpd is an ever-so-lightly patched fork of
thttpd.
Unless supplied a root directory with the -d flag, thttpd will host the
current working directory. That's obviously a problem for an rc.d
script. Stuart and I talked for a little while about the best way to do
this, and he suggested that I look at /etc/rc.d/amd. I adapted that
approach.
I thought it was best to stop the process with SIGUSR1, allowing
existing connections to complete. Let me know if this could cause
unacceptable latency.
Looking forward to feedback,
Michael
Index: Makefile
===
RCS file: /cvs/ports/www/sthttpd/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile6 May 2014 09:00:37 - 1.2
+++ Makefile15 Jan 2016 22:55:31 -
@@ -3,6 +3,7 @@
COMMENT= tiny/turbo/throttling HTTP server
DISTNAME= sthttpd-2.26.4
+REVISION= 0
CATEGORIES=www
MASTER_SITES= http://opensource.dyc.edu/pub/sthttpd/
Index: pkg/thttpd.rc
===
RCS file: pkg/thttpd.rc
diff -N pkg/thttpd.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/thttpd.rc 15 Jan 2016 22:55:31 -
@@ -0,0 +1,21 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+daemon="${TRUEPREFIX}/sbin/thttpd"
+
+. /etc/rc.d/rc.subr
+
+# The /var/www root directory will be overridden by any -d flag the user
+# supplies. This addresses the awkward fact that thttpd defaults to the
+# current working directory.
+rc_start() {
+ ${rcexec} "cd /var/www; ${pexp}"
+}
+
+# SIGUSR1 allows all existing connections to terminate before exiting.
+rc_stop() {
+ pkill -USR1 -xf "^${pexp}"
+}
+
+rc_cmd $1
Remove www/weblint?
Currently, it fails when called, like this: defined(%hash) is deprecated at /usr/local/bin/weblint line 844. (Maybe you should just omit the defined()?) Can't locate newgetopt.pl in @INC (@INC contains: /home/mike/.opam/system/lib/perl5 /home/mike/.opam/system/lib/perl5 /home/mike/.opam/system/lib/perl5 /usr/local/libdata/perl5/site_perl/amd64-openbsd /usr/libdata/perl5/site_perl/amd64-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd/5.20.2 /usr/local/libdata/perl5/amd64-openbsd/5.20.2 /usr/libdata/perl5 /usr/local/libdata/perl5 .) at /usr/local/bin/weblint line 508. This seems to be because it uses a deprecated getopt pod which was finally removed. The author's website, listed as the MASTER_SITES, has changed to: http://www.cpan.org/authors/id/N/NE/NEILB/ However, it's no longer available there, which makes me think he's abandoned it. It seems that there have been few or no functional changes to the port since at least 2003. The best I can tell, the latest release (1.020) was in 2000. Thoughts?
Remove security/its4?
o There seem to have been no specific functional changes since ~2002, aside from a few configuration tweaks by kili@ in 2011 o We haven't bumped the version since 2000 o The URL listed in FETCH_MANUALLY (http://www.cigital.com/its4/) no longer points to what it should o Does anyone care about this?
Re: www/apache-httpd segfaults
Pedro de Oliveira wrote: > Following your tips I built Apache with -O0 and the segfaults in > "mpm_prefork" no longer happen. Maybe its a gcc optimization issue. I > dont know which -O OpenBSD uses by default, but I will try it also > with -O1 and report back. Remember, compiler optimizations can worsen the impact of undefined behavior. That seems more likely than a compiler bug to me.
pledge textproc/the_silver_searcher
This works for me. It unconditionally vforks at some point so, unlike
grep, it needs proc. Also, the --pager flag lets the user specify a
pager to display the output in, so it needs exec in that case.
Index: patches/patch-src_options_c
===
RCS file: patches/patch-src_options_c
diff -N patches/patch-src_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_options_c 16 Jan 2016 21:01:58 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+--- src/options.c.orig Sun Sep 6 02:20:35 2015
src/options.c Sat Jan 16 15:52:17 2016
+@@ -543,6 +543,13 @@ void parse_options(int argc, char **argv, char **base_
+ }
+ }
+
++if (opts.pager == NULL) {
++ if (pledge("stdio rpath proc", NULL) == -1)
++ err(2, "pledge");
++} else {
++ if (pledge("stdio rpath proc exec", NULL) == -1)
++ err(2, "pledge");
++}
+
+ if (ext_index[0]) {
+ num_exts = combine_file_extensions(ext_index, lang_num, &extensions);
Re: pledge textproc/the_silver_searcher
Michael McConville wrote:
> This works for me. It unconditionally vforks at some point so, unlike
> grep, it needs proc. Also, the --pager flag lets the user specify a
> pager to display the output in, so it needs exec in that case.
And bump REVISION, of course. :-)
I'm going to look into whether we can safely place pledge after the
vfork.
> Index: patches/patch-src_options_c
> ===
> RCS file: patches/patch-src_options_c
> diff -N patches/patch-src_options_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_options_c 16 Jan 2016 21:01:58 -
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +--- src/options.c.orig Sun Sep 6 02:20:35 2015
> src/options.cSat Jan 16 15:52:17 2016
> +@@ -543,6 +543,13 @@ void parse_options(int argc, char **argv, char **base_
> + }
> + }
> +
> ++if (opts.pager == NULL) {
> ++if (pledge("stdio rpath proc", NULL) == -1)
> ++err(2, "pledge");
> ++} else {
> ++if (pledge("stdio rpath proc exec", NULL) == -1)
> ++err(2, "pledge");
> ++}
> +
> + if (ext_index[0]) {
> + num_exts = combine_file_extensions(ext_index, lang_num,
> &extensions);
>
Re: pledge textproc/the_silver_searcher
Florian Stinglmayr wrote:
> On Sat, Jan 16, 2016 at 04:09:20PM -0500, Michael McConville wrote:
> > This works for me. It unconditionally vforks at some point so, unlike
> > grep, it needs proc. Also, the --pager flag lets the user specify a
> > pager to display the output in, so it needs exec in that case.
> >
> >
>
> Thanks a lot. Here is one with revision bump:
>
> I will test this but so far it seems to work.
Here's a second draft with a few changes:
o wait a few lines (until after popening the pager) so that we can
unconditionally drop exec
o it seems that the vfork was from pthread_create, so drop proc after
we call that
Does that make sense? This is my first time pledging something from
scratch.
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile9 Oct 2015 12:48:22 - 1.19
+++ Makefile16 Jan 2016 23:44:21 -
@@ -3,6 +3,7 @@
COMMENT = code searching tool, with a focus on speed (ag)
DISTNAME = the_silver_searcher-0.31.0
+REVISION = 0
CATEGORIES = textproc
HOMEPAGE = https://github.com/ggreer/the_silver_searcher
Index: patches/patch-src_main_c
===
RCS file: patches/patch-src_main_c
diff -N patches/patch-src_main_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_c16 Jan 2016 23:44:21 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+--- src/main.c.origSun Sep 6 00:29:27 2015
src/main.c Sat Jan 16 18:40:08 2016
+@@ -1,3 +1,4 @@
++#include
+ #include
+ #include
+ #include
+@@ -137,6 +138,10 @@ int main(int argc, char **argv) {
+ if (rv != 0) {
+ die("Error in pthread_create(): %s", strerror(rv));
+ }
++
++if (pledge("stdio rpath", NULL) == -1)
++err(2, "pledge");
++
+ #if defined(HAVE_PTHREAD_SETAFFINITY_NP) && defined(USE_CPU_SET)
+ if (opts.use_thread_affinity) {
+ cpu_set_t cpu_set;
Index: patches/patch-src_options_c
===
RCS file: patches/patch-src_options_c
diff -N patches/patch-src_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_options_c 16 Jan 2016 23:44:21 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+--- src/options.c.orig Sun Sep 6 02:20:35 2015
src/options.c Sat Jan 16 18:40:21 2016
+@@ -1,3 +1,4 @@
++#include
+ #include
+ #include
+ #include
+@@ -573,6 +574,9 @@ void parse_options(int argc, char **argv, char **base_
+ exit(1);
+ }
+ }
++
++if (pledge("stdio rpath proc", NULL) == -1)
++err(2, "pledge");
+
+ if (help) {
+ usage();
Re: textproc/xlsx2csv breakage
Looks like it tried to install textproc/go-xlsx (github.com/tealeg/xlsx) despite the fact that it's listed as a build dep. This might be due to a build logic bug on our end that relates to having a build dep from the same GH_ACCOUNT. I'm debugging go.port.mk at the moment. Antoine Jacoutot wrote: > ===> textproc/xlsx2csv > ===> Checking files for xlsx2csv-20150225p0 > `/exopi-cvs/ports/distfiles/xlsx2csv-20150225.tar.gz' is up to date. > ===> Extracting for xlsx2csv-20150225p0 > ===> Patching for xlsx2csv-20150225p0 > mkdir -p /exopi-obj/pobj/xlsx2csv-20150225/go/src/github.com/tealeg; mv > /exopi-obj/pobj/xlsx2csv-20150225/xlsx2csv-4d67bed54074c9f55a5443623155e57d4723901b > /exopi-obj/pobj/xlsx2csv-20150225/go/src/github.com/tealeg/xlsx2csv; > ===> Configuring for xlsx2csv-20150225p0 > ===> Building for xlsx2csv-20150225p0 > unset GOPATH; export > GOPATH="/exopi-obj/pobj/xlsx2csv-20150225/go:/usr/local/go-pkg"; go install > -x github.com/tealeg/xlsx2csv > WORK=/tmp/go-build334751853 > mkdir -p $WORK/github.com/tealeg/xlsx/_obj/ > mkdir -p $WORK/github.com/tealeg/ > cd /usr/local/go-pkg/src/github.com/tealeg/xlsx > /usr/local/go/pkg/tool/openbsd_amd64/compile -o > $WORK/github.com/tealeg/xlsx.a -trimpath $WORK -p github.com/tealeg/xlsx > -complete -buildid 90518c0c038b7176e8b01fb5b752aef4df0eb80d -D > _/usr/local/go-pkg/src/github.com/tealeg/xlsx -I $WORK -pack ./cell.go > ./col.go ./date.go ./doc.go ./file.go ./hsl.go ./lib.go ./reftable.go > ./row.go ./sheet.go ./style.go ./templates.go ./theme.go ./write.go > ./xmlContentTypes.go ./xmlSharedStrings.go ./xmlStyle.go ./xmlTheme.go > ./xmlWorkbook.go ./xmlWorksheet.go > ===> Exiting textproc/xlsx2csv with an error > mkdir -p /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/ > cp $WORK/github.com/tealeg/xlsx.a > /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a > go install github.com/tealeg/xlsx: open > /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a: permission > denied > *** Error 1 in textproc/xlsx2csv (/exopi-cvs/ports/lang/go/go.port.mk:66 > 'do-build') > *** Error 1 in textproc/xlsx2csv > (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2769 > '/exopi-obj/pobj/xlsx2csv-20150225/build-amd64/.build_done') > *** Error 1 in textproc/xlsx2csv > (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2495 'build') > *** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:147 > 'build') > Error: job failed 256
Re: pledge textproc/the_silver_searcher
Michael McConville wrote:
> Florian Stinglmayr wrote:
> > On Sat, Jan 16, 2016 at 04:09:20PM -0500, Michael McConville wrote:
> > > This works for me. It unconditionally vforks at some point so, unlike
> > > grep, it needs proc. Also, the --pager flag lets the user specify a
> > > pager to display the output in, so it needs exec in that case.
> > >
> > >
> >
> > Thanks a lot. Here is one with revision bump:
> >
> > I will test this but so far it seems to work.
>
> Here's a second draft with a few changes:
>
> o wait a few lines (until after popening the pager) so that we can
>unconditionally drop exec
>
> o it seems that the vfork was from pthread_create, so drop proc after
>we call that
>
> Does that make sense? This is my first time pledging something from
> scratch.
tb@ pointed out a mistake: my second pledge was within the pthread
creation loop. It should still work that way because repledging the same
promise set is legal. It's also unnecessary, though.
New patch:
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile9 Oct 2015 12:48:22 - 1.19
+++ Makefile17 Jan 2016 01:07:40 -
@@ -3,6 +3,7 @@
COMMENT = code searching tool, with a focus on speed (ag)
DISTNAME = the_silver_searcher-0.31.0
+REVISION = 0
CATEGORIES = textproc
HOMEPAGE = https://github.com/ggreer/the_silver_searcher
Index: patches/patch-src_main_c
===
RCS file: patches/patch-src_main_c
diff -N patches/patch-src_main_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_c17 Jan 2016 01:07:40 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+--- src/main.c.origSun Sep 6 00:29:27 2015
src/main.c Sat Jan 16 20:02:25 2016
+@@ -1,3 +1,4 @@
++#include
+ #include
+ #include
+ #include
+@@ -156,6 +157,10 @@ int main(int argc, char **argv) {
+ log_debug("No CPU affinity support.");
+ #endif
+ }
++
++if (pledge("stdio rpath", NULL) == -1)
++err(2, "pledge");
++
+ for (i = 0; paths[i] != NULL; i++) {
+ log_debug("searching path %s for %s", paths[i], opts.query);
+ symhash = NULL;
Index: patches/patch-src_options_c
===
RCS file: patches/patch-src_options_c
diff -N patches/patch-src_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_options_c 17 Jan 2016 01:07:40 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+--- src/options.c.orig Sun Sep 6 02:20:35 2015
src/options.c Sat Jan 16 18:40:21 2016
+@@ -1,3 +1,4 @@
++#include
+ #include
+ #include
+ #include
+@@ -573,6 +574,9 @@ void parse_options(int argc, char **argv, char **base_
+ exit(1);
+ }
+ }
++
++if (pledge("stdio rpath proc", NULL) == -1)
++err(2, "pledge");
+
+ if (help) {
+ usage();
Re: pledge textproc/the_silver_searcher
Michael McConville wrote:
> Michael McConville wrote:
> > Florian Stinglmayr wrote:
> > > On Sat, Jan 16, 2016 at 04:09:20PM -0500, Michael McConville wrote:
> > > > This works for me. It unconditionally vforks at some point so, unlike
> > > > grep, it needs proc. Also, the --pager flag lets the user specify a
> > > > pager to display the output in, so it needs exec in that case.
> > > >
> > > >
> > >
> > > Thanks a lot. Here is one with revision bump:
> > >
> > > I will test this but so far it seems to work.
> >
> > Here's a second draft with a few changes:
> >
> > o wait a few lines (until after popening the pager) so that we can
> >unconditionally drop exec
> >
> > o it seems that the vfork was from pthread_create, so drop proc after
> >we call that
> >
> > Does that make sense? This is my first time pledging something from
> > scratch.
>
> tb@ pointed out a mistake: my second pledge was within the pthread
> creation loop. It should still work that way because repledging the same
> promise set is legal. It's also unnecessary, though.
(Ignore the second half of the above paragraph. It would abort if it had
multiple workers that each called vfork.)
Also, yet another tweak. deraadt@ pointed out that I should use the
local err clone (die()) rather than including err.h.
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile9 Oct 2015 12:48:22 - 1.19
+++ Makefile17 Jan 2016 01:28:24 -
@@ -3,6 +3,7 @@
COMMENT = code searching tool, with a focus on speed (ag)
DISTNAME = the_silver_searcher-0.31.0
+REVISION = 0
CATEGORIES = textproc
HOMEPAGE = https://github.com/ggreer/the_silver_searcher
Index: patches/patch-src_main_c
===
RCS file: patches/patch-src_main_c
diff -N patches/patch-src_main_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_c17 Jan 2016 01:28:24 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+--- src/main.c.origSun Sep 6 00:29:27 2015
src/main.c Sat Jan 16 20:25:38 2016
+@@ -156,6 +156,10 @@ int main(int argc, char **argv) {
+ log_debug("No CPU affinity support.");
+ #endif
+ }
++
++if (pledge("stdio rpath", NULL) == -1)
++die("pledge: %s", strerror(errno));
++
+ for (i = 0; paths[i] != NULL; i++) {
+ log_debug("searching path %s for %s", paths[i], opts.query);
+ symhash = NULL;
Index: patches/patch-src_options_c
===
RCS file: patches/patch-src_options_c
diff -N patches/patch-src_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_options_c 17 Jan 2016 01:28:24 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- src/options.c.orig Sun Sep 6 02:20:35 2015
src/options.c Sat Jan 16 20:25:13 2016
+@@ -574,6 +574,9 @@ void parse_options(int argc, char **argv, char **base_
+ }
+ }
+
++if (pledge("stdio rpath proc", NULL) == -1)
++die("pledge: %s", strerror(errno));
++
+ if (help) {
+ usage();
+ exit(0);
update fonts/hack-fonts
I don't know why this used the zip archive. Maybe gzip archives weren't
available when it started.
ok?
Index: Makefile
===
RCS file: /cvs/ports/fonts/hack-fonts/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile30 Nov 2015 14:09:33 - 1.3
+++ Makefile21 Jan 2016 20:14:15 -
@@ -4,7 +4,7 @@ PKG_ARCH = *
COMMENT = typeface designed for source code
-V =2.018
+V =2.019
DISTNAME = Hack-v${V:S/./_/}-otf
PKGNAME = hack-fonts-$V
CATEGORIES = fonts
@@ -16,7 +16,6 @@ MAINTAINER = Michael McConville https://github.com/chrissimpkins/Hack/releases/download/v$V/
-EXTRACT_SUFX = .zip
WRKDIST = ${WRKDIR}
Index: distinfo
===
RCS file: /cvs/ports/fonts/hack-fonts/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo30 Nov 2015 14:09:33 - 1.2
+++ distinfo21 Jan 2016 20:14:15 -
@@ -1,2 +1,2 @@
-SHA256 (Hack-v2_018-otf.zip) = Q99xiVy4tbDhTyiAqM4mFwZNzDbPIp5WgvHgZROkYEY=
-SIZE (Hack-v2_018-otf.zip) = 466060
+SHA256 (Hack-v2_019-otf.tar.gz) = /oOGKnFSijpLWVCzyRwqHxLrwZsujzGtl4J73o+4ckI=
+SIZE (Hack-v2_019-otf.tar.gz) = 464176
update mail/imapfilter
One of our SSLv3 patches got upstreamed. I'll submit the other one soon.
ok?
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile7 Jan 2016 17:33:38 - 1.20
+++ Makefile21 Jan 2016 20:34:44 -
@@ -2,7 +2,7 @@
COMMENT= remote IMAP filtering utility
-V= 2.6.4
+V= 2.6.5
DISTNAME= imapfilter-${V}
GH_TAGNAME=v${V}
Index: distinfo
===
RCS file: /cvs/ports/mail/imapfilter/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo7 Jan 2016 17:33:38 - 1.11
+++ distinfo21 Jan 2016 20:34:44 -
@@ -1,2 +1,2 @@
-SHA256 (imapfilter-2.6.4.tar.gz) = qyn6qxWluaxha/ymURTFBno6JrezLipwwy6xKsHxbB4=
-SIZE (imapfilter-2.6.4.tar.gz) = 56920
+SHA256 (imapfilter-2.6.5.tar.gz) = D0tJ4b516/1eOjvb/wHWiqr9t6zdw1/EDc9DcClwgFU=
+SIZE (imapfilter-2.6.5.tar.gz) = 56993
Index: patches/patch-src_imapfilter_c
===
RCS file: patches/patch-src_imapfilter_c
diff -N patches/patch-src_imapfilter_c
--- patches/patch-src_imapfilter_c 4 Nov 2015 17:51:18 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,48 +0,0 @@
-$OpenBSD: patch-src_imapfilter_c,v 1.3 2015/11/04 17:51:18 jca Exp $
-
-Cope with SSLv3 removal.
-
src/imapfilter.c.orig Wed Sep 30 22:55:26 2015
-+++ src/imapfilter.c Mon Nov 2 22:37:03 2015
-@@ -21,7 +21,10 @@
-
- extern buffer ibuf, obuf, nbuf, cbuf;
- extern regexp responses[];
--extern SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx;
-+extern SSL_CTX *ssl23ctx, *tls1ctx;
-+#ifndef OPENSSL_NO_SSL3_METHOD
-+extern SSL_CTX *ssl3ctx;
-+#endif
- #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
- extern SSL_CTX *tls11ctx, *tls12ctx;
- #endif
-@@ -114,7 +117,9 @@ main(int argc, char *argv[])
-
- SSL_library_init();
- SSL_load_error_strings();
-+#ifndef OPENSSL_NO_SSL3_METHOD
- ssl3ctx = SSL_CTX_new(SSLv3_client_method());
-+#endif
- ssl23ctx = SSL_CTX_new(SSLv23_client_method());
- tls1ctx = SSL_CTX_new(TLSv1_client_method());
- #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
-@@ -125,7 +130,9 @@ main(int argc, char *argv[])
- capath = opts.truststore;
- else if (exists_file(opts.truststore))
- cafile = opts.truststore;
-+#ifndef OPENSSL_NO_SSL3_METHOD
- SSL_CTX_load_verify_locations(ssl3ctx, cafile, capath);
-+#endif
- SSL_CTX_load_verify_locations(ssl23ctx, cafile, capath);
- SSL_CTX_load_verify_locations(tls1ctx, cafile, capath);
- #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
-@@ -150,7 +157,9 @@ main(int argc, char *argv[])
- #endif
- stop_lua();
-
-+#ifndef OPENSSL_NO_SSL3_METHOD
- SSL_CTX_free(ssl3ctx);
-+#endif
- SSL_CTX_free(ssl23ctx);
- SSL_CTX_free(tls1ctx);
- #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
Re: update net/scapy
Daniel Jakots wrote: > Our scapy is old. Here's a diff to update it to latest stable. > Upstream moved to github. > > While talking with them, they advised me to get ethertypes somewhere > else than the website [1]. As it's the same name but with different > checksum, you'll have to use REFETCH=true. The difference with the > previous file are "+RARP 8035 # Reverse ARP [RFC903]", a couple of > space/tabs fixes and another link in the comment. > > If you do make test, it will hang and if you ^C it will simply stop. If > you go in scapy-2.3.2 and do `python2.7 scapy/tools/UTscapy.py -t > test/regression.uts -f html -l -o /tmp/scapy_regression_test.html` it > will hang but just ^C a couple of times and then it finishes. I've the > same behaviour with the current scapy we have in port (2.1.0). > > On 2.1.0/amd64: > PASSED=698 FAILED=58 > on 2.3.2/amd64: > PASSED=739 FAILED=28 > on 2.3.2/i386: > PASSED=739 FAILED=28 > on 2.3.2/i386 with root: > PASSED=748 FAILED=19 > > [1]: https://twitter.com/pi3rre/status/689716600056987648 Does it hang in RARP-reading code? I came across a potential bug in our RARP yesterday. Currently working on it with a few other people.
update devel/frama-c
This builds and tests successfully for me.
I needed to add an additional macro alias for a glibc rounding
operation. I'll submit upstream soon. The existing ones are wrapped in
an #ifdef __OpenBSD__, so presumably they'll accept it.
The PID-related fix is unchanged, but the source file moved.
I also got this during make update-plist:
> pkg/PFRAG.no-native empty fragment: NOT writing it
Does that mean that pkg/PFRAG.no-native is no longer needed and should
be removed? Or was it added manually?
Make test succeeds aside from a few non-fatal mutex errors:
> pthread_mutex_destroy on mutex with waiters!
jca@ verified that those are present in the current port, though, so it
doesn't seem like a regression.
I also add myself as maintainer.
Index: Makefile
===
RCS file: /cvs/ports/devel/frama-c/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile30 Aug 2015 16:22:15 - 1.7
+++ Makefile22 Jan 2016 20:58:16 -
@@ -6,10 +6,12 @@ COMMENT = an extensible platform for an
BROKEN-powerpc = Error while linking
/usr/local/lib/ocaml/vmthreads/stdlib.cma
BROKEN-alpha = Error while linking
/usr/local/lib/ocaml/vmthreads/stdlib.cma
-DISTNAME = frama-c-Sodium-20150201
-PKGNAME = frama-c-1.11
+DISTNAME = frama-c-Magnesium-20151002
+PKGNAME = frama-c-1.12
CATEGORIES = devel
HOMEPAGE = http://www.frama-c.com/
+
+MAINTAINER = Michael McConville
# LGPLv2
PERMIT_PACKAGE_CDROM = Yes
Index: distinfo
===
RCS file: /cvs/ports/devel/frama-c/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo30 Aug 2015 16:22:15 - 1.2
+++ distinfo22 Jan 2016 20:58:16 -
@@ -1,2 +1,2 @@
-SHA256 (frama-c-Sodium-20150201.tar.gz) =
WHXYawwmnTSK+kYC8Mp/5raFYZH9twPY6wvJDUyYWn0=
-SIZE (frama-c-Sodium-20150201.tar.gz) = 6155507
+SHA256 (frama-c-Magnesium-20151002.tar.gz) =
Fh9lvWbtX+ECBUYtU00bOHrHJ2Zs2XTM1J0UpQSSaB4=
+SIZE (frama-c-Magnesium-20151002.tar.gz) = 6330931
Index: patches/patch-src_buckx_buckx_c_c
===
RCS file: patches/patch-src_buckx_buckx_c_c
diff -N patches/patch-src_buckx_buckx_c_c
--- patches/patch-src_buckx_buckx_c_c 21 Apr 2014 16:02:26 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_buckx_buckx_c_c,v 1.1.1.1 2014/04/21 16:02:26 jca Exp $
src/buckx/buckx_c.c.orig Fri Apr 18 10:56:21 2014
-+++ src/buckx/buckx_c.cFri Apr 18 10:57:30 2014
-@@ -153,8 +153,8 @@ value single_precision_of_string(value str)
- value terminate_process(value v)
- {
- long pid = Long_val(v);
--#if _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE ||
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
-- kill(pid,9);
-+#if 1 || _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE ||
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
-+ kill(pid,15);
- #else
- #ifdef _WIN32
- TerminateProcess((HANDLE)pid,9);
Index: patches/patch-src_libraries_utils_c_bindings_c
===
RCS file: patches/patch-src_libraries_utils_c_bindings_c
diff -N patches/patch-src_libraries_utils_c_bindings_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libraries_utils_c_bindings_c 22 Jan 2016 20:58:16
-
@@ -0,0 +1,22 @@
+$OpenBSD$
+--- src/libraries/utils/c_bindings.c.orig Thu Jan 14 11:30:26 2016
src/libraries/utils/c_bindings.c Fri Jan 22 00:53:06 2016
+@@ -41,6 +41,7 @@
+ # define FE_DOWNWARD FP_RM
+ # define FE_UPWARD FP_RP
+ # define FE_TONEAREST FP_RN
++# define FE_TOWARDZERO FP_RZ
+ # define fegetround() fpgetround()
+ # define fesetround(RM) fpsetround(RM)
+ #else
+@@ -242,8 +243,8 @@ value single_precision_of_string(value str)
+ value terminate_process(value v)
+ {
+ long pid = Long_val(v);
+-#if _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE ||
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
+- kill(pid,9);
++#if 1 || _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE ||
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
++ kill(pid,15);
+ #else
+ #ifdef _WIN32
+ TerminateProcess((HANDLE)pid,9);
Index: pkg/PFRAG.native
===
RCS file: /cvs/ports/devel/frama-c/pkg/PFRAG.native,v
retrieving revision 1.3
diff -u -p -r1.3 PFRAG.native
--- pkg/PFRAG.native30 Aug 2015 16:22:15 - 1.3
+++ pkg/PFRAG.native22 Jan 2016 20:58:16 -
@@ -1,44 +1,16 @@
@comment $OpenBSD: PFRAG.native,v 1.3 2015/08/30 16:22:15 avsm Exp $
%%dynlink%%
@bin bin/ptests.opt
-lib/frama-c/Constant_Propagation.cmx
-lib/frama-c/Constant_Propagation.o
lib/frama-c/FCHashtbl.cmx
lib/frama-c/FCHashtbl.o
lib/frama-c/FCMap.cmx
Re: LLVM update (again)
FWIW, I've been running this patch without issue for months. Juan Francisco Cantero Hurtado wrote: > Can you modify the structure of devel/llvm/ to something like > devel/llvm/version/? With lang/gcc works pretty well, we can work with > the latest version while the ports tree uses the stable version by > default. This sounds like a good idea to me. We should probably also make sure that this update won't further complicate things for Jonathan: https://marc.info/?l=openbsd-cvs&m=145088099210901&w=2 https://marc.info/?l=openbsd-cvs&m=144816103704050&w=2 https://marc.info/?l=openbsd-cvs&m=145091674119104&w=2 https://marc.info/?l=openbsd-cvs&m=145108545813434&w=2
Re: [update] math/coq to 8.5
Yozo TODA wrote: > hi, here is an update for coq from 8.4pl6 to 8.5. > I'm working on amd64. > anyone please verify this, and commit to the tree? Thanks for this! I don't have time to fully review at the moment, but: > -# Order is important! > -INSTALL_TARGET= install-byte install-ide-byte install > +## default value for INSTALL_TARGET is "install", it's enough. > +INSTALL_TARGET= install IIUC, install is the default INSTALL_TARGET (/usr/ports/infrastructure/mk/bsd.port.mk:269), so you can probably remove that entirely.
Re: [update] math/coq to 8.5
Yozo TODA wrote: > +--- configure.ml.origThu Jan 21 01:52:18 2016 > configure.ml Sun Jan 24 23:32:41 2016 > +@@ -843,7 +843,7 @@ > + (** * md5sum command *) > + > + let md5sum = > +- if arch = "Darwin" then "md5 -q" else "md5sum" > ++ if arch = "Darwin" then "md5 -q" else if arch = "OpenBSD" then "cksum -qa > md5" else "md5sum" > + > + > + (** * Documentation : do we have latex, hevea, ... *) I suspect that our 'md5 -q' is the same as Darwin's. If so, something like this might be simpler: > +- if arch = "Darwin" || arch = "OpenBSD" then "md5 -q" else "md5sum"
Re: Vulnerable package in ports tree 29/01
Sevan / Venture37 wrote: > emulators/qemu - > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1779 Do you mean in the 5.7 or 5.8 release trees? This was patched in August.
Re: pledge textproc/the_silver_searcher
Sorry for disappearing.
Thanks for pointing out the VCS popen. Below is a draft that
incorporates your suggestions. Let me know if it's too fine-grained. My
thought was that it's ideal to drop exec as early as possible.
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile9 Oct 2015 12:48:22 - 1.19
+++ Makefile29 Jan 2016 21:12:05 -
@@ -4,6 +4,7 @@ COMMENT = code searching tool, with a fo
DISTNAME = the_silver_searcher-0.31.0
CATEGORIES = textproc
+REVISION = 0
HOMEPAGE = https://github.com/ggreer/the_silver_searcher
MAINTAINER = Florian Stinglmayr
Index: patches/patch-src_main_c
===
RCS file: patches/patch-src_main_c
diff -N patches/patch-src_main_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_c29 Jan 2016 21:12:05 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+--- src/main.c.origSun Sep 6 00:29:27 2015
src/main.c Fri Jan 29 16:01:04 2016
+@@ -35,6 +35,9 @@ int main(int argc, char **argv) {
+ int workers_len;
+ int num_cores;
+
++if (pledge("stdio rpath proc exec", NULL) == -1)
++die("pledge: %s", strerror(errno));
++
+ set_log_level(LOG_LEVEL_WARN);
+
+ work_queue = NULL;
+@@ -156,6 +159,10 @@ int main(int argc, char **argv) {
+ log_debug("No CPU affinity support.");
+ #endif
+ }
++
++if (pledge("stdio rpath", NULL) == -1)
++die("pledge: %s", strerror(errno));
++
+ for (i = 0; paths[i] != NULL; i++) {
+ log_debug("searching path %s for %s", paths[i], opts.query);
+ symhash = NULL;
Index: patches/patch-src_options_c
===
RCS file: patches/patch-src_options_c
diff -N patches/patch-src_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_options_c 29 Jan 2016 21:12:05 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+--- src/options.c.orig Sun Sep 6 02:20:35 2015
src/options.c Fri Jan 29 16:07:02 2016
+@@ -574,6 +574,9 @@ void parse_options(int argc, char **argv, char **base_
+ }
+ }
+
++if (opts.skip_vcs_ignores && pledge("stdio rpath proc", NULL) == -1)
++die("pledge: %s", strerror(errno));
++
+ if (help) {
+ usage();
+ exit(0);
+@@ -632,6 +635,9 @@ void parse_options(int argc, char **argv, char **base_
+ pclose(gitconfig_file);
+ }
+ }
++
++if (pledge("stdio rpath proc", NULL) == -1)
++die("pledge: %s", strerror(errno));
+
+ if (opts.context > 0) {
+ opts.before = opts.context;
emulators/dynamips
I started updating this but realized that it's more time than I'm
willing to invest. Does anyone use it? A lot has changed since the last
port update.
Below is the Makefile diff I needed. I don't think I'm going to try to
merge our patches, but I'm happy to review diffs if someone else tries.
Index: Makefile
===
RCS file: /cvs/ports/emulators/dynamips/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile22 Jan 2015 21:17:46 - 1.11
+++ Makefile31 Jan 2016 01:24:16 -
@@ -2,7 +2,7 @@
COMMENT= cisco 3600/7200 platform emulator
-DISTNAME= dynamips-0.2.8-RC2
+DISTNAME= dynamips-0.2.14
PKGNAME= ${DISTNAME:S/-RC/rc/}
REVISION= 4
CATEGORIES=emulators
@@ -10,6 +10,11 @@ CATEGORIES= emulators
HOMEPAGE= http://www.gns3.net/dynamips/
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=gns-3/}
+EXTRACT_SUFX= .zip
+DISTFILES= ${DISTNAME}-source${EXTRACT_SUFX}
+
+WRKDIST= ${WRKDIR}
+
MAINTAINER=Stuart Henderson
# GPL
@@ -30,6 +35,10 @@ DYNAMIPS_ARCH= "amd64"
.else
DYNAMIPS_ARCH= "nojit"
.endif
+
+DYNAMIPS_CODE= "stable"
+
+MODULES= devel/cmake
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/dynamips
Re: [update] devel/codeblocks
Josh Grosse wrote: > On Fri, Jan 29, 2016 at 03:09:38PM +0100, Antoine Jacoutot wrote: > > On Fri, Jan 29, 2016 at 08:28:31AM -0500, Josh Grosse wrote: > > > Update to 16.01. Builds and runs on amd64, with ongoing testing in > > > progress. > > > > > > Significant app changes: 6 years of development in $WRKSRC/ChangeLog > > > > > > Significant port changes: > > > > > > * wxmathplot library added > > > * new dependency on devel/libtool for libtoolize and automake pre-patch > > > * assigning maintainership > > > * parallel build permitted > > > > Thanks, I'll take care of it. > > Thank you, Antoine, for taking the time to look at the proposed update. > > I've spent several hours testing on amd64. Unlike the old version 13.12, > I have not had *any* occurances of an abort on exit. I mentioned this to Josh, but it's probably worth sharing: using an extreme malloc.conf(5) like CFJSU often reliably exposes bugs like this.
Re: jabberd out of date
Stephen Graf wrote: > It would seem that the current version of the jabberd package is 2.0, > with a date of about May 2013. The latest release is 2.3.5. I > installed the jabberd package on openBSD 5.8 and was experiencing some > difficulties with the SSL certs. I would rather work with a more > recent version before digging into problems. > > Would it be possible to have port for a more recent release? It looks like jabberd doesn't have a maintainer. The most reliable solution is to try updating it yourself: http://www.openbsd.org/faq/ports/index.html It's easier than it sounds if you have some coding experience. Otherwise, you can wait and see if someone else updates it.
lang/gcc on macppc
I'm getting the below error when building the GCC port on a Power Mac G5 running the most recent snapshot. It fails reliably when I retry the build, so it doesn't seem like an Act of God(TM) caused by a kernel or hardware bug. The build is successful with Ada disabled. Is this a known issue? Let me know if a full build log would be useful. true DO=all multi-do # gmake gmake[4]: Leaving directory '/home/build/build-powerpc/libbacktrace' gmake[3]: Leaving directory '/home/build/build-powerpc/libbacktrace' gmake[3]: Entering directory '/home/build/build-powerpc/libcpp' test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) gmake[3]: Leaving directory '/home/build/build-powerpc/libcpp' gmake[3]: Entering directory '/home/build/build-powerpc/libdecnumber' gmake[3]: Nothing to be done for 'all'. gmake[3]: Leaving directory '/home/build/build-powerpc/libdecnumber' gmake[3]: Entering directory '/home/build/build-powerpc/gcc' /home/build/build-powerpc/./prev-gcc/gnatbind -nostdinc -I- -I. -Iada -I/home/build/gcc-4.9.3/gcc/ada -I/home/build/gcc-4.9.3/gcc/ada/gcc-interface -o b_gnat1.adb -n ada/gnat1drv.ali raised CONSTRAINT_ERROR : SIGBUS /home/build/gcc-4.9.3/gcc/ada/gcc-interface/Make-lang.in:932: recipe for target 'ada/b_gnat1.adb' failed gmake[3]: *** [ada/b_gnat1.adb] Error 1 gmake[3]: Leaving directory '/home/build/build-powerpc/gcc' Makefile:4256: recipe for target 'all-stage2-gcc' failed gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory '/home/build/build-powerpc' Makefile:18532: recipe for target 'stage2-bubble' failed gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory '/home/build/build-powerpc' Makefile:18551: recipe for target 'bootstrap2' failed gmake: *** [bootstrap2] Error 2
Re: Spending time for macppc - taken from [Re: lang/gcc on macppc]
Christoph R. Murauer wrote: > > macppc is starting to be unusable as desktop because nobody > > is spending time to ensure the ports build and run correctly. > > > > Seriously asked, what is the reason, that noone spent time? There's effectively no one making new PowerPC hardware and the existing stuff is aging. Apple certainly isn't, and our port is Mac-specific. > If I am interested spending time, could I get some help (specially as > if I decided to learn coding)? With the PowerPC part, yeah, but you'll have to learn to code on your own. Do you have macppc hardware?
Re: LLVM update (again)
Has anyone else tested this on macppc? I'm getting the following error on the latest snapshot during linking. I'll try rebuilding while saving a full build log. [1/8] : && /usr/local/bin/cmake -E remove lib/libclangCodeGen.a && /usr/bin/ar qc lib/libclangCodeGen.a tools/clang/lib/CodeGen/CMakeFiles/clangCode[1/1828] BackendUtil.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGAtomic.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGBlocks.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGBuiltin.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGCUDANV.cpp.o tools/clang/lib/CodeGen/CM$keFiles/clangCodeGen.dir/CGCUDARuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen$dir/CGCXXABI.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGCall.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGClass.cpp.o tools/$lang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGCleanup.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGDebugInfo.cpp.o tools/clang/lib/CodeGen/C$akeFiles/clangCodeGen.dir/CGDecl.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGDeclCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.d$r/CGException.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExpr.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExprAgg.cpp.o too$s/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExprCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExprComplex.cpp.o tools/clang/lib/Code$en/CMakeFiles/clangCodeGen.dir/CGExprConstant.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExprScalar.cpp.o tools/clang/lib/CodeGen/CMakeFile$/clangCodeGen.dir/CGLoopInfo.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGObjC.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGOb$CGNU.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGObjCMac.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGObjCRuntime.cpp.o tools$clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGOpenCLRuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGOpenMPRuntime.cpp.o tools/clang/li$/CodeGen/CMakeFiles/clangCodeGen.dir/CGRecordLayoutBuilder.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGStmt.cpp.o tools/clang/lib/CodeGen/CM$keFiles/clangCodeGen.dir/CGStmtOpenMP.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGVTT.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.$ir/CGVTables.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenABITypes.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenActi$n.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenFunction.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenModule.cpp.o to$ls/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenPGO.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CodeGenTBAA.cpp.o tools/clang/lib/Code$en/CMakeFiles/clangCodeGen.dir/CodeGenTypes.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CoverageMappingGen.cpp.o tools/clang/lib/CodeGen/CMake$iles/clangCodeGen.dir/ItaniumCXXABI.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clang$odeGen.dir/ModuleBuilder.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/ObjectFilePCHContainerOperations.cpp.o tools/clang/lib/CodeGen/CMakeFiles$clangCodeGen.dir/SanitizerMetadata.cpp.o tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/TargetInfo.cpp.o && /usr/bin/ranlib lib/libclangCodeGen.a && : [2/8] : && /home/build/bin/c++ -O2 -pipe-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-fiel$-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -DNDEBUG -Wl,--relax -nopie -Wl,-allow-shlib-undefined-Wl,-O3 tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-t$st.c.o -o bin/c-arcmt-test -L/home/build/build-powerpc/lib -lclang -Wl,-rpath,"\$ORIGIN/../lib" -Wl,-rpath-link,/usr/X11R6/lib && : FAILED: : && /home/build/bin/c++ -O2 -pipe-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-fi$ld-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtu$l -fno-strict-aliasing -DNDEBUG -Wl,--relax -nopie -Wl,-allow-shlib-undefined-Wl,-O3 tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt$test.c.o -o bin/c-arcmt-test -L/home/build/build-powerpc/lib -lclang -Wl,-rpath,"\$ORIGIN/../lib" -Wl,-rpath-link,/usr/X11R6/lib && : /home/build/build-powerpc/lib/libclang.so.2.0:(.sdata+0x0): multiple definition of `__dso_handle' /usr/lib/
Re: Call for help updating a port (net/mcabber).
Christoph R. Murauer wrote: > Hello ! > > I know, the port mcabber has a maintainer but I needed something to > start / for understanding. In short, everything works at the first try > but at the second try I can't reproduce it. > > My snapshot is from Feb 4 and the ports tree is up to date. > > I downloaded mcabber and the needed sha from the given homepage. > Edited the Makefile and the distinfo file, runned all test steps from > the porters handbook 4.4 including updating the plist without errors. > After that I installed the package and tried it out. Everything works > so, I deinstalled the package, removed all files from the build and > thought, I try it again to reproduce it. At the second try I hat no > luck at make fetch and get the message *Size does not match for > mcabber-1.0.1.tar.bz2*. > > [...] > > Is there another way to get the size of the file or better, what I > have done wrong, that it worked at the first try but not at the second > ? Did you try: make distclean make makesum
Re: update: databases/pgbadger 3.5 to 7.3
Abel Abraham Camarillo Ojeda wrote: > On Mon, Feb 8, 2016 at 9:59 PM, Abel Abraham Camarillo Ojeda > wrote: > > hi > > > > attached patch updates pgbadger, > > also I'd like to take maintainership if no one > > cares. > > I'm unsure about the PLIST change, tough... > > > > comments, ok? > > > > thanks. > > anyone? > > thanks We're in release mode as of a few days ago, so I don't think this will be committed until the release is cut and the tree is unlocked. Thanks for the contribution! Feel free to poke me if no one gets back to you after unlock. Michael
Re: [update] math/coq to 8.5
Yozo TODA wrote: > I didn't try Compcert and not sure if Compcert is compliant to coq > 8.5, how about branching math/coq to math/coq/8.4 and math/coq/8.5 ? IIUC, this is only done when absolutely necessary. We'll probably just wait for Daniel's ok and then update to 8.5.
Re: NEW: htop 2.0.0
Pedro de Oliveira wrote: > Hi, > > Attached is a new port for sysutils/htop.The new 2.0.0 release now > supports OpenBSD. > It's my first port, so be easy! > > Any comments? OK to import? > > Regards, > Pedro de Oliveira Hi, Pedro. I wrote the OpenBSD-specific htop code. I was planning on making a proper port ASAP; thanks for beating me to it! :-) I'll try to review it this weekend. It's too late to get it into 5.9, sadly. This gives us more time to improve the OS-specific code, though. If you want to help with that, you could review and test this patch by juanfra@: https://github.com/hishamhm/htop/pull/376 Thanks again, Michael
www/awl size mismatch
Below is a failed fetch log for www/awl. Is this a known issue? Or is it just me? It's been failing because of this for the 3-4 weeks that I've been running bulk builds. >>> From www/awl ===> Trying https://gitlab.com/davical-project/awl/repository/ /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v https://gitlab.com/davical-project/awl/repository/archive.tar.gz?ref=r0.55 Trying 104.210.2.228... Requesting https://gitlab.com/davical-project/awl/repository/archive.tar.gz?ref=r0.55 766017 bytes received in 4.26 seconds (175.68 KB/s) size does not match ===> Trying http://ftp.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 Trying 129.128.5.191... Requesting http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 ftp: Error retrieving file: 404 Not Found ===> Trying ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 Connected to plier.ucar.edu. 220 plier.ucar.edu FTP server ready. 331 Guest login ok, send your email address as password. 230- Welcome to ftp.usa.OpenBSD.org in Boulder, Colorado, USA. 230- For other mirror sites visit http://www.openbsd.org/ftp.html 230-_ _ _ 230- / ___ \ | _ \ / | __ \ 230- / / / /___ ___ | |_) | (___ | | | | 230- / / / / __ \/ _ \/ __ \| _ < \___ \| | | | 230-/ /__/ / /_/ / __/ / / /| |_) |) | |__| | 230-\_/ .___/\___/_/ /_/ |/|_/|_/ 230- /_/ 230-|.The proactively secure Unix-like 230-. |L /| .Operating System. 230-_ . |\ _| \--+._/| . Please visit the OpenBSD web site 230- / ||\| Y J ) / |/| ./ at http://www.openbsd.org/ 230- J |)'( |` F`.'/ 230--<| F __ .-< All transfers are logged, if you don't 230- | / .-'. `. /-. L___ like this policy, disconnect now! 230- J \ <\ | | O\|.-' 230-_J \ .-\/ O | | \ |F 230- '-F -<_. \ .-' `-' L__ OpenBSD 5.8 has now been released! 230- __J _ _. >-' )._. |-' You can order a CD of OpenBSD 5.8 230- `-|.' /_. \_| F from http://www.openbsd.org/orders.html. 230-/.- ._.Trying http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 Trying 145.238.209.46... Requesting http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 ftp: Error retrieving file: 404 Not Found >>> From www/awl ===> Trying https://gitlab.com/davical-project/awl/repository/ /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v https://gitlab.com/davical-project/awl/repository/archive.tar.gz?ref=r0.55 Trying 104.210.2.228... Requesting https://gitlab.com/davical-project/awl/repository/archive.tar.gz?ref=r0.55 766017 bytes received in 1.38 seconds (541.09 KB/s) size does not match ===> Trying http://ftp.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 Trying 129.128.5.191... Requesting http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 ftp: Error retrieving file: 404 Not Found ===> Trying ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/awl-0.55.tar.gz.part -v ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r0.55 Connected to plier.ucar.edu. 220 plier.ucar.edu FTP server ready. 331 Guest login ok, send your email address as password. 230- Welcome to ftp.usa.OpenBSD.org in Boulder, Colorado, USA. 230- For other mirror sites visit http://www.openbsd.org/ftp.html 230-_ _ _ 230- / ___ \ | _ \ / | __ \ 230- / / / /___ ___ | |_) | (___ | | | | 230- / / / / __ \/ _ \/ __ \| _ <
Re: lang/gcc on macppc
Have you guys had issues with wd(4) timeouts on macppc? It was happening intermittently, but I figured it was because the drive was old. However, I'm now experiencing it again with a brand new hard drive and it's making the machine unusable.
Re: lang/gcc on macppc
Michael McConville wrote: > Have you guys had issues with wd(4) timeouts on macppc? It was > happening intermittently, but I figured it was because the drive was > old. However, I'm now experiencing it again with a brand new hard > drive and it's making the machine unusable. To clarify: this could be because of a worn out motherboard. I think this machine was heavily used back in the day.
devel/coccinelle failing
IIUC, we use a bundled version of Menhir in Coccinelle. It exists as the tarball bundles/menhirLib/menhir-20120123.tar.gz in the Coccinelle codebase. Here's the relevant Makefile line: > CONFIGURE_ARGS += --disable-menhirLib # version in ports is too new However, the build fails for me because it can't find the module MenhirLib.IncrementalEngine. This seems related, but I'm not sure. It's been failing for me for weeks; maybe the fact that no one else has reported it means that it's something anomalous on my machine. Has anyone else run into this? I have the Menhir package installed - maybe that's what triggers it. >>> Building on localhost under devel/coccinelle BDEPENDS = [lang/ocaml-camlp4;devel/gmake;devel/ocaml-pcre;devel/ocaml-parmap;textproc/latexmk;textproc/gdiff;sysutils/ggrep;lang/ocaml;sysutils/findlib;textproc/hevea;lang/python/2.7;print/texlive/texmf,-full;print/texlive/base] DIST = [devel/coccinelle:coccinelle-1.0.4.tgz] FULLPKGNAME = coccinelle-1.0.4 RDEPENDS = [devel/ocaml-parmap;devel/ocaml-pcre;lang/python/2.7;lang/ocaml;sysutils/findlib;textproc/gdiff;sysutils/ggrep] (Junk lock obtained for localhost at 1453032007) >>> Running depends in devel/coccinelle at 1453032007 last junk was in devel/sdl-sound /usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 ocaml-pcre-7.1.5 texlive_base-2014p1 texlive_texmf-full-2014p0 was: /usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 gmake-4.1p0 hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 ocaml-pcre-7.1.5 python-2.7.11 texlive_base-2014p1 texlive_texmf-full-2014p0 /usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 ocaml-pcre-7.1.5 texlive_base-2014p1 texlive_texmf-full-2014p0 --- +hevea-2.23 --- The imagen script needs LaTeX, dvips, ghostscript and tools from netpbm. Thus, Hevea does not require texlive, ghostscript, nor netpbm, but its full functionality can only be achieved if you install those packages. >>> Running show-prepare-results in devel/coccinelle at 1453032016 ===> devel/coccinelle ===> coccinelle-1.0.4 depends on: ocaml-parmap-* -> ocaml-parmap-1.0rc7 ===> coccinelle-1.0.4 depends on: ocaml-pcre-* -> ocaml-pcre-7.1.5 ===> coccinelle-1.0.4 depends on: findlib-* -> findlib-1.5.5 ===> coccinelle-1.0.4 depends on: ggrep-* -> ggrep-2.22 ===> coccinelle-1.0.4 depends on: gdiff-* -> gdiff-3.3p0 ===> coccinelle-1.0.4 depends on: ocaml-=4.02.3 -> ocaml-4.02.3 ===> coccinelle-1.0.4 depends on: python->=2.7,<2.8 -> python-2.7.11 ===> coccinelle-1.0.4 depends on: ocaml-camlp4-=4.02+6 -> ocaml-camlp4-4.02+6 ===> coccinelle-1.0.4 depends on: texlive_base-* -> texlive_base-2014p1 ===> coccinelle-1.0.4 depends on: texlive_texmf-full-* -> texlive_texmf-full-2014p0 ===> coccinelle-1.0.4 depends on: hevea-* -> hevea-2.23 ===> coccinelle-1.0.4 depends on: latexmk-* -> latexmk-443ap0 ===> coccinelle-1.0.4 depends on: gmake-* -> gmake-4.1p0 ===> Verifying specs: c curses m pthread util pcre python2.7 ===> found c.84.2 curses.14.0 m.9.0 pthread.20.1 util.12.1 pcre.3.0 python2.7.0.0 findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 gmake-4.1p0 hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 ocaml-pcre-7.1.5 python-2.7.11 texlive_base-2014p1 texlive_texmf-full-2014p0 Still tainted: 1 >>> Running junk in devel/coccinelle at 1453032019 Can't run junk because of lock on x11/qt5 (Junk lock released for localhost at 1453032019) distfiles size=2484218 >>> Running patch in devel/coccinelle at 1453032019 ===> devel/coccinelle ===> Checking files for coccinelle-1.0.4 `/mnt/big/ports/distfiles/coccinelle-1.0.4.tgz' is up to date. ===> Extracting for coccinelle-1.0.4 ===> Patching for coccinelle-1.0.4 >>> Running configure in devel/coccinelle at 1453032020 ===> devel/coccinelle ===> Configuring for coccinelle-1.0.4 Using /home/dpb-wrk/coccinelle-1.0.4/config.site (generated) perl -pi -e s,/usr/local,/usr/local,g /home/dpb-wrk/coccinelle-1.0.4/coccinelle-1.0.4/scripts/spatch* configure: WARNING: unrecognized options: --disable-gtk-doc configure: loading site script /home/dpb-wrk/coccinelle-1.0.4/config.site configure: configuring coccinelle 1.0.4 in /home/dpb-wrk/coccinelle-1.0.4/coccinelle-1.0.4 checking for a BSD-compatible install... /home/dpb-wrk/coccinelle-1.0.4/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... mkdir -p checking for gawk... (cached) awk checking whether gmake sets $(MAKE)... yes checking whether gmake supports nested variables... yes configure: determining version suffix checking for date... /bin/date configure: version suffix set to Sun, 17 Jan 2016 07:00:21 -0500 configure: this configure program uses pkg-config m4 macros co
Re: NEW: htop 2.0.0
Juan Francisco Cantero Hurtado wrote: > I've seeing a bunch of double-free and use-after-free in htop. Please, > run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code > yourself in the upstream github repo if you can. Hm. I've been running it with a brutal malloc.conf for more than a day with no issues. How immediately and regularly are you seeing these errors? Are you running something process-intensive like dpb on the machine? We fixed a few memleaks recently. Maybe this is related.
Re: NEW: htop 2.0.0
Juan Francisco Cantero Hurtado wrote: > On Tue, Feb 16, 2016 at 06:04:29PM -0500, Michael McConville wrote: > > Juan Francisco Cantero Hurtado wrote: > > > I've seeing a bunch of double-free and use-after-free in htop. > > > Please, run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix > > > the code yourself in the upstream github repo if you can. > > > > Hm. I've been running it with a brutal malloc.conf for more than a > > day with no issues. How immediately and regularly are you seeing > > these errors? Are you running something process-intensive like dpb > > on the machine? > > Yes. Sometimes I just see the crash when I change some option. > Unfortunately, I only saved the coredump from the crash which I > reported. I see. I take a pretty tedu approach to htop - the only command I use is 'q'. This may change at some point, but I can't be trusted to maintain the less common features. I pulled the stub code from the FreeBSD port, but in at least one case it's been insufficient and led to a null pointer deref. > > We fixed a few memleaks recently. Maybe this is related. > > Maybe. If you look the port which I sent to Pedro, I disabled the > stripping of symbols, so we could import the port after of the cvs > lock and to get better reports from the users. We can't test every > corner case in htop. > > IMHO, the port is good enough as-is now. Yeah, I wasn't too upset that it missed the 5.9 lock for this reason. Six months of -current testing will be useful.
mail/imapfilter update
The only change in this release is the addition of our SSLv3 patch.
ok?
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile22 Jan 2016 00:51:24 - 1.21
+++ Makefile25 Feb 2016 01:49:19 -
@@ -2,7 +2,7 @@
COMMENT= remote IMAP filtering utility
-V= 2.6.5
+V= 2.6.6
DISTNAME= imapfilter-${V}
GH_TAGNAME=v${V}
Index: distinfo
===
RCS file: /cvs/ports/mail/imapfilter/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo22 Jan 2016 00:51:24 - 1.12
+++ distinfo25 Feb 2016 01:49:19 -
@@ -1,2 +1,2 @@
-SHA256 (imapfilter-2.6.5.tar.gz) = D0tJ4b516/1eOjvb/wHWiqr9t6zdw1/EDc9DcClwgFU=
-SIZE (imapfilter-2.6.5.tar.gz) = 56993
+SHA256 (imapfilter-2.6.6.tar.gz) = Pukh2cojx5QpH6mBUCjgLBngVJ4fje0RM6DuF0emIw4=
+SIZE (imapfilter-2.6.6.tar.gz) = 57086
Index: patches/patch-src_socket_c
===
RCS file: patches/patch-src_socket_c
diff -N patches/patch-src_socket_c
--- patches/patch-src_socket_c 4 Nov 2015 17:51:18 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,32 +0,0 @@
-$OpenBSD: patch-src_socket_c,v 1.1 2015/11/04 17:51:18 jca Exp $
-
-Cope with SSLv3 removal.
-
src/socket.c.orig Wed Sep 30 22:55:26 2015
-+++ src/socket.c Mon Nov 2 22:47:35 2015
-@@ -16,8 +16,10 @@
- #include "imapfilter.h"
- #include "session.h"
-
--
--SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx;
-+SSL_CTX *ssl23ctx, *tls1ctx;
-+#ifndef OPENSSL_NO_SSL3_METHOD
-+SSL_CTX *ssl3ctx;
-+#endif
- #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
- SSL_CTX *tls11ctx, *tls12ctx;
- #endif
-@@ -95,7 +97,12 @@ open_secure_connection(session *ssn)
- if (!ssn->sslproto) {
- ctx = ssl23ctx;
- } else if (!strcasecmp(ssn->sslproto, "ssl3")) {
-+#ifndef OPENSSL_NO_SSL3_METHOD
- ctx = ssl3ctx;
-+#else
-+ error("protocol SSLv3 not supported\n");
-+ goto fail;
-+#endif
- } else if (!strcasecmp(ssn->sslproto, "tls1")) {
- ctx = tls1ctx;
- } else if (!strcasecmp(ssn->sslproto, "tls1.1")) {
Re: mail/imapfilter update
Michael McConville wrote:
> The only change in this release is the addition of our SSLv3 patch.
>
> ok?
jturner@ pointed out that this has to wait two weeks because it removes
a file, but ok'd otherwise.
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/imapfilter/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- Makefile 22 Jan 2016 00:51:24 - 1.21
> +++ Makefile 25 Feb 2016 01:49:19 -
> @@ -2,7 +2,7 @@
>
> COMMENT= remote IMAP filtering utility
>
> -V= 2.6.5
> +V= 2.6.6
> DISTNAME=imapfilter-${V}
>
> GH_TAGNAME= v${V}
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/imapfilter/distinfo,v
> retrieving revision 1.12
> diff -u -p -r1.12 distinfo
> --- distinfo 22 Jan 2016 00:51:24 - 1.12
> +++ distinfo 25 Feb 2016 01:49:19 -
> @@ -1,2 +1,2 @@
> -SHA256 (imapfilter-2.6.5.tar.gz) =
> D0tJ4b516/1eOjvb/wHWiqr9t6zdw1/EDc9DcClwgFU=
> -SIZE (imapfilter-2.6.5.tar.gz) = 56993
> +SHA256 (imapfilter-2.6.6.tar.gz) =
> Pukh2cojx5QpH6mBUCjgLBngVJ4fje0RM6DuF0emIw4=
> +SIZE (imapfilter-2.6.6.tar.gz) = 57086
> Index: patches/patch-src_socket_c
> ===
> RCS file: patches/patch-src_socket_c
> diff -N patches/patch-src_socket_c
> --- patches/patch-src_socket_c4 Nov 2015 17:51:18 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,32 +0,0 @@
> -$OpenBSD: patch-src_socket_c,v 1.1 2015/11/04 17:51:18 jca Exp $
> -
> -Cope with SSLv3 removal.
> -
> src/socket.c.origWed Sep 30 22:55:26 2015
> -+++ src/socket.c Mon Nov 2 22:47:35 2015
> -@@ -16,8 +16,10 @@
> - #include "imapfilter.h"
> - #include "session.h"
> -
> --
> --SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx;
> -+SSL_CTX *ssl23ctx, *tls1ctx;
> -+#ifndef OPENSSL_NO_SSL3_METHOD
> -+SSL_CTX *ssl3ctx;
> -+#endif
> - #if OPENSSL_VERSION_NUMBER >= 0x01000100fL
> - SSL_CTX *tls11ctx, *tls12ctx;
> - #endif
> -@@ -95,7 +97,12 @@ open_secure_connection(session *ssn)
> - if (!ssn->sslproto) {
> - ctx = ssl23ctx;
> - } else if (!strcasecmp(ssn->sslproto, "ssl3")) {
> -+#ifndef OPENSSL_NO_SSL3_METHOD
> - ctx = ssl3ctx;
> -+#else
> -+error("protocol SSLv3 not supported\n");
> -+goto fail;
> -+#endif
> - } else if (!strcasecmp(ssn->sslproto, "tls1")) {
> - ctx = tls1ctx;
> - } else if (!strcasecmp(ssn->sslproto, "tls1.1")) {
>
remove mail/faces?
This port seems truly ancient - if I understand correctly, it's been on version 1.6.1 since it was imported in 1997. The fact that it's a server makes this less tolerable. I came across it while scanning distfiles for undefined behavior... And it has a patch that changes gets(3) to fgets(3). What's more, I *guessed* correctly that it had a patch replacing gets(3) just based on its datedness. Any remaining users?
Re: remove mail/faces?
Matthias Kilian wrote: > On Sat, Feb 27, 2016 at 02:04:37AM -0500, Michael McConville wrote: > > This port seems truly ancient - if I understand correctly, it's been on > > version 1.6.1 since it was imported in 1997. The fact that it's a server > > makes this less tolerable. I came across it while scanning distfiles for > > undefined behavior... And it has a patch that changes gets(3) to > > fgets(3). What's more, I *guessed* correctly that it had a patch > > replacing gets(3) just based on its datedness. > > > > Any remaining users? > > I bet the number of people committing to this port (to catch up > with infrastructure and wantlib changes) is magnitudes larger than > the number of people who installed or even used it ;-) > > So: yes, please kill it. Thanks! Also, as semarie mentioned off-list: this won't happen until after the semi-lock, as it removes files.
Remove needless HOMEPAGE defs for GitHub projects
It's implicit when GH_ACCOUNT and GH_PROJECT are set.
ok?
Index: devel/ocaml-ppx-tools/Makefile
===
RCS file: /cvs/ports/devel/ocaml-ppx-tools/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- devel/ocaml-ppx-tools/Makefile 29 Dec 2015 19:49:40 - 1.2
+++ devel/ocaml-ppx-tools/Makefile 27 Feb 2016 07:53:01 -
@@ -4,12 +4,11 @@ COMMENT = tools for authors of OCaml ppx
CATEGORIES = devel
V =0.99.2
+REVISION = 0
GH_ACCOUNT = alainfrisch
GH_PROJECT = ppx_tools
GH_TAGNAME = ppx_tools_${V}
PKGNAME = ocaml-ppx-tools-${V}
-
-HOMEPAGE = https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
ALL_TARGET =byte
.include
Index: devel/ocaml-re/Makefile
===
RCS file: /cvs/ports/devel/ocaml-re/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- devel/ocaml-re/Makefile 30 Aug 2015 16:03:42 - 1.2
+++ devel/ocaml-re/Makefile 27 Feb 2016 07:53:01 -
@@ -4,12 +4,11 @@ COMMENT = regular expression library for
CATEGORIES = devel
V =1.4.1
+REVISION = 0
GH_ACCOUNT = ocaml
GH_PROJECT = ocaml-re
GH_TAGNAME = ${GH_PROJECT}-${V}
DISTNAME = ${GH_PROJECT}-${V}
-
-HOMEPAGE = https://github.com/${GH_ACCOUNT}/${GH_PROJECT}/
# LGPLv2.1+
PERMIT_PACKAGE_CDROM = Yes
Index: mail/mailest/Makefile
===
RCS file: /cvs/ports/mail/mailest/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- mail/mailest/Makefile 23 Jun 2015 07:21:08 - 1.3
+++ mail/mailest/Makefile 27 Feb 2016 07:53:14 -
@@ -3,14 +3,13 @@
COMMENT = search backend for Mew with Hyper Estrairer
V =0.9.20
+REVISION = 0
GH_ACCOUNT = yasuoka
GH_PROJECT = mailest
GH_TAGNAME = mailest-${V}
DISTNAME = ${GH_PROJECT}-${V}
CATEGORIES = mail
-
-HOMEPAGE = https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
MAINTAINER = YASUOKA Masahiko
Index: net/rabbitmq-c/Makefile
===
RCS file: /cvs/ports/net/rabbitmq-c/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- net/rabbitmq-c/Makefile 29 Nov 2015 14:39:53 - 1.2
+++ net/rabbitmq-c/Makefile 27 Feb 2016 07:53:23 -
@@ -3,6 +3,7 @@
COMMENT= rabbitmq C library and commandline AMQP utilities
V= 0.7.1
+REVISION= 0
GH_ACCOUNT=alanxz
GH_PROJECT=rabbitmq-c
GH_TAGNAME=v${V}
@@ -11,8 +12,6 @@ DISTNAME= ${GH_PROJECT}-${V}
SHARED_LIBS = rabbitmq 0.0 # 4.1
CATEGORIES=net
-
-HOMEPAGE= https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
MAINTAINER=Gregor Best
Index: sysutils/iwatch/Makefile
===
RCS file: /cvs/ports/sysutils/iwatch/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- sysutils/iwatch/Makefile12 Jan 2016 13:15:20 - 1.3
+++ sysutils/iwatch/Makefile27 Feb 2016 07:53:29 -
@@ -3,6 +3,7 @@
COMMENT = watch the command output with interval timer
V =1.0.3
+REVISION = 0
GH_ACCOUNT = iij
GH_PROJECT = iwatch
GH_TAGNAME = v${V}
@@ -10,8 +11,6 @@ DISTNAME =${GH_PROJECT}-${V}
REVISION = 0
CATEGORIES = sysutils
-
-HOMEPAGE = https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
MAINTAINER = YASUOKA Masahiko
devel/cil moved to GitHub
Does this look good? The distfile's slightly different - otherwise, this
is straight-forward.
Our port's pretty out of date, too. If anyone's interested in updating
it, let me know. Otherwise, I may try in the next couple weeks.
Index: Makefile
===
RCS file: /cvs/ports/devel/cil/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile7 Sep 2014 16:14:43 - 1.32
+++ Makefile29 Feb 2016 17:50:29 -
@@ -8,11 +8,10 @@ COMMENT= framework for analysis and tran
CATEGORIES = devel lang
DISTNAME = cil-1.5.1
-REVISION = 5
-EXTRACT_SUFX = .tar.gz
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=cil/}
+REVISION = 6
-HOMEPAGE= http://kerneis.github.com/cil/
+GH_ACCOUNT = cil-project
+GH_PROJECT = cil
# BSD license
PERMIT_PACKAGE_CDROM= Yes
@@ -21,6 +20,8 @@ WANTLIB= c curses m pthread
MODULES = lang/ocaml
BUILD_DEPENDS= sysutils/findlib
+
+WRKDIST = ${WRKDIR}/cil-${DISTNAME}
CONFIGURE_STYLE = autoconf no-autoheader
AUTOCONF_VERSION = 2.69
Index: distinfo
===
RCS file: /cvs/ports/devel/cil/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo18 Aug 2012 22:00:56 - 1.8
+++ distinfo29 Feb 2016 17:50:29 -
@@ -1,2 +1,2 @@
-SHA256 (cil-1.5.1.tar.gz) = 4hcrQFO/gGTsXqfe6/Fp0rlE9YimTBGf4xC0i1fizXs=
-SIZE (cil-1.5.1.tar.gz) = 1792712
+SHA256 (cil-1.5.1.tar.gz) = jeaCp61ur/lSHobaIbKsVRf8vnwD56Ok+9/HKdegybo=
+SIZE (cil-1.5.1.tar.gz) = 1792797
delete net/nicotine?
It seems unmaintained, it hasn't been updated since 2005, and the website is gone. I don't know if this is considered acceptable for a network client. There was Nicotine+: http://www.nicotine-plus.org/ But that seems dead too.
fix x11/grantlee's HOMEPAGE
ok?
It's also due for an update, if anyone uses it and has time.
Index: Makefile
===
RCS file: /cvs/ports/x11/grantlee/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile15 Aug 2015 22:30:57 - 1.5
+++ Makefile29 Feb 2016 21:23:10 -
@@ -3,10 +3,11 @@
SHARED_ONLY = Yes
COMMENT = template and text document library for Qt4
PKG_VERSION = 0.5.1
+REVISION = 0
PLIST_VERSION =${PKG_VERSION:R}
DISTNAME = grantlee-${PKG_VERSION}
CATEGORIES = devel x11
-HOMEPAGE = http://www.gitorious.org/grantlee/
+HOMEPAGE = https://github.com/steveire/grantlee
MAINTAINER = KDE porting team
PORTROACH =limit:^[0-4].*
Remove a couple mail/faces flavors
It's probably easiest to do this before we remove mail/faces and
mail/xfaces.
ok?
Index: claws-mail/Makefile
===
RCS file: /cvs/ports/mail/claws-mail/Makefile,v
retrieving revision 1.86
diff -u -p -r1.86 Makefile
--- claws-mail/Makefile 19 Jan 2016 18:19:22 - 1.86
+++ claws-mail/Makefile 1 Mar 2016 05:14:21 -
@@ -11,6 +11,7 @@ COMMENT-pdfviewer=pdfviewer plugin
COMMENT-gdata= gdata plugin
V= 3.13.2
+REVISION= 0
DISTNAME= claws-mail-${V}
PKGNAME-main= ${DISTNAME}
PKGNAME-bogofilter=claws-mail-bogofilter-${V}
@@ -32,7 +33,7 @@ MASTER_SITES= http://www.claws-mail.org
DIST_SUBDIR= claws
MULTI_PACKAGES=-main -bogofilter -spamassassin -htmlviewer
-pdfviewer -gdata
-FLAVORS= jpilot compface ldap
+FLAVORS= jpilot ldap
FLAVOR?=
FLAVOR_STRING= ${FLAVOR_EXT:S/-/,/g}
@@ -110,6 +111,7 @@ LIB_DEPENDS-gdata= ${LIB_DEPENDS} \
CONFIGURE_ARGS+= --disable-acpi_notifier-plugin \
--disable-geolocation-plugin \
--disable-python-plugin \
+ --disable-compface \
--enable-new-addrbook
@@ -128,15 +130,6 @@ WANTLIB-main +=pisock
RUN_DEPENDS-main+= comms/jpilot
.else
CONFIGURE_ARGS+= --disable-jpilot
-.endif
-
-.if ${FLAVOR:Mcompface}
-PERMIT_PACKAGE_CDROM= No Fee
-PERMIT_PACKAGE_FTP=Yes
-LIB_DEPENDS-main+= mail/faces
-WANTLIB-main +=compface>=1
-.else
-CONFIGURE_ARGS+= --disable-compface
.endif
.if ${FLAVOR:Mldap}
Index: claws-mail/pkg/PLIST-bogofilter
===
RCS file: /cvs/ports/mail/claws-mail/pkg/PLIST-bogofilter,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST-bogofilter
--- claws-mail/pkg/PLIST-bogofilter 9 Oct 2012 16:41:29 - 1.5
+++ claws-mail/pkg/PLIST-bogofilter 1 Mar 2016 05:14:21 -
@@ -1,4 +1,4 @@
@comment $OpenBSD: PLIST-bogofilter,v 1.5 2012/10/09 16:41:29 sthen Exp $
-@pkgpath mail/sylpheed-claws,-bogofilter[,compface][,pgpmime][,jpilot][,ldap]
+@pkgpath mail/sylpheed-claws,-bogofilter[,pgpmime][,jpilot][,ldap]
lib/claws-mail/plugins/bogofilter.la
lib/claws-mail/plugins/bogofilter.so
Index: claws-mail/pkg/PLIST-main
===
RCS file: /cvs/ports/mail/claws-mail/pkg/PLIST-main,v
retrieving revision 1.33
diff -u -p -r1.33 PLIST-main
--- claws-mail/pkg/PLIST-main 23 Dec 2015 23:12:23 - 1.33
+++ claws-mail/pkg/PLIST-main 1 Mar 2016 05:14:21 -
@@ -7,8 +7,8 @@
@pkgpath mail/claws-mail-notification
@pkgpath mail/claws-mail-rssyl
@pkgpath mail/claws-mail-vcalendar
-@pkgpath mail/sylpheed-claws,-main[,compface][,pgpmime][,jpilot][,ldap]
-@pkgpath mail/sylpheed-claws[,compface][,pgpmime][,jpilot][,ldap]
+@pkgpath mail/sylpheed-claws,-main[,pgpmime][,jpilot][,ldap]
+@pkgpath mail/sylpheed-claws[,pgpmime][,jpilot][,ldap]
@bin bin/claws-mail
@comment bin/sylpheed-claws
include/claws-mail/
Index: claws-mail/pkg/PLIST-spamassassin
===
RCS file: /cvs/ports/mail/claws-mail/pkg/PLIST-spamassassin,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST-spamassassin
--- claws-mail/pkg/PLIST-spamassassin 9 Oct 2012 16:41:29 - 1.5
+++ claws-mail/pkg/PLIST-spamassassin 1 Mar 2016 05:14:21 -
@@ -1,4 +1,4 @@
@comment $OpenBSD: PLIST-spamassassin,v 1.5 2012/10/09 16:41:29 sthen Exp $
-@pkgpath mail/sylpheed-claws,-spamassassin[,compface][,pgpmime][,jpilot][,ldap]
+@pkgpath mail/sylpheed-claws,-spamassassin[,pgpmime][,jpilot][,ldap]
lib/claws-mail/plugins/spamassassin.la
lib/claws-mail/plugins/spamassassin.so
Index: sylpheed/Makefile
===
RCS file: /cvs/ports/mail/sylpheed/Makefile,v
retrieving revision 1.106
diff -u -p -r1.106 Makefile
--- sylpheed/Makefile 4 Apr 2015 09:21:02 - 1.106
+++ sylpheed/Makefile 1 Mar 2016 05:14:22 -
@@ -3,7 +3,7 @@
COMMENT = lightweight and user-friendly e-mail client
DISTNAME = sylpheed-3.4.2
-REVISION = 1
+REVISION = 2
SHARED_LIBS += sylph-0 3.0 # 3.0
SHARED_LIBS += sylpheed-plugin-0 3.0 # 3.0
@@ -39,21 +39,9 @@ CONFIGURE_ARGS = ${CONFIGURE_SHARED} \
--disable-ldap \
--disable-oniguruma \
--enable-gpgme \
+ --disable-compface \
--disable-updatecheck
CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib -pthread"
-
-FLAVORS = compface
-FLAVOR ?=
-
-.if ${FLAVOR:Mcompface}
-LIB_DEPENDS +=
removing sysutils/toprump
Any objections? lum@, its author and maintainer, doesn't develop it anymore and thinks it should probably go.
change upstream for net/loudmouth
We last updated net/loudmouth in 2008. Upstream is gone, and the
following depend on it:
o net/mcabber
o net/irssi-xmpp
o net/freetalk
o lang/io (strangly)
I know that at least two of those are pretty common chat clients.
Because loudmouth is a network-exposed XMPP library, this is probably a
dangerous situation. The best solution is likely to switch to a
(somewhat) maintained fork from the mcabber people:
https://github.com/mcabber/loudmouth
Below is an initial patch for that. I haven't tested whether it works
with its dependencies yet - I thought I'd get a sanity check first.
A few things to note:
o I have to remove "include $(top_srcdir)/gtk-doc.make" from one of the
Makefile.am's or the build fails
o Their means of checking for strndup(3) support didn't work, so I just
removed their redefinition
o I don't entirely know what I'm doing with the autononsense, so there
may be an easier way of dealing with it
Index: Makefile
===
RCS file: /cvs/ports/net/loudmouth/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- Makefile21 Apr 2015 18:24:23 - 1.25
+++ Makefile3 Mar 2016 00:09:35 -
@@ -2,13 +2,16 @@
COMMENT= lightweight Jabber client library
-V= 1.4.3
-DISTNAME= loudmouth-$V
-REVISION= 6
+VERSION = 1.5.0
+DISTNAME = loudmouth-${VERSION}
+
SHARED_LIBS += loudmouth-1 3.0 # .1.0
CATEGORIES=net devel
-HOMEPAGE= http://groups.google.com/group/loudmouth-dev/
+GH_ACCOUNT = mcabber
+GH_PROJECT = loudmouth
+
+DISTFILES =${VERSION}${EXTRACT_SUFX}
# LGPLv2.1
PERMIT_PACKAGE_CDROM= Yes
@@ -17,18 +20,33 @@ WANTLIB += crypto glib-2.0 idn>=16 pcre
MODULES= devel/gettext
-MASTER_SITES=
${MASTER_SITE_GNOME:=sources/loudmouth/${V:C/^([0-9]+\.[0-9]+).*/\1/}/}
-EXTRACT_SUFX= .tar.bz2
-
LIB_DEPENDS= devel/glib2 \
devel/libidn
-BUILD_DEPENDS= ${TEST_DEPENDS}
-TEST_DEPENDS= devel/check
-CONFIGURE_STYLE= gnu
+BUILD_DEPENDS =${TEST_DEPENDS} \
+ ${MODGNU_AUTOCONF_DEPENDS} \
+ ${MODGNU_AUTOMAKE_DEPENDS} \
+ devel/libtool
+
+TEST_DEPENDS = devel/check
+
+CONFIGURE_STYLE = autoconf automake gnu
+AUTOCONF_VERSION = 2.69
+AUTOMAKE_VERSION = 1.15
+# with-compile-warnings=yes prevents it from using -Werror
CONFIGURE_ARGS+= ${CONFIGURE_SHARED} \
--disable-mono \
--with-check=${LOCALBASE} \
+ --with-compile-warnings=yes \
--with-ssl=openssl
+
+AUTO_ENV = AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \
+ AUTOCONF_VERSION=${AUTOCONF_VERSION}
+
+post-patch:
+ cd ${WRKSRC}; ${AUTO_ENV} aclocal
+
+pre-configure:
+ cd ${WRKSRC}; libtoolize && ${AUTO_ENV} automake --add-missing --foreign
.include
Index: distinfo
===
RCS file: /cvs/ports/net/loudmouth/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo18 Jan 2015 03:14:42 - 1.6
+++ distinfo3 Mar 2016 00:09:35 -
@@ -1,2 +1,2 @@
-SHA256 (loudmouth-1.4.3.tar.bz2) = lak/XQCbceqBk9mUqhHzEbwzCj7+G3zXTcSPEcf5KeM=
-SIZE (loudmouth-1.4.3.tar.bz2) = 366818
+SHA256 (1.5.0.tar.gz) = UUAxemOEUMl3pynexUW1lTjqSy5Rndcj07/aEsonhmU=
+SIZE (1.5.0.tar.gz) = 124001
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 18 Nov 2008 11:41:23 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,19 +0,0 @@
-$OpenBSD: patch-configure,v 1.3 2008/11/18 11:41:23 jasper Exp $
configure.orig Wed Oct 29 21:25:57 2008
-+++ configure Tue Nov 18 12:33:20 2008
-@@ -21423,6 +21423,7 @@ cat >>conftest.$ac_ext <<_ACEOF
-
- #include
- #include
-+#include
-
- #include
-
-@@ -21532,6 +21533,7 @@ cat >>conftest.$ac_ext <<_ACEOF
-
- #include
- #include
-+#include
-
- #include
-
Index: patches/patch-docs_reference_Makefile_am
===
RCS file: patches/patch-docs_reference_Makefile_am
diff -N patches/patch-docs_reference_Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-docs_reference_Makefile_am3 Mar 2016 00:09:35 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- docs/reference/Makefile.am.origWed Mar 2 14:22:02 2016
docs/reference/Makefile.am Wed Mar 2 14:22:25 2016
+@@ -80,9 +80,6 @@ GTKDOC_LIBS= \
+ $(top_builddir)/loudmouth/libloudmouth.la
+
+
+-# This includes the standard gtk-doc make rules, copied by gtkdoci
