CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/10/01 23:44:37 Modified files: textproc/ruby-rouge: Makefile distinfo Log message: Update ruby-rouge to 3.11.1.
Re: Neovim update and new libluv port
Hey there,
Thanks for the feedback.
On Tue, Oct 1, 2019, at 02:20, Edd Barrett wrote:
> Hi,
>
> Thanks for looking at this.
>
> On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote:
> > * 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.
>
> Let's start with this ^
>
> Should the package name be "libluv" or "luv"? Upstream seems to call it "luv".
You're probably right. I've changed it to just "luv".
>
>
> > PKGVER = 1.30.1.1
>
> Since that's only used once, you might aswell inline it. Or even better,
> to the replacement using make's regex support:
>
> PKGNAME = libluv-${VER:S/-/./g}
Good idea. Fixed.
> > BUILD_DEPENDS = devel/cmake \
> > devel/libuv
> >
> > LIB_DEPENDS = devel/libuv
>
> If libuv is a LIB_DEPEND, I don't think you need it as a BUILD_DEPEND as
> well.
Makes sense. DRY. Fixed.
> > CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
> > -DWITH_LUA_ENGINE=Lua \
> > -DLUA_BUILD_TYPE=System \
> > -DBUILD_MODULE=OFF \
> > -DBUILD_SHARED_LIBS=ON \
>
> Indent is odd here. I'd make all the `-D`s line up.
Yeah, sorry fixed.
> In Makefile and pkg/DESCR we need to use the right capitalisation for Lua and
> LuaJIT:
> - s/luajit/LuaJIT/g
> - s/lua/Lua/g
Those were a copy paste from the upstream README.md on github, but I agree
about making
it have the proper capitalization. Fixed.
> `make port-lib-depends-check` says:
> ---8<---
> Extra: pthread.26
> --->8---
>
> So you probably want to kill that from your WANTLIB.
A little surprised I didn't catch that. But fixed.
> I notice that the source tarball bundles some dependencies in `deps/` and
> uses them once during the build:
> ---8<---
> ===> Building for libluv-1.30.1.1
> [1/3] /usr/local/pobj/libluv-1.30.1.1/bin/cc -DLUA_USE_DLOPEN -Dluv_EXPORTS
> -I/usr/local/include -I/usr/local/include/lua-5.1
> -I/usr/local/pobj/libluv-1.30.1.1/luv-1.30.1-1/deps/lua-compat-5.3 -O2 -pipe
> -g -DNDEBUG -fPIC -MD -MT CMakeFile
> s/luv.dir/src/luv.c.o -MF CMakeFiles/luv.dir/src/luv.c.o.d -o
> CMakeFiles/luv.dir/src/luv.c.o -c /usr/local/pobj/liblu
> v-1.30.1.1/luv-1.30.1-1/src/luv.c
> --->8---
>
> So it's using `deps/lua-compat-5.3`. I notice we have a port
> devel/lua-compat53
> already. It'd be best if you can make your port use it. Perhaps we should `rm
> -rf` the `deps/` directory in `pre-build:` so as to avoid accidental usage of
> bundled deps?
This one I'm not totally sure what to do about. I tried your advice and it it
breaks the build with:
/usr/obj/ports/luv-1.30.1.1/luv-1.30.1-1/src/luv.c:20:10: fatal error:
'c-api/compat-5.3.h' file not found
#include "c-api/compat-5.3.h"
^~~~
lua-compat-5.3 doesn't install any headers, and no other PLIST file in ports
has it either.
I'm not sure if it's best to keep the deps dir? or are we talking about
modifying lua-compat53 to install
those headers?
Or is there a simpler option that I'm missing?
> And finally:
> ---8<---
> fremen$ /usr/ports/infrastructure/bin/portcheck
> trailing whitespace in Makefile
> --->8---
Ah, I should have caught this one to. Fixed.
>
> Other than these, this looks good. If you mail me a revised diff, I'll start
> looking for an OK.
I also added:
SEPARATE_BUILD =YES
New tar attached.
Thanks!
luv.tar.gz
Description: application/gzip
ghc vs gmp
Hi Matthias,
On Mon, Sep 23, 2019 at 2:40 PM Matthias Kilian wrote:
> Instead of adding more madness (like a patch to diff in this case),
> I compared the bundled gmp sources against the upstream used by
> devel/gmp (which are identical except for the remoced coeumentation
> in ghc's version) and hat a look at at the patch to gmp contained
> in the ghc sources (libraries/integer-gmp/gmp/gmpsrc.patch, which
> only adds -fPIC for some systems).
I was browsing the old ghc patches and we switched from the ports to
the bundled gmp some 7 years ago
https://github.com/openbsd/ports/commit/47aa23534d85b9287ed8fe026c98a13d9e2599e4
I couldn't get my "large Fibonacci numbers" to crash anything. I'm
curious if anybody has a
bottled testcase to try or knows how to modify the one below to stress
things more.
{-# Language BangPatterns #-}
main = mapM_ (putStrLn . take 20 . show . fib) [0..]
fib :: Integer -> Integer
fib n = fibs 1 1 n
where fibs !a !b !n
| n == 0 = a
| otherwise = fibs b (a+b) (n-1)
Thanks
Greg
Re: math/coq: fix plist for bytecode-only build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
hi, chrisz,
> for building bytecode-only coq I need the following patch. (Did I send
> you this before? I misconfigured my mail client.) OK?
I'm not sure I understand correctly full, but
this restructures plist files to PFRAG.native and PFRAG.no-nonative.
then I've no objection.
I want to verify the build on amd64, but how can I build as bytecode-only?
my experiment in a short time is to redefine PROPERTIES.
is there any more smart test setting?
% diff -u /usr/ports/mystuff/math/coq/Makefile{.orig,}
--- /usr/ports/mystuff/math/coq/Makefile.orig Sat Sep 28 22:18:22 2019
+++ /usr/ports/mystuff/math/coq/Makefile Sun Sep 29 16:13:56 2019
@@ -41,6 +41,12 @@
-configdir ${SYSCONFDIR}/xdg/coq
.include
+
+## On amd64 and i386, PROPERTIES includes
+## all apm le lp64 clang gcc49 mono llvm cxx11 ocaml_native
ocaml_native_dynlink go lld rust
+## To test bytecode only archs, we remove ocaml_native and
ocaml_native_dynlink.
+PROPERTIES := ${PROPERTIES:Nocaml_native:Nocaml_native_dynlink}
+
.if ${PROPERTIES:Mocaml_native}
ALL_TARGET= world
INSTALL_TARGET= install
-- yozo.
-BEGIN PGP SIGNATURE-
iQJJBAEBCgAzFiEEsSBE3BD3oI0EPJSvM6KY3A5GNSgFAl2T8VYVHHlvem9AdjAw
Ny52YWlvLm5lLmpwAAoJEDOimNwORjUozbQQAJd+D7ew3c0kNtn8AJWRZvzgOa9l
0oVh+yfQ5KdThqYzrYqRlVVBiT1xiJY9Ngd9zTnN6wdC3LGX2y5DP3SnM1kaFfJt
TqAkMN6CHRwxE/fIDSaJZvPR8hzKHG24ZWiIjUiPgg6ulcGBAPQu80y0HDqlHJHL
q6kcWkUyU2YmMoKOShMBDtibCvZc8YB+3erQVvp0+tpVMuEW9F5CnphM7M8DmAYY
X796FZmnr4r3FDh+XvvcDVa6unuyxuGK6TCbBq19tnWAaFBltfNhGMDWHJ5gLBX8
Sm2Exan/F3We5AGqQDxzoHtKAxCv+t0jmT7+jut0ksfeqs+pxJXTX0JgoS5P+Zzs
DL8iS4wodoItt00CBORyiLCBSL6uFcXe+sbTp4WZTNuoB1ljdV37cYq0yTxHSEV5
hGbTIDWCjenw40Y/UsLUiZNcBL3ina4SLj3ulexVNIgKHB6xg+RwdtUp6+nMMROC
RZ2at8tubP3KsqLoovEFOo8MTsBjpRaXOAcIah2w+lMrb5j2Tbgit38e2TPClpSv
Og01MnEkuPpdEVtsH1ZlgiFmsgLoVYYXdblgRYfQaiCoHaZgGgbWrKSMB5tMCigJ
nfyYNS+7Vu2Uz71VEE5s+zxITwDpKhLAlqrQja6lpOU4qtc6jBUAKKtNDf/bhWxD
OtSmghGidZDknMoM
=5Boe
-END PGP SIGNATURE-
games/opensonic doesn't run at 100% speed
On amd64 -current (today snapshot) it seems games/opensonic runs slower than expected music is slow, game is slow. Here is a sample in video: https://perso.pw/sonic.flv in that state, the game is not playable.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/10/01 13:56:58 Modified files: audio/libopenmpt: Makefile distinfo Log message: Update libopenmpt to 0.4.8.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/10/01 13:18:27 Modified files: devel/hs-resourcet: Makefile Log message: Fix dependencies. Breakage noticed by naddy@. >From Greg Steuck. Tested by a) removing hs-sandi, darcs and hedgewars from my package repository and rebuilding them, b) removing all haskell ports (except ghc itself) from my package repository and rebuilding everything.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/10/01 12:44:43 Modified files: graphics/lcms2 : Makefile Added files: graphics/lcms2/patches: patch-src_cmstypes_c Log message: Fix for intermittent crash in graphics/colord. Patch from upstream. okay ajacoutot@ naddy@
Ruby Security Releases: 2.4.8, 2.5.7, 2.6.5
New versions of Ruby were released today for 4 vulnerabilities:
https://www.ruby-lang.org/en/news/2019/10/01/webrick-regexp-digestauth-dos-cve-2019-16201/
https://www.ruby-lang.org/en/news/2019/10/01/nul-injection-file-fnmatch-cve-2019-15845/
https://www.ruby-lang.org/en/news/2019/10/01/http-response-splitting-in-webrick-cve-2019-16254/
https://www.ruby-lang.org/en/news/2019/10/01/code-injection-shell-test-cve-2019-16255/
Release announcements are at:
https://www.ruby-lang.org/en/news/2019/10/01/ruby-2-4-8-released/
https://www.ruby-lang.org/en/news/2019/10/01/ruby-2-5-7-released/
https://www.ruby-lang.org/en/news/2019/10/01/ruby-2-6-5-released/
Unfortunately, there is a packaging issue with the ruby 2.4.8 tarball,
so instead of using that, this just picks the 4 patch commits from
GitHub.
I've only done minor testing of this so far. I will be doing more
testing, but if there are no problems, I plan to commit in a couple
days.
Thanks,
Jeremy
Index: 2.4/Makefile
===
RCS file: /cvs/ports/lang/ruby/2.4/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- 2.4/Makefile30 Aug 2019 15:56:31 - 1.18
+++ 2.4/Makefile1 Oct 2019 17:43:03 -
@@ -4,6 +4,14 @@ VERSION = 2.4.7
SHARED_LIBS = ruby24 2.0
NEXTVER = 2.5
+REVISION-main =0
+MASTER_SITES0 =https://github.com/ruby/ruby/commit/
+PATCHFILES = 88387876af112eb0bdefe7408bca6cf52d6f.patch:0 \
+ 38d2d0dbd319a9cc49fd2c945be4090cea72ef36.patch:0 \
+ 8eff476bce40b52f244b8c912d1a5f40aa64b683.patch:0 \
+ 1a45b0448224009a9bde9b28ae259d8674c792be.patch:0
+PATCH_DIST_STRIP = -p1
+
PSEUDO_FLAVORS=no_ri_docs bootstrap
# Do not build the RI docs on slow arches
.if ${MACHINE_ARCH:Malpha} || ${MACHINE_ARCH:Marm} || ${MACHINE_ARCH:Mhppa}
Index: 2.4/distinfo
===
RCS file: /cvs/ports/lang/ruby/2.4/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- 2.4/distinfo30 Aug 2019 15:56:31 - 1.11
+++ 2.4/distinfo1 Oct 2019 17:43:16 -
@@ -1,2 +1,10 @@
+SHA256 (1a45b0448224009a9bde9b28ae259d8674c792be.patch) =
TUEQjT2myZa7OtZtD0QnhG9eify0Bit1CR41TkkVTRQ=
+SHA256 (38d2d0dbd319a9cc49fd2c945be4090cea72ef36.patch) =
gpCnkgBLmApAWI1lKnBES0qwiUmZbzm6PDYVtdbE8jM=
+SHA256 (88387876af112eb0bdefe7408bca6cf52d6f.patch) =
mbF/Q1Pjrvs3vQz5SHT4vGtPwZh1cjFmK8zGDEDzy7A=
+SHA256 (8eff476bce40b52f244b8c912d1a5f40aa64b683.patch) =
qhjeBfpMFa6OR/uqQAbXIpQgoK7OsWDFlxNEMEe3y7w=
SHA256 (ruby-2.4.7.tar.gz) = zW78cgympiJ0XiusefRebNY6sPWlOtfriBVF9Y/zi4k=
+SIZE (1a45b0448224009a9bde9b28ae259d8674c792be.patch) = 2439
+SIZE (38d2d0dbd319a9cc49fd2c945be4090cea72ef36.patch) = 3154
+SIZE (88387876af112eb0bdefe7408bca6cf52d6f.patch) = 1917
+SIZE (8eff476bce40b52f244b8c912d1a5f40aa64b683.patch) = 4033
SIZE (ruby-2.4.7.tar.gz) = 16036496
Index: 2.5/Makefile
===
RCS file: /cvs/ports/lang/ruby/2.5/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- 2.5/Makefile30 Aug 2019 15:57:24 - 1.10
+++ 2.5/Makefile1 Oct 2019 15:24:38 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.10 2019/08/30 15:57:24 jeremy Exp $
-VERSION = 2.5.6
+VERSION = 2.5.7
SHARED_LIBS = ruby25 0.0
NEXTVER = 2.6
Index: 2.5/distinfo
===
RCS file: /cvs/ports/lang/ruby/2.5/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- 2.5/distinfo30 Aug 2019 15:57:24 - 1.6
+++ 2.5/distinfo1 Oct 2019 15:25:04 -
@@ -1,2 +1,2 @@
-SHA256 (ruby-2.5.6.tar.gz) = HX7QbGcwIM0SpzftaGRwVS6Omdcrgs08JtqjEVw2vqc=
-SIZE (ruby-2.5.6.tar.gz) = 17684288
+SHA256 (ruby-2.5.7.tar.gz) = Cy0NXjRRtqtFT4Gxv8oAdAfAVI3qQD8eui5CnaSt1tQ=
+SIZE (ruby-2.5.7.tar.gz) = 15669771
Index: 2.6/Makefile
===
RCS file: /cvs/ports/lang/ruby/2.6/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- 2.6/Makefile30 Aug 2019 15:58:26 - 1.7
+++ 2.6/Makefile1 Oct 2019 15:25:17 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.7 2019/08/30 15:58:26 jeremy Exp $
-VERSION = 2.6.4
+VERSION = 2.6.5
DISTNAME = ruby-${VERSION}
SHARED_LIBS = ruby26 0.0
NEXTVER = 2.7
Index: 2.6/distinfo
===
RCS file: /cvs/ports/lang/ruby/2.6/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- 2.6/distinfo30 Aug 2019 15:58:26 - 1.6
+++ 2.6/distinfo1 Oct 2019 15:25:37 -
@@ -1,2 +1,2 @@
-SHA256 (ruby-2.6.4.tar.gz) =
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/10/01 11:58:40 Modified files: games/freedink/game: Makefile games/julius : Makefile Added files: games/freedink/game/patches: patch-src_input_cpp games/julius/patches: patch-src_platform_julius_c Log message: replace SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH with SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS per sdl2 2.0.10 update instructions. >From thfr@, ok bcallah@
[FIX] graphics/lcms2 intermittent crash (colord)
Fixes intermittent crash in graphics/colord. Patch from upstream.
okay?
Repoduced and tested with the following loop:
cd /usr/obj/ports/colord-1.3.5/colord-1.3.5/data/profiles
while LD_LIBRARY_PATH=../../client/.libs/ ../../client/.libs/cd-create-profile
--output x11-colors.icc ./x11-colors.xml; do rm x11-colors.icc; done
Index: Makefile
===
RCS file: /cvs/ports/graphics/lcms2/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile12 Jul 2019 20:47:01 - 1.16
+++ Makefile1 Oct 2019 17:51:06 -
@@ -3,6 +3,7 @@
COMMENT = color management library
DISTNAME = lcms2-2.9
+REVISION = 0
CATEGORIES = graphics
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=lcms/}
Index: patches/patch-src_cmstypes_c
===
RCS file: patches/patch-src_cmstypes_c
diff -N patches/patch-src_cmstypes_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_cmstypes_c1 Oct 2019 17:51:06 -
@@ -0,0 +1,138 @@
+$OpenBSD$
+
+fixed a out-of-bounds error on certain conditions
+https://github.com/mm2/Little-CMS/commit/9632a058a0c617a6461a1c32bc437fef87b3de9c
+
+Index: src/cmstypes.c
+--- src/cmstypes.c.orig
src/cmstypes.c
+@@ -1853,7 +1853,7 @@ Error:
+ static
+ cmsBool Type_LUT8_Write(struct _cms_typehandler_struct* self, cmsIOHANDLER*
io, void* Ptr, cmsUInt32Number nItems)
+ {
+-cmsUInt32Number j, nTabSize;
++cmsUInt32Number j, nTabSize, i, n;
+ cmsUInt8Number val;
+ cmsPipeline* NewLUT = (cmsPipeline*) Ptr;
+ cmsStage* mpe;
+@@ -1902,22 +1902,19 @@ cmsBool Type_LUT8_Write(struct _cms_typehandler_struc
+ if (!_cmsWriteUInt8Number(io, (cmsUInt8Number) clutPoints)) return FALSE;
+ if (!_cmsWriteUInt8Number(io, 0)) return FALSE; // Padding
+
++ n = NewLUT->InputChannels * NewLUT->OutputChannels;
+
+ if (MatMPE != NULL) {
+
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[0])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[1])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[2])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[3])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[4])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[5])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[6])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[7])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[8])) return FALSE;
+-
++ for (i = 0; i < n; i++)
++ {
++ if (!_cmsWrite15Fixed16Number(io, MatMPE->Double[i]))
return FALSE;
++ }
+ }
+ else {
+
++ if (n != 9) return FALSE;
++
+ if (!_cmsWrite15Fixed16Number(io, 1)) return FALSE;
+ if (!_cmsWrite15Fixed16Number(io, 0)) return FALSE;
+ if (!_cmsWrite15Fixed16Number(io, 0)) return FALSE;
+@@ -2143,7 +2140,7 @@ Error:
+ static
+ cmsBool Type_LUT16_Write(struct _cms_typehandler_struct* self, cmsIOHANDLER*
io, void* Ptr, cmsUInt32Number nItems)
+ {
+-cmsUInt32Number nTabSize;
++cmsUInt32Number nTabSize, n;
+ cmsPipeline* NewLUT = (cmsPipeline*) Ptr;
+ cmsStage* mpe;
+ _cmsStageToneCurvesData* PreMPE = NULL, *PostMPE = NULL;
+@@ -2194,21 +2191,20 @@ cmsBool Type_LUT16_Write(struct _cms_typehandler_stru
+ if (!_cmsWriteUInt8Number(io, (cmsUInt8Number) clutPoints)) return FALSE;
+ if (!_cmsWriteUInt8Number(io, 0)) return FALSE; // Padding
+
++ n = NewLUT->InputChannels * NewLUT->OutputChannels;
+
+ if (MatMPE != NULL) {
+
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[0])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[1])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[2])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[3])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[4])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[5])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[6])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[7])) return FALSE;
+-if (!_cmsWrite15Fixed16Number(io, MatMPE -> Double[8])) return FALSE;
++ for (i = 0; i < n; i++)
++ {
++ if (!_cmsWrite15Fixed16Number(io, MatMPE->Double[i]))
return FALSE;
++ }
++
+ }
+ else {
+
++ if (n != 9) return FALSE;
++
+ if (!_cmsWrite15Fixed16Number(io, 1)) return FALSE;
+ if (!_cmsWrite15Fixed16Number(io, 0)) return FALSE;
+ if (!_cmsWrite15Fixed16Number(io, 0)) return FALSE;
+@@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/10/01 11:53:51 ports/games/freedink/game/patches Update of /cvs/ports/games/freedink/game/patches In directory cvs.openbsd.org:/tmp/cvs-serv76535/patches Log Message: Directory /cvs/ports/games/freedink/game/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/10/01 11:40:30 Modified files: devel/alex : Makefile devel/hasktags : Makefile Log message: Missed REVISION bump. Noticed by naddy@.
Re: [FIX] mozilla ComputeRandomAllocationAddress
On Tue, Oct 01, 2019 at 09:34:25AM -0400, k...@intricatesoftware.com wrote: > Similar to devel/spidermonkey60 change. Allow OpenBSD's mmap to > handle ASLR by using NULL as hint to mmap. > > Built and lightly tested on amd64 (although not exactly sure > how to ensure java script is executed in thunderbird). As soon as you have a UI, pretty sure javascript runs. Maybe not the JIT, no idea. > okay? Please file a bug upstream, so that it's at least discussed with them, as i'm not the one who would be able to justify such a change there so that it's properly upstreamed later on. Sorry, no time those days. > Did I miss any copies of mozilla java script in other ports? there's www/seamonkey & www/tor-browser/browser but they're both marked BROKEN. Landry
games/ace crashes
on amd64, few days old snap (I can't upgrade now for some reasons..) >From games/ace a lot of binaries produce a segmentation fault: /tmp $ canfield Segmentation fault (core dumped) /tmp $ freecell Segmentation fault (core dumped) /tmp $ golf Segmentation fault (core dumped) /tmp $ solitaire Segmentation fault (core dumped) /tmp $ taipedit Segmentation fault (core dumped) /tmp $ thornq Segmentation fault (core dumped) /tmp $ taipei Segmentation fault (core dumped) an egdb stacktrace for solitaire shows 0x0ef60c5b99a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 (gdb) bt #0 0x0ef60c5b99a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 #1 0x0ef60c5b4517 in card_synth () from /usr/local/lib/libcards.so.0.0 #2 0x0ef60c5b737b in stack_set_card_size () from /usr/local/lib/libcards.so.0.0 #3 0x0ef3e3104cbe in ?? () #4 0x0ef60c5b3385 in table_loop () from /usr/local/lib/libcards.so.0.0 #5 0x0ef3e31033bb in ?? () #6 0x0ef3e310313b in ?? () #7 0x in ?? () for taipei 0x1107a0e0b9a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 (gdb) (gdb) bt #0 0x1107a0e0b9a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 #1 0x1105a020704f in ?? () #2 0x1105a0206a04 in ?? () #3 0x1107a0e05385 in table_loop () from /usr/local/lib/libcards.so.0.0 #4 0x1105a02053b9 in ?? () #5 0x1105a020513b in ?? () #6 0x in ?? () for golf 0x130c0bd869a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 (gdb) (gdb) bt #0 0x130c0bd869a4 in alloc_synth_image () from /usr/local/lib/libcards.so.0.0 #1 0x130c0bd81517 in card_synth () from /usr/local/lib/libcards.so.0.0 #2 0x130c0bd8437b in stack_set_card_size () from /usr/local/lib/libcards.so.0.0 #3 0x13095bc02df5 in ?? () #4 0x130c0bd80385 in table_loop () from /usr/local/lib/libcards.so.0.0 #5 0x13095bc0239a in ?? () #6 0x13095bc0213b in ?? () #7 0x in ?? ()
Re: valgrind diff to fix run memcheck on amd64
Stuart Henderson wrote: > On 2019/10/01 11:13, Kurt Mosiejczuk wrote: > > On Tue, Oct 01, 2019 at 12:42:18PM +0200, Rafael Sadowski wrote: > > > On Tue Oct 01, 2019 at 03:54:32PM +0900, Masato Asou wrote: > > > > > > Additional information: > > > > > > - Abort trap was occurred when lounched valgrind. > > > > > > $ cd /usr/ports/devel/valgrind > > > > $ make && doas make install > > > > $ valgrind /bin/ls > > > > Abort trap > > > > $ > > > > > > Sorry, I lost --strip-all option into > > > > coregrind/link_tool_exe_openbsd.in. > > > > > > New patch is below: > > > > > Thanks Masato Asou > > > > > I can confirm this patch fixes valgrind on amd64. I'm not in the > > > position to evaluate the quality of the patch, however it unbreaks > > > valgrind for me. > > > > > RS > > > > Unfortunately on my test amd64 box, valgrind still just abort traps on > > launch. > > > > eisenhower$ valgrind > > Abort trap > > eisenhower$ valgrind /bin/ls > > Abort trap > > eisenhower$ valgrind python2.7 > > Abort trap > > eisenhower$ valgrind python3.7 > > Abort trap > > eisenhower$ valgrind /bin/true > > Abort trap > > eisenhower$ > > Not sure about the pythons, but most things in base won't work due to pledge Which is a good thing. valgrind wants to do too much.
Re: valgrind diff to fix run memcheck on amd64
On 2019/10/01 11:13, Kurt Mosiejczuk wrote: > On Tue, Oct 01, 2019 at 12:42:18PM +0200, Rafael Sadowski wrote: > > On Tue Oct 01, 2019 at 03:54:32PM +0900, Masato Asou wrote: > > > > Additional information: > > > > - Abort trap was occurred when lounched valgrind. > > > > $ cd /usr/ports/devel/valgrind > > > $ make && doas make install > > > $ valgrind /bin/ls > > > Abort trap > > > $ > > > > Sorry, I lost --strip-all option into > > > coregrind/link_tool_exe_openbsd.in. > > > > New patch is below: > > > Thanks Masato Asou > > > I can confirm this patch fixes valgrind on amd64. I'm not in the > > position to evaluate the quality of the patch, however it unbreaks > > valgrind for me. > > > RS > > Unfortunately on my test amd64 box, valgrind still just abort traps on > launch. > > eisenhower$ valgrind > Abort trap > eisenhower$ valgrind /bin/ls > Abort trap > eisenhower$ valgrind python2.7 > Abort trap > eisenhower$ valgrind python3.7 > Abort trap > eisenhower$ valgrind /bin/true > Abort trap > eisenhower$ Not sure about the pythons, but most things in base won't work due to pledge
Re: [Update] converters/dos2unix : Update to 7.4.1
On 2019/10/01 14:31, wen heping wrote: > Hi, > >Here is a simple patch for converters/dos2unix: > i) Update to 7.4.1 > ii) Add another MASTER_SITE >It build well and pass all tests on amd64-head system. >No other ports depends on it. > > Comments? OK? > wen waterlan.home.xs4all.nl can use https now. what's the point in adding sourceforge?
[Update] converters/dos2unix : Update to 7.4.1
Hi, Here is a simple patch for converters/dos2unix: i) Update to 7.4.1 ii) Add another MASTER_SITE It build well and pass all tests on amd64-head system. No other ports depends on it. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/converters/dos2unix/Makefile,v retrieving revision 1.21 diff -u -p -r1.21 Makefile --- Makefile12 Jul 2019 20:43:49 - 1.21 +++ Makefile1 Oct 2019 14:26:37 - @@ -2,8 +2,7 @@ COMMENT= convert DOS/MAC files to UNIX (line-endings/charset) -DISTNAME = dos2unix-7.4.0 -REVISION = 0 +DISTNAME = dos2unix-7.4.1 CATEGORIES=converters @@ -15,7 +14,8 @@ PERMIT_PACKAGE= Yes WANTLIB += c intl -MASTER_SITES= http://waterlan.home.xs4all.nl/dos2unix/ +MASTER_SITES= http://waterlan.home.xs4all.nl/dos2unix/ \ + https://sourceforge.net/projects/dos2unix/files/dos2unix/7.4.1/ BUILD_DEPENDS= devel/gettext,-tools Index: distinfo === RCS file: /cvs/ports/converters/dos2unix/distinfo,v retrieving revision 1.17 diff -u -p -r1.17 distinfo --- distinfo14 Oct 2017 05:46:52 - 1.17 +++ distinfo1 Oct 2019 14:26:37 - @@ -1,2 +1,2 @@ -SHA256 (dos2unix-7.4.0.tar.gz) = usdlq9vZXN2HpxmJ1DgsMs88v+7iFT8Ahsuc8YJhBIo= -SIZE (dos2unix-7.4.0.tar.gz) = 710339 +SHA256 (dos2unix-7.4.1.tar.gz) = HNWKYLA+0o+jkEYQKhhcXojE92ZeHgQXwl3n+Ln3hiM= +SIZE (dos2unix-7.4.1.tar.gz) = 711570
Re: [FIX] mozilla ComputeRandomAllocationAddress
On Tue, 01 Oct 2019 07:47:44 -0600, "Theo de Raadt" wrote: > Still, I'm astounded. I haven't seen any other program trying to do this, > and I doubt even mozilla has sufficient braintrust to review the impact > of this decision on all the platforms they run. Just weird. The funny thing is they got the idea from the Windows code in V8. I don't know if chrome tries to do anything like this on non-Windows platforms. - todd
Re: [FIX] mozilla ComputeRandomAllocationAddress
Seems legit.
The strange thing about how they are emulating ASR direct from inside
the program is there's no attempt at reducing fragmentation. Without
such attempts, process teardown is very expensive as the kernel's
address space tracking datastructures have become very complicated.
That's why it is better to have the kernel do ASR. It can provide random
addresses, which are still organized to keep the address space tracking
a bit more dense.
Still, I'm astounded. I haven't seen any other program trying to do this,
and I doubt even mozilla has sufficient braintrust to review the impact
of this decision on all the platforms they run. Just weird.
k...@intricatesoftware.com wrote:
> Similar to devel/spidermonkey60 change. Allow OpenBSD's mmap to
> handle ASLR by using NULL as hint to mmap.
>
> Built and lightly tested on amd64 (although not exactly sure
> how to ensure java script is executed in thunderbird).
>
> okay?
>
> Did I miss any copies of mozilla java script in other ports?
>
> Index: mail/mozilla-thunderbird/Makefile
> ===
> RCS file: /cvs/ports/mail/mozilla-thunderbird/Makefile,v
> retrieving revision 1.296
> diff -u -p -u -r1.296 Makefile
> --- mail/mozilla-thunderbird/Makefile 22 Sep 2019 17:19:07 - 1.296
> +++ mail/mozilla-thunderbird/Makefile 30 Sep 2019 18:21:54 -
> @@ -10,6 +10,7 @@ MOZILLA_VERSION = 68.1.0
> MOZILLA_BRANCH = release
> MOZILLA_PROJECT =thunderbird
> MOZILLA_CODENAME = comm/mail
> +REVISION = 0
> EXTRACT_SUFX = .tar.xz
>
> MULTI_PACKAGES = -main -lightning
> Index:
> mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
> ===
> RCS file:
> mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
> diff -N
> mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++
> mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
> 30 Sep 2019 18:21:54 -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +Index: js/src/jit/ProcessExecutableMemory.cpp
> +--- js/src/jit/ProcessExecutableMemory.cpp.orig
> js/src/jit/ProcessExecutableMemory.cpp
> +@@ -318,6 +318,12 @@ static void DecommitPages(void* addr, size_t bytes) {
> + }
> + #else // !XP_WIN
> + static void* ComputeRandomAllocationAddress() {
> ++#ifdef __OpenBSD__
> ++ // OpenBSD already has random mmap and the idea that all x64 cpus
> ++ // have 48-bit address space is not correct. Returning nullptr
> ++ // allows OpenBSD do to the right thing.
> ++ return nullptr;
> ++#else
> + uint64_t rand = js::GenerateRandomSeed();
> +
> + # ifdef HAVE_64BIT_BUILD
> +@@ -337,6 +343,7 @@ static void* ComputeRandomAllocationAddress() {
> + // Ensure page alignment.
> + uintptr_t mask = ~uintptr_t(gc::SystemPageSize() - 1);
> + return (void*)uintptr_t(rand & mask);
> ++#endif
> + }
> +
> + static void* ReserveProcessExecutableMemory(size_t bytes) {
> Index:
> mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
> ===
> RCS file:
> /cvs/ports/mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 patch-mozilla_js_src_jit_ProcessExecutableMemory_h
> ---
> mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
>13 Sep 2019 15:05:17 - 1.5
> +++
> mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
>30 Sep 2019 18:21:54 -
> @@ -11,4 +11,4 @@ Index: js/src/jit/ProcessExecutableMemor
> +#if JS_BITS_PER_WORD == 32 || defined (__OpenBSD__)
> static const size_t MaxCodeBytesPerProcess = 140 * 1024 * 1024;
> #else
> - static const size_t MaxCodeBytesPerProcess = 1 * 1024 * 1024 * 1024;
> + // This is the largest number which satisfies various alignment static
> Index:
> mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
> ===
> RCS file:
> /cvs/ports/mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js,v
> retrieving revision 1.9
> diff -u -p -u -r1.9
> patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
> ---
> mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
> 13 Sep 2019 15:05:17 - 1.9
> +++
> mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
> 30 Sep 2019 18:21:54 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-mozilla_security_manager
> Index: security/manager/pki/resources/content/exceptionDialog.js
> ---
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/10/01 07:42:06 Modified files: devel/appstream-glib: Makefile distinfo devel/appstream-glib/patches: patch-client_as-compose_c devel/appstream-glib/pkg: PLIST Log message: Update to appstream-glib-0.7.16.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: jtur...@cvs.openbsd.org 2019/10/01 07:39:50
Modified files:
mail/opensmtpd-filters/dkimsign: Makefile
mail/opensmtpd-filters/dkimsign/pkg: PLIST
Log message:
Sample ${SYSCONFDIR}/mail/dkim as a directory not a file
OK martijn@
[FIX] mozilla ComputeRandomAllocationAddress
Similar to devel/spidermonkey60 change. Allow OpenBSD's mmap to
handle ASLR by using NULL as hint to mmap.
Built and lightly tested on amd64 (although not exactly sure
how to ensure java script is executed in thunderbird).
okay?
Did I miss any copies of mozilla java script in other ports?
Index: mail/mozilla-thunderbird/Makefile
===
RCS file: /cvs/ports/mail/mozilla-thunderbird/Makefile,v
retrieving revision 1.296
diff -u -p -u -r1.296 Makefile
--- mail/mozilla-thunderbird/Makefile 22 Sep 2019 17:19:07 - 1.296
+++ mail/mozilla-thunderbird/Makefile 30 Sep 2019 18:21:54 -
@@ -10,6 +10,7 @@ MOZILLA_VERSION = 68.1.0
MOZILLA_BRANCH = release
MOZILLA_PROJECT = thunderbird
MOZILLA_CODENAME = comm/mail
+REVISION = 0
EXTRACT_SUFX = .tar.xz
MULTI_PACKAGES = -main -lightning
Index:
mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
===
RCS file:
mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
diff -N
mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++
mail/mozilla-thunderbird/patches/patch-js_src_jit_ProcessExecutableMemory_cpp
30 Sep 2019 18:21:54 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+Index: js/src/jit/ProcessExecutableMemory.cpp
+--- js/src/jit/ProcessExecutableMemory.cpp.orig
js/src/jit/ProcessExecutableMemory.cpp
+@@ -318,6 +318,12 @@ static void DecommitPages(void* addr, size_t bytes) {
+ }
+ #else // !XP_WIN
+ static void* ComputeRandomAllocationAddress() {
++#ifdef __OpenBSD__
++ // OpenBSD already has random mmap and the idea that all x64 cpus
++ // have 48-bit address space is not correct. Returning nullptr
++ // allows OpenBSD do to the right thing.
++ return nullptr;
++#else
+ uint64_t rand = js::GenerateRandomSeed();
+
+ # ifdef HAVE_64BIT_BUILD
+@@ -337,6 +343,7 @@ static void* ComputeRandomAllocationAddress() {
+ // Ensure page alignment.
+ uintptr_t mask = ~uintptr_t(gc::SystemPageSize() - 1);
+ return (void*)uintptr_t(rand & mask);
++#endif
+ }
+
+ static void* ReserveProcessExecutableMemory(size_t bytes) {
Index:
mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
===
RCS file:
/cvs/ports/mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h,v
retrieving revision 1.5
diff -u -p -u -r1.5 patch-mozilla_js_src_jit_ProcessExecutableMemory_h
---
mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
13 Sep 2019 15:05:17 - 1.5
+++
mail/mozilla-thunderbird/patches/patch-mozilla_js_src_jit_ProcessExecutableMemory_h
30 Sep 2019 18:21:54 -
@@ -11,4 +11,4 @@ Index: js/src/jit/ProcessExecutableMemor
+#if JS_BITS_PER_WORD == 32 || defined (__OpenBSD__)
static const size_t MaxCodeBytesPerProcess = 140 * 1024 * 1024;
#else
- static const size_t MaxCodeBytesPerProcess = 1 * 1024 * 1024 * 1024;
+ // This is the largest number which satisfies various alignment static
Index:
mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
===
RCS file:
/cvs/ports/mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js,v
retrieving revision 1.9
diff -u -p -u -r1.9
patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
---
mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
13 Sep 2019 15:05:17 - 1.9
+++
mail/mozilla-thunderbird/patches/patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js
30 Sep 2019 18:21:54 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-mozilla_security_manager
Index: security/manager/pki/resources/content/exceptionDialog.js
--- security/manager/pki/resources/content/exceptionDialog.js.orig
+++ security/manager/pki/resources/content/exceptionDialog.js
-@@ -241,6 +241,7 @@ function updateCertStatus() {
+@@ -248,6 +248,7 @@ function updateCertStatus() {
// In these cases, we do want to enable the "Add Exception" button
gDialog.getButton("extra1").disabled = false;
Index:
mail/mozilla-thunderbird/patches/patch-mozilla_storage_mozStorageConnection_cpp
===
RCS file:
/cvs/ports/mail/mozilla-thunderbird/patches/patch-mozilla_storage_mozStorageConnection_cpp,v
retrieving revision 1.5
diff -u -p -u -r1.5 patch-mozilla_storage_mozStorageConnection_cpp
---
mail/mozilla-thunderbird/patches/patch-mozilla_storage_mozStorageConnection_cpp
13 Sep 2019 15:05:17 - 1.5
+++
Re: add pledge to devel/cvsweb
Hi Solene, Solene Rapenne wrote on Tue, Oct 01, 2019 at 02:15:02PM +0200: > I don't really want to work more on cvsweb, Fair enough, you get to choose what you want to work on. :-) > I did this because it's a cgi scripts run on official > cvsweb.openbsd.org website and I wanted to help there. Sure, thank you, so i'll integrate your work into 2.0.7 and 4.0.x when i find the time. Whether to commit it to the port until then - i leave that decision to other porters... > Altough it may be a good project for a port hackathon if > someone wants to read / debug some perl. Good idea. I might do that in Bukarest if people there consider it a useful idea. Yours, Ingo
Re: add pledge to devel/cvsweb
On Sun, Sep 29, 2019 at 07:37:26PM +0200, Ingo Schwarze wrote: > 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 All of what you said make sense, I did not consider looking for a newer version before trying to pledge cvsweb. I don't really want to work more on cvsweb, I did this because it's a cgi scripts run on official cvsweb.openbsd.org website and I wanted to help there.. Altough it may be a good project for a port hackathon if someone wants to read / debug some perl.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/10/01 05:38:15 Modified files: security/aide : Makefile distinfo security/aide/patches: patch-configure patch-doc_aide_1_in patch-doc_aide_conf_5_in patch-doc_aide_conf_in patch-src_util_c Log message: update to aide-0.16.2
UPDATE: net/mattermost-server
Dear all,
Please find the update for net/mattermost-server attached.
Changelog: https://docs.mattermost.com/administration/changelog.html
One more or less significant change is this one, introduced in 5.14:
"The config.json file is now generated with build time using defaults in code
and not in default.json"
Wouldn't affect exising installs, but I'd recommend to review the configuration
after each upgrade, just in case.
OK to commit?
--
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/net/mattermost-server/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile15 Sep 2019 02:04:00 - 1.16
+++ Makefile1 Oct 2019 10:56:27 -
@@ -2,11 +2,10 @@
COMMENT = open source Slack-alternative
-V =5.13.2
+V =5.15.0
GH_ACCOUNT = mattermost
GH_PROJECT = mattermost-server
GH_TAGNAME = v${V}
-REVISION = 0
MASTER_SITES0 =https://releases.mattermost.com/${V}/
@@ -29,8 +28,11 @@ MODULES =lang/go
MODGO_LDFLAGS =-X
github.com/mattermost/mattermost-server/model.BuildNumber=${V}
NO_TEST = Yes
+post-extract:
+ cp ${WRKDIR}/mattermost/config/config.json ${WRKDIST}/config/
+
pre-configure:
- ${SUBST_CMD} ${WRKDIST}/config/default.json
${WRKDIST}/utils/fileutils/fileutils.go \
+ ${SUBST_CMD} ${WRKDIST}/config/config.json
${WRKDIST}/utils/fileutils/fileutils.go \
${WRKDIST}/config/file.go
${WRKDIST}/cmd/mattermost/commands/logs.go
do-build:
@@ -41,7 +43,7 @@ do-install:
${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/mattermost ${PREFIX}/bin/
${INSTALL_DATA_DIR} ${PREFIX}/share/mattermost/
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/mattermost/
- cp ${WRKSRC}/config/default.json ${PREFIX}/share/examples/mattermost/
+ cp ${WRKSRC}/config/config.json ${PREFIX}/share/examples/mattermost/
.for _d in client fonts i18n templates
cp -Rp ${WRKDIR}/mattermost/${_d} ${PREFIX}/share/mattermost/
.endfor
Index: distinfo
===
RCS file: /cvs/ports/net/mattermost-server/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo6 Aug 2019 09:38:15 - 1.11
+++ distinfo1 Oct 2019 10:56:27 -
@@ -1,4 +1,4 @@
-SHA256 (mattermost-5.13.2-linux-amd64.tar.gz) =
TA3L/TyS9nTho6Chf1GhJhEeDZrncDOTTGyStHlAHic=
-SHA256 (mattermost-server-5.13.2.tar.gz) =
7LL7Gk9EXFVH2EhGylsW3lWSDZJrs6QaK1U381xn+G8=
-SIZE (mattermost-5.13.2-linux-amd64.tar.gz) = 127092635
-SIZE (mattermost-server-5.13.2.tar.gz) = 16001316
+SHA256 (mattermost-5.15.0-linux-amd64.tar.gz) =
heyejCaB0BhvphXv0e3frGfTrT+bOPW3BgvcS7xgtY8=
+SHA256 (mattermost-server-5.15.0.tar.gz) =
V/iQLprv1j1DCH8KGL54c9CVtehOvjvecuzrlpLvKNc=
+SIZE (mattermost-5.15.0-linux-amd64.tar.gz) = 154556059
+SIZE (mattermost-server-5.15.0.tar.gz) = 16078125
Index: patches/patch-config_config_json
===
RCS file: patches/patch-config_config_json
diff -N patches/patch-config_config_json
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-config_config_json1 Oct 2019 10:56:27 -
@@ -0,0 +1,86 @@
+$OpenBSD$
+
+Index: config/config.json
+--- config/config.json.orig
config/config.json
+@@ -128,7 +128,7 @@
+ },
+ "SqlSettings": {
+ "DriverName": "mysql",
+-"DataSource":
"mmuser:mostest@tcp(dockerhost:3306)/mattermost_test?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s",
++"DataSource":
"mmuser:mostest@tcp(localhost:3306)/mattermost_test?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s",
+ "DataSourceReplicas": [],
+ "DataSourceSearchReplicas": [],
+ "MaxIdleConns": 20,
+@@ -139,13 +139,13 @@
+ "QueryTimeout": 30
+ },
+ "LogSettings": {
+-"EnableConsole": true,
++"EnableConsole": false,
+ "ConsoleLevel": "INFO",
+ "ConsoleJson": true,
+ "EnableFile": true,
+ "FileLevel": "INFO",
+ "FileJson": true,
+-"FileLocation": "",
++"FileLocation": "${LOCALSTATEDIR}/log/mattermost",
+ "EnableWebhookDebugging": true,
+ "EnableDiagnostics": true
+ },
+@@ -171,7 +171,7 @@
+ "EnableMobileDownload": true,
+ "MaxFileSize": 52428800,
+ "DriverName": "local",
+-"Directory": "./data/",
++"Directory": "${LOCALSTATEDIR}/mattermost/data/",
+ "EnablePublicLink": false,
+ "PublicLinkSalt": "",
+ "InitialFont": "nunito-bold.ttf",
+@@ -199,8 +199,8 @@
+ "EnableSMTPAuth": false,
+ "SMTPUsername": "",
+ "SMTPPassword": "",
+-"SMTPServer": "",
+-"SMTPPort": "",
++"SMTPServer": "localhost",
++"SMTPPort": "25",
+ "ConnectionSecurity": "",
+ "SendPushNotifications": true,
+ "PushNotificationServer": "https://push-test.mattermost.com;,
+@@ -311,7 +311,7 @@
+ },
+ "ComplianceSettings": {
+ "Enable": false,
Re: valgrind diff to fix run memcheck on amd64
On Tue Oct 01, 2019 at 03:54:32PM +0900, Masato Asou wrote:
> From: Masato Asou
> Date: Fri, 27 Sep 2019 13:18:50 +0900 (JST)
>
> > Hi ports,
> >
> > This is a patch for running valgrind memcheck on amd64. I corrected
> > the following two problems.
> >
> > - FS register can be used.
> > - Fixed a problem that strip command rewrites offset and align of
> > memcheck ELF file.
>
> Additional information:
>
> - Abort trap was occurred when lounched valgrind.
>
> $ cd /usr/ports/devel/valgrind
> $ make && doas make install
> $ valgrind /bin/ls
> Abort trap
> $
>
> Sorry, I lost --strip-all option into
> coregrind/link_tool_exe_openbsd.in.
>
> New patch is below:
Thanks Masato Asou
I can confirm this patch fixes valgrind on amd64. I'm not in the
position to evaluate the quality of the patch, however it unbreaks
valgrind for me.
RS
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/valgrind/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 12 Jul 2019 20:46:03 - 1.19
> +++ Makefile 27 Sep 2019 03:08:46 -
> @@ -38,4 +38,10 @@ AUTORECONF = /bin/sh ./autogen.sh
> .if ${PROPERTIES:Mclang}
> # replace -lgcc
> MAKE_FLAGS = TOOL_LDADD_COMMON=-lcompiler_rt
> +# XXX The '-s' option was not specified when executing the install command.
> +# Instead '--strip-all' is now executed at link time.
> +# strip command rewrite offset and align in ELF file. Therefor, when valgrind
> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
> +# call.
> +INSTALL_STRIP =
> .endif
> Index: patches/patch-VEX_priv_guest_amd64_helpers_c
> ===
> RCS file: patches/patch-VEX_priv_guest_amd64_helpers_c
> diff -N patches/patch-VEX_priv_guest_amd64_helpers_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-VEX_priv_guest_amd64_helpers_c 27 Sep 2019 03:08:46
> -
> @@ -0,0 +1,16 @@
> +--- VEX/priv/guest_amd64_helpers.c.orig
> VEX/priv/guest_amd64_helpers.c
> +@@ -3744,6 +3744,13 @@ void LibVEX_GuestAMD64_initialise (
> /*OUT*/VexGuestAMD64State* vex_state )
> +/* HACK: represent the offset associated with %fs==0. This
> + assumes that %fs is only ever zero. */
> +vex_state->guest_FS_ZERO = 0;
> ++#if defined(__OpenBSD__)
> ++{
> ++ int fs;
> ++ __asm__("mov %%fs,%0" : "=r" (fs));
> ++ vex_state->guest_FS_ZERO = fs;
> ++}
> ++#endif
> +
> +vex_state->guest_RIP = 0;
> +
> Index: patches/patch-VEX_priv_guest_amd64_toIR_c
> ===
> RCS file: patches/patch-VEX_priv_guest_amd64_toIR_c
> diff -N patches/patch-VEX_priv_guest_amd64_toIR_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-VEX_priv_guest_amd64_toIR_c 27 Sep 2019 03:08:46 -
> @@ -0,0 +1,205 @@
> +--- VEX/priv/guest_amd64_toIR.c.orig
> VEX/priv/guest_amd64_toIR.c
> +@@ -312,7 +312,11 @@ static IROp mkSizedOp ( IRType ty, IROp op8 )
> +|| op8 == Iop_Shl8 || op8 == Iop_Shr8 || op8 == Iop_Sar8
> +|| op8 == Iop_CmpEQ8 || op8 == Iop_CmpNE8
> +|| op8 == Iop_CasCmpNE8
> ++#if !defined(__OpenBSD__)
> +|| op8 == Iop_Not8 );
> ++#else
> ++ || op8 == Iop_Not8 || op8 == Iop_MovFromSeg8);
> ++#endif
> +switch (ty) {
> + case Ity_I8: return 0 +op8;
> + case Ity_I16: return 1 +op8;
> +@@ -709,6 +713,12 @@ static Bool haveF3 ( Prefix pfx ) {
> +return toBool((pfx & PFX_F3) > 0);
> + }
> +
> ++#if defined(__OpenBSD__)
> ++static Bool haveFS( Prefix pfx ) {
> ++ return toBool((pfx & PFX_FS) > 0);
> ++}
> ++#endif
> ++
> + static Bool have66 ( Prefix pfx ) {
> +return toBool((pfx & PFX_66) > 0);
> + }
> +@@ -1213,7 +1223,6 @@ static void putIRegRexB ( Int sz, Prefix pfx, UInt
> lo3bits, IRExpr* e )
> +));
> + }
> +
> +-
> + /* Functions for getting register numbers from modrm bytes and REX
> +when we don't have to consider the complexities of integer subreg
> +accesses.
> +@@ -3137,6 +3146,136 @@ ULong dis_op2_G_E ( VexAbiInfo* vbi,
> + }
> +
> +
> ++#if defined(__OpenBSD__)
> ++/* Handle binary integer instructions of the form
> ++ op S, G, E meaning
> ++ op segment reg, reg, reg
> ++ Is passed the a ptr to the modRM byte, the actual operation, and the
> ++ data size. Returns the address advanced completely over this
> ++ instruction.
> ++
> ++ S(segment) is reg.
> ++ G(src) is reg.
> ++
> ++ OP %S:%G, tmp
> ++ PUT tmp, %E
> ++*/
> ++static
> ++Int dis_op3_S_G_E ( VexAbiInfo* vbi,
> ++Prefix pfx,
> ++IROpop,
> ++Int size,
> ++Longdelta0,
> ++/*OUT*/HChar* buf)
> ++{
> ++ IRType ty= szToITy(size);
> ++ IRTemp dst1 = newTemp(ty);
> ++ IRTemp off =
Re: aarch64 bulk build report
Kurt Miller: > It looks like colord failure took out a lot of ports. I am unable > to reproduce the segfault in the build log: This is a sporadic segfault. It is machine independent and happens on amd64, too. It is fairly easy to reproduce on amd64, just run colord in a build loop. Nobody has managed to debug it yet. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/10/01 04:13:32 Modified files: astro/stellarium: Makefile distinfo astro/stellarium/pkg: PLIST Log message: Update to stellarium-0.19.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/10/01 04:03:39 Modified files: fonts/spleen : Makefile distinfo Log message: Update spleen to 1.5.0.
Re: Neovim update and new libluv port
Hi,
Thanks for looking at this.
On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote:
> * 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.
Let's start with this ^
Should the package name be "libluv" or "luv"? Upstream seems to call it "luv".
> PKGVER =1.30.1.1
Since that's only used once, you might aswell inline it. Or even better,
to the replacement using make's regex support:
PKGNAME = libluv-${VER:S/-/./g}
> BUILD_DEPENDS = devel/cmake \
> devel/libuv
>
> LIB_DEPENDS = devel/libuv
If libuv is a LIB_DEPEND, I don't think you need it as a BUILD_DEPEND as well.
> CONFIGURE_ARGS =-DWITH_SHARED_LIBUV=ON \
>-DWITH_LUA_ENGINE=Lua \
>-DLUA_BUILD_TYPE=System \
>-DBUILD_MODULE=OFF \
>-DBUILD_SHARED_LIBS=ON \
Indent is odd here. I'd make all the `-D`s line up.
In Makefile and pkg/DESCR we need to use the right capitalisation for Lua and
LuaJIT:
- s/luajit/LuaJIT/g
- s/lua/Lua/g
`make port-lib-depends-check` says:
---8<---
Extra: pthread.26
--->8---
So you probably want to kill that from your WANTLIB.
I notice that the source tarball bundles some dependencies in `deps/` and uses
them once during the build:
---8<---
===> Building for libluv-1.30.1.1
[1/3] /usr/local/pobj/libluv-1.30.1.1/bin/cc -DLUA_USE_DLOPEN -Dluv_EXPORTS
-I/usr/local/include -I/usr/local/include/lua-5.1
-I/usr/local/pobj/libluv-1.30.1.1/luv-1.30.1-1/deps/lua-compat-5.3 -O2 -pipe -g
-DNDEBUG -fPIC -MD -MT CMakeFile
s/luv.dir/src/luv.c.o -MF CMakeFiles/luv.dir/src/luv.c.o.d -o
CMakeFiles/luv.dir/src/luv.c.o -c /usr/local/pobj/liblu
v-1.30.1.1/luv-1.30.1-1/src/luv.c
--->8---
So it's using `deps/lua-compat-5.3`. I notice we have a port devel/lua-compat53
already. It'd be best if you can make your port use it. Perhaps we should `rm
-rf` the `deps/` directory in `pre-build:` so as to avoid accidental usage of
bundled deps?
And finally:
---8<---
fremen$ /usr/ports/infrastructure/bin/portcheck
trailing whitespace in Makefile
--->8---
Other than these, this looks good. If you mail me a revised diff, I'll start
looking for an OK.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: valgrind diff to fix run memcheck on amd64
From: Masato Asou
Date: Fri, 27 Sep 2019 13:18:50 +0900 (JST)
> Hi ports,
>
> This is a patch for running valgrind memcheck on amd64. I corrected
> the following two problems.
>
> - FS register can be used.
> - Fixed a problem that strip command rewrites offset and align of
> memcheck ELF file.
Additional information:
- Abort trap was occurred when lounched valgrind.
$ cd /usr/ports/devel/valgrind
$ make && doas make install
$ valgrind /bin/ls
Abort trap
$
Sorry, I lost --strip-all option into
coregrind/link_tool_exe_openbsd.in.
New patch is below:
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile12 Jul 2019 20:46:03 - 1.19
+++ Makefile27 Sep 2019 03:08:46 -
@@ -38,4 +38,10 @@ AUTORECONF = /bin/sh ./autogen.sh
.if ${PROPERTIES:Mclang}
# replace -lgcc
MAKE_FLAGS = TOOL_LDADD_COMMON=-lcompiler_rt
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
+INSTALL_STRIP =
.endif
Index: patches/patch-VEX_priv_guest_amd64_helpers_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_helpers_c
diff -N patches/patch-VEX_priv_guest_amd64_helpers_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_helpers_c27 Sep 2019 03:08:46
-
@@ -0,0 +1,16 @@
+--- VEX/priv/guest_amd64_helpers.c.orig
VEX/priv/guest_amd64_helpers.c
+@@ -3744,6 +3744,13 @@ void LibVEX_GuestAMD64_initialise (
/*OUT*/VexGuestAMD64State* vex_state )
+/* HACK: represent the offset associated with %fs==0. This
+ assumes that %fs is only ever zero. */
+vex_state->guest_FS_ZERO = 0;
++#if defined(__OpenBSD__)
++{
++ int fs;
++ __asm__("mov %%fs,%0" : "=r" (fs));
++ vex_state->guest_FS_ZERO = fs;
++}
++#endif
+
+vex_state->guest_RIP = 0;
+
Index: patches/patch-VEX_priv_guest_amd64_toIR_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_toIR_c
diff -N patches/patch-VEX_priv_guest_amd64_toIR_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_toIR_c 27 Sep 2019 03:08:46 -
@@ -0,0 +1,205 @@
+--- VEX/priv/guest_amd64_toIR.c.orig
VEX/priv/guest_amd64_toIR.c
+@@ -312,7 +312,11 @@ static IROp mkSizedOp ( IRType ty, IROp op8 )
+|| op8 == Iop_Shl8 || op8 == Iop_Shr8 || op8 == Iop_Sar8
+|| op8 == Iop_CmpEQ8 || op8 == Iop_CmpNE8
+|| op8 == Iop_CasCmpNE8
++#if !defined(__OpenBSD__)
+|| op8 == Iop_Not8 );
++#else
++ || op8 == Iop_Not8 || op8 == Iop_MovFromSeg8);
++#endif
+switch (ty) {
+ case Ity_I8: return 0 +op8;
+ case Ity_I16: return 1 +op8;
+@@ -709,6 +713,12 @@ static Bool haveF3 ( Prefix pfx ) {
+return toBool((pfx & PFX_F3) > 0);
+ }
+
++#if defined(__OpenBSD__)
++static Bool haveFS( Prefix pfx ) {
++ return toBool((pfx & PFX_FS) > 0);
++}
++#endif
++
+ static Bool have66 ( Prefix pfx ) {
+return toBool((pfx & PFX_66) > 0);
+ }
+@@ -1213,7 +1223,6 @@ static void putIRegRexB ( Int sz, Prefix pfx, UInt
lo3bits, IRExpr* e )
+));
+ }
+
+-
+ /* Functions for getting register numbers from modrm bytes and REX
+when we don't have to consider the complexities of integer subreg
+accesses.
+@@ -3137,6 +3146,136 @@ ULong dis_op2_G_E ( VexAbiInfo* vbi,
+ }
+
+
++#if defined(__OpenBSD__)
++/* Handle binary integer instructions of the form
++ op S, G, E meaning
++ op segment reg, reg, reg
++ Is passed the a ptr to the modRM byte, the actual operation, and the
++ data size. Returns the address advanced completely over this
++ instruction.
++
++ S(segment) is reg.
++ G(src) is reg.
++
++ OP %S:%G, tmp
++ PUT tmp, %E
++*/
++static
++Int dis_op3_S_G_E ( VexAbiInfo* vbi,
++Prefix pfx,
++IROpop,
++Int size,
++Longdelta0,
++/*OUT*/HChar* buf)
++{
++ IRType ty= szToITy(size);
++ IRTemp dst1 = newTemp(ty);
++ IRTemp off = newTemp(ty);
++ IRTemp dst0 = newTemp(ty);
++ Long delta = delta0;
++ UChar modrm = getUChar(delta0++);
++ UChar rm= (modrm & 7);
++
++ assign(dst0, getIRegG(size, pfx, modrm));
++ assign(off, getIRegE(size, pfx, modrm | 0xc0));
++ assign(dst1, binop(op, mkexpr(dst0), mkexpr(off)));
++ putIRegG(size, pfx, modrm, mkexpr(dst1));
++
++ if (rm == 0x4) {
++ UChar tmp = getUChar(delta0++);
++ vassert(tmp == 0x24);
++ } else if (rm == 0x05) {
++ UChar tmp =
[Update] textproc/p5-String-ToIdentifier-EN : Update to 0.12
Hi, Here is a patch for textproc/p5-String-ToIdentifier-EN : i) Update to 0.12 ii) Add TEST_POD=yes and AUTHOR_TESTING=yes to MAKE_ENV It build well and passed all tests on amd64-head system. One port depends on it ：databases/p5-DBIx-Class-Schema-Loader. It build well and pass all tests with this patch. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/textproc/p5-String-ToIdentifier-EN/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile12 Jul 2019 20:50:06 - 1.6 +++ Makefile1 Oct 2019 07:10:48 - @@ -1,8 +1,7 @@ # $OpenBSD: Makefile,v 1.6 2019/07/12 20:50:06 sthen Exp $ COMMENT = convert strings to english program identifiers -DISTNAME = String-ToIdentifier-EN-0.11 -REVISION = 0 +DISTNAME = String-ToIdentifier-EN-0.12 CATEGORIES = textproc MAINTAINER = Andrew Fresh @@ -13,6 +12,7 @@ PERMIT_PACKAGE = Yes MODULES = cpan PKG_ARCH = * CONFIGURE_ARGS = --skipdeps +MAKE_ENV = TEST_POD=yes AUTHOR_TESTING=yes RUN_DEPENDS = devel/p5-namespace-clean \ textproc/p5-Lingua-EN-Inflect-Phrase \ Index: distinfo === RCS file: /cvs/ports/textproc/p5-String-ToIdentifier-EN/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo16 Mar 2014 21:57:04 - 1.2 +++ distinfo1 Oct 2019 07:10:48 - @@ -1,2 +1,2 @@ -SHA256 (String-ToIdentifier-EN-0.11.tar.gz) = 0BaNoJ2CyfFVctzoSUwpP/S4x9NFZrvVkKfP+SZ8XK0= -SIZE (String-ToIdentifier-EN-0.11.tar.gz) = 19204 +SHA256 (String-ToIdentifier-EN-0.12.tar.gz) = OvuEIykwuaxbGto4PI3VkHrk4jrsWrsBb3D56AU83Io= +SIZE (String-ToIdentifier-EN-0.12.tar.gz) = 18777
