redis-sentinel segfault workaround
I was given a reliable reproducer for the sentinel segfault that seems
to be present since at least Redis 4. I can only reproduce on amd64 and
only when compiling with -O1 or -O2, but not with -O0.
>From what I can tell, it is an out-of-bounds access trying to read from
a page without read permissions, hence the process is killed. It's
always the same line 2216 in sentinel.c:
#0 0x03dc47ed6750 in sentinelRefreshInstanceInfo (ri=0x3de5f0ac008,
info=)
at sentinel.c:2216
#1 0x03dc47f17a1f in __redisRunCallback (ac=, cb=,
reply=) at async.c:255
#2 redisProcessCallbacks (ac=0x3df2e288e00) at async.c:478
#3 0x03dc47f18097 in redisAsyncHandleRead (ac=0x3df2e288e00) at async.c:549
#4 0x03dc47e52c68 in aeProcessEvents (eventLoop=, flags=27)
at ae.c:479
#5 0x03dc47e5300d in aeMain (eventLoop=0x3deb34c6c88) at ae.c:539
#6 0x03dc47e601ec in main (argc=, argv=0x7f7c6c28) at
server.c:5173
2212 /* master_link_down_since_seconds: */
2213 if (sdslen(l) >= 32 &&
2214 !memcmp(l,"master_link_down_since_seconds",30))
2215 {
2216 ri->master_link_down_time = strtoll(l+31,NULL,10)*1000;
2217 }
Inspecting the pointer l at the crash shows:
(gdb) x /32xb l-3
0x3df3123aff8: 0x000x000x010x000xdf0xdf0xdf0xdf
0x3df3123b000: Cannot access memory at address 0x3df3123b000
since l[-1] is 1, sdslen() returns the byte stored at l-3 - see sds.h.
You can see that l itself is an empty string followed by df's, then
memory that isn't readable on the next page. The four df's are db when
using MALLOC_OPTIONS=J and 00 with j, so it's unitialized memory that
was previously freed. As sdslen(l) works out to 0, line 2216 should not
be hit...
I get similar results using printf debugging, so I don't think the
debugger lies to me.
As a last data point, when running the sentinel in the debugger, I
always saw three threads starting right before the crash.
Here's the reproducer:
$ cat > sentinel.conf
logfile ""
maxclients 100
port 26379
daemonize no
pidfile "/tmp/redis-sentinel.pid"
dir "/tmp"
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel myid 8ae1a55e5cd1228bb4f29951d799e59937357542
EOF
$ redis-server --daemonize yes
$ redis-sentinel sentinel.conf
This will lead to a segfault of the sentinel after a few minutes (it
happens sometimes after a few seconds and usually well before 10 minutes
on my laptop).
With the patch below that special cases the compilation of sentinel.c
to use -O0, I can no longer reproduce the crash. The sentinel remained
up for many hours several times.
If someone with stronger make or debugging skills than mine has
improvements or even a fix to offer, I'd be keen. The build starts with
a 'make clean', so a pre-build target in the port's Makefile probably
won't work without additional patches in the Makefile either.
Index: Makefile
===
RCS file: /var/cvs/ports/databases/redis/Makefile,v
retrieving revision 1.113
diff -u -p -r1.113 Makefile
--- Makefile14 Jun 2020 07:35:36 - 1.113
+++ Makefile23 Jun 2020 13:36:54 -
@@ -4,6 +4,7 @@ COMMENT = persistent key-value database
DISTNAME = redis-6.0.5
CATEGORIES = databases
HOMEPAGE = https://redis.io/
+REVISION = 0
# BSD
PERMIT_PACKAGE = Yes
Index: patches/patch-src_Makefile
===
RCS file: /var/cvs/ports/databases/redis/patches/patch-src_Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 patch-src_Makefile
--- patches/patch-src_Makefile 8 Jun 2020 07:32:47 - 1.32
+++ patches/patch-src_Makefile 24 Jun 2020 03:26:11 -
@@ -1,5 +1,12 @@
$OpenBSD: patch-src_Makefile,v 1.32 2020/06/08 07:32:47 tb Exp $
+Changes in this file:
+- install redis-server and redis-sentinel into ${PREFIX}/sbin
+- don't use jemalloc and bundled lua; use lua from ports.
+- do not use -funwind-tables and -latomic on armv7
+- compile sentinel.c with -O0 to avoid a redis-sentinel segfault on amd64
+- run tests with datasize, fds, stacksize and processes at the hard limit
+
Index: src/Makefile
--- src/Makefile.orig
+++ src/Makefile
@@ -65,7 +72,17 @@ Index: src/Makefile
# redis-sentinel
$(REDIS_SENTINEL_NAME): $(REDIS_SERVER_NAME)
-@@ -315,7 +318,7 @@ distclean: clean
+@@ -302,6 +305,9 @@ DEP = $(REDIS_SERVER_OBJ:%.o=%.d) $(REDIS_CLI_OBJ:%.o=
+ %.o: %.c .make-prerequisites
+ $(REDIS_CC) -MMD -o $@ -c $<
+
++sentinel.o: sentinel.c .make-prerequisites
++ $(REDIS_CC) -O0 -MMD -o $@ -c $<
++
+ clean:
+ rm -rf $(REDIS_SERVER_NAME) $(REDIS_SENTINEL_NAME) $(REDIS_CLI_NAME)
$(REDIS_BENCHMARK_NAME) $(REDIS_CHECK_RDB_NAME) $(REDIS_CHECK_AOF_NAME) *.o
*.gcda *.gcno *.gcov redis.info lcov-html Makefile.dep dict-benchmark
+ rm -f $(DEP)
+@@ -315,7 +321,7 @@ distclean: clean
.PHONY: distclean
test:
Re: CVS: cvs.openbsd.org: ports
Hi Stuart -- ‐‐‐ Original Message ‐‐‐ On Tuesday, June 23, 2020 3:14 PM, Stuart Henderson wrote: > aclocal-1.16: error: aclocal: file '/usr/local/share/aclocal/apertium.m4' > does not exist This would appear to suggest that HandBrake requires textproc/apertium, at least for the build. But, I could not find any references to apertium anywhere in the handbrake source code. I also cross-referenced other OSes, like FreeBSD and pkgsrc and Debian, and can find no dep reference to apertium in any of their handbrake packages. And indeed, I've never had apertium installed and I was able to rebuild handbrake just fine. I'm not sure what to do in this situation. ~Brian
Re: [clang+ld.bfd/all archs] Unbreak misc/osinfo/libosinfo, https HOMEPAGE
On Tue, Jun 23, 2020 at 05:51:09PM +0200, Charlene Wendling wrote:
> On Mon, 22 Jun 2020 10:26:31 +0100
> Stuart Henderson wrote:
>
> > I haven't checked but the libraries are probably really needed at
> > runtime (at least if it crashes at runtime, that's where the unwind
> > functions are most likely to be used) on clang LLD arches too. The
> > difference is that LLD will still link if there are missing symbols
> > and crash at runtime if the functions are called, ld.bfd will check
> > at link time.
> >
> > I would make it conditional on just clang rather than the linker too.
> >
> > --
> > Sent from a phone, apologies for poor formatting.
> > On 22 June 2020 09:43:51 Charlene Wendling
> > wrote:
> >
> > > On Mon, 15 Jun 2020 21:12:48 +0100
> > > Stuart Henderson wrote:
> > >
> > >> On 2020/06/15 21:46, Charlene Wendling wrote:
> > >> > Hi,
> > >> >
> > >> > libosinfo's build fails on my macppc machine with:
> > >> >
> > >> > > /usr/ports/pobj/libosinfo-1.8.0/build-powerpc/osinfo/libosinfo-1.0.so.
> > >> > > 1.5: undefined reference to `_Unwind_GetIP'
> > >> > > /usr/ports/pobj/libosinfo-1.8.0/build-powerpc/osinfo/libosinfo-1.0.so.
> > >> > > 1.5: undefined reference to `_Unwind_GetRegionStart'
> > >> > (etc.)
> > >> >
> > >> > I don't know why macppc is the only one needing that, but linking
> > >> > against libc++abi and pthread works, tests have only 1 failure,
> > >> > as seen on amd64.
> > >>
> > >> btw, same on amd64 if you set USE_LLD=No.
> > >
> > > I missed the fact that mips64 had the same issue, so the diff is now
> > > targeting clang+lb.bfd archs.
> > >
> > >> > While here i've moved HOMEPAGE to https.
> > >> >
> > >> > Comments/feedback are welcome,
> > >> >
> > >> > Charlène.
> > >> >
>
> The _Unwind_* symbols seem to come from osinfo_loader_process_user_path,
> i've tried to isolate the situation in C and vala without success. I may
> be wrong about this assumption.
>
> The only other case where it's needed is for lang/luajit, so i've
> looked at the cvs log, and there was no clear reason invoked by espie
> back then as well.
>
> So here is a diff that adds the WANTLIBs and LDFLAGS for all base-clang
> archs. I've updated the comment in case someone may think it's unneeded.
>
> Charlène.
Did you try patching out -fexceptions or -fasynchronous-unwind-tables from
meson.build?
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/misc/osinfo/Makefile.inc,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 Makefile.inc
> --- Makefile.inc 31 May 2020 10:36:21 - 1.11
> +++ Makefile.inc 23 Jun 2020 15:39:20 -
> @@ -6,7 +6,7 @@ CATEGORIES= misc devel
>
> MAINTAINER= Antoine Jacoutot
>
> -HOMEPAGE=http://libosinfo.org/
> +HOMEPAGE=https://libosinfo.org/
>
> # GPLv2+ - LGPLv2+
> PERMIT_PACKAGE= Yes
> Index: libosinfo/Makefile
> ===
> RCS file: /cvs/ports/misc/osinfo/libosinfo/Makefile,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 Makefile
> --- libosinfo/Makefile9 Jun 2020 07:14:44 - 1.12
> +++ libosinfo/Makefile23 Jun 2020 15:39:20 -
> @@ -3,7 +3,7 @@
> COMMENT= library for managing information about operating systems
>
> DISTNAME=libosinfo-${V}
> -REVISION=0
> +REVISION=1
>
> SHARED_LIBS += osinfo-1.01.5 # 0.1008.0
>
> @@ -29,5 +29,13 @@ TEST_DEPENDS= misc/osinfo/osinfo-db
>
> CONFIGURE_ARGS=
> -Dwith-pci-ids-path=${LOCALBASE}/share/hwdata/pnp.ids \
> -Dwith-usb-ids-path=${LOCALBASE}/share/hwdata/usb.ids
> +
> +.include
> +# Fix undefined reference errors to _Unwind_* on clang+ld.bfd archs;
> +# it may cause runtime issues on lld archs as well.
> +.if ${PROPERTIES:Mclang}
> +CONFIGURE_ENV += LDFLAGS="${LDFLAGS} -lc++abi -lpthread"
> +WANTLIB += c++abi pthread
> +.endif
>
> .include
> Index: osinfo-db/Makefile
> ===
> RCS file: /cvs/ports/misc/osinfo/osinfo-db/Makefile,v
> retrieving revision 1.33
> diff -u -p -u -p -r1.33 Makefile
> --- osinfo-db/Makefile31 May 2020 10:36:36 - 1.33
> +++ osinfo-db/Makefile23 Jun 2020 15:39:20 -
> @@ -3,6 +3,7 @@
> COMMENT= osinfo database files
>
> V= 20200529
> +REVISION=0
> DISTNAME=osinfo-db-${V}
> EXTRACT_SUFX=.tar.xz
>
> Index: osinfo-db-tools/Makefile
> ===
> RCS file: /cvs/ports/misc/osinfo/osinfo-db-tools/Makefile,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 Makefile
> --- osinfo-db-tools/Makefile 31 May 2020 10:36:21 - 1.11
> +++ osinfo-db-tools/Makefile 23 Jun 2020 15:39:21 -
> @@ -3,6
fonts.conf: remove defunct element (tor-browser)
This diff gets rid of the following line in ~/.xsession-error Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf The following diff is build and run tested. This diff of course serves no critical purpose but since a previous patch already exist, I guess this can be appended. Index: browser/patches/patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf === RCS file: /cvs/ports/www/tor-browser/browser/patches/patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf,v retrieving revision 1.1 diff -u -p -r1.1 patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf --- browser/patches/patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf 13 Apr 2020 16:25:42 - 1.1 +++ browser/patches/patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf 23 Jun 2020 17:17:38 - @@ -14,3 +14,21 @@ Index: tor-browser_en-US/Browser/TorBrow +- ++ + 0x0020 + 0x00A0 + 0x00AD +@@ -142,7 +142,7 @@ PERFORMANCE OF THIS SOFTWARE. + 0xFFF9 + 0xFFFA + 0xFFFB +- ++ + diff Description: Binary data
Re: http://search.cpan.org/dist/ --> https://metacpan.org/release/
On 2020/06/23 10:34, Andrew Hewus Fresh wrote:
> On Sun, Jun 21, 2020 at 08:41:03PM +0100, Stuart Henderson wrote:
> > On 2020/06/22 02:59, Yozo TODA wrote:
> > > -HOMEPAGE ?= http://search.cpan.org/dist/${DISTNAME:C/-[^-]*$//}/
> > > +HOMEPAGE ?= https://metacpan.org/release/${DISTNAME:C/-[^-]*$//}/
> >
> > It does seem a good idea, but it's a lot of work, it is necessary
> > to bump REVISION in all ports where the HOMEPAGE is changed as a
> > result of this. That is around 1700 ports.
>
>
> Does it help that perl v5.32.0 came out over the weekend and I'll be
> working on updating patches for that. Probably won't actually import it
> for a while though.
>
> That will bump libperl, but I'm not sure that actually has any effect on
> pure-perl ports.
Doing it at the same time would make the update cheaper for snapshot users
(only have to update p5-* once not twice) but the revision bumps still need
doing because +DESC will change (hash won't match).
It can be semi-automated with portbump but that often gets confused with
flavours/subpackages and maybe some other cases so there will probably be
some where it fails to bump properly, so still wants either a build test
or eyeballing "make show=PKGNAMES" before/after (test build avoids eyes
going funny looking at columns of identical-except-for-one-char names!).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/23 14:55:24 Modified files: devel/ccache : Makefile distinfo Log message: update to ccache-3.7.10
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/23 14:55:07 Modified files: textproc/pdftk : Makefile distinfo Log message: update to pdftk-3.1.3
Re: CVS: cvs.openbsd.org: ports
On 2020/06/23 19:36, Brian Callahan wrote: > Hi Stuart -- > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, June 23, 2020 3:14 PM, Stuart Henderson > wrote: > > > > aclocal-1.16: error: aclocal: file '/usr/local/share/aclocal/apertium.m4' > > does not exist > > This would appear to suggest that HandBrake requires textproc/apertium, at > least for the build. > > But, I could not find any references to apertium anywhere in the handbrake > source code. I also cross-referenced other OSes, like FreeBSD and pkgsrc and > Debian, and can find no dep reference to apertium in any of their handbrake > packages. And indeed, I've never had apertium installed and I was able to > rebuild handbrake just fine. > > I'm not sure what to do in this situation. > > ~Brian oh, i've just seen this # Yes, autoconf is called *during* the build but not at configure time... ugh. This might mean the environment/parameters aren't setup correctly, or it might be something else. I'm just reporting the error, I don't really want to untangle their strange build system, maybe someone else has an idea though.
Re: NEW: astro/gnuastro
‐‐‐ Original Message ‐‐‐ On Sunday, May 24, 2020 2:02 PM, Brian Callahan wrote: > Hi ports -- > > Attached is a new port, astro/gnuastro. These are the GNU Astronomy > Utilities. > > > > pkg/DESCR: > The GNU Astronomy Utilities (Gnuastro) is an official GNU package > consisting of various programs and library functions for the > manipulation and analysis of astronomical data. All the programs share > the same basic command-line user interface for the comfort of both the > users and developers. > > -- > > Works well and all tests pass on amd64 and sparc64. > > OK? > > ~Brian Ping. Reattached for convenience. gnuastro.tgz Description: application/compressed-tar
Re: CVS: cvs.openbsd.org: ports
On 2020/06/20 15:12, Brian Callahan wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: bcal...@cvs.openbsd.org 2020/06/20 15:12:38
>
> Modified files:
> multimedia/handbrake: Makefile distinfo
> multimedia/handbrake/pkg: PLIST
>
> Log message:
> Update to handbrake-1.3.3
> Changelog: https://github.com/HandBrake/HandBrake/releases/tag/1.3.3
>
==> failures/multimedia/handbrake.log <==
set -e; cd /pobj/handbrake-1.3.3/HandBrake-1.3.3/gtk/; NOCONFIGURE=1 autoreconf
-fiv
autoreconf-2.69: Entering directory `.'
autoreconf-2.69: running: autopoint --force
Copying file ABOUT-NLS
Copying file config.rpath
Creating directory m4
Copying file m4/codeset.m4
Copying file m4/extern-inline.m4
Copying file m4/fcntl-o.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intlmacosx.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lcmessage.m4
Copying file m4/lib-ld.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/progtest.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/threadlib.m4
Copying file m4/uintmax_t.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makevars.template
autoreconf-2.69: running: aclocal --force -I m4
aclocal-1.16: error: aclocal: file '/usr/local/share/aclocal/apertium.m4' does
not exist
autoreconf-2.69: aclocal failed with exit status: 1
gmake: *** [/pobj/handbrake-1.3.3/HandBrake-1.3.3/gtk/module.rules:16:
gtk/.stamp.configure] Error 1
*** Error 2 in multimedia/handbrake
(/usr/ports/infrastructure/mk/bsd.port.mk:2922
'/pobj/handbrake-1.3.3/build-i386/.build_done': @cd /pobj...)
*** Error 2 in multimedia/handbrake
(/usr/ports/infrastructure/mk/bsd.port.mk:2581 'build': @lock=handbrake-1.3.3;
export _LOCKS_HELD=" han...)
===> Exiting multimedia/handbrake with an error
*** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build': @:
${echo_msg:=echo}; : ${target:=build}; for i in ; do eval...)
>>> Ended at 1592910359.60
max_stuck=3.34/depends=3.57/show-prepare-results=2.26/extract=2.27/patch=0.28/configure=0.56/build=27.54
Error: job failed with 512 on i386-2 at 1592910359
Re: NEW: astro/gnuastro
On Tue, Jun 23, 2020 at 04:25:21PM +, Brian Callahan wrote: > > ‐‐‐ Original Message ‐‐‐ > On Sunday, May 24, 2020 2:02 PM, Brian Callahan > wrote: > > > Hi ports -- > > > > Attached is a new port, astro/gnuastro. These are the GNU Astronomy > > Utilities. > > > > > > > > pkg/DESCR: > > The GNU Astronomy Utilities (Gnuastro) is an official GNU package > > consisting of various programs and library functions for the > > manipulation and analysis of astronomical data. All the programs share > > the same basic command-line user interface for the comfort of both the > > users and developers. > > > > -- > > > > Works well and all tests pass on amd64 and sparc64. > > > > OK? > > > > ~Brian > > Ping. Reattached for convenience. Heh, that's pretty cool. Builds and installs fine on sparc64 and amd64. Ran `astarithmetic -q 10.32 3.84 - 2.7 pow` for fun. Ok tracey@ -- Tracey Emery
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: feine...@cvs.openbsd.org2020/06/23 12:54:24 Modified files: math/R : Makefile distinfo Log message: Update to R 4.0.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2020/06/23 11:35:41 Modified files: net/haproxy: Makefile distinfo Log message: Update to haproxy-2.0.15
Re: http://search.cpan.org/dist/ --> https://metacpan.org/release/
On Sun, Jun 21, 2020 at 08:41:03PM +0100, Stuart Henderson wrote:
> On 2020/06/22 02:59, Yozo TODA wrote:
> > -HOMEPAGE ?=http://search.cpan.org/dist/${DISTNAME:C/-[^-]*$//}/
> > +HOMEPAGE ?=https://metacpan.org/release/${DISTNAME:C/-[^-]*$//}/
>
> It does seem a good idea, but it's a lot of work, it is necessary
> to bump REVISION in all ports where the HOMEPAGE is changed as a
> result of this. That is around 1700 ports.
Does it help that perl v5.32.0 came out over the weekend and I'll be
working on updating patches for that. Probably won't actually import it
for a while though.
That will bump libperl, but I'm not sure that actually has any effect on
pure-perl ports.
l8rZ,
--
andrew - http://afresh1.com
Life's unfair - but root password helps!
Re: Xfce: display flicker on recent snaps
Hi, I'm relatively new to the ports list but I can confirm I have also had this issue with an AMD system with integrated HD 4250 graphics. On the 6.6 release I solved it by turning the compositor off in XFCE. On my new OpenBSD current system I used the fix mentioned in the XFCE pkg-readme to force use of XPresent for vblank. This seems to persist over a reboot. Regards Ed Gray On Thu, 7 May 2020 at 14:36, Amit Kulkarni wrote: > On Thu, May 7, 2020 at 1:25 AM Landry Breuil wrote: > > > > On Thu, May 07, 2020 at 08:14:56AM +0200, Landry Breuil wrote: > > > On Wed, May 06, 2020 at 10:43:14PM -0500, Amit Kulkarni wrote: > > > > Hi, > > > > > > > > Since about the last couple of days or so, the firefox display keeps > flickering every 5-7 seconds on a plain install of Xfce desktop.It looks > like the title bar of the browser keeps on turning off and then on. > > > > > > > > Is it just me or does it happen with anybody else with xfce ? > > > > This does not happen with firefox in fvwm. > > > > > > probably related to the xfwm4 update in > > > https://marc.info/?l=openbsd-ports-cvs=158840312213950=2 (see > > > https://mail.xfce.org/pipermail/xfce-announce/2020-May/000856.html), > > > flickering is usually due to xpresent being used or not for > vblank_mode. > > > (see /usr/local/share/doc/pkg-readmes/xfce where this is documented). > > > > More specifically for AMD, this is probably related to > > > https://gitlab.xfce.org/xfce/xfwm4/commit/7c00911a556c27c57c9f719c12cfda967016dc28 > > which stops prefering xpresent on those chips, cf > > https://bugzilla.xfce.org/show_bug.cgi?id=16716 > > > > Thanks for the confirmation. > >
[clang+ld.bfd/all archs] Unbreak misc/osinfo/libosinfo, https HOMEPAGE
On Mon, 22 Jun 2020 10:26:31 +0100
Stuart Henderson wrote:
> I haven't checked but the libraries are probably really needed at
> runtime (at least if it crashes at runtime, that's where the unwind
> functions are most likely to be used) on clang LLD arches too. The
> difference is that LLD will still link if there are missing symbols
> and crash at runtime if the functions are called, ld.bfd will check
> at link time.
>
> I would make it conditional on just clang rather than the linker too.
>
> --
> Sent from a phone, apologies for poor formatting.
> On 22 June 2020 09:43:51 Charlene Wendling
> wrote:
>
> > On Mon, 15 Jun 2020 21:12:48 +0100
> > Stuart Henderson wrote:
> >
> >> On 2020/06/15 21:46, Charlene Wendling wrote:
> >> > Hi,
> >> >
> >> > libosinfo's build fails on my macppc machine with:
> >> >
> >> > > /usr/ports/pobj/libosinfo-1.8.0/build-powerpc/osinfo/libosinfo-1.0.so.
> >> > > 1.5: undefined reference to `_Unwind_GetIP'
> >> > > /usr/ports/pobj/libosinfo-1.8.0/build-powerpc/osinfo/libosinfo-1.0.so.
> >> > > 1.5: undefined reference to `_Unwind_GetRegionStart'
> >> > (etc.)
> >> >
> >> > I don't know why macppc is the only one needing that, but linking
> >> > against libc++abi and pthread works, tests have only 1 failure,
> >> > as seen on amd64.
> >>
> >> btw, same on amd64 if you set USE_LLD=No.
> >
> > I missed the fact that mips64 had the same issue, so the diff is now
> > targeting clang+lb.bfd archs.
> >
> >> > While here i've moved HOMEPAGE to https.
> >> >
> >> > Comments/feedback are welcome,
> >> >
> >> > Charlène.
> >> >
The _Unwind_* symbols seem to come from osinfo_loader_process_user_path,
i've tried to isolate the situation in C and vala without success. I may
be wrong about this assumption.
The only other case where it's needed is for lang/luajit, so i've
looked at the cvs log, and there was no clear reason invoked by espie
back then as well.
So here is a diff that adds the WANTLIBs and LDFLAGS for all base-clang
archs. I've updated the comment in case someone may think it's unneeded.
Charlène.
Index: Makefile.inc
===
RCS file: /cvs/ports/misc/osinfo/Makefile.inc,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile.inc
--- Makefile.inc31 May 2020 10:36:21 - 1.11
+++ Makefile.inc23 Jun 2020 15:39:20 -
@@ -6,7 +6,7 @@ CATEGORIES= misc devel
MAINTAINER=Antoine Jacoutot
-HOMEPAGE= http://libosinfo.org/
+HOMEPAGE= https://libosinfo.org/
# GPLv2+ - LGPLv2+
PERMIT_PACKAGE=Yes
Index: libosinfo/Makefile
===
RCS file: /cvs/ports/misc/osinfo/libosinfo/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- libosinfo/Makefile 9 Jun 2020 07:14:44 - 1.12
+++ libosinfo/Makefile 23 Jun 2020 15:39:20 -
@@ -3,7 +3,7 @@
COMMENT= library for managing information about operating systems
DISTNAME= libosinfo-${V}
-REVISION= 0
+REVISION= 1
SHARED_LIBS += osinfo-1.01.5 # 0.1008.0
@@ -29,5 +29,13 @@ TEST_DEPENDS=misc/osinfo/osinfo-db
CONFIGURE_ARGS=
-Dwith-pci-ids-path=${LOCALBASE}/share/hwdata/pnp.ids \
-Dwith-usb-ids-path=${LOCALBASE}/share/hwdata/usb.ids
+
+.include
+# Fix undefined reference errors to _Unwind_* on clang+ld.bfd archs;
+# it may cause runtime issues on lld archs as well.
+.if ${PROPERTIES:Mclang}
+CONFIGURE_ENV += LDFLAGS="${LDFLAGS} -lc++abi -lpthread"
+WANTLIB += c++abi pthread
+.endif
.include
Index: osinfo-db/Makefile
===
RCS file: /cvs/ports/misc/osinfo/osinfo-db/Makefile,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 Makefile
--- osinfo-db/Makefile 31 May 2020 10:36:36 - 1.33
+++ osinfo-db/Makefile 23 Jun 2020 15:39:20 -
@@ -3,6 +3,7 @@
COMMENT= osinfo database files
V= 20200529
+REVISION= 0
DISTNAME= osinfo-db-${V}
EXTRACT_SUFX= .tar.xz
Index: osinfo-db-tools/Makefile
===
RCS file: /cvs/ports/misc/osinfo/osinfo-db-tools/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- osinfo-db-tools/Makefile31 May 2020 10:36:21 - 1.11
+++ osinfo-db-tools/Makefile23 Jun 2020 15:39:21 -
@@ -3,6 +3,7 @@
COMMENT= tools to manage the libosinfo database
DISTNAME= osinfo-db-tools-${V}
+REVISION= 0
WANTLIB += archive c gio-2.0 glib-2.0 gobject-2.0 intl json-glib-1.0
WANTLIB += soup-2.4 xml2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2020/06/23 08:55:15 Modified files: misc/open62541 : Makefile misc/open62541/patches: patch-arch_network_tcp_c Added files: misc/open62541/patches: patch-include_open62541_server_h patch-src_server_ua_services_attribute_c patch-src_server_ua_services_nodemanagement_c patch-src_ua_types_encoding_binary_c patch-tests_server_check_server_userspace_c patch-tests_server_check_services_nodemanagement_c Log message: Backport some fixes and important features from open62541 upstream. Bump library minor version.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/06/23 07:28:24 Modified files: www/chromium : Makefile distinfo Log message: update to 83.0.4103.116
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2020/06/23 07:21:23 Modified files: misc/p5-OPCUA-Open62541: Makefile distinfo Log message: update p5-OPCUA-Open62541 to 0.017
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2020/06/23 06:43:57 Modified files: net/prosody: Makefile Log message: test suite fails, it depends on busted not yet in, discussed with/OK Lucas maintainer
emulators/vbam build failure
In my latest amd64 bulk build, emulators/vbam failed to build: /bin/sh: /usr/local/bin/llvm-ar: not found Presumably it detects llvm-ar if installed at configure time, and tries to use it later. Since there is no dependency on devel/llvm, llvm-ar may have been removed by dpb junking in the meantime. There is no mention of llvm in the cmake configure output, though. Here's the full log: >>> Building on amd64-3 under emulators/vbam BDEPENDS = [devel/sdl2;multimedia/sfml;devel/cmake;devel/gettext,-runtime;devel/gettext,-tools;graphics/png;devel/ninja] DIST = [emulators/vbam:visualboyadvance-m-2.1.4.tar.gz] FULLPKGNAME = vbam-2.1.4 RDEPENDS = [multimedia/sfml;devel/gettext,-runtime;devel/sdl2;graphics/png] (Junk lock obtained for amd64-3 at 1592871627.53) >>> Running depends in emulators/vbam at 1592871627.60 last junk was in geo/py-cligj,python3 /usr/sbin/pkg_add -aI -Drepair gettext-runtime-0.20.2 gettext-tools-0.20.2 png-1.6.37 sdl2-2.0.12 sfml-2.4.0p2 was: /usr/sbin/pkg_add -aI -Drepair cmake-3.17.2p0v0 gettext-runtime-0.20.2 gettext-tools-0.20.2 ninja-1.10.0 png-1.6.37 sdl2-2.0.12 sfml-2.4.0p2 /usr/sbin/pkg_add -aI -Drepair gettext-runtime-0.20.2 gettext-tools-0.20.2 png-1.6.37 sdl2-2.0.12 sfml-2.4.0p2 >>> Running show-prepare-results in emulators/vbam at 1592871630.87 ===> emulators/vbam ===> vbam-2.1.4 depends on: gettext-tools-* -> gettext-tools-0.20.2 ===> vbam-2.1.4 depends on: cmake-* -> cmake-3.17.2p0v0 ===> vbam-2.1.4 depends on: ninja->=1.5.1 -> ninja-1.10.0 ===> vbam-2.1.4 depends on: gettext-runtime-* -> gettext-runtime-0.20.2 ===> vbam-2.1.4 depends on: sdl2-* -> sdl2-2.0.12 ===> vbam-2.1.4 depends on: png-* -> png-1.6.37 ===> vbam-2.1.4 depends on: sfml-* -> sfml-2.4.0p2 ===> Verifying specs: c++ c++abi pthread GL GLU SDL2 c iconv intl m png sfml-network sfml-system z ===> found c++.4.0 c++abi.2.1 pthread.26.1 GL.17.1 GLU.9.0 SDL2.0.8 c.96.0 iconv.7.0 intl.7.0 m.10.1 png.18.0 sfml-network.1.0 sfml-system.1.0 z.5.0 cmake-3.17.2p0v0 gettext-runtime-0.20.2 gettext-tools-0.20.2 ninja-1.10.0 png-1.6.37 sdl2-2.0.12 sfml-2.4.0p2 Don't run junk because nojunk in math/mlpack,-main (Junk lock released for amd64-3 at 1592871631.93) distfiles size=3891574 >>> Running build in emulators/vbam at 1592871631.99 ===> emulators/vbam ===> Checking files for vbam-2.1.4 `/usr/ports/distfiles/visualboyadvance-m-2.1.4.tar.gz' is up to date. >> (SHA256) visualboyadvance-m-2.1.4.tar.gz: OK ===> Extracting for vbam-2.1.4 ===> Patching for vbam-2.1.4 ===> Applying OpenBSD patch patch-CMakeLists_txt Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-CMakeLists_txt,v 1.3 2019/11/17 00:14:36 cwen Exp $ | |Fix build with ports-gcc: |eg++: error: libgomp.spec: No such file or directory | |Index: CMakeLists.txt |--- CMakeLists.txt.orig |+++ CMakeLists.txt -- Patching file CMakeLists.txt using Plan A... Hunk #1 succeeded at 526. done ===> Applying OpenBSD patch patch-src_common_Patch_cpp Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_common_Patch_cpp,v 1.3 2019/11/11 11:13:13 fcambus Exp $ | |Index: src/common/Patch.cpp |--- src/common/Patch.cpp.orig |+++ src/common/Patch.cpp -- Patching file src/common/Patch.cpp using Plan A... Hunk #1 succeeded at 15. done ===> Applying OpenBSD patch patch-src_common_Port_h Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_common_Port_h,v 1.2 2018/04/24 12:04:00 jasper Exp $ |Index: src/common/Port.h |--- src/common/Port.h.orig |+++ src/common/Port.h -- Patching file src/common/Port.h using Plan A... Hunk #1 succeeded at 14. Hunk #2 succeeded at 47. done ===> Applying OpenBSD patch patch-src_filters_xBRZ_xbrz_cpp Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_filters_xBRZ_xbrz_cpp,v 1.1 2019/11/17 00:14:36 cwen Exp $ | |Fix "error: impossible constraint in 'asm'" on !x86 | |Index: src/filters/xBRZ/xbrz.cpp |--- src/filters/xBRZ/xbrz.cpp.orig |+++ src/filters/xBRZ/xbrz.cpp -- Patching file src/filters/xBRZ/xbrz.cpp using Plan A... Hunk #1 succeeded at 66. done ===> Applying OpenBSD patch patch-src_gba_GBALink_cpp Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_gba_GBALink_cpp,v 1.2 2019/11/11 11:13:13 fcambus Exp $ | |Index: src/gba/GBALink.cpp |--- src/gba/GBALink.cpp.orig |+++ src/gba/GBALink.cpp -- Patching file src/gba/GBALink.cpp using Plan A... Hunk #1 succeeded at 4. done ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ ->
Re: UPDATE: security/luasec-0.9
Gleydson Soares wrote: > > Regarding setting NO_TEST, bsd.port.mk(5) says it should be set to Yes > > "only for ports with no regression test", so I'm not sure if using Yes > > here would be an abuse. > > yes, right. > maybe we should add a comment showing that failure is kwown. Sure, no problem. Feel free to commit it. -Lucas
Re: UPDATE: security/luasec-0.9
> Deployed this on my server and I don't see any issue so far. In fact,
> prosody is communicating over TLS without problems, so I'd it's OK
> from prosody side.
thanks for testing, i have just committed the luasec update.
> Regarding setting NO_TEST, bsd.port.mk(5) says it should be set to Yes
> "only for ports with no regression test", so I'm not sure if using Yes
> here would be an abuse.
yes, right.
maybe we should add a comment showing that failure is kwown.
? prosofy.diff
Index: Makefile
===
RCS file: /cvs/ports/net/prosody/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- Makefile2 Jun 2020 07:22:46 - 1.57
+++ Makefile23 Jun 2020 11:16:39 -
@@ -20,7 +20,10 @@ MODLUA_RUN_DEPENDS+= databases/luadbi \
devel/luafs \
security/luasec \
textproc/luaexpat>=1.3.0
+
+# fails, depends on busted not yet in
TEST_DEPENDS = ${MODLUA_RUN_DEPENDS}
+
WANTLIB+= crypto idn
CONFIGURE_STYLE=simple
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2020/06/23 05:08:26 Modified files: security/luasec: Makefile distinfo security/luasec/patches: patch-src_Makefile security/luasec/pkg: PLIST Log message: update to luasec-0.9 thanks Lucas for testing
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/23 04:50:07 Modified files: devel/harfbuzz : Makefile distinfo devel/harfbuzz/pkg: PLIST-main Log message: Update to harfbuzz-2.6.8.
[update] pgbouncer 1.14.0
Hi,
so, giving up on 1.13.0 after a month, here's 1.14.0, released the 11th
of june:
Encrypted SCRAM secrets in PgBouncer can now be used for server-side
login, so storing plain-text passwords in PgBouncer is no longer
necessary to be able to use SCRAM.
the other bits in changelog are for windows and systemd:
http://www.pgbouncer.org/changelog.html#pgbouncer-114x
ok this time ?
Landry
Index: Makefile
===
RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
retrieving revision 1.29
diff -u -r1.29 Makefile
--- Makefile12 Jul 2019 21:15:34 - 1.29
+++ Makefile23 Jun 2020 09:03:40 -
@@ -2,7 +2,7 @@
COMMENT = lightweight connection pooler for PostgreSQL
-V =1.9.0
+V =1.14.0
DISTNAME = pgbouncer-${V}
CATEGORIES = databases
@@ -14,11 +14,11 @@
# BSD
PERMIT_PACKAGE = Yes
-WANTLIB = c event crypto ssl pthread
+WANTLIB = c event_core event_extra crypto ssl
MASTER_SITES = https://pgbouncer.github.io/downloads/files/${V}/
-BUILD_DEPENDS =devel/libeventextra
+LIB_DEPENDS = devel/libevent2
CONFIGURE_STYLE = gnu
#Disable the detection of asciidoc since docs are already included
@@ -31,6 +31,6 @@
# The actual regress tests are (cd ${WRKSRC}/test; ./test.sh)
# They want to create full postgres install and also play with
# firewall (iptables)
-NO_TEST = Yes
+#NO_TEST = Yes
.include
Index: distinfo
===
RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
retrieving revision 1.12
diff -u -r1.12 distinfo
--- distinfo10 Sep 2018 12:38:35 - 1.12
+++ distinfo23 Jun 2020 09:03:40 -
@@ -1,2 +1,2 @@
-SHA256 (pgbouncer-1.9.0.tar.gz) = OeypYTOYY2Mn55y8vVtBEVA1vKnKG9NyVTlkZGiCXwQ=
-SIZE (pgbouncer-1.9.0.tar.gz) = 469300
+SHA256 (pgbouncer-1.14.0.tar.gz) = oME9EBSPVX42/37TF5Ort6SeH4sJqi1GldHCj6EB/uc=
+SIZE (pgbouncer-1.14.0.tar.gz) = 578955
Index: patches/patch-configure
===
RCS file: /cvs/ports/databases/pgbouncer/patches/patch-configure,v
retrieving revision 1.1
diff -u -r1.1 patch-configure
--- patches/patch-configure 22 Jan 2018 10:57:29 - 1.1
+++ patches/patch-configure 23 Jun 2020 09:03:40 -
@@ -3,7 +3,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -7190,7 +7190,7 @@ $as_echo_n "checking for the pthreads library -l$flag.
+@@ -7359,7 +7359,7 @@ $as_echo_n "checking for the pthreads library -l$flag.
# We try pthread_create on general principles.
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
Index: patches/patch-etc_pgbouncer_ini
===
RCS file: /cvs/ports/databases/pgbouncer/patches/patch-etc_pgbouncer_ini,v
retrieving revision 1.5
diff -u -r1.5 patch-etc_pgbouncer_ini
--- patches/patch-etc_pgbouncer_ini 22 Jan 2018 10:57:29 - 1.5
+++ patches/patch-etc_pgbouncer_ini 23 Jun 2020 09:03:40 -
@@ -2,21 +2,21 @@
Index: etc/pgbouncer.ini
--- etc/pgbouncer.ini.orig
+++ etc/pgbouncer.ini
-@@ -103,7 +103,7 @@ listen_port = 6432
+@@ -112,7 +112,7 @@ listen_port = 6432
;;;
- ; any, trust, plain, crypt, md5, cert, hba, pam
+ ;; any, trust, plain, md5, cert, hba, pam
-auth_type = trust
+auth_type = md5
- ;auth_file = /8.0/main/global/pg_auth
auth_file = /etc/pgbouncer/userlist.txt
-@@ -119,7 +119,7 @@ auth_file = /etc/pgbouncer/userlist.txt
+ ;; Path to HBA-style auth config
+@@ -127,7 +127,7 @@ auth_file = /etc/pgbouncer/userlist.txt
;;;
- ; comma-separated list of users, who are allowed to change settings
+ ;; comma-separated list of users who are allowed to change settings
-;admin_users = user2, someadmin, otheradmin
+admin_users = admin, pgbouncer
- ; comma-separated list of users who are just allowed to use SHOW command
+ ;; comma-separated list of users who are just allowed to use SHOW command
;stats_users = stats, root
Index: patches/patch-lib_usual_tls_tls_c
===
RCS file: /cvs/ports/databases/pgbouncer/patches/patch-lib_usual_tls_tls_c,v
retrieving revision 1.2
diff -u -r1.2 patch-lib_usual_tls_tls_c
--- patches/patch-lib_usual_tls_tls_c 22 Jan 2018 10:57:29 - 1.2
+++ patches/patch-lib_usual_tls_tls_c 23 Jun 2020 09:03:40 -
@@ -3,7 +3,7 @@
Index: lib/usual/tls/tls.c
--- lib/usual/tls/tls.c.orig
+++ lib/usual/tls/tls.c
-@@ -350,7 +350,7 @@ tls_info_callback(const SSL *ssl, int where, int rc)
+@@ -362,7 +362,7 @@ tls_info_callback(const SSL *ssl, int where, int rc)
{
struct tls *ctx = SSL_get_app_data(ssl);
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/pgbouncer/pkg/PLIST,v
retrieving revision 1.7
diff -u -r1.7 PLIST
--- pkg/PLIST
update games/eliot qt5 (Was: Re: Remove games/eliot)
Thomas Frohwein writes:
> On Wed, Jun 10, 2020 at 09:47:44PM +0200, Rafael Sadowski wrote:
>> I would like to delete eliot for the following reasons:
>>
>> - Segmentation fault on startup
>
> Also here on amd64.
>
>> - xscrabble (Alternative scrabble works fine here)
>> - Qt4
>
> There is a "prepare for 2.2" in the commit log, indicating that eliot
> may see a new release soon. This appears to add Qt5 support [1].
>
>> OK to delete it?
>
> I think it would be good to see if updating to a recent checkout would
> fix the seg fault and can run with Qt5 before deleting. I'm a little
> short on time today to do that myself, but hope to test this out in the
> next couple of days unless someone beats me to it.
>
> [1] http://git.savannah.nongnu.org/cgit/eliot.git/tree/configure.ac#n185
This is an update for games/eliot to qt5 with a segfault fix when
opening menus.
- Move HOMEPAGE to https
- Hosts MASTER_SITES as a tarball from a git checkout dated 2018/11/10
on my server. Does anyone have space available to host this distfile
until upstream does a new release? My VPS is cheap and not so reliable,
but if this is acceptable, I could host it.
- Moves to qt5
- CONFIGURE_STYLE autoreconf because it is not a release tarball
- Adds gettext,-tools to BUILD_DEPENDS for building translations
- do-gen line taken from Makefile.template to run autohell
Note: I omitted BUILD_DEPENDS like devel/libtool and
${MODGNU_AUTOHELL_DEPENDS} because they seem to be pulled in by
the autoreconf CONFIGURE_STYLE.
- pre-build calls e...@quot.po-create and e...@boldquot.po-create targets in
the po/Makefile. By default msgfmt fails because it expects a header
(the header is inserted by these targets) when converting the po
(portable object) files into gmo (GNU machine object).
Note: I omitted the canonical env -i ${MAKE_ENV} before
${MAKE_PROGRAM} because it strangely fails. It should not be a problem
because the *.po for quot and boldquot get headers correctly inserted
for processing by gettext's msgfmt. Also, quote and boldquot only
change quotation marks and are not really translation files.
- new qt_new_game_cpp patch for missing header
- removal of patch for utils/Makefile.in, which can be brought back with
new release. ncurses works fine still.
- I discovered a new segfault when opening any menu, resolved by
patch-qt_main_cpp. eliot adds its own MyApplication class with
superclass QApplication. MyApplication's constructor wrongly passes in
the argc argument by value because these superclasses store argc as
reference to this argument. However, this argument expires after the
constructor returns.
Opening a menu uses a codepath that eventually calls arguments().
x11/qt/qtbase's ${WRKSRC}/src/corelib/kernel/qcoreapplication.cpp
QCoreApplication::arguments() returns command-line arguments as a list
of strings.
const int ac = self->d_func()->argc;
char ** const av = self->d_func()->argv;
gdb showed that ac had a distinct, large value and different address
from main()'s argc (argc = 1 and argv[0] = /usr/local/bin/eliot
typically). The large ac caused reading past the end of av.
To resolve, heed the warning in the documentation, "Warning: The data
referred to by argc and argv must stay valid for the entire lifetime
of the QApplication object." Pass argc from main() by reference to
MyApplication and all of its superclasses, which already store
references to argc.
- Known quirks
1. I experienced a rare segfault at startup at one point during
development, as brought up by rsadowski@ and thfr@, but I can no
longer reproduce it.
2. Starting at the second turn, the rack might contain:
D+EAD?BEEF
where ? is a question mark. + is a bug and should not appear. It
actually goes away if you rearrange tiles, but the + does appear in
the game history.
3. I tested the ncurses interface. It segfaults if you forget to add
--human players.
$ eliotcurses -m d -d /usr/local/share/eliot/twl06.dawg --human player1
Feedback and tests are welcome.
Index: Makefile
===
RCS file: /cvs/ports/games/eliot/Makefile,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile
--- Makefile12 Jul 2019 20:46:17 - 1.14
+++ Makefile23 Jun 2020 08:16:51 -
@@ -1,14 +1,13 @@
# $OpenBSD: Makefile,v 1.14 2019/07/12 20:46:17 sthen Exp $
-V =2.1
+V =2.1pl20181110
COMMENT = scrabble game
DISTNAME = eliot-${V}
CATEGORIES = games
-REVISION = 5
-HOMEPAGE = http://nongnu.org/eliot/
+HOMEPAGE = https://nongnu.org/eliot/
-MASTER_SITES = ${MASTER_SITE_SAVANNAH:=eliot/releases/${V}/}
+MASTER_SITES = https://namtsui.com/source/
EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUFX}
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
@@ -22,24 +21,41 @@ MASTER_SITES0 = ${MASTER_SITE_SAVANNAH:=
# GPLv2
PERMIT_PACKAGE = Yes
-MODULES = x11/qt4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 02:27:26 Modified files: graphics/evince: Makefile distinfo Log message: update to evince-3.36.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 02:16:57 Modified files: x11/gnome/contacts: Makefile distinfo Log message: update to gnome-contacts-3.36.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 01:54:47 Modified files: x11/gnome/libgweather: Makefile distinfo x11/gnome/libgweather/patches: patch-libgweather_weather-metar_c Log message: - update to libgweather-3.36.1 - give tests a better chance at running by setting XDG_CACHE_HOME
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 01:36:53 Modified files: sysutils/py-pynetbox: Makefile distinfo Log message: update to pynetbox-4.3.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 01:35:45 Modified files: sysutils/py-croniter: Makefile distinfo Log message: update to py-croniter-0.3.34
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 01:34:17 Modified files: net/gupnp/core : Makefile distinfo net/gupnp/core/pkg: PLIST Log message: update to gupnp-1.2.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/23 01:34:11 Modified files: net/gssdp : Makefile distinfo Log message: update to gssdp-1.2.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/06/23 00:32:53 Modified files: www/chromium : Makefile www/chromium/patches: patch-base_system_sys_info_openbsd_cc Added files: www/chromium/patches: patch-base_system_sys_info_cc patch-components_autofill_core_browser_autofill_external_delegate_cc patch-components_viz_service_display_embedder_software_output_surface_cc patch-components_viz_service_display_embedder_software_output_surface_h Removed files: www/chromium/patches: patch-components_sync_device_info_device_info_sync_bridge_cc patch-components_sync_device_info_local_device_info_util_linux_cc Log message: unbreak sync to google and add some missing OS_BSD ifdefs to the viz and autofill code sync was broken because we had the a function neutered that pulled hardware information (manufacturer and model) which was required for sync to work. this commit implements this function but sends dummy information about the hardware: manufacturer is OpenBSD and the model is an empty string
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/23 00:00:27 Modified files: x11/kde-applications/akonadi: Makefile Log message: Unbreak akonadi build s/=/+=/ in second BUILD_DEPENDS. Spotted by ajacoutot@, merci
