Re: [NEW] net/libmaxminddb
On 06/26/16 21:53, Frederic Cambus wrote: > On Wed, Jun 22, 2016 at 08:11:39PM +0100, Stuart Henderson wrote: >>> >>> Issue fixed, thanks. New tarball attached if anyone wants to import. >> >> OK sthen@. > > Ping. Could anyone import this? Thanks! > I will take care of it soon. Giovanni
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil wrote: > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: >> Hi ports@, >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just >> today. I believe I have addressed all previous concerns: >> >> * Our extensions now live in /usr/local/lib/... and run directly from >> there, they are not unpacked under the user's profile (enabledScopes >> solved this); >> * addon PLIST files redone to just have the .xpi file; >> * No more hardcoded /usr/local paths >> * Only addons we actually have to patch are packaged by us; otherwise >> we just wrap around the distributed .xpi (noscript, https-everywhere) > > Great stuff, thanks for spending the time to do all this right ! > > Why are you overriding FETCH_CMD in noscript subdir ? That looks > wrong... That's because it fails without "-S dont": >> Fetch https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi ftp: SSL read error: handshake failed: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Probably it should be mirrored on a decent web server... Ciao! David
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote: > On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil wrote: > > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: > >> Hi ports@, > >> > >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just > >> today. I believe I have addressed all previous concerns: > >> > >> * Our extensions now live in /usr/local/lib/... and run directly from > >> there, they are not unpacked under the user's profile (enabledScopes > >> solved this); > >> * addon PLIST files redone to just have the .xpi file; > >> * No more hardcoded /usr/local paths > >> * Only addons we actually have to patch are packaged by us; otherwise > >> we just wrap around the distributed .xpi (noscript, https-everywhere) > > > > Great stuff, thanks for spending the time to do all this right ! > > > > Why are you overriding FETCH_CMD in noscript subdir ? That looks > > wrong... > > That's because it fails without "-S dont": > > >> Fetch > >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi > ftp: SSL read error: handshake failed: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > Probably it should be mirrored on a decent web server... How... ironic. I think it'd actually be better to fetch it from addons.mozilla.org, to stress that's the unmodified/official version. Or get upstream to fix their ssl cert... which seems to be Let's Encrypt powered, and is valid - opens in firefox.. so i dont get why ftp fails. Landry
[UPDATE] net/haproxy 1.6.6
Hi,
this is haproxy update, the two temporary patches are unnecessary now.
Kind regards.
Index: Makefile
===
RCS file: /cvs/ports/net/haproxy/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile15 Jun 2016 06:55:58 - 1.30
+++ Makefile27 Jun 2016 08:16:46 -
@@ -2,7 +2,7 @@
COMMENT = reliable, high performance TCP/HTTP load balancer
-DISTNAME = haproxy-1.6.5
+DISTNAME = haproxy-1.6.6
REVISION = 0
CATEGORIES = net www
HOMEPAGE = http://www.haproxy.org/
Index: distinfo
===
RCS file: /cvs/ports/net/haproxy/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo13 May 2016 03:34:28 - 1.17
+++ distinfo27 Jun 2016 08:16:46 -
@@ -1,2 +1,2 @@
-SHA256 (haproxy-1.6.5.tar.gz) = xLP7k4h0q7u9UngghxF8wlkCY694/c6G1k5KEaz+hd4=
-SIZE (haproxy-1.6.5.tar.gz) = 1563272
+SHA256 (haproxy-1.6.6.tar.gz) = /bA9YweMw8aIu205/HXcwVjWU1bkyOHEWQM+vt3/VfU=
+SIZE (haproxy-1.6.6.tar.gz) = 1565046
Index: patches/patch-include_types_proto_http_h
===
RCS file: patches/patch-include_types_proto_http_h
diff -N patches/patch-include_types_proto_http_h
--- patches/patch-include_types_proto_http_h15 Jun 2016 06:55:58 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-include_types_proto_http_h,v 1.1 2016/06/15 06:55:58 jasper
Exp $
-
-Security fix for CVE-2016-5360
-http://git.haproxy.org/?p=haproxy-1.6.git;a=commitdiff;h=60f01f8c89e4fb2723d5a9f2046286e699567e0b
-
include/types/proto_http.h.origTue May 10 15:42:00 2016
-+++ include/types/proto_http.h Tue Jun 14 15:10:23 2016
-@@ -362,7 +362,6 @@ struct http_txn {
- unsigned int flags; /* transaction flags */
- enum http_meth_t meth; /* HTTP method */
- /* 1 unused byte here */
-- short rule_deny_status; /* HTTP status from rule when denying */
- short status; /* HTTP status from the server,
negative if from proxy */
-
- char *uri; /* first line if log needed, NULL
otherwise */
Index: patches/patch-src_proto_http_c
===
RCS file: patches/patch-src_proto_http_c
diff -N patches/patch-src_proto_http_c
--- patches/patch-src_proto_http_c 15 Jun 2016 06:55:58 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,77 +0,0 @@
-$OpenBSD: patch-src_proto_http_c,v 1.3 2016/06/15 06:55:58 jasper Exp $
-
-Security fix for CVE-2016-5360
-http://git.haproxy.org/?p=haproxy-1.6.git;a=commitdiff;h=60f01f8c89e4fb2723d5a9f2046286e699567e0b
-
src/proto_http.c.orig Tue May 10 15:42:00 2016
-+++ src/proto_http.c Tue Jun 14 15:10:23 2016
-@@ -3490,10 +3490,12 @@ static int http_transform_header(struct stream* s, str
- * further processing of the request (auth, deny, ...), and defaults to
- * HTTP_RULE_RES_STOP if it executed all rules or stopped on an allow, or
- * HTTP_RULE_RES_CONT if the last rule was reached. It may set the TX_CLTARPIT
-- * on txn->flags if it encounters a tarpit rule.
-+ * on txn->flags if it encounters a tarpit rule. If is not NULL
-+ * and a deny/tarpit rule is matched, it will be filled with this rule's deny
-+ * status.
- */
- enum rule_result
--http_req_get_intercept_rule(struct proxy *px, struct list *rules, struct
stream *s)
-+http_req_get_intercept_rule(struct proxy *px, struct list *rules, struct
stream *s, int *deny_status)
- {
- struct session *sess = strm_sess(s);
- struct http_txn *txn = s->txn;
-@@ -3539,12 +3541,14 @@ resume_execution:
- return HTTP_RULE_RES_STOP;
-
- case ACT_ACTION_DENY:
-- txn->rule_deny_status = rule->deny_status;
-+ if (deny_status)
-+ *deny_status = rule->deny_status;
- return HTTP_RULE_RES_DENY;
-
- case ACT_HTTP_REQ_TARPIT:
- txn->flags |= TX_CLTARPIT;
-- txn->rule_deny_status = rule->deny_status;
-+ if (deny_status)
-+ *deny_status = rule->deny_status;
- return HTTP_RULE_RES_DENY;
-
- case ACT_HTTP_REQ_AUTH:
-@@ -4303,6 +4307,7 @@ int http_process_req_common(struct stream *s, struct c
- struct redirect_rule *rule;
- struct cond_wordlist *wl;
- enum rule_result verdict;
-+ int deny_status = HTTP_ERR_403;
-
- if (unlikely(msg->msg_state < HTTP_MSG_BODY)) {
- /* we need more data */
-@@ -4323,7 +4328,7 @@ int http_process_req_common(struct stream *s, struct c
-
- /* evaluate http-request rules */
- if (!LIST_ISEMPTY(&px->http_req_rules)) {
-- verdict = http_r
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Mon, Jun 27, 2016 at 10:09 AM, Landry Breuil wrote: > On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote: >> On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil wrote: >> > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: >> >> Hi ports@, >> >> >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just >> >> today. I believe I have addressed all previous concerns: >> >> >> >> * Our extensions now live in /usr/local/lib/... and run directly from >> >> there, they are not unpacked under the user's profile (enabledScopes >> >> solved this); >> >> * addon PLIST files redone to just have the .xpi file; >> >> * No more hardcoded /usr/local paths >> >> * Only addons we actually have to patch are packaged by us; otherwise >> >> we just wrap around the distributed .xpi (noscript, https-everywhere) >> > >> > Great stuff, thanks for spending the time to do all this right ! >> > >> > Why are you overriding FETCH_CMD in noscript subdir ? That looks >> > wrong... >> >> That's because it fails without "-S dont": >> >> >> Fetch >> >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi >> ftp: SSL read error: handshake failed: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> >> Probably it should be mirrored on a decent web server... > > How... ironic. I think it'd actually be better to fetch it from > addons.mozilla.org, to stress that's the unmodified/official version. > Or get upstream to fix their ssl cert... which seems to be Let's Encrypt > powered, and is valid - opens in firefox.. so i dont get why ftp fails. > > Landry Reading from https://letsencrypt.org/certificates/, It seems something could be missing from /etc/ssl/cert.pem. Or is it the libressl cert chain problem again? Maybe Stuart can shed some light on this. Ciao! David
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On 2016/06/27 10:35, David Coppa wrote: > On Mon, Jun 27, 2016 at 10:09 AM, Landry Breuil wrote: > > On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote: > >> On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil > >> wrote: > >> > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: > >> >> Hi ports@, > >> >> > >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just > >> >> today. I believe I have addressed all previous concerns: > >> >> > >> >> * Our extensions now live in /usr/local/lib/... and run directly from > >> >> there, they are not unpacked under the user's profile (enabledScopes > >> >> solved this); > >> >> * addon PLIST files redone to just have the .xpi file; > >> >> * No more hardcoded /usr/local paths > >> >> * Only addons we actually have to patch are packaged by us; otherwise > >> >> we just wrap around the distributed .xpi (noscript, https-everywhere) > >> > > >> > Great stuff, thanks for spending the time to do all this right ! > >> > > >> > Why are you overriding FETCH_CMD in noscript subdir ? That looks > >> > wrong... > >> > >> That's because it fails without "-S dont": You can't do that, apart from anything else it won't work in bulks. > >> >> Fetch > >> >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi > >> ftp: SSL read error: handshake failed: error:14090086:SSL > >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > >> > >> Probably it should be mirrored on a decent web server... > > > > How... ironic. I think it'd actually be better to fetch it from > > addons.mozilla.org, to stress that's the unmodified/official version. > > Or get upstream to fix their ssl cert... which seems to be Let's Encrypt > > powered, and is valid - opens in firefox.. so i dont get why ftp fails. > > > > Landry > > Reading from https://letsencrypt.org/certificates/, It seems something > could be missing from /etc/ssl/cert.pem. --- Certificate chain 0 s:/CN=secure.informaction.com i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- They just don't know how to SSL - they aren't serving the chain certificate like they should. Quite funny because with Tor's uncontrolled exit nodes, you have to be *damn* sure that you are connecting to who you think you are. > Or is it the libressl cert chain problem again? It's not the libressl bug this time, just incompetent admins.
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: > Hi ports@, > > Here is another try at the Tor Browser Bundle, updated to 6.0.2 just > today. > [...] > > All feedback most welcome. > Hi, I would like to ask some questions. - www/tbb/tor-browser/files/tor-browser.cfg file where does the configuration comes from you ? is it settings from you or from TBB ? I ask due to default bridges configuration (addresses, fingerprints and certs), and to default plugins configuration. These configuration settings are very sensible. - www/tbb/tor-browser/patches/patch-toolkit_xre_nsAppRunner_cpp file "Revert the file back to ESR45.1.1, all diffs were TB-specific and not relevant to OpenBSD". Can you explain why ? The diff is quite large, and reverts elements like: - In Tor Browser, remoting is disabled by default unless -osint is used (so --no-remote isn't the default anymore with TBB). - Set the application-wide C-locale. Needed to resist fingerprinting of Date.toLocaleFormat(). - www/tbb/tor-browser/patches/patch-toolkit_xre_nsXREDirProvider_cpp file You revert TBB specific code for cache data dir: so the port will use $XDG_CACHE_HOME if defined, or use $HOME/.cache instead of keeping stuff in GetTorBrowserUserDataDir() Shouldn't all TBB stuff to be kept under one directory ? If I understood the purpose of patches in www/tbb/tor-browser (if I don't consider patches copied from www/firefox-esr or security/nss), it is to remove specific code in TBB to use ~/.tor-browser instead of the TBB default to TorBrowser/Data/Browser. But when doing that you also remove specific code (like anti-fingerprinting or keeping all data under one well-know directory). I wonder if it wouldn't be more safe (and facilitating porting on long-term) to try to not diverge to much from TBB upstream. - www/tbb/torbutton/patches/patch-src_defaults_preferences_preferences_js you change log settings to stdout with less level of verbose. if TBB is launched via desktop menu, there is no console to see the potential errors. and why less level of verbosity ? you disable version checking. shouldn't be still enable ? I understand to no try to update, but if a new version of TBB is available, having the information could be valuable: else you could put users at risk if they use an old version (with potentially know vulnerabilities) due to a no up-to-date port under OpenBSD. - www/tbb/tor-launcher/patches/patch-src_defaults_preferences_prefs_js same question than for torbutton about log level and log method (reducing the verbosity and change output to stdout). - www/tbb/tor-launcher/patches/patch-src_components_tl-process_js "Let geoip/geoip6 file paths be set by prefs like everything else. Go back to old way of munging relative paths, their new way is effectively a no-op for us anyway." Do you know why tor devs doesn't use prefs for these settings ? Why do you think diverging from upstream (and maintains the diff) would be good if their "new way" is a no-op under OpenBSD ? And after all these elements, I would like to say that I would be glad to see support of TBB in OpenBSD :) Thanks. -- Sebastien Marie
Re: [UPDATE] net/haproxy 1.6.6
On Mon, 27 Jun 2016 09:19:00 +0100, David CARLIER wrote: > Hi, > > this is haproxy update, the two temporary patches are unnecessary now. > > Kind regards. You forgot to remove the REVISION.
Re: [UPDATE] net/haproxy 1.6.6
true.
On 27 June 2016 at 10:11, Daniel Jakots wrote:
> On Mon, 27 Jun 2016 09:19:00 +0100, David CARLIER
> wrote:
>
> > Hi,
> >
> > this is haproxy update, the two temporary patches are unnecessary now.
> >
> > Kind regards.
>
> You forgot to remove the REVISION.
>
Index: Makefile
===
RCS file: /cvs/ports/net/haproxy/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile15 Jun 2016 06:55:58 - 1.30
+++ Makefile27 Jun 2016 09:21:45 -
@@ -2,8 +2,7 @@
COMMENT = reliable, high performance TCP/HTTP load balancer
-DISTNAME = haproxy-1.6.5
-REVISION = 0
+DISTNAME = haproxy-1.6.6
CATEGORIES = net www
HOMEPAGE = http://www.haproxy.org/
MAINTAINER = Daniel Jakots
Index: distinfo
===
RCS file: /cvs/ports/net/haproxy/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo13 May 2016 03:34:28 - 1.17
+++ distinfo27 Jun 2016 09:21:45 -
@@ -1,2 +1,2 @@
-SHA256 (haproxy-1.6.5.tar.gz) = xLP7k4h0q7u9UngghxF8wlkCY694/c6G1k5KEaz+hd4=
-SIZE (haproxy-1.6.5.tar.gz) = 1563272
+SHA256 (haproxy-1.6.6.tar.gz) = /bA9YweMw8aIu205/HXcwVjWU1bkyOHEWQM+vt3/VfU=
+SIZE (haproxy-1.6.6.tar.gz) = 1565046
Index: patches/patch-include_types_proto_http_h
===
RCS file: /cvs/ports/net/haproxy/patches/patch-include_types_proto_http_h,v
retrieving revision 1.1
diff -u -p -r1.1 patch-include_types_proto_http_h
--- patches/patch-include_types_proto_http_h15 Jun 2016 06:55:58 -
1.1
+++ patches/patch-include_types_proto_http_h27 Jun 2016 09:21:45 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-include_types_proto_http_h,v 1.1 2016/06/15 06:55:58 jasper
Exp $
-
-Security fix for CVE-2016-5360
-http://git.haproxy.org/?p=haproxy-1.6.git;a=commitdiff;h=60f01f8c89e4fb2723d5a9f2046286e699567e0b
-
include/types/proto_http.h.origTue May 10 15:42:00 2016
-+++ include/types/proto_http.h Tue Jun 14 15:10:23 2016
-@@ -362,7 +362,6 @@ struct http_txn {
- unsigned int flags; /* transaction flags */
- enum http_meth_t meth; /* HTTP method */
- /* 1 unused byte here */
-- short rule_deny_status; /* HTTP status from rule when denying */
- short status; /* HTTP status from the server,
negative if from proxy */
-
- char *uri; /* first line if log needed, NULL
otherwise */
Index: patches/patch-src_proto_http_c
===
RCS file: /cvs/ports/net/haproxy/patches/patch-src_proto_http_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-src_proto_http_c
--- patches/patch-src_proto_http_c 15 Jun 2016 06:55:58 - 1.3
+++ patches/patch-src_proto_http_c 27 Jun 2016 09:21:45 -
@@ -1,77 +0,0 @@
-$OpenBSD: patch-src_proto_http_c,v 1.3 2016/06/15 06:55:58 jasper Exp $
-
-Security fix for CVE-2016-5360
-http://git.haproxy.org/?p=haproxy-1.6.git;a=commitdiff;h=60f01f8c89e4fb2723d5a9f2046286e699567e0b
-
src/proto_http.c.orig Tue May 10 15:42:00 2016
-+++ src/proto_http.c Tue Jun 14 15:10:23 2016
-@@ -3490,10 +3490,12 @@ static int http_transform_header(struct stream* s, str
- * further processing of the request (auth, deny, ...), and defaults to
- * HTTP_RULE_RES_STOP if it executed all rules or stopped on an allow, or
- * HTTP_RULE_RES_CONT if the last rule was reached. It may set the TX_CLTARPIT
-- * on txn->flags if it encounters a tarpit rule.
-+ * on txn->flags if it encounters a tarpit rule. If is not NULL
-+ * and a deny/tarpit rule is matched, it will be filled with this rule's deny
-+ * status.
- */
- enum rule_result
--http_req_get_intercept_rule(struct proxy *px, struct list *rules, struct
stream *s)
-+http_req_get_intercept_rule(struct proxy *px, struct list *rules, struct
stream *s, int *deny_status)
- {
- struct session *sess = strm_sess(s);
- struct http_txn *txn = s->txn;
-@@ -3539,12 +3541,14 @@ resume_execution:
- return HTTP_RULE_RES_STOP;
-
- case ACT_ACTION_DENY:
-- txn->rule_deny_status = rule->deny_status;
-+ if (deny_status)
-+ *deny_status = rule->deny_status;
- return HTTP_RULE_RES_DENY;
-
- case ACT_HTTP_REQ_TARPIT:
- txn->flags |= TX_CLTARPIT;
-- txn->rule_deny_status = rule->deny_status;
-+ if (deny_status)
-+ *deny_status = rule->deny_status;
- return HTTP_RULE_RES_DENY;
-
- case ACT_HTTP_REQ_AUTH:
-@@ -4303,6 +4307,7 @@ int http_process_req_common(struct stream *s, struct c
- struct redirect_rule *rule;
- struct cond_wordlist *wl;
- en
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Mon, 27 Jun 2016, Landry Breuil wrote:
> On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote:
> > On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil
> > wrote:
> > > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote:
> > >> Hi ports@,
> > >>
> > >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just
> > >> today. I believe I have addressed all previous concerns:
> > >>
> > >> * Our extensions now live in /usr/local/lib/... and run directly from
> > >> there, they are not unpacked under the user's profile (enabledScopes
> > >> solved this);
> > >> * addon PLIST files redone to just have the .xpi file;
> > >> * No more hardcoded /usr/local paths
> > >> * Only addons we actually have to patch are packaged by us; otherwise
> > >> we just wrap around the distributed .xpi (noscript, https-everywhere)
> > >
> > > Great stuff, thanks for spending the time to do all this right !
> > >
> > > Why are you overriding FETCH_CMD in noscript subdir ? That looks
> > > wrong...
> >
> > That's because it fails without "-S dont":
> >
> > >> Fetch
> > >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi
> > ftp: SSL read error: handshake failed: error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> >
> > Probably it should be mirrored on a decent web server...
>
> How... ironic. I think it'd actually be better to fetch it from
> addons.mozilla.org, to stress that's the unmodified/official version.
Indeed. This works w/o problems:
--- www/tbb/noscript/Makefile.old Thu Jun 23 19:56:02 2016
+++ www/tbb/noscript/Makefile Mon Jun 27 11:20:03 2016
@@ -4,8 +4,7 @@
V =2.9.0.11
COMMENT = flexible JS blocker for firefox (Tor browser variant)
HOMEPAGE = http://noscript.net
-MASTER_SITES = https://secure.informaction.com/download/releases/
-FETCH_CMD ?= /usr/bin/ftp -V ${_PROGRESS} -k ${FTP_KEEPALIVE} -C -S
dont
+MASTER_SITES =
https://addons.mozilla.org/firefox/downloads/file/421899/
GUID = {73a6fe31-595d-460b-a920-fcc0f8843232}
DISTFILE_IS_XPI = Yes
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil wrote: > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: >> Hi ports@, >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just >> today. I believe I have addressed all previous concerns: >> >> * Our extensions now live in /usr/local/lib/... and run directly from >> there, they are not unpacked under the user's profile (enabledScopes >> solved this); >> * addon PLIST files redone to just have the .xpi file; >> * No more hardcoded /usr/local paths >> * Only addons we actually have to patch are packaged by us; otherwise >> we just wrap around the distributed .xpi (noscript, https-everywhere) > > Great stuff, thanks for spending the time to do all this right ! > > Why are you overriding FETCH_CMD in noscript subdir ? That looks > wrong... > > Other than that, until someone else that me *also* looks into your > submission, i wont spend time on this port, sorry. Apparently i'm the > only one somewhat caring about that, and getting no feedback/okays from > another developer means that will never get imported... I've built and installed tbb-6.0.2. The tor-browser works fine for me, but I've only "light-tested" it so far... What about importing it and then fixing the few remaining rough edges in tree? You have my ok to do so! Ciao, David
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
First of all, it's great to see this effort. But, we have seen diffs in ports tree which were irrelevant, eg. upstream solved the issues the diffs were trying to solve specifically for OpenBSD ports tree. semarie@ did a review for TBB and he raised some question about diverting from upstream. As TBB is anonymity oriented sw and can be considered by users as "safe to use", this raises a question - what is the trust between all changes in OpenBSD ports tree and upstream? What would be regular review mode? I have no answer to this question but I would be hesitant to see current situation as optimal, because a little mistake/oversight could have real impact on TBB users using it in some peculiar countries. I just wanted to show my cautiousness towards potential issues just existing in OpenBSD porting effort itself. j.
[UPDATE] Python 3.4.5 and 3.5.2
Hi, attached are the diff: - update from python 3.4.4 -> 3.4.5 - update from 3.5.1 -> 3.5.2 Ok? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/lang/python/3.4/Makefile,v retrieving revision 1.10 diff -u -p -u -p -r1.10 Makefile --- Makefile 11 May 2016 22:43:49 - 1.10 +++ Makefile 27 Jun 2016 14:36:31 - @@ -6,8 +6,7 @@ # Python itself. VERSION = 3.4 -PATCHLEVEL = .4 -REVISION = 1 +PATCHLEVEL = .5 SHARED_LIBS = python3.4m 1.0 VERSION_SPEC = >=3.4,<3.5 Index: distinfo === RCS file: /cvs/ports/lang/python/3.4/distinfo,v retrieving revision 1.5 diff -u -p -u -p -r1.5 distinfo --- distinfo 23 Dec 2015 07:18:12 - 1.5 +++ distinfo 27 Jun 2016 14:36:31 - @@ -1,2 +1,2 @@ -SHA256 (Python-3.4.4.tgz) = vJPpRAJYFuw2BxK0xC2NX3KertKyZYXpvIhE+T8MOC4= -SIZE (Python-3.4.4.tgz) = 19435166 +SHA256 (Python-3.4.5.tgz) = mXrKTdhpLzyVRlij2xHB0IYry/jq3WoWR0brM9MXwDQ= +SIZE (Python-3.4.5.tgz) = 19611207 Index: pkg/PLIST-main === RCS file: /cvs/ports/lang/python/3.4/pkg/PLIST-main,v retrieving revision 1.7 diff -u -p -u -p -r1.7 PLIST-main --- pkg/PLIST-main 11 May 2016 22:43:49 - 1.7 +++ pkg/PLIST-main 27 Jun 2016 14:36:31 - @@ -1600,8 +1600,8 @@ lib/python3.4/ensurepip/__pycache__/__ma lib/python3.4/ensurepip/__pycache__/_uninstall.cpython-34.pyc lib/python3.4/ensurepip/__pycache__/_uninstall.cpython-34.pyo lib/python3.4/ensurepip/_bundled/ -lib/python3.4/ensurepip/_bundled/pip-7.1.2-py2.py3-none-any.whl -lib/python3.4/ensurepip/_bundled/setuptools-18.2-py2.py3-none-any.whl +lib/python3.4/ensurepip/_bundled/pip-8.1.1-py2.py3-none-any.whl +lib/python3.4/ensurepip/_bundled/setuptools-20.10.1-py2.py3-none-any.whl lib/python3.4/ensurepip/_uninstall.py lib/python3.4/enum.py lib/python3.4/filecmp.py @@ -1752,9 +1752,9 @@ lib/python3.4/lib-dynload/xxlimited.so lib/python3.4/lib-dynload/zlib.so lib/python3.4/lib2to3/ lib/python3.4/lib2to3/Grammar.txt -lib/python3.4/lib2to3/Grammar3.4.4.final.0.pickle +lib/python3.4/lib2to3/Grammar3.4.5.final.0.pickle lib/python3.4/lib2to3/PatternGrammar.txt -lib/python3.4/lib2to3/PatternGrammar3.4.4.final.0.pickle +lib/python3.4/lib2to3/PatternGrammar3.4.5.final.0.pickle lib/python3.4/lib2to3/__init__.py lib/python3.4/lib2to3/__main__.py lib/python3.4/lib2to3/__pycache__/ Index: pkg/PLIST-tests === RCS file: /cvs/ports/lang/python/3.4/pkg/PLIST-tests,v retrieving revision 1.6 diff -u -p -u -p -r1.6 PLIST-tests --- pkg/PLIST-tests 23 Dec 2015 07:18:12 - 1.6 +++ pkg/PLIST-tests 27 Jun 2016 14:36:32 - @@ -929,10 +929,12 @@ lib/python3.4/test/badsyntax_pep3120.py lib/python3.4/test/buffer_tests.py lib/python3.4/test/bytecode_helper.py lib/python3.4/test/capath/ +lib/python3.4/test/capath/0e4015b9.0 lib/python3.4/test/capath/4e1295a3.0 lib/python3.4/test/capath/5ed36f99.0 lib/python3.4/test/capath/6e88d7b8.0 lib/python3.4/test/capath/99d0fa06.0 +lib/python3.4/test/capath/ce7b8643.0 lib/python3.4/test/cfgparser.1 lib/python3.4/test/cfgparser.2 lib/python3.4/test/cfgparser.3 @@ -1143,7 +1145,6 @@ lib/python3.4/test/formatfloat_testcases lib/python3.4/test/future_test1.py lib/python3.4/test/future_test2.py lib/python3.4/test/gdb_sample.py -lib/python3.4/test/https_svn_python_org_root.pem lib/python3.4/test/ieee754.txt lib/python3.4/test/imghdrdata/ lib/python3.4/test/imghdrdata/python.bmp Index: Makefile === RCS file: /cvs/ports/lang/python/3.5/Makefile,v retrieving revision 1.7 diff -u -p -u -p -r1.7 Makefile --- Makefile 11 May 2016 22:43:49 - 1.7 +++ Makefile 27 Jun 2016 14:36:29 - @@ -6,8 +6,7 @@ # Python itself. VERSION = 3.5 -PATCHLEVEL = .1 -REVISION = 1 +PATCHLEVEL = .2 SHARED_LIBS = python3.5m 0.0 VERSION_SPEC = >=3.5,<3.6 Index: distinfo === RCS file: /cvs/ports/lang/python/3.5/distinfo,v retrieving revision 1.2 diff -u -p -u -p -r1.2 distinfo --- distinfo 22 Dec 2015 18:00:30 - 1.2 +++ distinfo 27 Jun 2016 14:36:29 - @@ -1,2 +1,2 @@ -SHA256 (Python-3.5.1.tgz) = aH4GfZ85HaZFQjx+2oIFuunTXtwMdu9SGNy+TMdw0Nc= -SIZE (Python-3.5.1.tgz) = 20143759 +SHA256 (Python-3.5.2.tgz) = FSS4QOQs87kJ6PjfZ8FyQBLH3H+dB21P7vLT7/Ax6KA= +SIZE (Python-3.5.2.tgz) = 20566643 Index: pkg/PLIST-idle === RCS file: /cvs/ports/lang/python/3.5/pkg/PLIST-idle,v retrieving revision 1.2 diff -u -p -u -p -r1.2 PLIST-idle --- pkg/PLIST-idle 22 Dec 2015 18:00:31 - 1.2 +++ pkg/PLIST-idle 27 Jun 2016 14:36:29 - @@ -294,6 +294,9 @@ lib/python3.5/idlelib/idle_test/__pycach lib/python3.5/idlelib/idle_test/__pycache__/test_calltips.cpython-35.opt-1.pyc lib/python3.5/idlelib/idle_tes
Re: net/kea: Ensure base awk is used
On 2016/06/27 18:15, Patrik Lundin wrote: > +CONFIGURE_ENV+= ac_cv_path_AWK=awk That should already be set. Is it not picking up config.site for some reason?
net/kea: Ensure base awk is used
Hello,
This diff solves a problem found by naddy@ where the build will fail if
gawk happens to be temporarily installed during a bulk build.
The fix was suggested by naddy@ as well, much appreciated!
It changes the output of a clean (no gawk installed) ./configure from:
===
checking for gawk... (cached) awk
checking for gawk... no
checking for awk... /usr/bin/awk
===
... to:
===
checking for gawk... (cached) awk
checking for gawk... (cached) awk
===
Without the diff and with gawk installed it looked like this:
===
checking for gawk... (cached) awk
checking for gawk... /usr/local/bin/gawk
===
I started an upstream discussion which can be found here:
https://lists.isc.org/pipermail/kea-users/2016-June/000416.html
Since upstream did not jump on this I feel it is good enough to fix it
this way for now.
Again, extra thanks to naddy@ for not only finding this bug but
also helping me wrap my head around the autoconf magic involved.
--
Patrik Lundin
Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile14 Mar 2016 06:46:24 - 1.5
+++ Makefile27 Jun 2016 15:55:51 -
@@ -3,6 +3,7 @@
COMMENT= high-performance and extensible DHCP server engine from ISC
VERSION= 1.0.0
+REVISION= 0
DISTNAME= kea-${VERSION}
PKGNAME= ${DISTNAME:S/-P/pl/}
@@ -47,6 +48,7 @@ CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --with-openssl=/usr \
--with-boost-libs=-lboost_system \
--with-boost-lib-dir=${LOCALBASE}/lib
+CONFIGURE_ENV+= ac_cv_path_AWK=awk
LIBTOOL_FLAGS= --tag=disable-static
Re: net/kea: Ensure base awk is used
On 2016/06/27 17:19, Stuart Henderson wrote: > On 2016/06/27 18:15, Patrik Lundin wrote: > > +CONFIGURE_ENV+= ac_cv_path_AWK=awk > > That should already be set. Is it not picking up config.site for some reason? > Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea is also looking at ac_cv_*path*_AWK. Perhaps we should add the path variant to config.site then..
net/kea: Helpfully failing test in ./configure
Hello, When looking at the output of ./configure in net/kea I noticed the following warning which I have previously missed: === ./configure[15929]: test: <: unexpected operator/operand === The responsible code in the configure script should be this: === # gcc 4.4 would emit warnings about breaking strict aliasing rules. # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.` if test "$CXX_DUMP_VERSION" \< "4.5"; then WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing" fi === The error message is thrown because the builtin test does not support the "<" operator (which /bin/test does). The funny thing is that gcc in base does not seem to suffer from the bug that is described in the bug tracker linked above, because the build generates no warnings relating to strict-aliasing. This means that the failing "test" can actually be thought of as a feature. It is of course brittle, and will modify the build parameters if someone decides to teach the test builtin about "<" prior to bumping base gcc past 4.5. Basically I am just asking for pointers from other porters, anyone have an idea how I should deal with this? Should I bother at all? -- Patrik Lundin
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
Sebastien Marie writes: > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: >> Hi ports@, >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just >> today. >> > [...] >> >> All feedback most welcome. >> > > Hi, > > I would like to ask some questions. This makes me very happy :-). > > - www/tbb/tor-browser/files/tor-browser.cfg file > > where does the configuration comes from you ? is it settings from you > or from TBB ? > > I ask due to default bridges configuration (addresses, fingerprints > and certs), and to default plugins configuration. These configuration > settings are very sensible. > This mostly comes directly from Tor Browser. Our tor-browser.cfg is actually two things: (1) the contents of extension-overrides.js from the TBB, lightly edited to pass muster as a cfg file... for some reason they use #comments in extension-overrides.js. I don't know why this is valid syntax in that context but it isn't in a cfg file, which is pure JS; (2) The bit at the end is my addition, whose purpose is to initialize your ~/.tor-browser/torrc to an empty config if it doesn't exist. This has to happen before the tor-launcher addon tries to start tor or else we have problems. In the past I tried to solve this issue by adding a sh script called start-tor-browser that took care of these things but landry@ pointed out that I should not need to do this if I'm using moz correctly. All of the settings that come along with (1) are verbatim what the Tor project says. They change between releases quite often. I track that file manually right now, I would like to make this more automated. The second point needs some explanation. We need ~/.tor-browser/torrc to exist before tor browser starts for the first time, or else it will never get created and tor browser won't work correctly. Worse, it will *appear* to work correctly the first time. This is more an issue in tor itself. If you say $ tor -f /some/nonexistent/file --ignore-missing-torrc \ --defaults-torrc /file/that/exists ... tor will start, using the config in /file/that/exists, and not complain about /some/nonexistent/file, but it will also forget that you said -f /some/nonexstent/file. This is a problem because Tor browser starts and controls its own instance of the tor daemon via the control port. One of the first things it does once it gets going is send tor a SAVECONF command, which means: save the non-default settings in your running config as a torrc file. The question is: where will it try to write them? If -f specified a non-exstent file that pathname gets forgotten, so under OpenBSD it ends up trying to write onto /etc/tor/torrc. In the best case this fails due to perms, and the user can't really change their config via the normal means (e.g. add bridge lines to the config when TB starts up using their dialog, which I generally do in Mexico). In the worst case, the user is in the same group as the /etc/tor/torrc file and it is group-writable (happened to me once due to stupidity which I will not repeat), and, well... Okay, I guess the worse case is that the user runs tor-browser as root, which, sadly, will "work" without incident... except that your system-wide tor config gets stomped on silently. Somehow I have a feeling most OpenBSD users know not to run stuff as root... It has been on my list for a while to investigate whether this is considered a bug by the tor people or not (-f forgets a non-existent path). I just haven't gotten to it, since I had a patch that dealt with the issue regardless... death by a thousand patches. > > - www/tbb/tor-browser/patches/patch-toolkit_xre_nsAppRunner_cpp file > "Revert the file back to ESR45.1.1, all diffs were TB-specific and not > relevant to OpenBSD". > > Can you explain why ? The diff is quite large, and reverts elements > like: > - In Tor Browser, remoting is disabled by default unless -osint is > used (so --no-remote isn't the default anymore with TBB). This was an oversight on my part. I shouldn't have reverted that part. > - Set the application-wide C-locale. Needed to resist fingerprinting > of Date.toLocaleFormat(). This is another oversight. As you point out the patch is too big and these are good examples of why that's a bad idea, since I missed some things I should've caught. In the switch to ESR45 the Tor people changed their hacks to the stuff in toolkit/xre, probably in part because moz itself changed there between ESR38 and ESR45. They had hacks strewn through several files before that were effectively the core of "the bundle": stuff that hard-coded paths relative to the location of the tor-browser binary that didn't work how the normal moz code worked when it comes to finding your profile, etc. Instead now in ESR45-based Tor Browser they refactored most of their stuff into a separate module and call into that module from various places in toolkit/xre.
Re: [NEW] www/tbb - Tor Browser Bundle 6.0.2
David Coppa writes:
> On Mon, 27 Jun 2016, Landry Breuil wrote:
>
>> On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote:
>> > On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil
>> > wrote:
>> > > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote:
>> > >> Hi ports@,
>> > >>
>> > >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just
>> > >> today. I believe I have addressed all previous concerns:
>> > >>
>> > >> * Our extensions now live in /usr/local/lib/... and run directly from
>> > >> there, they are not unpacked under the user's profile (enabledScopes
>> > >> solved this);
>> > >> * addon PLIST files redone to just have the .xpi file;
>> > >> * No more hardcoded /usr/local paths
>> > >> * Only addons we actually have to patch are packaged by us; otherwise
>> > >> we just wrap around the distributed .xpi (noscript, https-everywhere)
>> > >
>> > > Great stuff, thanks for spending the time to do all this right !
>> > >
>> > > Why are you overriding FETCH_CMD in noscript subdir ? That looks
>> > > wrong...
>> >
>> > That's because it fails without "-S dont":
>> >
>> > >> Fetch
>> > >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi
>> > ftp: SSL read error: handshake failed: error:14090086:SSL
>> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>> >
>> > Probably it should be mirrored on a decent web server...
>>
>> How... ironic. I think it'd actually be better to fetch it from
>> addons.mozilla.org, to stress that's the unmodified/official version.
>
> Indeed. This works w/o problems:
>
> --- www/tbb/noscript/Makefile.old Thu Jun 23 19:56:02 2016
> +++ www/tbb/noscript/Makefile Mon Jun 27 11:20:03 2016
> @@ -4,8 +4,7 @@
> V = 2.9.0.11
> COMMENT =flexible JS blocker for firefox (Tor browser variant)
> HOMEPAGE = http://noscript.net
> -MASTER_SITES =
> https://secure.informaction.com/download/releases/
> -FETCH_CMD ?= /usr/bin/ftp -V ${_PROGRESS} -k
> ${FTP_KEEPALIVE} -C -S dont
> +MASTER_SITES =
> https://addons.mozilla.org/firefox/downloads/file/421899/
> GUID = {73a6fe31-595d-460b-a920-fcc0f8843232}
> DISTFILE_IS_XPI =Yes
>
Wow, by the time I refreshed my mail you guys had already figured out
why I did that ugly thing and fixed it. Thanks! Will be fixed in
next post, as soon as I address some of smarie@'s concerns.
Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
devel/llvm: make clang build working static PIE programs
clang currently links against /usr/lib/crt0.o when building
a binary with the -static -pie options. That makes such
programs segfault on startup (gcc 4.9 seems to have the same
problem).
When building a static PIE program, we need to link against
/usr/lib/rcrt0.o, as shown below. Bitrig has this part also
in their local llvm tree. I'll try to get it into upstream for
clang 3.9 as well.
--- tools/clang/lib/Driver/Tools.cpp.orig Fri Feb 12 23:51:41 2016
+++ tools/clang/lib/Driver/Tools.cppSun Jun 26 20:24:44 2016
@@ -7600,6 +7600,10 @@ void openbsd::Linker::ConstructJob(Compilation &C, con
if (Args.hasArg(options::OPT_pg))
CmdArgs.push_back(
Args.MakeArgString(getToolChain().GetFilePath("gcrt0.o")));
+ else if (Args.hasArg(options::OPT_static) &&
+ !Args.hasArg(options::OPT_nopie))
+CmdArgs.push_back(
+Args.MakeArgString(getToolChain().GetFilePath("rcrt0.o")));
else
CmdArgs.push_back(
Args.MakeArgString(getToolChain().GetFilePath("crt0.o")));
Full diff against the ports tree below.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.114
diff -u -p -r1.114 Makefile
--- Makefile24 May 2016 07:53:23 - 1.114
+++ Makefile27 Jun 2016 17:24:32 -
@@ -11,7 +11,7 @@ COMMENT = modular, fast C/C++/ObjC compi
LLVM_V = 3.8.0
DISTNAME = llvm-${LLVM_V}.src
PKGNAME = llvm-${LLVM_V}
-REVISION = 1
+REVISION = 2
CATEGORIES = devel
DISTFILES =llvm-${LLVM_V}.src${EXTRACT_SUFX} \
cfe-${LLVM_V}.src${EXTRACT_SUFX}
Index: patches/patch-tools_clang_lib_Driver_Tools_cpp
===
RCS file: /cvs/ports/devel/llvm/patches/patch-tools_clang_lib_Driver_Tools_cpp,v
retrieving revision 1.30
diff -u -p -r1.30 patch-tools_clang_lib_Driver_Tools_cpp
--- patches/patch-tools_clang_lib_Driver_Tools_cpp 24 May 2016 07:53:23
- 1.30
+++ patches/patch-tools_clang_lib_Driver_Tools_cpp 27 Jun 2016 17:24:32
-
@@ -1,6 +1,5 @@
-$OpenBSD: patch-tools_clang_lib_Driver_Tools_cpp,v 1.30 2016/05/24 07:53:23
ajacoutot Exp $
tools/clang/lib/Driver/Tools.cpp.orig Fri Feb 12 17:51:41 2016
-+++ tools/clang/lib/Driver/Tools.cpp Tue May 17 14:45:22 2016
+--- tools/clang/lib/Driver/Tools.cpp.orig Fri Feb 12 23:51:41 2016
tools/clang/lib/Driver/Tools.cpp Sun Jun 26 20:24:44 2016
@@ -78,7 +78,7 @@ static const char *getSparcAsmModeForCPU(StringRef Nam
.Case("niagara2", "-Av9b")
.Case("niagara3", "-Av9d")
@@ -10,7 +9,18 @@ $OpenBSD: patch-tools_clang_lib_Driver_T
} else {
return llvm::StringSwitch(Name)
.Case("v8", "-Av8")
-@@ -7611,15 +7611,17 @@ void openbsd::Linker::ConstructJob(Compilation &C, con
+@@ -7600,6 +7600,10 @@ void openbsd::Linker::ConstructJob(Compilation &C, con
+ if (Args.hasArg(options::OPT_pg))
+ CmdArgs.push_back(
+ Args.MakeArgString(getToolChain().GetFilePath("gcrt0.o")));
++ else if (Args.hasArg(options::OPT_static) &&
++ !Args.hasArg(options::OPT_nopie))
++CmdArgs.push_back(
++Args.MakeArgString(getToolChain().GetFilePath("rcrt0.o")));
+ else
+ CmdArgs.push_back(
+ Args.MakeArgString(getToolChain().GetFilePath("crt0.o")));
+@@ -7611,15 +7615,17 @@ void openbsd::Linker::ConstructJob(Compilation &C, con
}
}
Re: net/kea: Helpfully failing test in ./configure
Patrik Lundin writes: > Hello, > > When looking at the output of ./configure in net/kea I noticed the > following warning which I have previously missed: > === > ./configure[15929]: test: <: unexpected operator/operand > === > > The responsible code in the configure script should be this: > === > # gcc 4.4 would emit warnings about breaking strict aliasing rules. > # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 > CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.` > if test "$CXX_DUMP_VERSION" \< "4.5"; then >WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing" > fi > === > > The error message is thrown because the builtin test does not support > the "<" operator (which /bin/test does). > > The funny thing is that gcc in base does not seem to suffer from the > bug that is described in the bug tracker linked above, because the build > generates no warnings relating to strict-aliasing. > > This means that the failing "test" can actually be thought of as a > feature. It is of course brittle, and will modify the build parameters > if someone decides to teach the test builtin about "<" prior to bumping > base gcc past 4.5. This is a very unlikely scenario. > Basically I am just asking for pointers from other porters, anyone have > an idea how I should deal with this? Should I bother at all? I guess you could just use /bin/test. -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: 5.9-stable Samba 4.3.10 update
Ian Mcwilliam writes: > Samba 4.3.10 update for 5.9-stable. No CVEs just bug fixes. > > https://www.samba.org/samba/history/samba-4.3.10.html I haven't taken a close look yet, but if this update isn't disruptive I'd like to commit it. The rationale being that samba often sees security updates, and that the OPENBSD_5_9 branch will probably have one before the branch gets out of support. Small steps and consistent testing means that we can more easily integrate security updates that matter. So please -stable users, send us test reports. :) -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [UPDATE] net/haproxy 1.6.6
On Mon, 27 Jun 2016 10:22:42 +0100, David CARLIER wrote: > true. > > On 27 June 2016 at 10:11, Daniel Jakots wrote: > > > On Mon, 27 Jun 2016 09:19:00 +0100, David CARLIER > > wrote: > > > > > Hi, > > > > > > this is haproxy update, the two temporary patches are unnecessary > > > now. > > > > > > Kind regards. > > > > You forgot to remove the REVISION. > > Thanks, committed.
Re: net/kea: Ensure base awk is used
On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson wrote: > Perhaps we should add the path variant to config.site then.. It looks like the right approach to me, ok dcoppa@. ciao! David
Re: net/kea: Ensure base awk is used
On 2016/06/27 21:10, David Coppa wrote:
> On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson
> wrote:
>
> > Perhaps we should add the path variant to config.site then..
>
> It looks like the right approach to me, ok dcoppa@.
These are the relevant ports,
bacula-7.4.0
check-0.10.0
check_mssql_health-1.5.19
clusterit-2.5
djview4-4.10.6
elinks-0.11.7
freedroidrpg-0.16
geda-gaf-1.6.0
kea-1.0.0
lam-6.5.9
latex-mk-1.9.1
lbdb_0.40
libgnome-2.32.1
libgnomecanvas-2.30.3
libgnomeui-2.24.5
libreoffice-5.1.2.2
libsmi-0.4.8
quilt-0.64
xboard-4.8.0
basic diff:
Index: config.no-gawk
===
RCS file: /cvs/ports/infrastructure/db/config.no-gawk,v
retrieving revision 1.1
diff -u -p -r1.1 config.no-gawk
--- config.no-gawk 12 Dec 2011 10:33:33 - 1.1
+++ config.no-gawk 27 Jun 2016 19:32:34 -
@@ -1,3 +1,4 @@
# $OpenBSD: config.no-gawk,v 1.1 2011/12/12 10:33:33 jasper Exp $
# included unless lang/gawk
ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
+ac_cv_path_AWK=${ac_cv_path_AWK=/usr/bin/awk}
...but there's also this in config.site, which seems incorrect:
ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}
Re: maintainer update to libetpan-1.7.2
Daniel Jakots writes: > Hi, > > Here's an update to latest libetpan release. All patchs were > merged upstream. A major bump is required (and was done upstream too) > as some functions were removed. > > Comments? OK? Looks fine ports-wise, ok jca@ -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: net/kea: Ensure base awk is used
On 2016-06-27, Stuart Henderson wrote: >> That should already be set. Is it not picking up config.site for some reason? > > Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea > is also looking at ac_cv_*path*_AWK. > > Perhaps we should add the path variant to config.site then.. In fact, ac_cv_prog_AWK is set in both config.site and again in config.no-gawk. That doesn't make sense. I suspect the intention was to set ac_cv_path_AWK in config.no-gawk. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: net/kea: Helpfully failing test in ./configure
On 2016-06-27, Patrik Lundin wrote: > CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.` > if test "$CXX_DUMP_VERSION" \< "4.5"; then >WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing" > fi > > The error message is thrown because the builtin test does not support > the "<" operator (which /bin/test does). That's not portable. POSIX does not specify an operator < for test. For a portable solution, use expr(1) instead. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [NEW] audio/svmidi
On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote: > Sorry deleted the original email before I noticed this. > > svmidi needs fonts/terminus > -- > Edgar Pettijohn Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on base right? Attached updated archive. Regards; Henrique N. Lengler svmidi-0.2.tar.gz Description: application/tar-gz
Re: [NEW] audio/svmidi
Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler" > On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote: > > Sorry deleted the original email before I noticed this. > > > > svmidi needs fonts/terminus > > -- > > Edgar Pettijohn > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on base > right? Was this not 13 as seen here in file /usr/X11R6/share/X11/app-defaults/XTerm 141:*VT100.utf8Fonts.font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 Try with this: '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' You could test around with xfontsel(1) xfontsel - point and click selection of X11 font names [http://man.openbsd.org/xfontsel] $ xfontsel NB: I may be completely wrong, please don't take it verbatim, verify. > Attached updated archive. > > Regards; > > Henrique N. Lengler
Re: [NEW] emulators/virtualjaguar
On Sat, 18 Jun 2016 15:46:33 +0200 Frederic Cambus wrote: > Hi ports@, > > Here is a new port, for Virtual Jaguar. > From DESCR: > > Virtual Jaguar is a portable Atari Jaguar emulator. The software was > originally developed by David Raingeard of Potato Emulation. > > Currently all the major subsystems found in a real Jaguar are emulated > to some degree. > Tested on amd64 -current Initially I wondered why the pre-configure step instead of devel/cmake but I see the linking phase fails when using the module instead of the pre-configure step. The port builds and installs cleanly. I did notice that upstream provides a .desktop file that can be used for menu entries but I don't see an icon that would be decent enough to use... I also check archlinux packaging and netbsd - none of them ship the .desktop entry. I did try 3 roms with the port. - Doom world (failed, most I got out of it was loading splash screen) - Wolfestein 3D World (failed, black screen) - Doubel dragon (fully working) The failed ports were failed emulation. Log shows illegal instructions etc. I don't think it's caused by packaging. I am OK awolk@ to import this in the current state.
[update] lang/node 4.4.5 -> 4.4.6 and backport fix for 5.9
Hola!
This update fixes CVE-2016-1669, a High ranking buffer overflow in v8
that 'allows remote attackers to cause a denial of service (buffer
overflow) or possibly have unspecified other impact via crafted
JavaScript code'.
Also included is the backport for 5.9, which was tested on amd64 with
no issues.
The ChangeLog is here: https://github.com/nodejs/node/blob/v4.4.6/CHANGELOG.md
OK?
--- current ---
diff --git a/lang/node/Makefile b/lang/node/Makefile
index ed992ce..3cd4e9a 100644
--- a/lang/node/Makefile
+++ b/lang/node/Makefile
@@ -8,7 +8,7 @@ ONLY_FOR_ARCHS= amd64 i386 powerpc
COMMENT= V8 JavaScript for clients and servers
-NODE_VERSION= v4.4.5
+NODE_VERSION= v4.4.6
PLEDGE_VER=1.1.0
DISTFILES= node-pledge-{}${PLEDGE_VER}.tar.gz:0 ${DISTNAME}.tar.gz
diff --git a/lang/node/distinfo b/lang/node/distinfo
index 115fd9b..0c99a6a 100644
--- a/lang/node/distinfo
+++ b/lang/node/distinfo
@@ -1,4 +1,4 @@
SHA256 (node-pledge-1.1.0.tar.gz) =
BuKnrXSkqpTb5Tfap1AHk+l7ucTJLEWbMFNbgQkNBsw=
-SHA256 (node-v4.4.5.tar.gz) = 6pyWrkdo/u5PGKJrgZubT25JEF6g7oxcnRiNyNSdS3c=
+SHA256 (node-v4.4.6.tar.gz) = Reqz1BVhblgxullhtnzsVCPh+cF1yn4zHef1YMKZjZ8=
SIZE (node-pledge-1.1.0.tar.gz) = 2560
-SIZE (node-v4.4.5.tar.gz) = 22675369
+SIZE (node-v4.4.6.tar.gz) = 22675490
--- 5.9 back port ---
diff --git a/lang/node/Makefile b/lang/node/Makefile
index 5b2e555..39b88d7 100644
--- a/lang/node/Makefile
+++ b/lang/node/Makefile
@@ -9,6 +9,7 @@ ONLY_FOR_ARCHS= amd64 i386 powerpc
COMMENT= V8 JavaScript for clients and servers
NODE_VERSION= v4.3.0
+REVISION= 0
PLEDGE_VER=1.1.0
DISTFILES= node-pledge-{}${PLEDGE_VER}.tar.gz:0 ${DISTNAME}.tar.gz
diff --git a/lang/node/patches/patch-deps_v8_include_v8-version_h
b/lang/node/patches/patch-deps_v8_include_v8-version_h
index e69de29..80a6cbc 100644
--- a/lang/node/patches/patch-deps_v8_include_v8-version_h
+++ b/lang/node/patches/patch-deps_v8_include_v8-version_h
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- deps/v8/include/v8-version.h.orig Tue Feb 9 07:02:02 2016
deps/v8/include/v8-version.h Mon Jun 27 14:05:55 2016
+@@ -11,7 +11,7 @@
+ #define V8_MAJOR_VERSION 4
+ #define V8_MINOR_VERSION 5
+ #define V8_BUILD_NUMBER 103
+-#define V8_PATCH_LEVEL 35
++#define V8_PATCH_LEVEL 36
+
+ // Use 1 for candidates and 0 otherwise.
+ // (Boolean macro values are not supported by all preprocessors.)
diff --git a/lang/node/patches/patch-deps_v8_src_zone_cc
b/lang/node/patches/patch-deps_v8_src_zone_cc
index e69de29..f9d951c 100644
--- a/lang/node/patches/patch-deps_v8_src_zone_cc
+++ b/lang/node/patches/patch-deps_v8_src_zone_cc
@@ -0,0 +1,27 @@
+$OpenBSD$
+--- deps/v8/src/zone.cc.orig Tue Feb 9 07:02:05 2016
deps/v8/src/zone.ccMon Jun 27 14:06:04 2016
+@@ -105,7 +105,10 @@ void* Zone::New(size_t size) {
+ Address result = position_;
+
+ const size_t size_with_redzone = size + kASanRedzoneBytes;
+- if (limit_ < position_ + size_with_redzone) {
++ const uintptr_t limit = reinterpret_cast(limit_);
++ const uintptr_t position = reinterpret_cast(position_);
++ // position_ > limit_ can be true after the alignment correction above.
++ if (limit < position || size_with_redzone > limit - position) {
+ result = NewExpand(size_with_redzone);
+ } else {
+ position_ += size_with_redzone;
+@@ -222,7 +225,10 @@ Address Zone::NewExpand(size_t size) {
+ // Make sure the requested size is already properly aligned and that
+ // there isn't enough room in the Zone to satisfy the request.
+ DCHECK_EQ(size, RoundDown(size, kAlignment));
+- DCHECK_LT(limit_, position_ + size);
++ DCHECK(limit_ < position_ ||
++ reinterpret_cast(limit_) -
++ reinterpret_cast(position_) <
++ size);
+
+ // Compute the new segment size. We use a 'high water mark'
+ // strategy, where we increase the segment size every time we expand
Re: [NEW] audio/svmidi
On Tue, Jun 28, 2016 at 12:09:10AM +0300, li...@wrant.com wrote: > Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler" > > > On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote: > > > Sorry deleted the original email before I noticed this. > > > > > > svmidi needs fonts/terminus > > > -- > > > Edgar Pettijohn > > > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on base > > right? > > Was this not 13 as seen here in file /usr/X11R6/share/X11/app-defaults/XTerm > > 141:*VT100.utf8Fonts.font: > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 > > Try with this: > > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' > > You could test around with xfontsel(1) > > xfontsel - point and click selection of X11 font names > [http://man.openbsd.org/xfontsel] > > $ xfontsel > > NB: I may be completely wrong, please don't take it verbatim, verify. Why not 14? I got it from xfontsel > > > Attached updated archive. > > > > Regards; > > > > Henrique N. Lengler >
Re: [NEW] audio/svmidi
Mon, 27 Jun 2016 18:50:01 -0300 "Henrique N. Lengler" > On Tue, Jun 28, 2016 at 12:09:10AM +0300, li...@wrant.com wrote: > > Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler" > > > > > On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote: > > > > Sorry deleted the original email before I noticed this. > > > > > > > > svmidi needs fonts/terminus > > > > -- > > > > Edgar Pettijohn > > > > > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on > > > base > > > right? > > > > Was this not 13 as seen here in file /usr/X11R6/share/X11/app-defaults/XTerm > > > > 141:*VT100.utf8Fonts.font: > > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 > > > > Try with this: > > > > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' > > > > You could test around with xfontsel(1) > > > > xfontsel - point and click selection of X11 font names > > [http://man.openbsd.org/xfontsel] > > > > $ xfontsel > > > > NB: I may be completely wrong, please don't take it verbatim, verify. > > Why not 14? I got it from xfontsel It's up to you mostly, if you choose to follow that just for consistency given the following statements are not completely off the chart or wrong. While there may be very few reasons for the *-13-* I'll try to add some: + XTerm 'probably' uses *-13-* by default on a fresh install + 'maybe' some of the sizes cover more from the UTF-8 demo sample http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt And then again, it's a matter of personal preferences, for my eyes, I just stick to fonts that draw the letter with 1 pixel line width only. Experiment a bit with various settings and pick the one you like best. > > > Attached updated archive. > > > > > > Regards; > > > > > > Henrique N. Lengler > > >
Re: net/kea: Helpfully failing test in ./configure
On Mon, Jun 27, 2016 at 07:51:33PM +, Christian Weisgerber wrote: > On 2016-06-27, Patrik Lundin wrote: > > > CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.` > > if test "$CXX_DUMP_VERSION" \< "4.5"; then > >WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing" > > fi > > > > The error message is thrown because the builtin test does not support > > the "<" operator (which /bin/test does). > > That's not portable. POSIX does not specify an operator < for test. > > For a portable solution, use expr(1) instead. > Thanks, that sounds like the most proper way forward. I have opened a PR against upstream, lets see what they think: https://github.com/isc-projects/kea/pull/25 I guess the side effect of fixing the check (adding "-fno-strict-aliasing" to the build even if not strictly needed) is not really detrimental to the build. -- Patrik Lundin
Re: net/kea: Helpfully failing test in ./configure
On Mon, Jun 27, 2016 at 07:44:07PM +0200, Jeremie Courreges-Anglas wrote: > Patrik Lundin writes: > > > > > This means that the failing "test" can actually be thought of as a > > feature. It is of course brittle, and will modify the build parameters > > if someone decides to teach the test builtin about "<" prior to bumping > > base gcc past 4.5. > > This is a very unlikely scenario. > > > Basically I am just asking for pointers from other porters, anyone have > > an idea how I should deal with this? Should I bother at all? > > I guess you could just use /bin/test. > I figured that such a gcc version bump is fairly unlikely but I would rather ask than guess :). Thanks for the input, I'll see what upstream thinks about the "expr" proposal. If they decide to merge it I will return with a patch for the port. -- Patrik Lundin
Re: [NEW] audio/svmidi
On Tue, Jun 28, 2016 at 01:26:10AM +0300, li...@wrant.com wrote: > Mon, 27 Jun 2016 18:50:01 -0300 "Henrique N. Lengler" > > > On Tue, Jun 28, 2016 at 12:09:10AM +0300, li...@wrant.com wrote: > > > Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler" > > > > > > > On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote: > > > > > Sorry deleted the original email before I noticed this. > > > > > > > > > > svmidi needs fonts/terminus > > > > > -- > > > > > Edgar Pettijohn > > > > > > > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on > > > > base > > > > right? > > > > > > Was this not 13 as seen here in file > > > /usr/X11R6/share/X11/app-defaults/XTerm > > > > > > 141:*VT100.utf8Fonts.font: > > > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 > > > > > > Try with this: > > > > > > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' > > > > > > You could test around with xfontsel(1) > > > > > > xfontsel - point and click selection of X11 font names > > > [http://man.openbsd.org/xfontsel] > > > > > > $ xfontsel > > > > > > NB: I may be completely wrong, please don't take it verbatim, verify. > > > > Why not 14? I got it from xfontsel > > It's up to you mostly, if you choose to follow that just for consistency > given the following statements are not completely off the chart or wrong. > > While there may be very few reasons for the *-13-* I'll try to add some: > > + XTerm 'probably' uses *-13-* by default on a fresh install > + 'maybe' some of the sizes cover more from the UTF-8 demo sample > > http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt > > And then again, it's a matter of personal preferences, for my eyes, I > just stick to fonts that draw the letter with 1 pixel line width only. > > Experiment a bit with various settings and pick the one you like best. Ok I got it, changed to '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' Attached updated archive. Regards; Henrique N. Lengler
Re: [NEW] audio/svmidi
> > > > > > Sorry deleted the original email before I noticed this. > > > > > > > > > > > > svmidi needs fonts/terminus > > > > > > -- > > > > > > Edgar Pettijohn > > > > > > > > > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is > > > > > on base > > > > > right? > > > > > > > > Was this not 13 as seen here in file > > > > /usr/X11R6/share/X11/app-defaults/XTerm > > > > > > > > 141:*VT100.utf8Fonts.font: > > > > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 > > > > > > > > Try with this: > > > > > > > > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' > > > > > > > > You could test around with xfontsel(1) > > > > > > > > xfontsel - point and click selection of X11 font names > > > > [http://man.openbsd.org/xfontsel] > > > > > > > > $ xfontsel > > > > > > > > NB: I may be completely wrong, please don't take it verbatim, verify. > > > > > > Why not 14? I got it from xfontsel > > > > It's up to you mostly, if you choose to follow that just for consistency > > given the following statements are not completely off the chart or wrong. > > > > While there may be very few reasons for the *-13-* I'll try to add some: > > > > + XTerm 'probably' uses *-13-* by default on a fresh install > > + 'maybe' some of the sizes cover more from the UTF-8 demo sample > > > > http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt > > > > And then again, it's a matter of personal preferences, for my eyes, I > > just stick to fonts that draw the letter with 1 pixel line width only. > > > > Experiment a bit with various settings and pick the one you like best. > > Ok I got it, > > changed to '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*' > > Attached updated archive. While terminus itself is not bad, I think you improved upon the choice. Thank you, hope I get to play with your program from the packages soon! > Regards; > > Henrique N. Lengler >
Re: [UPDATE] games/yquake2 5.32 => 5.34
Sun, 26 Jun 2016 22:31:55 +0200 Adam Wolk
> > Same diff but with an additional change to
> > ports/infrastructure/db/user.list and using the same ID.
An underscore informs me it's a program Who brought the user, correct?
Is it any reasonable consideration to make the user names any package,
(here a port) brings up on the system match the _program (_port) name?
Is it also worth making packages (ports) users/groups start with a _p
so they end up together when listed alphabetically, e.g. _pdescent2 ?
NB: I am only considering the system maintenance factors, and don't
insist on anything changed, but please let me know what is the norm.
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/yquake2/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 16 Mar 2016 16:46:32 - 1.3
> +++ Makefile 26 Jun 2016 20:23:55 -
> @@ -4,12 +4,13 @@ ONLY_FOR_ARCHS= i386 amd64 sparc64
>
> COMMENT= Yamagi Quake II
> N= yquake2
> -V= 5.32
> +V= 5.34
> PKGNAME= ${N}-${V}
> DISTNAME=quake2-${V}
> CATEGORIES= games
>
> HOMEPAGE=http://www.yamagi.org/quake2/
> +MAINTAINER= Adam Wolk
> MASTER_SITES=http://deponie.yamagi.org/quake2/
> EXTRACT_SUFX=.tar.xz
>
> @@ -25,11 +26,12 @@ LIB_DEPENDS= audio/libvorbis \
> MAKE_ENV+= VERBOSE=1
> USE_GMAKE= Yes
>
> +MAKE_FLAGS = config WITH_SYSTEMWIDE=yes WITH_SYSTEMDIR=${PREFIX}/share/${N}
> +
> do-install:
> - ${INSTALL_SCRIPT} ${FILESDIR}/yquake2 ${PREFIX}/bin/
> ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}
> ${INSTALL_PROGRAM} ${WRKBUILD}/release/{quake2,q2ded} \
> - ${PREFIX}/share/${N}/
> + ${PREFIX}/bin/
> ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}/baseq2
> ${INSTALL_PROGRAM} ${WRKBUILD}/release/baseq2/game.so \
> ${PREFIX}/share/${N}/baseq2/
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/yquake2/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 17 Jan 2016 15:18:31 - 1.1.1.1
> +++ distinfo 26 Jun 2016 20:23:55 -
> @@ -1,2 +1,2 @@
> -SHA256 (quake2-5.32.tar.xz) = v8eAMlSp0iiIVU1a8lL//iEts9qwYxY3u5BFhhuOUIw=
> -SIZE (quake2-5.32.tar.xz) = 1692720
> +SHA256 (quake2-5.34.tar.xz) = gOEZPGM9vuh7n8uGQwafm9pEOqZVUcjzUYcBNsM9ONQ=
> +SIZE (quake2-5.34.tar.xz) = 1702984
> Index: files/yquake2
> ===
> RCS file: files/yquake2
> diff -N files/yquake2
> --- files/yquake2 17 Jan 2016 15:18:31 - 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,3 +0,0 @@
> -#!/bin/sh
> -cd /usr/local/share/yquake2
> -exec /usr/local/share/yquake2/quake2 "$@"
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/games/yquake2/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 17 Jan 2016 15:18:31 - 1.1.1.1
> +++ pkg/PLIST 26 Jun 2016 20:23:55 -
> @@ -1,8 +1,17 @@
> @comment $OpenBSD: PLIST,v 1.1.1.1 2016/01/17 15:18:31 bmercer Exp $
> -bin/yquake2
> +@newgroup _q2:779
> +@newuser _q2:779:_q2:daemon:Yamagi Quake II Server:/var/q2:/sbin/nologin
> +@bin bin/q2ded
> +@bin bin/quake2
> share/doc/pkg-readmes/${FULLPKGNAME}
> share/yquake2/
> share/yquake2/baseq2/
> share/yquake2/baseq2/game.so
> -@bin share/yquake2/q2ded
> -@bin share/yquake2/quake2
> +@mode 750
> +@owner _q2
> +@group _q2
> +@sample /var/q2/
> +@owner
> +@group
> +@mode
> +@rcscript ${RCDIR}/q2ded
> Index: pkg/q2ded.rc
> ===
> RCS file: pkg/q2ded.rc
> diff -N pkg/q2ded.rc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pkg/q2ded.rc 26 Jun 2016 20:23:55 -
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +#
> +# $OpenBSD: $
> +
> +daemon="${TRUEPREFIX}/bin/q2ded"
> +daemon_user="_q2"
> +
> +. /etc/rc.d/rc.subr
> +
> +pexp="${daemon}.*"
> +
> +rc_bg=YES
> +rc_reload=NO
> +
> +rc_cmd $1
> Index: user.list
> ===
> RCS file: /cvs/ports/infrastructure/db/user.list,v
> retrieving revision 1.275
> diff -u -p -r1.275 user.list
> --- user.list 2 Jun 2016 18:32:26 - 1.275
> +++ user.list 26 Jun 2016 20:24:13 -
> @@ -287,3 +287,4 @@ id user group port options
> 776 _ioq3_ioq3 games/ioquake3
> 777 _svnserve_svnserve devel/subversion
> 778 _gitdaemon _gitdaemon devel/git
> +779 _q2 _q2 games/yquake2
>
>
Re: NEW sysutils/fuse-exfat 1.2.3 port
On Fri, Jun 3, 2016, at 09:13 AM, Mikolaj Kucharski wrote: > Upstream decided to install manual pages by default and > released 1.2.4. > Patches are not needed any more. Updated port of fuse-exfat attached. Any possibility this could get committed? It would be extremely useful for reading SDXC cards. Bryan
