Re: Care and Feeding
On Sun, Sep 29, 2019 at 6:15 AM Markus Lude wrote: > I don't understand what your goal is. My goal was to make a tf5 port, but since I use a shell script (involving xterm and nc) more often than I use tf5 these days (though I still use tf5, especially on lower-end machines) I think I'll just let things stay as they are now, and not do anything as for this. > Now you want tf 4 removed? I was mostly just curious how OpenBSD people handle abandoned software in ports. (both tf5 and tf4 are equally abandoned)
Re: Add rc file for nfcapd and a stubREADME
On 2019/09/29 16:26, Ville Valkonen wrote: > Week+ ping? Cc'ing Stuart as he's the maintainer of nfdump port. Yes you should definitely cc the maintainer - but no diff, and the inline parts in the quoted mail are not usable directly (missing headers, hardcoded paths that should come from variables)..
new: devel/py-rencode
Simple port that is required as dependency for my upcoming update of net/deluge to 2.0.3. Builds fine on amd64, deluge is happy so far and all 41 tests pass. OK? Information for inst:py3-rencode-1.0.6 Comment: module for fast object serialization similar to bencode Description: The rencode module is similar to bencode from the BitTorrent project. For complex, heterogeneous data structures with many small elements, r-encodings take up significantly less space than b-encodings. This version of rencode is a complete rewrite in Cython to attempt to increase the performance over the pure Python module written by Petru Paler, Connelly Barnes et al. Maintainer: The OpenBSD ports mailing-list WWW: https://github.com/aresch/rencode py-rencode.tgz Description: Binary data
Re: Epson ESC/P-R driver
On 2019/09/29 11:19, Antoine Jacoutot wrote: > I am also taking MAINTAINER (like I do with most (all?) print ports). You have done a great job with hplip! Regards,
Neovim update and new libluv port
Hi there,
I wanted Neovim 0.4.2 so I took the liberty of figuring out what it would take
to update the port.
I've included:
* A new port of libluv:
- Neovim now depends on libluv
- (See https://github.com/neovim/neovim/wiki/Following-HEAD) so I had
to
create a new port which I've attached.
* A patch to update unibilium to 2.0.0
- Unibilium has been forked and moved under the neovim github org so
I'm pointing at that.
* A patch to update libvterm to the latest git sha on the nvim branch.
- It seems that no other ports depend on libvterm, so it made sense to
use
the nvim branch.
- I updated the patch to bin/vterm-ctrl.c. Upstream hasn't integrated
the
previous patch and the code has drifted quite a lot.
* A patch to update neovim to v0.4.2
- Removed patch-src_nvim_os_process_c - I believe it was fixed upstream
here:
https://github.com/neovim/neovim/commit/6e01ed6a4c859ff915b42422622f1ba3cc80efd5
- make test completes with no failures
I've tested this on amd64 -CURRENT from yesterday and ran through the porting
and update checklists.
Happy to hear any feedback.
thanks!
Patches ahead.
unibilium.diff:
diff --git Makefile Makefile
index ddf0f1846db..1b0109fdb67 100644
--- Makefile
+++ Makefile
@@ -1,14 +1,14 @@
# $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
COMMENT = very basic terminfo library
-VERSION = 1.2.0
+VERSION = 2.0.0
DISTNAME = unibilium-${VERSION}
-GH_ACCOUNT = mauke
+GH_ACCOUNT = neovim
GH_PROJECT = unibilium
GH_TAGNAME = v${VERSION}
-SHARED_LIBS += unibilium 0.0 # 3.0
+SHARED_LIBS += unibilium 1.0 # 3.0
CATEGORIES = devel
diff --git distinfo distinfo
index 61047b4ed65..b531af481ad 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-1.2.0.tar.gz) = YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
-SIZE (unibilium-1.2.0.tar.gz) = 88488
+SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
+SIZE (unibilium-2.0.0.tar.gz) = 112570
libvterm.diff
diff --git Makefile Makefile
index 006367688e9..e79baa11807 100644
--- Makefile
+++ Makefile
@@ -1,16 +1,17 @@
-# $OpenBSD:
+# $OpenBSD: $
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20190910
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT =224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# commit sha from the nvim branch
+GH_COMMIT =4a5fa43e0dbc0db4fe67d40d788d60852864df9e
-SHARED_LIBS += vterm 0.0 # 0.0
+SHARED_LIBS += vterm 0.1 # 0.0
CATEGORIES = devel
diff --git distinfo distinfo
index 63c4d8e0322..9d064239eef 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20190910-4a5fa43e.tar.gz) =
SbPPLcuYi4h2cbEBHP6smP+Bu1wj+0rDS5GllSSZKTU=
+SIZE (libvterm-20190910-4a5fa43e.tar.gz) = 72448
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571b9ff..aa951f474a8 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD: $
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+-char c = csi[i] = getchar();
++int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+-char c = getchar();
++int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
neovim.diff:
diff --git Makefile Makefile
index e9b174a4512..3680334ad7c 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
Re: [NEW] comms/pterm-6.0.4
Stuart Henderson wrote: > tar is mangled (sent as text/plain). > > On 2019/09/28 10:31, trondd wrote: > > Bump to the top. > > > > No retro-computing/BBS nostalgia here? :P > > > > Thanks. > > Tim. > > > > On Sat, September 21, 2019 5:32 pm, trondd wrote: > > > New port of comms/pterm, aka PLATOterm. > > > > > > PLATO is a BBS-like system with roots in training and education but grew > > > into a community through muti-user games, messaging, and chat. There's > > > been a resurgence the past few years with effort from IRATA.online and > > > ports of pterm to different OS's and retro-computers. > > > > > > The binary is officially 'pterm' but I had to rename it to 'platoterm' as > > > putty already has a pterm binary. > > > > > > Only been able to test on amd64. Don't know how to test the floppy > > > support yet, either. > > > > > > Default connection is to cyber1's system, but IRATA.online is free to sign > > > up and also has a guest account for checking it out. If you want to try > > > it, be sure to know the PLATO terminal keyoard maping to a PC keyboard: > > > https://cyber1.org/keyboard.asp (it's also in pterm's help menu) > > > > > > Tim. > > > > > > DESCR: > > > Pterm is a terminal emulator designed for connecting to PLATO-like > > > systems such as Cyber1 and the Cybis release from Tom Hunter. It also > > > has the ability to run MicroTutor from floppy disk images. > > > > > > PLATO is a multi-user system hosting games, educational material, and > > > communities. A PLATO server is hosted at IRATA.online with free access > > > and a CYBIS system is hosted at cyber1.org > Ughsorry. pterm-6.0.4.tgz Description: application/gzip
Re: chromium-77.0.3865.90 and Aw, Snap! everywhere
Latest amd64 package snapshot has chromium-77.0.3865.90p1 available which includes fixes by robert@ and it works now. Thank you. -- Regards, Mikolaj
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/29 12:09:38 Modified files: mail/exim : Tag: OPENBSD_6_5 Makefile distinfo Log message: security update to exim-4.92.3; ok Renaud Allard (maintainer) "There is a heap-based buffer overflow in string_vformat (string.c). The currently known exploit uses a extraordinary long EHLO string to crash the Exim process that is receiving the message. While at this mode of operation Exim already dropped its privileges, other paths to reach the vulnerable code may exist."
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/29 12:08:55 Modified files: mail/exim : Makefile distinfo Log message: security update to exim-4.92.3; ok Renaud Allard (maintainer) "There is a heap-based buffer overflow in string_vformat (string.c). The currently known exploit uses a extraordinary long EHLO string to crash the Exim process that is receiving the message. While at this mode of operation Exim already dropped its privileges, other paths to reach the vulnerable code may exist."
update print/poppler
Hi, this updates poppler to 0.51.0. Only the main poppler library has changed (some #ifdefs removed at other places because CMYK rasterization is no longer optional). From the Changlog: * Splash: Always enable support for CMYK rasterization * CairoOutputDev: Check scaled dimensions for 0. Issue #737 * BaseCryptStream: Fix potential uninitialized memory read * SplashBitmap: Fix wrong width condition for splashModeDeviceN8 * Fix crashes in malformed files My build machine is too slow, so I didn't yet have a change to test it. So if anyone else wants to beat me and give it a try... Ciao, Kil Index: Makefile === RCS file: /cvs/ports/print/poppler/Makefile,v retrieving revision 1.148 diff -u -p -r1.148 Makefile --- Makefile15 Sep 2019 21:29:40 - 1.148 +++ Makefile29 Sep 2019 17:43:49 - @@ -4,9 +4,8 @@ COMMENT-main= PDF rendering library COMMENT-qt5= Qt5 interface to PDF rendering library COMMENT-utils= PDF conversion tools and utilities -V= 0.80.0 +V= 0.81.0 DISTNAME= poppler-$V -REVISION-main= 1 CATEGORIES=print PKGNAME-main= poppler-$V PKGNAME-utils= poppler-utils-$V @@ -14,7 +13,7 @@ PKGNAME-qt5= poppler-qt5-$V EXTRACT_SUFX= .tar.xz -SHARED_LIBS += poppler 55.0 # 90.0 +SHARED_LIBS += poppler 56.0 # 91.0 SHARED_LIBS += poppler-glib 19.3 # 8.14 SHARED_LIBS += poppler-qt5 7.3 # 1.21 SHARED_LIBS += poppler-cpp 11.0 # 0.7 Index: distinfo === RCS file: /cvs/ports/print/poppler/distinfo,v retrieving revision 1.75 diff -u -p -r1.75 distinfo --- distinfo10 Sep 2019 13:52:42 - 1.75 +++ distinfo29 Sep 2019 17:43:49 - @@ -1,2 +1,2 @@ -SHA256 (poppler-0.80.0.tar.xz) = TTymt5vBO44kCS40+D7184fzuwu9c1mmwHjgnGltEE8= -SIZE (poppler-0.80.0.tar.xz) = 1548908 +SHA256 (poppler-0.81.0.tar.xz) = IS0CCwNbZ7Nslma9CKx3jf8yIthcAcM4eH1Ubw+b/gI= +SIZE (poppler-0.81.0.tar.xz) = 1548944
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/09/29 11:41:52 Modified files: graphics/evince: Makefile distinfo Log message: update to evince-3.32.1
Re: add pledge to devel/cvsweb
Hi Solene, Solene Rapenne wrote on Thu, Sep 26, 2019 at 05:27:08PM +0200: > Hi, now that we have OpenBSD::pledge I thought it would be nice to use > it in devel/cvsweb I think this is a thoroughly bad idea. Pledge is useful for well-understood high-quality code. But CVSweb, at this point, is very old, barely maintained, low-quality code. With such code, adding pledge is mostly calling for trouble in the form of crashes that result from unexpected, but required behaviour. Besides, the CVSweb we have in ports is an old version: 2.0.6 (September 2002) plus patches. The latest upstream version is 3.0.6 (September 2005), but upstream is long dead. Doing new development in the form of patches to the port looks like a very bad idea. Some time ago, i set up a new upstream: http://mandoc.bsd.lv/cvsweb/ I admit i got distracted, but i hope to return to it. If we want to improve CVSweb (which i do think makes sense), then the proper course of action, i think, is to 1. Commit such improvements as can be easily done and are quite useful to the FreeBSD-cvsweb-2_0-branch. Possibly, pledge can be part of that if we are really sure we understand what all the code does. Otherwise, i think step 6 below is the proper time for adding pledge. 2. Release 2.0.7 from that branch. This can be a short-term goal, the only reason it didn't happen yet is that i got distracted. 3. Update the port to 2.0.7. 4. Update the bsd.lv and possibly cvsweb.openbsd.org servers to 2.0.7. 5. Merge 2.0.7 into the MAIN branch (4.x revision numbers). 6. Develop and release cvsweb-4.0.0 as a medium-term project. 7. Update the port to 4.0.0. 8. Update the two servers. If you want to help with that, i'm happy to give you commit access to the upstream repository on mandoc.bsd.lv. If other porters think that solene's work should be committed directly to the port, i don't veto that, but i do not consider it useful either. I doubt that any running server will update to a new version of the port before the release of 2.0.7. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/09/29 11:19:29 Modified files: infrastructure/lib/DPB/Core: Init.pm Log message: optimization: no need to compute library signatures in fetch_only mode
math/coq: fix plist for bytecode-only build
Hi,
for building bytecode-only coq I need the following patch. (Did I send
you this before? I misconfigured my mail client.) OK?
Christopher
Index: Makefile
===
RCS file: /cvs/ports/math/coq/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- Makefile27 Sep 2019 09:58:09 - 1.45
+++ Makefile28 Sep 2019 18:39:38 -
@@ -3,6 +3,7 @@
COMMENT= proof assistant based on a typed lambda calculus
V= 8.10+beta3
+REVISION = 0
GH_ACCOUNT = coq
GH_PROJECT = coq
GH_TAGNAME = V${V}
Index: pkg/PFRAG.native
===
RCS file: /cvs/ports/math/coq/pkg/PFRAG.native,v
retrieving revision 1.5
diff -u -p -r1.5 PFRAG.native
--- pkg/PFRAG.native20 Sep 2019 03:28:34 - 1.5
+++ pkg/PFRAG.native28 Sep 2019 18:39:38 -
@@ -578,6 +578,7 @@ lib/ocaml/coq/proofs/refine.cmx
lib/ocaml/coq/proofs/refiner.cmx
lib/ocaml/coq/proofs/tacmach.cmx
lib/ocaml/coq/proofs/tactypes.cmx
+lib/ocaml/coq/revision
lib/ocaml/coq/stm/asyncTaskQueue.cmx
lib/ocaml/coq/stm/coqworkmgrApi.cmx
lib/ocaml/coq/stm/dag.cmx
@@ -1461,6 +1462,7 @@ lib/ocaml/coq/theories/ZArith/.coq-nativ
lib/ocaml/coq/theories/ZArith/.coq-native/NCoq_ZArith_Zwf.o
lib/ocaml/coq/theories/ZArith/.coq-native/NCoq_ZArith_auxiliary.cmx
lib/ocaml/coq/theories/ZArith/.coq-native/NCoq_ZArith_auxiliary.o
+lib/ocaml/coq/topbin/
lib/ocaml/coq/topbin/coqc_bin.cmx
lib/ocaml/coq/topbin/coqproofworker_bin.cmx
lib/ocaml/coq/topbin/coqqueryworker_bin.cmx
Index: pkg/PFRAG.no-native
===
RCS file: /cvs/ports/math/coq/pkg/PFRAG.no-native,v
retrieving revision 1.1
diff -u -p -r1.1 PFRAG.no-native
--- pkg/PFRAG.no-native 4 Mar 2019 12:51:15 - 1.1
+++ pkg/PFRAG.no-native 28 Sep 2019 18:39:38 -
@@ -1,10 +1,11 @@
@comment $OpenBSD: PFRAG.no-native,v 1.1 2019/03/04 12:51:15 chrisz Exp $
lib/ocaml/coq/clib/clib.cma
+lib/ocaml/coq/config/config.cma
lib/ocaml/coq/dev/top_printers.cmi
lib/ocaml/coq/engine/engine.cma
+lib/ocaml/coq/gramlib/.pack/gramlib.cma
lib/ocaml/coq/ide/ide.cma
lib/ocaml/coq/interp/interp.cma
-lib/ocaml/coq/intf/intf.cma
lib/ocaml/coq/kernel/kernel.cma
lib/ocaml/coq/lib/lib.cma
lib/ocaml/coq/library/library.cma
@@ -24,6 +25,7 @@ lib/ocaml/coq/plugins/extraction/.coq-na
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrHaskellZInt.cmo
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrHaskellZInteger.cmo
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrHaskellZNum.cmo
+lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrOCamlInt63.cmo
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrOcamlBasic.cmo
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrOcamlBigIntConv.cmo
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_ExtrOcamlIntConv.cmo
@@ -35,17 +37,17 @@ lib/ocaml/coq/plugins/extraction/.coq-na
lib/ocaml/coq/plugins/extraction/.coq-native/NCoq_extraction_Extraction.cmo
lib/ocaml/coq/plugins/extraction/extraction_plugin.cmo
lib/ocaml/coq/plugins/firstorder/ground_plugin.cmo
-lib/ocaml/coq/plugins/fourier/.coq-native/NCoq_fourier_Fourier.cmo
-lib/ocaml/coq/plugins/fourier/.coq-native/NCoq_fourier_Fourier_util.cmo
-lib/ocaml/coq/plugins/fourier/fourier_plugin.cmo
lib/ocaml/coq/plugins/funind/.coq-native/NCoq_funind_FunInd.cmo
lib/ocaml/coq/plugins/funind/.coq-native/NCoq_funind_Recdef.cmo
lib/ocaml/coq/plugins/funind/recdef_plugin.cmo
lib/ocaml/coq/plugins/ltac/.coq-native/NCoq_ltac_Ltac.cmo
lib/ocaml/coq/plugins/ltac/ltac_plugin.cmo
lib/ocaml/coq/plugins/ltac/tauto_plugin.cmo
+lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_DeclConstant.cmo
lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Env.cmo
lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_EnvRing.cmo
+lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Fourier.cmo
+lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Fourier_util.cmo
lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Lia.cmo
lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Lqa.cmo
lib/ocaml/coq/plugins/micromega/.coq-native/NCoq_micromega_Lra.cmo
@@ -69,11 +71,6 @@ lib/ocaml/coq/plugins/omega/.coq-native/
lib/ocaml/coq/plugins/omega/.coq-native/NCoq_omega_OmegaTactic.cmo
lib/ocaml/coq/plugins/omega/.coq-native/NCoq_omega_PreOmega.cmo
lib/ocaml/coq/plugins/omega/omega_plugin.cmo
-lib/ocaml/coq/plugins/quote/.coq-native/NCoq_quote_Quote.cmo
-lib/ocaml/coq/plugins/quote/quote_plugin.cmo
-lib/ocaml/coq/plugins/romega/.coq-native/NCoq_romega_ROmega.cmo
-lib/ocaml/coq/plugins/romega/.coq-native/NCoq_romega_ReflOmegaCore.cmo
-lib/ocaml/coq/plugins/romega/romega_plugin.cmo
lib/ocaml/coq/plugins/rtauto/.coq-native/NCoq_rtauto_Bintree.cmo
Re: [NEW/WIP] Zola 0.8.0
Hi ports@,
Is there any more feedback or possibly a second Ok for import on this?
Peter
On Wed, Sep 11, 2019 at 11:17 AM Peter Ezetta wrote:
> Package builds fine on my amd64 machine with your changes in place. ldd
> shows that libsass is being included dynamically now. Tests still pass,
> and the application still seems to work fine.
> Thanks for your help!
>
> Peter
>
> On Sun, Sep 8, 2019 at 4:46 AM Sebastien Marie wrote:
>
>> On Thu, Sep 05, 2019 at 01:16:12PM -0700, Peter Ezetta wrote:
>> >
>> > It turns out that build.rs is doing a check for the existance of
>> libsass
>> > before it goes building it's own. I have added www/libsass to
>> > BUILD_DEPENDS and RUN_DEPENDS, as well as adding sass to WANTLIB. This
>> > allows the build to complete without setting a COMPILER, or patching the
>> > libsass Makefile.
>> >
>>
>> for reference, when a library is statically linked (like what
>> sass-sys crate do by default), WANTLIB addition is not need ("make
>> port-lib-depends-check" should complain), and the library is only need
>> at build time (so added in BUILD_DEPENDS) and not at runtime (not need
>> in RUN_DEPENDS).
>>
>> here, we could do a bit better, and link to libsass.so dynamically (it
>> will be more simple when libsass.so would be updated in port tree: else
>> www/zola would need a REVISION bump to force an update with the new
>> libsass).
>>
>> to do that, we need to pass PKG_CONFIG_ALL_DYNAMIC=1 to cargo
>> environment (it is a configuration knob for pkg_config crate).
>>
>> and next, www/libsass should be in LIB_DEPENDS and sass in WANTLIB.
>>
>> > Bumped libc version and added it to MODCARGO_CRATES_UPDATE. I do not
>> > have access to a sparc64 machine to test the build though.
>>
>> the bulk build will test it, and I will take care of it if it fails. the
>> port doesn't have reverse-dependencies, so if it breaks on sparc64 it
>> isn't a big problem.
>>
>>
>> I attached a new tarball, which is ok semarie@ for importing if someone
>> else want to look at.
>>
>> Diff from your previous version below.
>>
>> Thanks.
>> --
>> Sebastien Marie
>>
>> diff -ur a/zola/Makefile b/zola/Makefile
>> --- a/zola/Makefile Thu Sep 5 20:58:43 2019
>> +++ b/zola/Makefile Sun Sep 8 13:30:57 2019
>> @@ -19,10 +19,11 @@
>> # MIT
>> PERMIT_PACKAGE = Yes
>>
>> -BUILD_DEPENDS =www/libsass
>> -RUN_DEPENDS = www/libsass
>> +WANTLIB += c c++abi crypto m pthread ssl sass
>>
>> -WANTLIB += c c++abi crypto m pthread ssl sass
>> +LIB_DEPENDS += www/libsass
>> +
>> +MAKE_ENV +=PKG_CONFIG_ALL_DYNAMIC=1
>>
>> MODULES = devel/cargo
>>
>>
Re: Add rc file for nfcapd and a stubREADME
Week+ ping? Cc'ing Stuart as he's the maintainer of nfdump port. On Thu 19. Sep 2019 at 7.09, Ville Valkonen wrote: > > On Thu, 19 Sep 2019 at 0.09, Raf Czlonka wrote: > >> On Wed, Sep 18, 2019 at 08:23:28PM BST, Ville Valkonen wrote: >> > >> > It should be noted that nfcapd can fill disk rather quickly in vibrant >> network >> > environments. Therefore it's important to flush the flow stats every >> now and >> > then. One could use the following root's crontab entry to expire flows >> older >> > than 31 days: >> > @daily /usr/local/bin/nfexpire -t 31d /var/cache/nfcapd 2>&1 >> > > /dev/null >> > >> >> The above should read: >> >> @daily /usr/local/bin/nfexpire -t 31d /var/cache/nfcapd >> >/dev/null 2>&1 >> >> Order matters here. >> >> Regards, >> >> Raf > > > Hello, > > you are right, I was sloppy on that part. Thanks. > > -- > Ville > >> >>
Re: Epson ESC/P-R driver
> I'm not sure why they added patch-lib_epson-typedefs_h, it doesn't fix any > warnings and may break arm/powerpc so I'd prefer to drop that unless you have > an idea? > > Otherwise OK but I don't have an epson printer to test. It would definitely be > nice to have this in ports. Committed with patch-lib_epson-typedefs_h removed. Thank you all. -- Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 07:41:11 Modified files: print/foo2zjs : Makefile distinfo print/foo2zjs/patches: patch-Makefile patch-getweb_in print/foo2zjs/pkg: PLIST Log message: Update to foo2zjs-20190909.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 07:36:28 Modified files: print/splix: Makefile print/splix/patches: patch-Makefile patch-rules_mk Added files: print/splix/patches: patch-ppd_samsung_drv_in patch-ppd_xerox_drv_in Log message: Fix printer IDs and pass LDFLAGS (from Fedora). Regen WANTLIB while here.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 07:25:15 Modified files: print/cups : Makefile print/cups/pkg : README-main Log message: Mention a couple more printer backends.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 07:22:55 Modified files: print : Makefile Log message: +epson-inkjet-printer-escpr
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 07:22:29 Log message: Import epson-inkjet-printer-escpr-1.7.3. This is a filter program for use with CUPS (Common UNIX Printing System) offering high quality printing with Seiko Epson colour ink jet printers. It can only be used with printers that support the Epson ESC/P-R language. most of the porting work done by sthen@ most patches from FreeBSD ok sthen@ Status: Vendor Tag: ajacoutot Release Tags: ajacoutot_20190929 N ports/print/epson-inkjet-printer-escpr/Makefile N ports/print/epson-inkjet-printer-escpr/distinfo N ports/print/epson-inkjet-printer-escpr/patches/patch-lib_epson-escpr-api-private_h N ports/print/epson-inkjet-printer-escpr/patches/patch-lib_epson-escpr-api_c N ports/print/epson-inkjet-printer-escpr/patches/patch-lib_epson-usb_c N ports/print/epson-inkjet-printer-escpr/patches/patch-src_filter_c N ports/print/epson-inkjet-printer-escpr/patches/patch-src_linux_cmn_c N ports/print/epson-inkjet-printer-escpr/patches/patch-src_mem_c N ports/print/epson-inkjet-printer-escpr/patches/patch-src_wrapper_c N ports/print/epson-inkjet-printer-escpr/pkg/DESCR N ports/print/epson-inkjet-printer-escpr/pkg/PLIST No conflicts created by this import
Re: [patch] security/keyringer
On Sun, Sep 29, 2019 at 02:19:42PM +0200, Jeremie Courreges-Anglas wrote: > > Hi, > > when using keyringer I noticed some "usage:" warnings coming from > /usr/bin/date. When it notices an expired key/subkey, keyringer does > a Unix time -> human readable time conversion using > date --date=@$seconds (GNU date specific). Instead of adding a dep on > sysutils/coreutils, here's a diff to use base date(1) -r. The diff > doesn't change the control flow, it only fixes the terminal output. > > I'd like this to be included in 6.6. ok? ok
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/09/29 06:57:51 Modified files: infrastructure/bin: dpb infrastructure/lib/DPB: Trace.pm Log message: move to new tracing
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/09/29 06:38:25 Modified files: devel/libgdata : Makefile distinfo devel/libgdata/pkg: PLIST Removed files: devel/libgdata/patches: patch-gdata_meson_build patch-meson_build patch-po_meson_build Log message: update to libgdata-0.17.11
[patch] security/keyringer
Hi,
when using keyringer I noticed some "usage:" warnings coming from
/usr/bin/date. When it notices an expired key/subkey, keyringer does
a Unix time -> human readable time conversion using
date --date=@$seconds (GNU date specific). Instead of adding a dep on
sysutils/coreutils, here's a diff to use base date(1) -r. The diff
doesn't change the control flow, it only fixes the terminal output.
I'd like this to be included in 6.6. ok?
Index: Makefile
===
RCS file: /cvs/ports/security/keyringer/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile12 Jul 2019 20:49:04 - 1.6
+++ Makefile29 Sep 2019 12:14:56 -
@@ -3,6 +3,7 @@
COMMENT = manage and share secrets using GnuPG and Git
DISTNAME = keyringer-0.5.4
+REVISION = 0
CATEGORIES = security
Index: patches/patch-lib_keyringer_functions
===
RCS file: /cvs/ports/security/keyringer/patches/patch-lib_keyringer_functions,v
retrieving revision 1.4
diff -u -p -r1.4 patch-lib_keyringer_functions
--- patches/patch-lib_keyringer_functions 25 Apr 2019 15:04:44 -
1.4
+++ patches/patch-lib_keyringer_functions 29 Sep 2019 12:14:56 -
@@ -2,6 +2,7 @@ $OpenBSD: patch-lib_keyringer_functions,
- no mount -l/tmpfs in OpenBSD
- use gpg2, upstream seems to rely on gpg being gpg2
+- use date(1) -r instead of GNU date(1) --date=
Index: lib/keyringer/functions
--- lib/keyringer/functions.orig
@@ -54,7 +55,7 @@ Index: lib/keyringer/functions
if [ "$?" != "0" ]; then
if [ "$BASENAME" == "check" ]; then
refresh="no"
-@@ -727,7 +727,7 @@ function keyringer_check_expiration {
+@@ -727,14 +727,14 @@ function keyringer_check_expiration {
seconds="`date +%s`"
# Check the main key
@@ -63,7 +64,21 @@ Index: lib/keyringer/functions
# TODO: Time to expire can be configured via repository options.
ahead="$((86400 * 30 + $seconds))"
-@@ -754,7 +754,7 @@ function keyringer_check_expiration {
+
+ # Check if key is expired
+ if [ ! -z "$expiry" ] && [[ "$seconds" -gt "$expiry" ]]; then
+-echo -n "Warning: primary key for $recipient expired on `date
--date="@$expiry"`"
++echo -n "Warning: primary key for $recipient expired on `date -r
"$expiry"`"
+
+ if [ "$KEYRINGER_MODE" == "write" ] || [ "$KEYRINGER_MODE" == "readwrite"
]; then
+ echo ", aborting."
+@@ -749,12 +749,12 @@ function keyringer_check_expiration {
+ # TODO: Users can be alerted by mail if configured by user preferences.
+ # TODO: Outgoing emails can be encrypted.
+ if [ "$BASENAME" == "check" ] && [ ! -z "$expiry" ] && [[ "$ahead" -gt
"$expiry" ]]; then
+-echo "Warning: key $recipient will expire soon, on `date
--date="@$expiry"`"
++echo "Warning: key $recipient will expire soon, on `date -r "$expiry"`"
+ fi
# Check the subkeys
local subkey=""
@@ -72,6 +87,15 @@ Index: lib/keyringer/functions
local expiry=$(cut -d : -f 7 <<< "$subkey")
if [[ -z "$expiry" ]]; then
+@@ -765,7 +765,7 @@ function keyringer_check_expiration {
+ not_expired="1"
+
+ if [[ "$ahead" -gt "$expiry" ]] && [ "$BASENAME" == "check" ]; then
+-echo "Warning: subkey from $recipient will expire soon, on `date
--date="@$expiry"`"
++echo "Warning: subkey from $recipient will expire soon, on `date -r
"$expiry"`"
+ fi
+ fi
+ done
@@ -851,7 +851,7 @@ function keyringer_create_new_recipients {
recipient="`grep -e "^default-key" ~/.gnupg/gpg.conf | cut -d ' ' -f 2`"
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
NEW sysutils/unionfs-fuse
This is a new port for unionfs-fuse. DESCR: unionfs-fuse overlays several directory into one single mount point. It first tries to access the file on the top branch and if the file does not exist there, it continues on lower level branches. If the user tries to modify a file on a lower level read-only branch the file is copied to a higher level read-write branch if the copy-on-write (cow) mode was enabled. 'make test' runs successfully (assuming that it was started as root). I patched test.sh so that it informs the user that root privileges are required. Run tested on amd64. Comments/OK? unionfs-fuse.tgz Description: application/tar-gz
Re: Epson ESC/P-R driver
On 2019/09/29 11:19, Antoine Jacoutot wrote: > > The port was only in attachments to the emails in that thread, it was > > never committed. I've attached an updated version for -current, I don't > > have time to backport it for 6.4 though. > > Hi Stuart. > > I reworked the port a bit and added some patches from FreeBSD which fixed > multiple warnings. > I am also taking MAINTAINER (like I do with most (all?) print ports). > > Ed, it'd be nice if you could test with your printer. > > OK to import? > > -- > Antoine I'm not sure why they added patch-lib_epson-typedefs_h, it doesn't fix any warnings and may break arm/powerpc so I'd prefer to drop that unless you have an idea? Otherwise OK but I don't have an epson printer to test. It would definitely be nice to have this in ports.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/09/29 04:58:10 Modified files: infrastructure/lib/OpenBSD: Trace.pm Log message: explain the handlers better also add a hook for tweaking Data::Dumper parameters
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/09/29 04:51:26 Added files: infrastructure/lib/OpenBSD: Trace.pm Log message: Move the BaseTrace class here for more general consumption. Include some documentation. (unused yet, there may be errors)
Re: [Update] mail/opensmtpd-filters/rspamd
September 29, 2019 9:22 AM, "Florian Obser" wrote: > On Sat, Sep 28, 2019 at 07:46:16PM +0200, Florian Obser wrote: > >> On Sat, Sep 28, 2019 at 08:18:57AM +, gil...@poolp.org wrote: >> Hello, >> >> The following diff updates filter-rspamd to 0.1.3: >> >> - fixes a concurrency-related crash which has been observed by patrick@ and >> otto@ >> - adds X-Spam-Symbols which was requested by florian@ >> >> Requested it such a strong word. I completely missed how all this >> stuff interconnects. I thougt rspamd itself adds those headers. ;) >> >> Thank you very much. Unfortunately I haven't gotten any spam yet, the >> rdns filters are just too good :D so I can't tell if it actually works. > > nd I got some spam and happy to report that it works: > > (I fiddled around with the score values, my rspamd never rejects, but > this is quite an impressively high score) > Perfect, committed ! In a future version we'll rework the X-Spam-Symbols header so that it's a bit more compact and so it also displays the individual score for matches but I think this version is good enough for the next OpenBSD release. Unless someone finds a very annoying bug I won't update it before release of OpenBSD 6.6. Thanks for testing :-)
Re: Care and Feeding
On Sat, Sep 28, 2019 at 05:42:08PM -0400, Andras Farkas wrote:
Hi Andras,
I don't understand what your goal is.
A few years ago you wrote me you would like to make a port of tinyfuge
5. I suggested to make a new port tinyfugue5 and maybe name the binary
tf5 instead of tf.
I'm MAINTAINER of net/tinyfuge which uses version 4.
As screen handling and others changed a lot between the two versions I
prefer the old style. Thats why the port use tf 4.
> On Sat, Sep 28, 2019 at 4:07 AM Stuart Henderson wrote:
> > Re the first submission you pointed out, here is the comment:
> > - programmable MUD client, but beta rather than stable
> > This doesn't sound like something we want in ports.
> TinyFugue is a weird thing. Both tf4 and tf5 (which should be
> considered separate ports/packages) haven't been touched by the
> developer since January 2007, over a decade ago. They're
> unmaintained, except in a variety of forks of which none are an
> obvious most popular successor.
> Because of the lack of a clear successor and lack of motivation to
> change ("if it's not totally broken and unusable, don't fix it!")
> people still use _both_ of those often. TinyFugue's sourceforge
> supplies users tf5 by default.
> Some OSes/packagemanagers have only tf4 (openbsd, netbsd), some have
> only tf5 (freebsd, fedora), and some have both tf4 and tf5 available
> as separate packages (debian and all debian-based distros)
> I checked all those stats myself, but this link may be useful too:
> https://repology.org/project/tinyfugue/versions
First, I think your intention is to have a tf 5 port.
> Is it possible that tf4 could be removed from ports? It's definitely
> unmaintained, but still used by the people who prefer it over tf5.
Now you want tf 4 removed?
According to sourceforge both version were last modified in 2007.
> (though I make a point to only use tf5, since tf4 doesn't support TLS.
> However, I myself don't use tf as often as I used to, even though I
> still use it)
> In my own opinion, I think it's smarter to have no tinyfugue than to
> not have both tinyfugue versions. But that's just me, and definitely
> because I care a lot about secure connections to the MU*s I use.
You may use tf 4 with stunnel.
> > (Also in general, new ports are always trickier because there's a policy of
> > always needing a second developer ok to commit them, so you need to get two
> > dev's interested in it!)
> Ahaa, I see.
> > Second one: diff please! Don't forget the REVISION bump.
> Did it. :3 Sent it back in its original thread.
Regards
Markus
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gil...@cvs.openbsd.org 2019/09/29 03:52:06 Modified files: mail/opensmtpd-filters/rspamd: Makefile distinfo Log message: update opensmtpd-filter-rspamd to 0.1.3, fixes a concurrency-related crash, and adds a few features ok florian@ and landry@
Re: NEW: geo/ruby-geoip2_c
Ping?
On Thu, 19 Sep 2019 14:26:33 +0900 Eric Elena wrote:
> On Wed, 2019-09-18 at 14:23 -0700, Jeremy Evans wrote:
> > On Wed, Sep 18, 2019 at 9:32 AM Stuart Henderson > > wrote:
> > > On 2019/09/18 18:26, Eric Elena wrote:
> > > > Hello list,
> > > >
> > > > Here is a new port geo/ruby-geoip2_c.
> > > >
> > > > DESCR:
> > > > This gem provides Ruby binding for libmaxminddb.
> > > >
> > > > By default this gem tries to build its own version of
> > > libmaxminddb,
> > > > which uses autotools. I patched the configuration to use
> > > > net/libmaxminddb instead and remove FMS extensions from the
> > > compiler
> > > > options as they are not supported on OpenBSD.
> > > >
> > > > I use it as a dependency of fluentd (fluentd geoip filter) to
> > > locate
> > > > the IP addresses collected via netflow and see that in grafana.
> > > This
> > > > gem is the only one that causes trouble hence a port for it.
> > > Porting
> > > > fluentd may be the next step for 6.7+.
> > > >
> > > > I'm a beginner in porting, comments are welcome.
> > > >
> > > > Thanks,
> > > > Eric
> > >
> > > Tweaked to use a COMPILER string so that it has a chance on non-
> > > clang
> > > arches, and to honour LOCALBASE.
> > >
> > > Am not a ruby ports expert but this looks ok to me ..
> >
> > Still needs removal of ${GEM_EXTENSIONS_DIR}
> > and ${GEM_LIB}/gems/${DISTNAME}/ext/ directories and stuff underneath
> > them from the PLIST. Then it should be OK to import, though Eric may
> > want to consider being the MAINTAINER.
>
> Thanks Jeremy and Stuart for the review. While cleaning the PLIST I
> also removed docker* files as they are not useful here.
> I added myself as the maintainer, Jeremy is already doing all the hard
> work in Ruby land :) (and thanks for that)
> Tested with fresh netflow data only, grafana is still happy with it.
>
> Thanks,
> Eric
>
> > Thanks,
> > Jeremy
> >
ruby-geoip2_c.tar.gz
Description: application/gzip
Re: Epson ESC/P-R driver
> The port was only in attachments to the emails in that thread, it was > never committed. I've attached an updated version for -current, I don't > have time to backport it for 6.4 though. Hi Stuart. I reworked the port a bit and added some patches from FreeBSD which fixed multiple warnings. I am also taking MAINTAINER (like I do with most (all?) print ports). Ed, it'd be nice if you could test with your printer. OK to import? -- Antoine epson-inkjet-printer-escpr.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2019/09/29 02:23:17 Modified files: lang/rust : Makefile distinfo lang/rust/patches: patch-src_bootstrap_bin_rustc_rs patch-src_bootstrap_lib_rs patch-src_bootstrap_test_rs patch-src_librustc_llvm_build_rs patch-src_librustc_target_spec_mod_rs patch-src_libstd_sys_unix_os_rs patch-src_libunwind_build_rs patch-src_tools_cargo_src_cargo_core_compiler_context_compilation_files_rs patch-src_tools_cargo_tests_testsuite_support_paths_rs lang/rust/pkg : PLIST-main Added files: lang/rust/patches: patch-src_test_ui-fulldeps_myriad-closures_rs patch-src_test_ui_out-of-stack_rs patch-src_test_ui_sse2_rs patch-src_test_ui_stack-probes-lto_rs patch-src_test_ui_stack-probes_rs patch-vendor_libc_src_unix_bsd_netbsdlike_openbsd_mod_rs patch-vendor_libc_src_unix_bsd_netbsdlike_openbsd_sparc64_rs patch-vendor_libgit2-sys_lib_rs Removed files: lang/rust/patches: patch-src_test_run-pass-fulldeps_myriad-closures_rs patch-src_test_run-pass_out-of-stack_rs patch-src_test_run-pass_sse2_rs patch-src_test_run-pass_stack-probes-lto_rs patch-src_test_run-pass_stack-probes_rs patch-vendor_libc_src_unix_bsd_netbsdlike_openbsdlike_openbsd_mod_rs patch-vendor_libc_src_unix_bsd_netbsdlike_openbsdlike_openbsd_sparc64_rs Log message: update lang/rust to 1.38.0 Release: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1380-2019-09-26 Announce: https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html ok landry@
Re: [Update] devel/liblouis : Update to 3.11.0
On Tue, Sep 24, 2019 at 07:32:01AM +, wen heping wrote:
> Hi, ports@:
>
> Here is a patch for devel/liblouis:
>i) Update to 3.11.0
>ii) Remove patches/patch-liblouis_compileTranslationTable_c, which
> had been included into upstream.
>
> It build well and passed all tests on amd64-head system.
> One port(x11/gnome/orca) depends on it, it build well with this patch too.
>
> Comments? OK?
> wen
Committed, thanks!
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/liblouis/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile 12 Jul 2019 20:44:39 - 1.29
> +++ Makefile 24 Sep 2019 07:27:45 -
> @@ -2,10 +2,10 @@
>
> COMMENT= braille translator, back-translator and formatter
>
> -V= 3.9.0
> +V= 3.11.0
> DISTNAME=liblouis-${V}
>
> -SHARED_LIBS += louis8.0 # 17.1
> +SHARED_LIBS += louis8.0 # 19.0
>
> CATEGORIES= devel
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/liblouis/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo 13 May 2019 22:14:01 - 1.14
> +++ distinfo 24 Sep 2019 07:27:45 -
> @@ -1,2 +1,2 @@
> -SHA256 (liblouis-3.9.0.tar.gz) = 5K4jNzdRADxuRLzaZTzzs94e/wuFD5NJCRrqfkoMuHg=
> -SIZE (liblouis-3.9.0.tar.gz) = 13923857
> +SHA256 (liblouis-3.11.0.tar.gz) =
> uAKroL/0ljaQfKdIIl4hxW7PPz68FD1YJDADbU2fYlk=
> +SIZE (liblouis-3.11.0.tar.gz) = 14105376
> Index: patches/patch-liblouis_compileTranslationTable_c
> ===
> RCS file: patches/patch-liblouis_compileTranslationTable_c
> diff -N patches/patch-liblouis_compileTranslationTable_c
> --- patches/patch-liblouis_compileTranslationTable_c 19 Aug 2018 07:54:04
> - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,23 +0,0 @@
> -$OpenBSD: patch-liblouis_compileTranslationTable_c,v 1.1 2018/08/19 07:54:04
> ajacoutot Exp $
> -
> -From dbfa58bb128cae86729578ac596056b3385817ef Mon Sep 17 00:00:00 2001
> -From: Christian Egli
> -Date: Wed, 6 Jun 2018 16:41:53 +0200
> -Subject: [PATCH] Check index before writing to result->chars
> -
> -Index: liblouis/compileTranslationTable.c
> liblouis/compileTranslationTable.c.orig
> -+++ liblouis/compileTranslationTable.c
> -@@ -1127,11 +1127,11 @@ parseChars(FileInfo *nested, CharsString *result,
> Char
> - }
> - in++;
> - }
> --result->chars[out++] = (widechar)ch;
> - if (out >= MAXSTRING) {
> - result->length = out;
> - return 1;
> - }
> -+result->chars[out++] = (widechar)ch;
> - continue;
> - }
> - lastOutSize = out;
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/liblouis/pkg/PLIST,v
> retrieving revision 1.15
> diff -u -p -r1.15 PLIST
> --- pkg/PLIST 13 May 2019 22:14:01 - 1.15
> +++ pkg/PLIST 24 Sep 2019 07:27:45 -
> @@ -21,7 +21,6 @@ bin/lou_maketable.d/wrap_patgen.sh
> @bin bin/lou_trace
> @bin bin/lou_translate
> include/liblouis/
> -include/liblouis/internal.h
> include/liblouis/liblouis.h
> lib/liblouis.a
> lib/liblouis.la
> @@ -29,7 +28,7 @@ lib/liblouis.la
> lib/pkgconfig/liblouis.pc
> lib/python${MODPY_VERSION}/site-packages/louis/
> lib/python${MODPY_VERSION}/site-packages/louis/__init__.py
> -lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}/
> +${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}/
>
> lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
> @man man/man1/lou_allround.1
> @man man/man1/lou_checkhyphens.1
> @@ -48,6 +47,7 @@ share/liblouis/tables/Lv-Lv-g1.utb
> share/liblouis/tables/Pl-Pl-g1.utb
> share/liblouis/tables/Se-Se-g1.utb
> share/liblouis/tables/afr-za-g1.ctb
> +share/liblouis/tables/afr-za-g2.ctb
> share/liblouis/tables/ar-ar-comp8.utb
> share/liblouis/tables/ar-ar-g1.utb
> share/liblouis/tables/ar-ar-g2.ctb
> @@ -72,7 +72,6 @@ share/liblouis/tables/braille-patterns.c
> share/liblouis/tables/ca-chardefs.cti
> share/liblouis/tables/ca-g1.ctb
> share/liblouis/tables/ca.tbl
> -share/liblouis/tables/chardefs.cti
> share/liblouis/tables/chr-us-g1.ctb
> share/liblouis/tables/ckb-chardefs.cti
> share/liblouis/tables/ckb-g1.ctb
> @@ -129,12 +128,13 @@ share/liblouis/tables/digits8Dots.uti
> share/liblouis/tables/dra.ctb
> share/liblouis/tables/dra.tbl
> share/liblouis/tables/el.ctb
> -share/liblouis/tables/el.tbl
> share/liblouis/tables/en-GB-g2.ctb
> +share/liblouis/tables/en-chardefs.cti
> share/liblouis/tables/en-chess.ctb
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/29 01:58:35 Modified files: devel/liblouis : Makefile distinfo devel/liblouis/patches: patch-python_louis_Makefile_in patch-tools_lou_compare_c devel/liblouis/pkg: PLIST Removed files: devel/liblouis/patches: patch-liblouis_compileTranslationTable_c Log message: Update to liblouis-3.11.0. from wen heping
Re: UPDATE: Nextcloud-16.0.5
On Sat, 28 Sep 2019 at 14:24:18 +0200, Björn Ketelaars wrote:
> On Thu 26/09/2019 19:53, Gonzalo L. Rodriguez wrote:
> > Hello,
> >
> > Update for Nextcloud to 16.0.5:
> >
> > https://nextcloud.com/changelog/
> >
> > OK? Comments?
>
> Works for me! I think (actually 'make update-plist' thinks) it is
> possible to optimise pkg/PLIST a bit:
>
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -13013,12 +13013,7 @@ nextcloud/apps/workflowengine/templates/admin.php
> @owner www
> @group www
> nextcloud/config/
> -@mode
> -@owner
> -@group
> @mode 0640
> -@owner www
> -@group www
> nextcloud/config/.htaccess
> nextcloud/config/CAN_INSTALL
> nextcloud/config/config.php.dist
>
> Enclosed your diff with the above applied. Either way OK bket@
>
>
> diff --git Makefile Makefile
> index c81c6542b5a..b7195bc5c2e 100644
> --- Makefile
> +++ Makefile
> @@ -2,7 +2,7 @@
>
> COMMENT= easy and universal access to shared and/or personal
> files
>
> -V= 16.0.4
> +V= 16.0.5
> DISTNAME=nextcloud-${V}
> EXTRACT_SUFX=.tar.bz2
>
> diff --git distinfo distinfo
> index 93079b41a66..c0a878318e5 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (nextcloud-16.0.4.tar.bz2) =
> 4GMAJR7JNaG8mPqQpKVr9JQrDlWdYKGRt+Sdj/2f7NA=
> -SIZE (nextcloud-16.0.4.tar.bz2) = 61914385
> +SHA256 (nextcloud-16.0.5.tar.bz2) =
> hwnGT6d2/XMcjl8asl1ZKi5pDl4YqBYBzM82N5X65VE=
> +SIZE (nextcloud-16.0.5.tar.bz2) = 62129676
> diff --git pkg/PLIST pkg/PLIST
> index 86b34d26a71..31392b881dc 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -5050,8 +5050,12 @@ nextcloud/apps/accessibility/l10n/he.js
> nextcloud/apps/accessibility/l10n/he.json
> nextcloud/apps/accessibility/l10n/hi_IN.js
> nextcloud/apps/accessibility/l10n/hi_IN.json
> +nextcloud/apps/accessibility/l10n/hr.js
> +nextcloud/apps/accessibility/l10n/hr.json
> nextcloud/apps/accessibility/l10n/hu.js
> nextcloud/apps/accessibility/l10n/hu.json
> +nextcloud/apps/accessibility/l10n/id.js
> +nextcloud/apps/accessibility/l10n/id.json
> nextcloud/apps/accessibility/l10n/is.js
> nextcloud/apps/accessibility/l10n/is.json
> nextcloud/apps/accessibility/l10n/it.js
> @@ -5064,6 +5068,8 @@ nextcloud/apps/accessibility/l10n/lt_LT.js
> nextcloud/apps/accessibility/l10n/lt_LT.json
> nextcloud/apps/accessibility/l10n/mk.js
> nextcloud/apps/accessibility/l10n/mk.json
> +nextcloud/apps/accessibility/l10n/nb.js
> +nextcloud/apps/accessibility/l10n/nb.json
> nextcloud/apps/accessibility/l10n/nl.js
> nextcloud/apps/accessibility/l10n/nl.json
> nextcloud/apps/accessibility/l10n/nn_NO.js
> @@ -5092,6 +5098,8 @@ nextcloud/apps/accessibility/l10n/tr.js
> nextcloud/apps/accessibility/l10n/tr.json
> nextcloud/apps/accessibility/l10n/uk.js
> nextcloud/apps/accessibility/l10n/uk.json
> +nextcloud/apps/accessibility/l10n/vi.js
> +nextcloud/apps/accessibility/l10n/vi.json
> nextcloud/apps/accessibility/l10n/zh_CN.js
> nextcloud/apps/accessibility/l10n/zh_CN.json
> nextcloud/apps/accessibility/l10n/zh_TW.js
> @@ -5785,6 +5793,8 @@ nextcloud/apps/dav/l10n/gl.js
> nextcloud/apps/dav/l10n/gl.json
> nextcloud/apps/dav/l10n/he.js
> nextcloud/apps/dav/l10n/he.json
> +nextcloud/apps/dav/l10n/hr.js
> +nextcloud/apps/dav/l10n/hr.json
> nextcloud/apps/dav/l10n/hu.js
> nextcloud/apps/dav/l10n/hu.json
> nextcloud/apps/dav/l10n/hu_HU.js
> @@ -6618,6 +6628,8 @@ nextcloud/apps/federation/l10n/gl.js
> nextcloud/apps/federation/l10n/gl.json
> nextcloud/apps/federation/l10n/he.js
> nextcloud/apps/federation/l10n/he.json
> +nextcloud/apps/federation/l10n/hr.js
> +nextcloud/apps/federation/l10n/hr.json
> nextcloud/apps/federation/l10n/hu.js
> nextcloud/apps/federation/l10n/hu.json
> nextcloud/apps/federation/l10n/hu_HU.js
> @@ -6642,6 +6654,8 @@ nextcloud/apps/federation/l10n/lt_LT.js
> nextcloud/apps/federation/l10n/lt_LT.json
> nextcloud/apps/federation/l10n/lv.js
> nextcloud/apps/federation/l10n/lv.json
> +nextcloud/apps/federation/l10n/mk.js
> +nextcloud/apps/federation/l10n/mk.json
> nextcloud/apps/federation/l10n/mn.js
> nextcloud/apps/federation/l10n/mn.json
> nextcloud/apps/federation/l10n/nb.js
> @@ -8100,6 +8114,8 @@ nextcloud/apps/files_rightclick/l10n/gl.js
> nextcloud/apps/files_rightclick/l10n/gl.json
> nextcloud/apps/files_rightclick/l10n/he.js
> nextcloud/apps/files_rightclick/l10n/he.json
> +nextcloud/apps/files_rightclick/l10n/hr.js
> +nextcloud/apps/files_rightclick/l10n/hr.json
> nextcloud/apps/files_rightclick/l10n/hu.js
> nextcloud/apps/files_rightclick/l10n/hu.json
> nextcloud/apps/files_rightclick/l10n/is.js
> @@ -8654,6 +8670,8 @@ nextcloud/apps/files_texteditor/l10n/gl.js
> nextcloud/apps/files_texteditor/l10n/gl.json
> nextcloud/apps/files_texteditor/l10n/he.js
> nextcloud/apps/files_texteditor/l10n/he.json
> +nextcloud/apps/files_texteditor/l10n/hr.js
> +nextcloud/apps/files_texteditor/l10n/hr.json
> nextcloud/apps/files_texteditor/l10n/hu.js
>
Re: [Update] mail/opensmtpd-filters/rspamd
On Sat, Sep 28, 2019 at 07:46:16PM +0200, Florian Obser wrote: > On Sat, Sep 28, 2019 at 08:18:57AM +, gil...@poolp.org wrote: > > Hello, > > > > The following diff updates filter-rspamd to 0.1.3: > > > > - fixes a concurrency-related crash which has been observed by patrick@ and > > otto@ > > - adds X-Spam-Symbols which was requested by florian@ > > Requested it such a strong word. I completely missed how all this > stuff interconnects. I thougt rspamd itself adds those headers. ;) > > Thank you very much. Unfortunately I haven't gotten any spam yet, the > rdns filters are just too good :D so I can't tell if it actually works. nd I got some spam and happy to report that it works: (I fiddled around with the score values, my rspamd never rejects, but this is quite an impressively high score) X-Spam: yes X-Spam-Score: 39.95 / 6 X-Spam-Symbols: R_SPF_SOFTFAIL, RCPT_COUNT_ONE, FROM_EQ_ENVFROM, ARC_NA, RBL_BLOCKLISTDE, RBL_SPAMHAUS_XBL_ANY, RCVD_NO_TLS_LAST, R_DKIM_NA, TO_MATCH_ENVRCPT_ALL, REPLYTO_EQ_FROM, HFILTER_HOSTNAME_5, TO_DN_NONE, SEM_URIBL, VIOLATED_DIRECT_SPF, FREEMAIL_REPLYTO, MIME_TRACE, RECEIVED_BLOCKLISTDE, HAS_REPLYTO, FREEMAIL_ENVFROM, FROM_HAS_DN, RBL_SPAMHAUS_CSS, RSPAMD_URIBL, HTML_SHORT_LINK_IMG_1, RECEIVED_SPAMHAUS_CSS, MID_RHS_MATCH_FROM, PREVIOUSLY_DELIVERED, URIBL_SBL, URIBL_BLACK, FREEMAIL_FROM, DBL_SPAM, FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN, DMARC_POLICY_SOFTFAIL, RCVD_COUNT_THREE, ASN, RBL_SENDERSCORE, RECEIVED_SPAMHAUS_PBL, MANY_INVISIBLE_PARTS, MIME_HTML_ONLY -- I'm not entirely sure you are real.
