Re: UPDATE: mail/msmtp 1.6.6p1 -> 1.8.6
Friendly ping. CCing Stuart in case he's interested. Xiyue Deng writes: > Friendly ping. > > Xiyue Deng writes: > >> Dear ports maintainers, >> >> I have updated msmtp to the latest version (1.8.6) in ports. It >> includes the following changes: >> >> * GnuTLS is recommended and deprecated OpenSSL. >> - So now GnuTLS is part of the build dependencies. >> >> * Use libidn2 instead of the older libidn. >> - Configure switch remains as "--with-libidn". >> >> * Refreshed patches to apply cleanly. >> >> I also have a few questions when working on this ports: >> >> * Many of the patches just replace "#!/usr/bin/env bash" to >> "#!/bin/sh". Now most of scripts are changed to use "#!/usr/bin/env >> sh" which should now be the same thing. Should we just drop those >> patches? >> >> * One of the patches changes the system /etc/msmtprc to provide an >> "account default" that listens on localhost:25, which will then use >> smtpd as server by default. I think the intention is to provide a >> working configure that works out of the box. However this may not do >> what you want because if one try to configure an account in a user >> configuration and somehow it contains errors (e.g. not properly >> provide a "from" address), msmtp will just send the mail through smtpd >> and returns OK which will result in the mail stuck in the system mail >> queue forever. So my suggestion is to leave this file untouched so >> that the system /etc/msmtprc will just provide a fake "account >> default" and any mail not handled with a user provided account will >> fail immediately. >> >> Tested on mips64el/loongson on 6.6-stable. Please let me know what you >> think. The diff is attached. >> >> Index: Makefile >> === >> RCS file: /cvs/ports/mail/msmtp/Makefile,v >> retrieving revision 1.47 >> diff -u -p -r1.47 Makefile >> --- Makefile 12 Jul 2019 20:47:30 - 1.47 >> +++ Makefile 21 Dec 2019 13:54:18 - >> @@ -2,27 +2,27 @@ >> >> COMMENT = SMTP plugin for MUAs >> >> -DISTNAME = msmtp-1.6.6 >> +DISTNAME = msmtp-1.8.6 >> CATEGORIES =mail >> -REVISION = 1 >> >> HOMEPAGE = https://marlam.de/msmtp/ >> >> # GPLv3 >> PERMIT_PACKAGE =Yes >> >> -WANTLIB = c crypto iconv idn intl ssl >> +WANTLIB = c crypto iconv idn2 intl gnutls >> >> MASTER_SITES = https://marlam.de/msmtp/releases/ >> EXTRACT_SUFX = .tar.xz >> >> -LIB_DEPENDS = devel/libidn >> +LIB_DEPENDS = devel/libidn2 \ >> +security/gnutls >> >> SEPARATE_BUILD =Yes >> CONFIGURE_STYLE = gnu >> CONFIGURE_ARGS =--with-libgsasl=no \ >> --with-libidn=yes \ >> ---with-tls=openssl \ >> +--with-tls=gnutls \ >> --without-libsecret >> >> post-install: >> Index: distinfo >> === >> RCS file: /cvs/ports/mail/msmtp/distinfo,v >> retrieving revision 1.30 >> diff -u -p -r1.30 distinfo >> --- distinfo 26 Mar 2017 13:34:06 - 1.30 >> +++ distinfo 21 Dec 2019 13:54:18 - >> @@ -1,2 +1,2 @@ >> -SHA256 (msmtp-1.6.6.tar.xz) = 2hXbH2K9AgH85TEK24nIYYi+kc10W3yztiuBpQHn+14= >> -SIZE (msmtp-1.6.6.tar.xz) = 283744 >> +SHA256 (msmtp-1.8.6.tar.xz) = ZiXxR0MMZbqFJ/UsT+XU0zVS08D7bXk7p9+BmjswQuE= >> +SIZE (msmtp-1.8.6.tar.xz) = 339732 >> Index: patches/patch-doc_msmtprc-system_example >> === >> RCS file: /cvs/ports/mail/msmtp/patches/patch-doc_msmtprc-system_example,v >> retrieving revision 1.1 >> diff -u -p -r1.1 patch-doc_msmtprc-system_example >> --- patches/patch-doc_msmtprc-system_example 13 Feb 2009 14:59:01 - >> 1.1 >> +++ patches/patch-doc_msmtprc-system_example 21 Dec 2019 13:54:18 - >> @@ -1,16 +1,25 @@ >> $OpenBSD: patch-doc_msmtprc-system_example,v 1.1 2009/02/13 14:59:01 >> pirofti Exp $ >> doc/msmtprc-system.example.orig Sat Apr 7 18:20:34 2007 >> -+++ doc/msmtprc-system.example Fri Feb 13 16:53:09 2009 >> -@@ -6,10 +6,10 @@ >> +--- doc/msmtprc-system.example.orig Thu Dec 13 00:22:06 2018 >> doc/msmtprc-system.example Sat Dec 21 01:17:17 2019 >> +@@ -6,15 +6,15 @@ >> account default >> >> - # The SMTP smarthost. >> + # The SMTP smarthost >> -host mailhub.oursite.example >> +host localhost >> >> - # Construct envelope-from addresses of the form "user@oursite.example". >> +-# Use TLS on port 465 >> +-port 465 >> +-tls on >> +-tls_starttls off >> ++## Use TLS on port 465 >> ++#port 465 >> ++#tls on >> ++#tls_starttls off >> + >> + # Construct envelope-from addresses of the form "user@oursite.example" >> -#auto_from on >> +auto_from on >> #maildomain oursite.example >> >> - # Use TLS. >> + # Syslog logging with facility LOG_MAIL instead of the
[PATCH] Support U2F/FIDO in www/chromium.
Fixes: https://bugs.chromium.org/p/chromium/issues/detail?id=451248
Uses /dev/fido via libfido2 bundled with the system. Due to an
abstraction level mismatch only the discovery phase is done via
libfido2.
The port was verified to work with demo.yubico.com, google.com,
github.com on amd64 6.6-current. 4 different devices from Yubico
and a couple other manufacturers work fine.
Known limitations:
* the u2f device needs to be plugged into the USB port before
starting authentication as the devices aren't discovered dynamically;
* kernel crashes are possible without patching a problem showing up
in filt_uhidrdetach https://marc.info/?l=openbsd-tech=157812352913919
The code started from FreeBSD port and then adapted for OpenBSD.
---
www/chromium/Makefile | 4 +-
www/chromium/files/hid_connection_fido.cc | 196 +++
www/chromium/files/hid_connection_fido.h | 56 +++
www/chromium/files/hid_service_fido.cc| 321 ++
www/chromium/files/hid_service_fido.h | 40 +++
www/chromium/files/unveil.main| 3 +
.../patch-services_device_hid_BUILD_gn| 10 +-
.../patch-services_device_hid_hid_service_cc | 23 ++
8 files changed, 650 insertions(+), 3 deletions(-)
create mode 100644 www/chromium/files/hid_connection_fido.cc
create mode 100644 www/chromium/files/hid_connection_fido.h
create mode 100644 www/chromium/files/hid_service_fido.cc
create mode 100644 www/chromium/files/hid_service_fido.h
create mode 100644
www/chromium/patches/patch-services_device_hid_hid_service_cc
diff --git a/www/chromium/Makefile b/www/chromium/Makefile
index 0345e7dddf4..7104534624c 100644
--- a/www/chromium/Makefile
+++ b/www/chromium/Makefile
@@ -36,7 +36,7 @@ FLAVOR?=
.if ${FLAVOR:Melectron}
REVISION= 3
.else
-REVISION= 0
+REVISION= 1
.endif
# BSD-like
@@ -79,6 +79,7 @@ WANTLIB += xml2 z
WANTLIB += harfbuzz
WANTLIB += ffi png
WANTLIB += iconv lzma
+WANTLIB += fido2 cbor usbhid crypto
RUN_DEPENDS= devel/xdg-utils \
devel/desktop-file-utils \
@@ -251,6 +252,7 @@ pre-configure:
. endfor
.endfor
@mkdir -p ${WRKSRC}/media/audio/sndio ${WRKSRC}/media/audio/openbsd
+ @cp ${FILESDIR}/hid_{service,connection}_fido.{cc,h}
${WRKSRC}/services/device/hid
@cp ${FILESDIR}/sndio_{out,in}put.{cc,h} ${WRKSRC}/media/audio/sndio
@cp ${FILESDIR}/audio_manager_openbsd.{cc,h} ${WRKSRC}/media/audio/openbsd
@mkdir -p ${WRKSRC}/third_party/node/openbsd/node-openbsd/bin
diff --git a/www/chromium/files/hid_connection_fido.cc
b/www/chromium/files/hid_connection_fido.cc
new file mode 100644
index 000..90575659610
--- /dev/null
+++ b/www/chromium/files/hid_connection_fido.cc
@@ -0,0 +1,196 @@
+// Copyright (c) 2020 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "services/device/hid/hid_connection_fido.h"
+
+#include "base/bind.h"
+#include "base/files/file_descriptor_watcher_posix.h"
+#include "base/location.h"
+#include "base/numerics/safe_math.h"
+#include "base/posix/eintr_wrapper.h"
+#include "base/single_thread_task_runner.h"
+#include "base/task/post_task.h"
+#include "base/threading/scoped_blocking_call.h"
+#include "base/threading/thread_restrictions.h"
+#include "base/threading/thread_task_runner_handle.h"
+#include "components/device_event_log/device_event_log.h"
+#include "services/device/hid/hid_service.h"
+
+namespace device {
+
+class HidConnectionFido::BlockingTaskHelper {
+public:
+ BlockingTaskHelper(base::ScopedFD fd,
+ scoped_refptr device_info,
+ base::WeakPtr connection)
+ : fd_(std::move(fd)),
+// Report buffers must always have room for the report ID.
+report_buffer_size_(device_info->max_input_report_size() + 1),
+has_report_id_(device_info->has_report_id()),
connection_(connection),
+origin_task_runner_(base::ThreadTaskRunnerHandle::Get()) {
+DETACH_FROM_SEQUENCE(sequence_checker_);
+ }
+
+ ~BlockingTaskHelper() {
DCHECK_CALLED_ON_VALID_SEQUENCE(sequence_checker_); }
+
+ // Starts the FileDescriptorWatcher that reads input events from the
device.
+ // Must be called on a thread that has a base::MessageLoopForIO.
+ void Start() {
+DCHECK_CALLED_ON_VALID_SEQUENCE(sequence_checker_);
+base::internal::AssertBlockingAllowed();
+
+file_watcher_ = base::FileDescriptorWatcher::WatchReadable(
+fd_.get(),
base::Bind(::OnFileCanReadWithoutBlocking,
+ base::Unretained(this)));
+ }
+
+ void Write(scoped_refptr buffer,
+ WriteCallback callback) {
+DCHECK_CALLED_ON_VALID_SEQUENCE(sequence_checker_);
+base::ScopedBlockingCall scoped_blocking_call(
+FROM_HERE, base::BlockingType::MAY_BLOCK);
+
+auto data = buffer->front();
+size_t size = buffer->size();
+// if report id is 0, it shouldn't be included
+if (data[0] == 0) {
+
Re: vim colors
>The latest vim update appears to have changed the default colorscheme to >reallyfreakingawful. The previous default seems to be called peachpuff. hth. does mailing ports@ help? much more likely, did upstream not make the decision? why not engage them and express your outrage? if it is not a ports decision, do you expect one cry in the wilderness to cause this small ports diff maintainance team to carry yet-another-diff which undoes an upstream decision, and each time a a new upstream version shows up, have to re-analyze the delta to make sure if doesn't cause harm? i did not look. i don't know who's decision it is, but i know we cannot collectivise the shifts and wims of a community fragment upon the downstream merge team, it is unsustainable effort for them. summary: i think you mailed the wrong list.
Re: [NEW] net/msoak
On 2020/01/04 19:10, Jan-Piet Mens wrote:
> Hello!
>
> This is a new port for msoak(1), a utility with which to simultaneously
> subscribe to an arbitrary number of topics on any number of MQTT brokers and
> optionally modify or normalize received payloads with Lua functions before
> printing them out.
>
> I am the author of said utility, too.
>
> Tested on 6.6-CURRENT
>
> I'm hoping somebody can test this and give me feedback on my first package
> for OpenBSD!
>
> Under the assumption that MQTT is not in everybody's repertoire (why not
> actually, it's great! :-), I have a short writeup about it at [1].
>
> Thank you and best regards,
>
> -JP
>
> [1]
> https://jpmens.net/2013/02/25/lots-of-messages-mqtt-pub-sub-and-the-mosquitto-broker/
Works for me, and a good first submission :) I've attached a tweaked
version, and will add commentary inline on a diff from your version:
: diff 986cac26887f6f0aacfba950d103b81aa829a56f /usr/ports/mystuff
: blob - 2c4b80e099a70cfb148c14beb35a29f0b7c13064
: file + net/msoak/Makefile
: --- net/msoak/Makefile
: +++ net/msoak/Makefile
: @@ -1,38 +1,37 @@
: # $OpenBSD$
:
: COMMENT =subscribe to multiple MQTT brokers and topics simultaneously
: -V = 0.5
: -DISTNAME = msoak-${V}
: +
: +GH_ACCOUNT = jpmens
: +GH_PROJECT = msoak
: +GH_TAGNAME = 0.5
: +
: CATEGORIES = net
:
: -HOMEPAGE = https://github.com/jpmens/msoak
Use standard location for GH_* variables in Makefile, no need to set
DISTNAME/HOMEPAGE which are set by default when GH_* are set
: MAINTAINER = Jan-Piet Mens
:
: -# License GPLv2+
: +# GPLv2+
: PERMIT_PACKAGE= Yes
:
: -GH_ACCOUNT = jpmens
: -GH_PROJECT = msoak
: -GH_TAGNAME = ${V}
: +WANTLIB += ${MODLUA_WANTLIB} c config mosquitto
Standard location for WANTLIB, use lua lib name coming from MODULES=lang/lua
:
: -BUILD_DEPENDS = devel/libconfig \
: - net/mosquitto \
: - devel/lua-compat53
: +MODULES =lang/lua
: +MODLUA_SA = Yes
: +NO_TEST =Yes
use MODULES=lang/lua to provide standard variables for lua ports,
set MODLUA_SA because it's a standalone port rather than lua library
(the module has some setup for multiple flavours for multiple lua
versions). set NO_TEST.
: -RUN_DEPENDS =devel/libconfig \
: - net/mosquitto \
: - devel/lua-compat53
: +LIB_DEPENDS =devel/libconfig \
: + net/mosquitto
library dependencies should use LIB_DEPENDS (+WANTLIB) rather
than BUILD+RUN_DEPENDS.
:
: -WANTLIB += c config lua5.1 mosquitto
: +BUILD_DEPENDS = devel/lua-compat53
: +RUN_DEPENDS =devel/lua-compat53
I've left this in for now, but I don't see where lua-compat53 is used,
and it seems to work OK without, if it's not really needed then let's
skip the dependency.
:
: -CFLAGS = -I/usr/local/include -I/usr/local/include/lua-5.1/
: -LDFLAGS =-L /usr/local/lib -llua5.1 -lmosquitto -lconfig
: +CFLAGS +=-I${LOCALBASE}/include -I${MODLUA_INCL_DIR}
: +LDFLAGS =-L${LOCALBASE}/lib ${MODLUA_LIB} -lmosquitto -lconfig
change = to += for CFLAGS - don't override standard flags,
avoid hardcoding paths that are normally set by ports infrastructure.
:
: -
: MAKE_FLAGS= CFLAGS="${CFLAGS}"
: MAKE_FLAGS+= LDFLAGS="${LDFLAGS}"
: -MAKE_FLAGS+= BINDIR=/usr/local/bin
: -MAKE_FLAGS+= MANDIR=/usr/local/man
: +MAKE_FLAGS+= BINDIR=${TRUEPREFIX}/bin
: +MAKE_FLAGS+= MANDIR=${TRUEPREFIX}/man
(LOCALBASE is "from some other port", TRUEPREFIX is "this port")
:
: post-install:
: ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/msoak
I see the Makefile in msoak distribution normally uses lua 5.3,
if you want to do that in the port too then you can just add
MODLUA_VERSION =5.3
- with the change I made to use the lua "MODULES" (the actual file
is found in lang/lua/lua.port.mk) then setting this will change the
paths/libs/dependencies automatically.
msoak,2.tgz
Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/04 15:47:08 Modified files: devel/libmpc : Tag: OPENBSD_6_6 Makefile Log message: fix MASTER_SITES for -stable, from dbar...@cs.williams.edu
[NEW] net/msoak
Hello! This is a new port for msoak(1), a utility with which to simultaneously subscribe to an arbitrary number of topics on any number of MQTT brokers and optionally modify or normalize received payloads with Lua functions before printing them out. I am the author of said utility, too. Tested on 6.6-CURRENT I'm hoping somebody can test this and give me feedback on my first package for OpenBSD! Under the assumption that MQTT is not in everybody's repertoire (why not actually, it's great! :-), I have a short writeup about it at [1]. Thank you and best regards, -JP [1] https://jpmens.net/2013/02/25/lots-of-messages-mqtt-pub-sub-and-the-mosquitto-broker/ msoak.tgz Description: application/tar-gz
new: opensmtpd clamav filter
Hi, after the previous thread back in November has gone sideways, here is another attempt. Please find attached a port for opensmtpd filter-clamav. Please, only port-wise comments. OKs? Thanks, Regards, Joerg clamav.tar.gz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/01/04 10:51:11 Modified files: www/epiphany : Makefile distinfo Log message: update to epiphany-3.34.3.1
Re: [update] sbcl-2.0.0
Ah, sorry I forgot to reply.
The rmdir seems good to me.
I've been doing further testing and with just the upstream patches I
occasionally get the test errors but not always so there seems to be something
there. In addition I have tried to resurrect my futex patch. With following
tweaks it compiles:
In sb-concurrency tests I reduced test-mailbox-producers-consumer test sleep to
0.001
In threads.pure.lisp, remove openbsd from fails-on list on "wait-on-semaphore
semaphore-notification :lp-1038034" as futexes are enabled.
With above I got following test failure:
Failure:threads.pure.lisp / WITHOUT-INTERRUPTS+CONDITION-WAIT
Expected failure: threads.pure.lisp / (WAIT-ON-SEMAPHORE
SEMAPHORE-NOTIFICATION LP-1038034)
Skipped (broken): compiler.impure.lisp / BUG-308921
I really don't have ideas how to proceed debugging the timing issues.
Heres the updated futex patch:
$OpenBSD$
add futex support
Index: src/runtime/bsd-os.c
--- src/runtime/bsd-os.c.orig
+++ src/runtime/bsd-os.c
@@ -86,6 +86,11 @@ static void dragonfly_init();
#ifdef LISP_FEATURE_X86
#include
#endif
+#if defined(LISP_FEATURE_SB_THREAD) && defined(LISP_FEATURE_SB_FUTEX) \
+&& !defined(LISP_FEATURE_SB_PTHREAD_FUTEX)
+#include
+#include
+#endif
static void openbsd_init();
#endif
@@ -690,7 +695,45 @@ os_dlsym(void *handle, const char *symbol)
return ret;
}
+#if defined(LISP_FEATURE_SB_THREAD) && defined(LISP_FEATURE_SB_FUTEX) \
+&& !defined(LISP_FEATURE_SB_PTHREAD_FUTEX)
+
+int
+futex_wait(int *lock_word, int oldval, long sec, unsigned long usec)
+{
+struct timespec timeout;
+int ret;
+
+if (sec < 0) {
+ret = futex(lock_word, FUTEX_WAIT, oldval, NULL, NULL);
+}
+else {
+timeout.tv_sec = sec;
+timeout.tv_nsec = usec * 1000;
+ret = futex(lock_word, FUTEX_WAIT, oldval, , NULL);
+}
+
+switch (ret) {
+case 0:
+return 0;
+case ETIMEDOUT:
+return 1;
+case EINTR:
+return 2;
+default:
+/* EWOULDBLOCK and others, need to check the lock */
+return -1;
+}
+}
+
+int
+futex_wake(int *lock_word, int n)
+{
+return (futex(lock_word, FUTEX_WAKE, n, NULL, NULL));
+}
+
#endif
+#endif /* __OpenBSD__ */
#if defined(LISP_FEATURE_SB_WTIMER) && !defined(LISP_FEATURE_DARWIN)
/*
Josh Elsasser writes:
> On Thu, Jan 02, 2020 at 08:14:10PM +0200, Timo Myyrä wrote:
>
>> Solene Rapenne writes:
>>
>> > On Wed, Jan 01, 2020 at 07:00:45PM +0200, Timo Myyrä wrote:
>> >
>> >> Hi,
>> >>
>> >> Here's an attempt to update sbcl to latest version.
>> >> Before adding the new patch I got consistent test failures in inpure
>> >> timer test
>> >> "(:WITH-TIMEOUT :MANY-AT-THE-SAME-TIME".
>> >>
>> >> After adding the patch to unix.lisp the tests have passed twice on amd64.
>> >> Does this look OK, does the tests work on other platforms?
>> >>
>> >> Timo
>> >>
>> >
>> > I'm ok and will commit it if maintainer is ok too
>>
>> Heres revised diff with upstream backports. I still think we're better off
>> waiting next release so we don't have to include these patches but it can't
>> hurt
>> to test these to see they indeed fix the issue.
>>
>> Tested clisp bootstrapped on amd64 and tests passed.
>>
>> timo
>
> I sent a reply a few days ago but it's gone missing, so let's try again.
>
> The timing-related tests can be a bit fragile, I think the
> gettimeofday() change is only hiding a heisenbug in the tests for
> you. Personally, I think this is a test bug and not a real sbcl
> problem and isn't really worth patching.
>
> Additionally, you've added an empty html doc directory to the
> PLIST. How about this, which rmdir's the directory so it doesn't get
> re-added? I've tested and i386/macppc test results aren't worse.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/sbcl/Makefile,v
> retrieving revision 1.43
> diff -u -r1.43 Makefile
> --- Makefile 16 Sep 2019 06:24:18 - 1.43
> +++ Makefile 2 Jan 2020 18:00:11 -
> @@ -6,7 +6,7 @@
>
> COMMENT= compiler and runtime system for ANSI Common Lisp
>
> -V = 1.5.5
> +V = 2.0.0
> DISTNAME=sbcl-${V}-source
> PKGNAME= sbcl-${V}
> WRKDIST= ${WRKDIR}/sbcl-${V}
> @@ -82,6 +82,7 @@
>
> post-install:
> chown -R 0:0 ${PREFIX}/lib/sbcl
> + rmdir ${PREFIX}/share/doc/sbcl/html
>
> do-test:
> cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} DONT_CLEAN_SBCL_CONTRIB=1 \
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/sbcl/distinfo,v
> retrieving revision 1.18
> diff -u -r1.18 distinfo
> --- distinfo 16 Sep 2019 06:24:18 - 1.18
> +++ distinfo 2 Jan 2020 18:00:11 -
> @@ -1,2 +1,2 @@
> -SHA256 (sbcl-1.5.5-source.tar.bz2) =
> y0f65qhvDFxXQxYE+05fEcioI/lM4SjVaLh3D8W8quI=
> -SIZE (sbcl-1.5.5-source.tar.bz2) = 6351480
Re: [update] sbcl-2.0.0
On Thu, Jan 02, 2020 at 08:14:10PM +0200, Timo Myyrä wrote:
> Solene Rapenne writes:
>
> > On Wed, Jan 01, 2020 at 07:00:45PM +0200, Timo Myyrä wrote:
> >
> >> Hi,
> >>
> >> Here's an attempt to update sbcl to latest version.
> >> Before adding the new patch I got consistent test failures in inpure timer
> >> test
> >> "(:WITH-TIMEOUT :MANY-AT-THE-SAME-TIME".
> >>
> >> After adding the patch to unix.lisp the tests have passed twice on amd64.
> >> Does this look OK, does the tests work on other platforms?
> >>
> >> Timo
> >>
> >
> > I'm ok and will commit it if maintainer is ok too
>
> Heres revised diff with upstream backports. I still think we're better off
> waiting next release so we don't have to include these patches but it can't
> hurt
> to test these to see they indeed fix the issue.
>
> Tested clisp bootstrapped on amd64 and tests passed.
>
> timo
I sent a reply a few days ago but it's gone missing, so let's try again.
The timing-related tests can be a bit fragile, I think the
gettimeofday() change is only hiding a heisenbug in the tests for
you. Personally, I think this is a test bug and not a real sbcl
problem and isn't really worth patching.
Additionally, you've added an empty html doc directory to the
PLIST. How about this, which rmdir's the directory so it doesn't get
re-added? I've tested and i386/macppc test results aren't worse.
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.43
diff -u -r1.43 Makefile
--- Makefile16 Sep 2019 06:24:18 - 1.43
+++ Makefile2 Jan 2020 18:00:11 -
@@ -6,7 +6,7 @@
COMMENT= compiler and runtime system for ANSI Common Lisp
-V =1.5.5
+V =2.0.0
DISTNAME= sbcl-${V}-source
PKGNAME= sbcl-${V}
WRKDIST= ${WRKDIR}/sbcl-${V}
@@ -82,6 +82,7 @@
post-install:
chown -R 0:0 ${PREFIX}/lib/sbcl
+ rmdir ${PREFIX}/share/doc/sbcl/html
do-test:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} DONT_CLEAN_SBCL_CONTRIB=1 \
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.18
diff -u -r1.18 distinfo
--- distinfo16 Sep 2019 06:24:18 - 1.18
+++ distinfo2 Jan 2020 18:00:11 -
@@ -1,2 +1,2 @@
-SHA256 (sbcl-1.5.5-source.tar.bz2) =
y0f65qhvDFxXQxYE+05fEcioI/lM4SjVaLh3D8W8quI=
-SIZE (sbcl-1.5.5-source.tar.bz2) = 6351480
+SHA256 (sbcl-2.0.0-source.tar.bz2) =
kDaSVoBdQ3yCq5vauaQQB29XgQpQuysijeTmyJJpL88=
+SIZE (sbcl-2.0.0-source.tar.bz2) = 6457217
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/01/04 07:49:15 Modified files: www/chromium : Makefile www/chromium/patches: patch-chrome_browser_about_flags_cc patch-chrome_browser_flag_descriptions_cc patch-chrome_browser_flag_descriptions_h patch-chrome_browser_ui_views_frame_browser_view_cc patch-ui_compositor_compositor_cc Added files: www/chromium/patches: patch-chrome_browser_memory_details_linux_cc Log message: unbreak chrome://system by not trying to get the amount of used file descriptors through the metrics code so that a pledge violation is avoided if the sandbox is enabled (which is the default)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/01/04 06:52:08 Modified files: textproc/highlight: Makefile distinfo textproc/highlight/patches: patch-src_makefile textproc/highlight/pkg: PLIST Log message: Update to highlight-3.54.
Re: UPDATE: graphviz-2.40.1
On Thu, Jan 02, 2020 at 02:02:22PM +, Stuart Henderson wrote:
> OK so in that case I think you can get rid of specifically-Tk-related things
> (--with-wish, TKCONFIG=) and change the other from Tk to Tcl.
Indeed. I realised that I attached the wrong diff last time!
I think the following is correct:
Index: Makefile
===
RCS file: /cvs/ports/math/graphviz/Makefile,v
retrieving revision 1.76
diff -u -p -r1.76 Makefile
--- Makefile18 Nov 2019 19:57:44 - 1.76
+++ Makefile4 Jan 2020 13:48:12 -
@@ -2,8 +2,7 @@
COMMENT-main= graph drawing software
-DISTNAME= graphviz-2.36.0
-REVISION= 14
+DISTNAME= graphviz-2.42.3
PKGNAME-main= ${DISTNAME}
CATEGORIES=math devel graphics
@@ -14,30 +13,32 @@ MULTI_PACKAGES= -main
# to let update-patches work in a simpler way
PATCHORIG= .orig2
-MASTER_SITES= ${HOMEPAGE}pub/graphviz/ARCHIVE/
+MASTER_SITES= https://www2.graphviz.org/Packages/stable/portable_source/
-SHARED_LIBS += gvplugin_core 1.0 # 6.0
-SHARED_LIBS += gvplugin_gd 1.0 # 6.0
-SHARED_LIBS += gvplugin_pango 1.0 # 6.0
-SHARED_LIBS += gvplugin_dot_layout 1.0 # 6.0
-SHARED_LIBS += gvplugin_neato_layout 1.0 # 6.0
-SHARED_LIBS += gvplugin_xlib 1.0 # 6.0
-SHARED_LIBS += gvplugin_gtk1.0 # 6.0
-SHARED_LIBS += gvplugin_rsvg 0.0 # 6.0
-SHARED_LIBS += gvplugin_gdk0.0 # 6.0
-SHARED_LIBS += gvplugin_poppler0.0 # 6.0
-
-SHARED_LIBS += cdt 1.0 # 5.0
-SHARED_LIBS += pathplan2.0 # 4.0
-SHARED_LIBS += gvc 1.0 # 6.0
-SHARED_LIBS += cgraph 0.0 # 6.0
-SHARED_LIBS += gvpr0.0 # 2.0
-SHARED_LIBS += xdot0.0 # 4.0
-SHARED_LIBS += gdtclft 3.0 # unknown
-SHARED_LIBS += tcldot 3.0 # unknown
-SHARED_LIBS += tcldot_builtin 3.0 # unknown
-SHARED_LIBS += tclplan 3.0 # unknown
-SHARED_LIBS += tkspline3.0 # unknown
+SHARED_LIBS += gvplugin_core 2.0 # 6.0
+SHARED_LIBS += gvplugin_gd 2.0 # 6.0
+SHARED_LIBS += gvplugin_pango 2.0 # 6.0
+SHARED_LIBS += gvplugin_dot_layout 2.0 # 6.0
+SHARED_LIBS += gvplugin_neato_layout 2.0 # 6.0
+SHARED_LIBS += gvplugin_xlib 2.0 # 6.0
+SHARED_LIBS += gvplugin_gtk2.0 # 6.0
+SHARED_LIBS += gvplugin_rsvg 1.0 # 6.0
+SHARED_LIBS += gvplugin_gdk1.0 # 6.0
+SHARED_LIBS += gvplugin_poppler1.0 # 6.0
+SHARED_LIBS += gvplugin_visio 0.0 # 6.0
+SHARED_LIBS += gvplugin_webp 0.0 # 6.0
+
+SHARED_LIBS += cdt 2.0 # 5.0
+SHARED_LIBS += pathplan3.0 # 4.0
+SHARED_LIBS += gvc 2.0 # 6.0
+SHARED_LIBS += cgraph 1.0 # 6.0
+SHARED_LIBS += gvpr1.0 # 2.0
+SHARED_LIBS += xdot1.0 # 4.0
+SHARED_LIBS += gdtclft 4.0 # unknown
+SHARED_LIBS += tcldot 4.0 # unknown
+SHARED_LIBS += tcldot_builtin 4.0 # unknown
+SHARED_LIBS += tclplan 4.0 # unknown
+SHARED_LIBS += lab_gamut 0.0 # 1.0
HOMEPAGE= http://www.graphviz.org/
@@ -47,18 +48,21 @@ MAINTAINER =Edd Barrett
Index: distinfo
===
RCS file: /cvs/ports/math/graphviz/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo6 Feb 2014 17:32:27 - 1.7
+++ distinfo2 Jan 2020 14:32:05 -
@@ -1,2 +1,2 @@
-SHA256 (graphviz-2.36.0.tar.gz) = N/1m2N7xWFdcdcT22/U2g55O5GiqWTFOtHLRrssHY2E=
-SIZE (graphviz-2.36.0.tar.gz) = 23846318
+SHA256 (graphviz-2.42.3.tar.gz) = j68/wlMXsdFRZiBb9kwbSu1VqKaVncq6pk260Zfket0=
+SIZE (graphviz-2.42.3.tar.gz) = 26246717
Index: files/config6
===
RCS file: /cvs/ports/math/graphviz/files/config6,v
retrieving revision 1.2
diff -u -p -r1.2 config6
--- files/config6 6 Feb 2014 17:32:27 - 1.2
+++ files/config6 4 Jan 2020 13:30:52 -
@@ -6,123 +6,128 @@
# Manual edits to this file **will be lost** on upgrade.
-libgvplugin_gd.so.${LIBgvplugin_gd_VERSION} gd {
- render {
- gd 1
- }
- render {
- vrml 1
+libgvplugin_core.so.${LIBgvplugin_core_VERSION} core {
+ device {
+ dot:dot 1
+ gv:dot 1
+ canon:dot 1
+ plain:dot 1
+ plain-ext:dot 1
+ xdot:xdot 1
+ xdot1.2:xdot 1
+ xdot1.4:xdot 1
}
- textlayout {
- textlayout 2
+ device {
+ fig:fig 1
}
- loadimage {
- gd:gd 1
- gd2:gd 1
- gif:gd 1
-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 05:30:41 Modified files: x11/gnome/maps : Makefile distinfo x11/gnome/maps/pkg: PLIST Log message: Update to gnome-maps-3.34.3.
Re: [PATCH] Firefox - Fix Japanese input by expanding unveiled directories
On Sat, Jan 04, 2020 at 12:53:23PM +0900, Bryan Linton wrote: > Hello ports@ > > After upgrading to Firefox 71, I was no longer able to input > Japanese due to the newly-added unveil and pledge support. After > some debugging, I found that adding the following lines to > /etc/firefox/unveil.main allowed me to input Japanese as usual. > > -8<-- > --- /usr/local/lib/firefox/browser/defaults/preferences/unveil.main Sat Dec > 21 15:08:23 2019 > +++ /etc/firefox/unveil.main Fri Jan 3 12:25:53 2020 > @@ -3,6 +3,12 @@ > /dev/video rw > /dev/video0 rw > > +# for launching the anthy input method from uim > +/etc/anthy-conf r > +~/.anthy r > +~/.tomoe r > +~/.uim.d r > + > /etc/fonts r > /etc/machine-id r > -8<-- > > However, this raises some interesting questions. How far down > this path do we want to go? The above patch enables the UIM+Anthy > combination to work again, but what about SCIM+Anthy? Ibus+Anthy? > SCIM+Pinyin? There are 26 ports in ports/inputmethods; do all of > them get added to unveil.main? > > While I'm aware that adding every possible contingency to unveil > largely defeats its purpose, I'm also concerned that the > alternative would be users simply disabling pledge+unveil > entirely if they find that they can no longer input CJK text. > > Which then brings us full circle to the security model of unveil > being defeated... Let's be practical here. It's already a pain in the ass to figure out how to input non-european scripts into programs. So if you add one more step, people are very likely to just disable unveil. I say we should go for what people actually use AND can test. So, you're using one specific method to input japanese characters. Let's start with adding THAT one. And let's tell people (on this ml, or possibly in the README) to chime in with whatever method they are using. That way, we get a set of unveil that actually gets tested by actual users.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 05:17:15 Modified files: mail/evolution-ews: Makefile distinfo Log message: Update to evolution-ews-3.34.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 05:16:50 Modified files: databases/evolution-data-server: Makefile distinfo Log message: Update to evolution-data-server-3.34.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 05:17:04 Modified files: mail/evolution : Makefile distinfo Log message: Update to evolution-3.34.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/04 04:50:30 Modified files: lang/php/7.2 : distinfo lang/php/7.3 : distinfo Log message: unbreak, sorry naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 04:34:58 Modified files: net/glib2-networking: Makefile distinfo Log message: Update to glib2-networking-2.62.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/04 04:09:54 Modified files: graphics/shotwell: Makefile distinfo graphics/shotwell/pkg: PLIST Log message: Update to shotwell-0.30.8.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/01/04 03:51:59 Modified files: games/rocksndiamonds: Makefile distinfo games/rocksndiamonds/pkg: PLIST Log message: Update to rocksndiamonds-4.1.4.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/01/04 03:36:32 Modified files: databases/p5-Redis: Makefile distinfo Log message: Update to p5-Redis-1.995.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: an...@cvs.openbsd.org 2020/01/04 02:32:36 Modified files: mail/mdsort: Makefile distinfo Log message: Update to mdsort-5.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/01/04 02:30:20 Modified files: emulators/stella: Makefile distinfo Log message: Update to stella-6.0.2.
Re: [PATCH] Firefox - Fix Japanese input by expanding unveiled directories
On Sat, Jan 04, 2020 at 12:53:23PM +0900, Bryan Linton wrote: > Hello ports@ > > After upgrading to Firefox 71, I was no longer able to input > Japanese due to the newly-added unveil and pledge support. After > some debugging, I found that adding the following lines to > /etc/firefox/unveil.main allowed me to input Japanese as usual. > > -8<-- > --- /usr/local/lib/firefox/browser/defaults/preferences/unveil.main Sat Dec > 21 15:08:23 2019 > +++ /etc/firefox/unveil.main Fri Jan 3 12:25:53 2020 > @@ -3,6 +3,12 @@ > /dev/video rw > /dev/video0 rw > > +# for launching the anthy input method from uim > +/etc/anthy-conf r > +~/.anthy r > +~/.tomoe r > +~/.uim.d r > + > /etc/fonts r > /etc/machine-id r > -8<-- > > However, this raises some interesting questions. How far down > this path do we want to go? The above patch enables the UIM+Anthy > combination to work again, but what about SCIM+Anthy? Ibus+Anthy? > SCIM+Pinyin? There are 26 ports in ports/inputmethods; do all of > them get added to unveil.main? > > While I'm aware that adding every possible contingency to unveil > largely defeats its purpose, I'm also concerned that the > alternative would be users simply disabling pledge+unveil > entirely if they find that they can no longer input CJK text. > > Which then brings us full circle to the security model of unveil > being defeated... > > That being the case, perhaps adding a short blurb like the > following to Firefox's pkg-readme would be a better way to go. I dont have a preference between those, and i'm fine with each of them.
