Fix mail/mlmmj -fno-common
I've copied this patch from FreeBSD ports[1], and submitted it to what appears[2] to be the new upstream on gitlab.com[3]. This fixes the build for me on -current amd64. Apologies if this isn't formatted correctly---I'm unsure how to represent "mkdir mail/mlmmj/patches" using cvs diff, but otherwise this applies cleanly for me on a fresh checkout. [1] https://svnweb.freebsd.org/ports/head/mail/mlmmj/files/patch-gcc10?view=markup&pathrev=562279 [2] https://marc.info/?l=mlmmj&m=161122707912991&w=2 [3] https://gitlab.com/mlmmj/mlmmj diff -u -p -r1.21 Makefile --- Makefile12 Jul 2019 20:47:30 - 1.21 +++ Makefile14 Feb 2021 01:31:22 - @@ -3,6 +3,7 @@ COMMENT= mailing list manager DISTNAME= mlmmj-1.3.0 +REVISION= 1 CATEGORIES=mail HOMEPAGE= http://mlmmj.org/ diff -u -p -N /dev/null patches/patch-include_mlmmj_h --- /dev/null Sat Feb 13 20:32:13 2021 +++ patches/patch-include_mlmmj_h Sat Feb 13 20:25:12 2021 @@ -0,0 +1,22 @@ +diff --git include/mlmmj.h include/mlmmj.h +index include/mlmmj.h 100644 +--- include/mlmmj.h include/mlmmj.h +@@ -81,7 +81,7 @@ enum subtype { + SUB_NONE /* For when an address is not subscribed at all */ + }; + +-char *subtype_strs[7]; /* count matches enum above; defined in subscriberfuncs.c */ ++extern char *subtype_strs[7]; /* count matches enum above; defined in subscriberfuncs.c */ + + enum subreason { + SUB_REQUEST, +@@ -92,7 +92,7 @@ enum subreason { + SUB_SWITCH + }; + +-char * subreason_strs[6]; /* count matches enum above; defined in subscriberfuncs.c */ ++extern char * subreason_strs[6]; /* count matches enum above; defined in subscriberfuncs.c */ + + void print_version(const char *prg); +
UPDATE: games/wrath 0.0.0.20210114
Hi ports@, This updates wrath to the latest commit of the wrath-darkplaces engine which is necessary to play the new update of the commercial game Wrath: Aeon of Ruin. Tested with the new game content on amd64. Index: Makefile === RCS file: /cvs/ports/games/wrath/Makefile,v retrieving revision 1.3 diff -u -p -u -r1.3 Makefile --- Makefile9 Jun 2020 16:14:49 - 1.3 +++ Makefile14 Feb 2021 05:04:19 - @@ -2,11 +2,11 @@ COMMENT = client of wrath-darkplaces engine -DISTNAME = wrath-0.0.0.20200530 +DISTNAME = wrath-0.0.0.20210114 GH_ACCOUNT = KillPixelGames GH_PROJECT = wrath-darkplaces -GH_COMMIT =7fa67fed66335554160a7c6d8b599c69b316e027 +GH_COMMIT =2e4c399f3b6428d313d408d84f9e3ac6355a857e CATEGORIES = games Index: distinfo === RCS file: /cvs/ports/games/wrath/distinfo,v retrieving revision 1.2 diff -u -p -u -r1.2 distinfo --- distinfo9 Jun 2020 16:14:49 - 1.2 +++ distinfo14 Feb 2021 05:04:19 - @@ -1,2 +1,2 @@ -SHA256 (wrath-0.0.0.20200530-7fa67fed.tar.gz) = tLCgezvbEIeJqWMM4GBg7rA1RzVIQMrZ58svs8pnP/Y= -SIZE (wrath-0.0.0.20200530-7fa67fed.tar.gz) = 2687099 +SHA256 (wrath-0.0.0.20210114-2e4c399f.tar.gz) = SoI3jHCfGwHqVxx6msqL2rSXFc7bYat+XFdemRzGcIU= +SIZE (wrath-0.0.0.20210114-2e4c399f.tar.gz) = 2687876 Index: pkg/README === RCS file: /cvs/ports/games/wrath/pkg/README,v retrieving revision 1.2 diff -u -p -u -r1.2 README --- pkg/README 9 Jun 2020 16:14:49 - 1.2 +++ pkg/README 14 Feb 2021 05:04:19 - @@ -12,10 +12,10 @@ of the game. If you have the GOG version, you need to use innoextract to extract the data: -$ innoextract setup_wrath_aeon_of_ruin_ea_1.3.1_\(64bit\)_\(38633\).exe +$ innoextract setup_wrath_aeon_of_ruin_ea_1.4.2_\(64bit\)_\(44508\).exe To start wrath, you need to run it in a directory containing the kp1 -directory of the game or you can start wrath using the -basedir= +directory of the game or you can start wrath using the -basedir option with a directory containing kp1. For example, if you copy kp1 into a $HOME/.wrath directory: $ wrath -basedir $HOME/.wrath
Re: misc/hfsplus -fno-common
On Tue, 9 Feb 2021 23:21:08 -0500 George Koehler wrote: > On Sat, 6 Feb 2021 11:53:22 +0100 > Thaison Nguyen wrote: > > > obsd# hpmount -r /dev/rsd1i > > hpmount: /dev/rsd1i: This is not a HFS+ volume (Unknown error: -1) Here's the diff that I want to commit. Thaison, does this work with your HFS+ drive? OpenBSD devs, is this ok to commit? misc/hfsplus is old code from 2002 and has 2 problems: 1. It is broken on LP64_ARCHS (like amd64), because the C code assumes sizeof(long) == 4. 2. It is broken when the HFS+ has no HFS wrapper. (My old macppc DVD from 2005 is new enough to lack a wrapper. A text file in the wrapper would tell users of Mac OS < 8.1 that HFS+ requires Mac OS >= 8.1.) In this diff: - Simplify Makefile by setting AUTORECONF. - Fix LP64_ARCHS by changing UInt32 and like from long to int. - Most of this diff is "%ld" -> "%d" in printf()s. - Fix -fno-common from Gentoo. - Fix HFS+ with no HFS wrapper by setting vol->maxblocks. - In src/copyout.c, fix passing &size to int *lenptr. For example, copy private/etc/passwd from my old DVD: $ hpmount -rp1 /dev/cd0c# -p1 only for Apple partition map $ hpcd private $ hpcd etc # private/etc doesn't work $ hpcopy passwd . $ hpumount Index: Makefile === RCS file: /cvs/ports/misc/hfsplus/Makefile,v retrieving revision 1.34 diff -u -p -r1.34 Makefile --- Makefile26 Jan 2020 11:14:32 - 1.34 +++ Makefile12 Feb 2021 05:29:54 - @@ -5,7 +5,7 @@ COMMENT=hfsplus filesystem access tool VERSION= 1.0.4 DISTNAME= hfsplus_${VERSION} PKGNAME= hfsplus-${VERSION} -REVISION= 6 +REVISION= 7 SHARED_LIBS= hfsp0.0 CATEGORIES=misc @@ -22,12 +22,9 @@ USE_GMAKE= Yes AUTOCONF_VERSION= 2.59 AUTOMAKE_VERSION= 1.9 -BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \ - ${MODGNU_AUTOMAKE_DEPENDS} -# needs the AM_PROG_LIBTOOL macro -BUILD_DEPENDS+=devel/libtool +AUTORECONF=${MAKE_PROGRAM} -f Makefile.cvs all -CONFIGURE_STYLE= gnu +CONFIGURE_STYLE= gnu autoreconf CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \ LDFLAGS="-L${LOCALBASE}/lib" \ CFLAGS="${CFLAGS} -fgnu89-inline" @@ -37,10 +34,7 @@ WRKDIST= ${WRKDIR}/hfsplus-${VERSION} DOC= bugs.html hfsp.html libhfsp.html post-patch: - @cd ${WRKDIST} && ln -s ${LOCALBASE}/share/libtool/config/ltmain.sh \ - @cd ${WRKDIST} && env AUTOCONF_VERSION=${AUTOCONF_VERSION} \ - AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \ - ${MAKE_PROGRAM} -f Makefile.cvs all + @cd ${WRKDIST} && ln -s ${LOCALBASE}/share/libtool/config/ltmain.sh . post-install: ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/hfsplus/ Index: patches/patch-libhfsp_src_apple_h === RCS file: patches/patch-libhfsp_src_apple_h diff -N patches/patch-libhfsp_src_apple_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-libhfsp_src_apple_h 12 Feb 2021 05:29:54 - @@ -0,0 +1,21 @@ +$OpenBSD$ + +Fix LP64_ARCHS: change UInt32 and like types from long to int, so each +type has exactly 32 bits; change printf()s to match. + +Index: libhfsp/src/apple.h +--- libhfsp/src/apple.h.orig libhfsp/src/apple.h +@@ -33,9 +33,9 @@ typedef signed char SInt8; + typedef unsigned char UInt8; + typedef signed short SInt16; + typedef unsigned shortUInt16; +-typedef signed long SInt32; +-typedef unsigned long UInt32; +-typedef unsigned long OSType; ++typedef signed intSInt32; ++typedef unsigned int UInt32; ++typedef unsigned int OSType; + typedef unsigned long long UInt64; + + #define PARTITION_SIG 0x504d /* 'PM' */ Index: patches/patch-libhfsp_src_btreecheck_c === RCS file: /cvs/ports/misc/hfsplus/patches/patch-libhfsp_src_btreecheck_c,v retrieving revision 1.1 diff -u -p -r1.1 patch-libhfsp_src_btreecheck_c --- patches/patch-libhfsp_src_btreecheck_c 6 Feb 2011 16:03:55 - 1.1 +++ patches/patch-libhfsp_src_btreecheck_c 12 Feb 2021 05:29:54 - @@ -1,6 +1,124 @@ $OpenBSD: patch-libhfsp_src_btreecheck_c,v 1.1 2011/02/06 16:03:55 fgsch Exp $ libhfsp/src/btreecheck.c.orig Tue Mar 5 19:50:29 2002 -+++ libhfsp/src/btreecheck.c Fri Jan 28 07:34:59 2011 + +Fix LP64_ARCHS: change UInt32 and like types from long to int, so each +type has exactly 32 bits; change printf()s to match. + +Other changes unbreak the build. + +Index: libhfsp/src/btreecheck.c +--- libhfsp/src/btreecheck.c.orig libhfsp/src/btreecheck.c +@@ -57,7 +57,7 @@ static void record_print_key(hfsp_cat_key* key) + { + char buf[255]; // mh th
Veracrypt port, anything new
Hi Portsmonitor and ports@, Portsmonitor I just saw your Veracrypt port update that you shared here on the ML 2020-10-14 [1], thanks a lot for sharing. Searching the ML backwards, I see Joshua uploaded the port on Github in 2019 - I presume you improved on that one - and then 2019-06-28 Chris asked what about adding it to OpenBSD's ports. [2] Veracrypt would solve the problem of being able to use one and the same encrypted volume on multiple operating systems, as Veracrypt has been ported to more OSes. Since then have you made any more ports updates? In your experience how well does Veracrypt work and how fast is it? And for the ml: What about including it? Joseph [1] https://marc.info/?l=openbsd-ports&m=160267080602189&w=2 [2] https://github.com/jcs/openbsd-ports/tree/master/security/veracrypt https://marc.info/?l=openbsd-ports&w=2&r=1&s=veracrypt&q=b [3] https://marc.info/?l=openbsd-ports&m=156174296027644&w=2
Re: Remove graphics/enjoympeg?
On Sun, Feb 14, 2021 at 12:06:31AM +0100, Christian Weisgerber wrote: > graphics/enjoympeg fails to build with -fno-error. A glance at DESCR > Enjoympeg is a MPEG-1 video player based on the source > of plaympeg from the SMPEG library. It has [... who cares...] > makes me think that this port can be removed. FreeBSD did so about > a decade ago. MPEG-1 video (Video CD) is laughably obsolete. > FFmpeg etc. can still handle it if somebody is really sitting on > an archive of VHS-quality videos. ok kmos@ to remove --Kurt
Re: UPDATE: lang/snobol4 2.0 => 2.2.1 (incl. -fno-common fixes)
Greg, thanks for this. I was intending to deal with this but I've been impeded with health issues of late. Now I can work on my thinkpad problems. There are actually users. Among people I've gotten to dabble in Openbsd, at least three are learning string processing languages like snobol and icon. Neat. STeve Feb 13, 2021 18:08:58 Greg Steuck : > Brian Callahan writes: > >> Hello -- >> >> Attached is a patch to update snobol4 to its latest version, which >> (among other things) fixes -fno-common issues. >> >> I added the COMPILER line because I ended up ^C'ing trying to build >> snobol4 with base-gcc on amd64 for taking way too long. The build >> times are reasonable with clang and ports-gcc. >> >> I added SUBST_VARS += V to help reduce PLIST churn in the future. >> >> Things work as expected on amd64. >> >> OK? > > OK gnezdo@ > >> >> ~Brian >> >> Index: Makefile >> === >> RCS file: /cvs/ports/lang/snobol4/Makefile,v >> retrieving revision 1.4 >> diff -u -p -r1.4 Makefile >> --- Makefile 12 Jul 2019 20:47:23 - 1.4 >> +++ Makefile 13 Feb 2021 16:46:46 - >> @@ -1,9 +1,9 @@ >> # $OpenBSD: Makefile,v 1.4 2019/07/12 20:47:23 sthen Exp $ >> >> +V = 2.2.1 >> COMMENT = CSNOBOL4 suite including interpreter, debugger and utilities >> -DISTNAME = snobol4-2.0 >> +DISTNAME = snobol4-${V} >> CATEGORIES = lang >> -REVISION = 1 >> >> HOMEPAGE = http://www.snobol4.org/csnobol4/curr/ >> MAINTAINER = STeve Andre >> @@ -11,10 +11,12 @@ MAINTAINER = STeve Andre > # BSD >> PERMIT_PACKAGE = Yes >> >> -WANTLIB += c ffi m ncurses readline sqlite3 util >> +WANTLIB += c crypto ffi m readline sqlite3 ssl util z >> >> MASTER_SITES = ftp://ftp.snobol4.org/snobol/ >> >> +COMPILER = base-clang ports-gcc >> + >> LIB_DEPENDS = databases/sqlite3 \ >> devel/libffi >> >> @@ -25,5 +27,7 @@ CONFIGURE_ARGS = --prefix="${PREFIX}" \ >> >> # Reduce PLIST churn at update time. >> FAKE_FLAGS = DOC_DIR="${DESTDIR}${PREFIX}/share/doc/snobol4" >> + >> +SUBST_VARS += V >> >> .include >> Index: distinfo >> === >> RCS file: /cvs/ports/lang/snobol4/distinfo,v >> retrieving revision 1.1.1.1 >> diff -u -p -r1.1.1.1 distinfo >> --- distinfo 6 Nov 2017 08:14:14 - 1.1.1.1 >> +++ distinfo 13 Feb 2021 16:46:46 - >> @@ -1,2 +1,2 @@ >> -SHA256 (snobol4-2.0.tar.gz) = lK569PyqkTmVTG1TDKkfJf/Xpp/0XxulK1IJW732Yx8= >> -SIZE (snobol4-2.0.tar.gz) = 903436 >> +SHA256 (snobol4-2.2.1.tar.gz) = 0w/eqzsCnmcAJW/GNPt4rxIQdxEjRJZ8Zbh3gJK34QE= >> +SIZE (snobol4-2.2.1.tar.gz) = 984384 >> Index: patches/patch-Makefile2_m4 >> === >> RCS file: /cvs/ports/lang/snobol4/patches/patch-Makefile2_m4,v >> retrieving revision 1.1.1.1 >> diff -u -p -r1.1.1.1 patch-Makefile2_m4 >> --- patches/patch-Makefile2_m4 6 Nov 2017 08:14:14 - 1.1.1.1 >> +++ patches/patch-Makefile2_m4 13 Feb 2021 16:46:46 - >> @@ -3,16 +3,16 @@ $OpenBSD: patch-Makefile2_m4,v 1.1.1.1 2 >> Index: Makefile2.m4 >> --- Makefile2.m4.orig >> +++ Makefile2.m4 >> -@@ -636,9 +636,9 @@ install: snobol4 sdb timing.out $(GENERATED_DOCS) >> +@@ -735,9 +735,9 @@ install_notiming: build_all >> $(INSTALL) sdb $(BINDIR)/sdb-$(VERS) >> $(INSTALL) snopea $(BINDIR)/snopea-$(VERS) >> rm -f $(BINDIR)/snobol4 $(BINDIR)/sdb $(BINDIR)/snopea >> -- ln -s $(BINDIR)/snobol4-$(VERS) $(BINDIR)/snobol4 >> -- ln -s $(BINDIR)/sdb-$(VERS) $(BINDIR)/sdb >> -- ln -s $(BINDIR)/snopea-$(VERS) $(BINDIR)/snopea >> +- cd $(BINDIR) && ln -s snobol4-$(VERS) snobol4 >> +- cd $(BINDIR) && ln -s sdb-$(VERS) sdb >> +- cd $(BINDIR) && ln -s snopea-$(VERS) snopea >> + $(INSTALL) $(INSTALL_BIN_FLAGS) snobol4 $(BINDIR)/snobol4 >> + $(INSTALL) sdb $(BINDIR)/sdb >> + $(INSTALL) snopea $(BINDIR)/snopea >> $(INSTALL) -d $(MAN1DIR) >> - for F in $(GENERATED_DOCS_DOCDIR1); do \ >> - $(INSTALL) -m 644 $$F $(MAN1DIR); \ >> + INSTALL_MAN_PAGES(.,1) >> + INSTALL_MAN_PAGES(doc,1) >> Index: patches/patch-configure >> === >> RCS file: patches/patch-configure >> diff -N patches/patch-configure >> --- patches/patch-configure 6 Nov 2017 08:14:14 - 1.1.1.1 >> +++ /dev/null 1 Jan 1970 00:00:00 - >> @@ -1,67 +0,0 @@ >> -$OpenBSD: patch-configure,v 1.1.1.1 2017/11/06 08:14:14 bcallah Exp $ >> - >> -Just lie. Does the wrong thing if you don't tell it you're using gcc. >> - >> -Index: configure >> configure.orig >> -+++ configure >> -@@ -13,10 +13,7 @@ OPTIONS="$*" >> - VERSION=2.0 >> - VERSION_DATE="January 1, 2015" >> - >> --if [ ! "$CC" ]; then >> -- # on most system gcc is preferred if it can be found >> -- WANTGCC=true >> --fi >> -+WANTGCC=true >> - >> - # save any CFLAGS passed to us... >> - INITIAL_CFLAGS="$CFLAGS" >> -@@ -366,21 +363,9 @@ echo '#define HAVE_BUILD_VARS' >> $CONFIG_H >> - >> - if [ "$CC" ]; t
Re: UPDATE: games/opentyrian 2.1.20130907 => 2.1.20201204 (incl. -fno-common fixes)
Brian Callahan writes: > Hi ports -- > > Attached is a diff to update games/opentyrian. Among other things, it > includes -fno-common fixes. > > While there has been no new official releases, development has moved > to GitHub, where there has been activity ever since the last release. > I chose to move there, and grab the latest head of their git tree. > This additionally sees the game move from SDL to SDL2. > > I kept the same installation structure as before. > > Works on amd64. > > OK? OK gnezdo@ > > ~Brian > > Index: Makefile > === > RCS file: /cvs/ports/games/opentyrian/Makefile,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile > --- Makefile 12 Jul 2019 20:46:22 - 1.5 > +++ Makefile 13 Feb 2021 17:33:41 - > @@ -1,33 +1,34 @@ > # $OpenBSD: Makefile,v 1.5 2019/07/12 20:46:22 sthen Exp $ > > -V = 2.1.20130907 > +V = 2.1.20201204 > COMMENT =port of the DOS shoot-em-up Tyrian > -DISTNAME = opentyrian-${V}-src > -PKGNAME =opentyrian-${V} > -REVISION = 1 > +DISTNAME = opentyrian-${V} > CATEGORIES = games x11 > > -HOMEPAGE = https://bitbucket.org/opentyrian/opentyrian/ > +# No new releases... but years of activity > +GH_ACCOUNT = opentyrian > +GH_PROJECT = opentyrian > +GH_COMMIT = 650e1f72fd18d2242d10d706afa7f77f80151aea > > # GPLv2+ > PERMIT_PACKAGE = Yes > > -MASTER_SITES = http://www.camanis.net/opentyrian/releases/ > - > -WANTLIB += SDL SDL_net c m pthread > +WANTLIB += SDL2 SDL2_net c m > > RUN_DEPENDS =archivers/unzip > -LIB_DEPENDS =devel/sdl-net > +LIB_DEPENDS =devel/sdl2-net > > USE_GMAKE = Yes > MAKE_FLAGS = CC="${CC}" \ > MAKECMDGOALS=release > > -WRKDIST =${WRKDIR}/opentyrian-${V} > +FAKE_FLAGS = mandir="${PREFIX}/man" > > -do-install: > - ${SUBST_PROGRAM} ${FILESDIR}/opentyrian ${PREFIX}/bin/opentyrian > +NO_TEST =Yes > + > +post-install: > ${INSTALL_DATA_DIR} ${PREFIX}/share/opentyrian > - ${INSTALL_PROGRAM} ${WRKSRC}/opentyrian > ${PREFIX}/share/opentyrian/opentyrian > + mv ${PREFIX}/bin/opentyrian ${PREFIX}/share/opentyrian/opentyrian > + ${SUBST_PROGRAM} ${FILESDIR}/opentyrian ${PREFIX}/bin/opentyrian > > .include > Index: distinfo > === > RCS file: /cvs/ports/games/opentyrian/distinfo,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 distinfo > --- distinfo 24 Mar 2014 09:08:55 - 1.1.1.1 > +++ distinfo 13 Feb 2021 17:33:41 - > @@ -1,2 +1,2 @@ > -SHA256 (opentyrian-2.1.20130907-src.tar.gz) = > 9UtrPO3O+hh8n2BdYWSq4p7EanMabfMNNRr0wAje5F8= > -SIZE (opentyrian-2.1.20130907-src.tar.gz) = 297517 > +SHA256 (opentyrian-2.1.20201204-650e1f72.tar.gz) = > 264l1jmasGRczg8Pnxtus4IZGsKEkkAb4C33HDAzf2s= > +SIZE (opentyrian-2.1.20201204-650e1f72.tar.gz) = 297432 > Index: pkg/PLIST > === > RCS file: /cvs/ports/games/opentyrian/pkg/PLIST,v > retrieving revision 1.2 > diff -u -p -r1.2 PLIST > --- pkg/PLIST 4 Sep 2018 12:46:13 - 1.2 > +++ pkg/PLIST 13 Feb 2021 17:33:41 - > @@ -1,5 +1,10 @@ > @comment $OpenBSD: PLIST,v 1.2 2018/09/04 12:46:13 espie Exp $ > bin/opentyrian > +@man man/man6/opentyrian.6 > +share/doc/opentyrian/ > +share/doc/opentyrian/CREDITS > +share/doc/opentyrian/NEWS > +share/doc/opentyrian/README > share/doc/pkg-readmes/${PKGSTEM} > share/opentyrian/ > @bin share/opentyrian/opentyrian
Remove graphics/enjoympeg?
graphics/enjoympeg fails to build with -fno-error. A glance at DESCR Enjoympeg is a MPEG-1 video player based on the source of plaympeg from the SMPEG library. It has [... who cares...] makes me think that this port can be removed. FreeBSD did so about a decade ago. MPEG-1 video (Video CD) is laughably obsolete. FFmpeg etc. can still handle it if somebody is really sitting on an archive of VHS-quality videos. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: UPDATE: lang/snobol4 2.0 => 2.2.1 (incl. -fno-common fixes)
Brian Callahan writes: > Hello -- > > Attached is a patch to update snobol4 to its latest version, which > (among other things) fixes -fno-common issues. > > I added the COMPILER line because I ended up ^C'ing trying to build > snobol4 with base-gcc on amd64 for taking way too long. The build > times are reasonable with clang and ports-gcc. > > I added SUBST_VARS += V to help reduce PLIST churn in the future. > > Things work as expected on amd64. > > OK? OK gnezdo@ > > ~Brian > > Index: Makefile > === > RCS file: /cvs/ports/lang/snobol4/Makefile,v > retrieving revision 1.4 > diff -u -p -r1.4 Makefile > --- Makefile 12 Jul 2019 20:47:23 - 1.4 > +++ Makefile 13 Feb 2021 16:46:46 - > @@ -1,9 +1,9 @@ > # $OpenBSD: Makefile,v 1.4 2019/07/12 20:47:23 sthen Exp $ > > +V = 2.2.1 > COMMENT =CSNOBOL4 suite including interpreter, debugger and utilities > -DISTNAME = snobol4-2.0 > +DISTNAME = snobol4-${V} > CATEGORIES = lang > -REVISION = 1 > > HOMEPAGE = http://www.snobol4.org/csnobol4/curr/ > MAINTAINER = STeve Andre > @@ -11,10 +11,12 @@ MAINTAINER = STeve Andre # BSD > PERMIT_PACKAGE = Yes > > -WANTLIB += c ffi m ncurses readline sqlite3 util > +WANTLIB += c crypto ffi m readline sqlite3 ssl util z > > MASTER_SITES = ftp://ftp.snobol4.org/snobol/ > > +COMPILER = base-clang ports-gcc > + > LIB_DEPENDS =databases/sqlite3 \ > devel/libffi > > @@ -25,5 +27,7 @@ CONFIGURE_ARGS =--prefix="${PREFIX}" \ > > # Reduce PLIST churn at update time. > FAKE_FLAGS = DOC_DIR="${DESTDIR}${PREFIX}/share/doc/snobol4" > + > +SUBST_VARS +=V > > .include > Index: distinfo > === > RCS file: /cvs/ports/lang/snobol4/distinfo,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 distinfo > --- distinfo 6 Nov 2017 08:14:14 - 1.1.1.1 > +++ distinfo 13 Feb 2021 16:46:46 - > @@ -1,2 +1,2 @@ > -SHA256 (snobol4-2.0.tar.gz) = lK569PyqkTmVTG1TDKkfJf/Xpp/0XxulK1IJW732Yx8= > -SIZE (snobol4-2.0.tar.gz) = 903436 > +SHA256 (snobol4-2.2.1.tar.gz) = 0w/eqzsCnmcAJW/GNPt4rxIQdxEjRJZ8Zbh3gJK34QE= > +SIZE (snobol4-2.2.1.tar.gz) = 984384 > Index: patches/patch-Makefile2_m4 > === > RCS file: /cvs/ports/lang/snobol4/patches/patch-Makefile2_m4,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 patch-Makefile2_m4 > --- patches/patch-Makefile2_m46 Nov 2017 08:14:14 - 1.1.1.1 > +++ patches/patch-Makefile2_m413 Feb 2021 16:46:46 - > @@ -3,16 +3,16 @@ $OpenBSD: patch-Makefile2_m4,v 1.1.1.1 2 > Index: Makefile2.m4 > --- Makefile2.m4.orig > +++ Makefile2.m4 > -@@ -636,9 +636,9 @@ install: snobol4 sdb timing.out $(GENERATED_DOCS) > +@@ -735,9 +735,9 @@ install_notiming: build_all > $(INSTALL) sdb $(BINDIR)/sdb-$(VERS) > $(INSTALL) snopea $(BINDIR)/snopea-$(VERS) > rm -f $(BINDIR)/snobol4 $(BINDIR)/sdb $(BINDIR)/snopea > --ln -s $(BINDIR)/snobol4-$(VERS) $(BINDIR)/snobol4 > --ln -s $(BINDIR)/sdb-$(VERS) $(BINDIR)/sdb > --ln -s $(BINDIR)/snopea-$(VERS) $(BINDIR)/snopea > +-cd $(BINDIR) && ln -s snobol4-$(VERS) snobol4 > +-cd $(BINDIR) && ln -s sdb-$(VERS) sdb > +-cd $(BINDIR) && ln -s snopea-$(VERS) snopea > +$(INSTALL) $(INSTALL_BIN_FLAGS) snobol4 $(BINDIR)/snobol4 > +$(INSTALL) sdb $(BINDIR)/sdb > +$(INSTALL) snopea $(BINDIR)/snopea > $(INSTALL) -d $(MAN1DIR) > - for F in $(GENERATED_DOCS_DOCDIR1); do \ > - $(INSTALL) -m 644 $$F $(MAN1DIR); \ > + INSTALL_MAN_PAGES(.,1) > + INSTALL_MAN_PAGES(doc,1) > Index: patches/patch-configure > === > RCS file: patches/patch-configure > diff -N patches/patch-configure > --- patches/patch-configure 6 Nov 2017 08:14:14 - 1.1.1.1 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,67 +0,0 @@ > -$OpenBSD: patch-configure,v 1.1.1.1 2017/11/06 08:14:14 bcallah Exp $ > - > -Just lie. Does the wrong thing if you don't tell it you're using gcc. > - > -Index: configure > configure.orig > -+++ configure > -@@ -13,10 +13,7 @@ OPTIONS="$*" > - VERSION=2.0 > - VERSION_DATE="January 1, 2015" > - > --if [ ! "$CC" ]; then > --# on most system gcc is preferred if it can be found > --WANTGCC=true > --fi > -+WANTGCC=true > - > - # save any CFLAGS passed to us... > - INITIAL_CFLAGS="$CFLAGS" > -@@ -366,21 +363,9 @@ echo '#define HAVE_BUILD_VARS' >> > $CONFIG_H > - > - if [ "$CC" ]; then > - echo 'using CC environment variable' 1>&2 > --CCPATH="$CC" > -+GCCPATH="$CC" > - fi > - > --if [ "$WANTGCC" ]; then > --# look for gcc up front (for Solaris/x86) > --echo 'looking for gcc' 1>&2 > --for DIR in `echo $PATH | tr ':' ' '`; do > --if [ -x $DIR/gcc ]; then > --echo "fou
Re: UPDATE: math/pspp 1.2.0 => 1.4.1 (incl. -fno-common fixes)
Brian Callahan writes: > Hi ports -- > > Attached is an update to math/pspp. > The major upstream changelog (to 1.4.0) is here: > http://savannah.gnu.org/forum/forum.php?forum_id=9795 > > Also fixes -fno-common errors. > > All tests pass on amd64. > > OK? OK gnezdo@
Re: devel/avr32 -fno-common fixes
Christian Weisgerber writes: > The GNU toolchain explicitly avoids common variables. Whoever > hacked up this derived version didn't understand that. > > * binutils: Since linkrelax is already defined as a global variable, > it is already initialized to 0, so we can simply drop this > initialization. > > * gcc-bootstrap, gcc: Use the mechanism provided by the .opt file > processing to initialize these globals. > > With this, devel/avr32/* builds. > > OK? OK gnezdo@ > Index: binutils/Makefile > === > RCS file: /cvs/ports/devel/avr32/binutils/Makefile,v > retrieving revision 1.4 > diff -u -p -r1.4 Makefile > --- binutils/Makefile 12 Jul 2019 21:15:34 - 1.4 > +++ binutils/Makefile 12 Feb 2021 22:41:54 - > @@ -2,6 +2,7 @@ > > COMMENT =Atmel AVR 32-bit binutils > V = 2.23.1 > +REVISION = 0 > DISTNAME = avr32-binutils-${V} > > # GPLv3 > Index: binutils/patches/patch-gas_config_tc-avr32_c > === > RCS file: binutils/patches/patch-gas_config_tc-avr32_c > diff -N binutils/patches/patch-gas_config_tc-avr32_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ binutils/patches/patch-gas_config_tc-avr32_c 12 Feb 2021 22:41:54 > - > @@ -0,0 +1,15 @@ > +$OpenBSD$ > + > +fix for -fno-common > + > +Index: gas/config/tc-avr32.c > +--- gas/config/tc-avr32.c.orig > gas/config/tc-avr32.c > +@@ -47,7 +47,6 @@ > + > + /* Flags given on the command line */ > + static int avr32_pic= FALSE; > +-int linkrelax = FALSE; > + int avr32_iarcompat = FALSE; > + > + /* This array holds the chars that always start a comment. */ > Index: gcc/Makefile > === > RCS file: /cvs/ports/devel/avr32/gcc/Makefile,v > retrieving revision 1.8 > diff -u -p -r1.8 Makefile > --- gcc/Makefile 15 Jan 2021 19:03:58 - 1.8 > +++ gcc/Makefile 12 Feb 2021 22:41:54 - > @@ -3,7 +3,7 @@ > COMMENT =Atmel AVR 32-bit gcc > V = 4.4.7 > DISTNAME = avr32-gcc-${V} > -REVISION = 1 > +REVISION = 2 > > # GPLv3 > PERMIT_PACKAGE = Yes > Index: gcc/patches/patch-gcc_config_avr32_avr32_c > === > RCS file: gcc/patches/patch-gcc_config_avr32_avr32_c > diff -N gcc/patches/patch-gcc_config_avr32_avr32_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ gcc/patches/patch-gcc_config_avr32_avr32_c12 Feb 2021 22:41:54 > - > @@ -0,0 +1,18 @@ > +$OpenBSD$ > + > +fix for -fno-common > + > +Index: gcc/config/avr32/avr32.c > +--- gcc/config/avr32/avr32.c.orig > gcc/config/avr32/avr32.c > +@@ -207,10 +207,6 @@ static const struct arch_type_s avr32_arch_types[] = { > + {NULL, 0, 0, 0, NULL} > + }; > + > +-/* Default arch name */ > +-const char *avr32_arch_name = "none"; > +-const char *avr32_part_name = "none"; > +- > + const struct part_type_s *avr32_part; > + const struct arch_type_s *avr32_arch; > + > Index: gcc/patches/patch-gcc_config_avr32_avr32_opt > === > RCS file: gcc/patches/patch-gcc_config_avr32_avr32_opt > diff -N gcc/patches/patch-gcc_config_avr32_avr32_opt > --- /dev/null 1 Jan 1970 00:00:00 - > +++ gcc/patches/patch-gcc_config_avr32_avr32_opt 12 Feb 2021 22:41:54 > - > @@ -0,0 +1,25 @@ > +$OpenBSD$ > + > +fix for -fno-common > + > +Index: gcc/config/avr32/avr32.opt > +--- gcc/config/avr32/avr32.opt.orig > gcc/config/avr32/avr32.opt > +@@ -56,7 +56,7 @@ Target Report Mask(HAS_ASM_ADDR_PSEUDOS) > + Use assembler pseudo-instructions lda.w and call for handling direct > addresses. (Enabled by default) > + > + mpart= > +-Target Report RejectNegative Joined Var(avr32_part_name) > ++Target Report RejectNegative Joined Var(avr32_part_name) Init("none") > + Specify the AVR32 part name > + > + mcpu= > +@@ -64,7 +64,7 @@ Target Report RejectNegative Joined Undocumented Var(a > + Specify the AVR32 part name (deprecated) > + > + march= > +-Target Report RejectNegative Joined Var(avr32_arch_name) > ++Target Report RejectNegative Joined Var(avr32_arch_name) Init("none") > + Specify the AVR32 architecture name > + > + mfast-float > Index: gcc-bootstrap/Makefile > === > RCS file: /cvs/ports/devel/avr32/gcc-bootstrap/Makefile,v > retrieving revision 1.8 > diff -u -p -r1.8 Makefile > --- gcc-bootstrap/Makefile9 Jan 2021 21:41:16 - 1.8 > +++ gcc-bootstrap/Makefile12 Feb 2021 22:41:54 - > @@ -7,7 +7,7 @@ PKGNAME = avr32-gcc-bootstrap-${V} > > # GPLv3 > PERMIT_PACKAGE = Yes > -REVISION = 1 > +REVISION = 2 > > WANTLIB =c gmp mpfr > DIST_SUBDIR =gcc > Index: gcc-bootstrap/patches/patch-gcc_config_avr32_avr32_c >
move games/hypatia to python3
seems to work ok under python3, gets rid of a py2-Pillow consumer. Also remove dead HOMEPAGE. ok? Index: Makefile === RCS file: /cvs/ports/games/hypatia/Makefile,v retrieving revision 1.21 diff -u -p -u -r1.21 Makefile --- Makefile24 Nov 2020 16:44:16 - 1.21 +++ Makefile13 Feb 2021 22:26:59 - @@ -7,21 +7,20 @@ SUBST_VARS += GH_TAGNAME GH_ACCOUNT = hypatia-engine GH_PROJECT = hypatia GH_TAGNAME = 0.3.6 -REVISION = 1 - -HOMEPAGE = http://engine.hypatia.software/ +REVISION = 2 # MIT PERMIT_PACKAGE = Yes MODULES = lang/python + MODPY_SETUPTOOLS = Yes +MODPY_VERSION =${MODPY_DEFAULT_VERSION_3} -RUN_DEPENDS = devel/py-enum34 \ - devel/pygame${MODPY_FLAVOR}>=1.9.1 \ - graphics/py2-Pillow +RUN_DEPENDS = devel/pygame${MODPY_FLAVOR}>=1.9.1 \ + graphics/py-Pillow${MODPY_FLAVOR} -TEST_DEPENDS = graphics/py2-Pillow +TEST_DEPENDS = graphics/py-Pillow${MODPY_FLAVOR} WRKDIST = ${WRKDIR}/hypatia-engine-${GH_TAGNAME} Index: pkg/PLIST === RCS file: /cvs/ports/games/hypatia/pkg/PLIST,v retrieving revision 1.6 diff -u -p -u -r1.6 PLIST --- pkg/PLIST 12 Dec 2015 20:23:03 - 1.6 +++ pkg/PLIST 13 Feb 2021 22:26:59 - @@ -2,33 +2,34 @@ bin/hypatia-demo lib/python${MODPY_VERSION}/site-packages/hypatia/ lib/python${MODPY_VERSION}/site-packages/hypatia/__init__.py -lib/python${MODPY_VERSION}/site-packages/hypatia/__init__.pyc +${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}/ +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}actor.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}animatedsprite.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}constants.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}controllers.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}dialog.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}game.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}physics.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}player.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}render.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}resources.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}sound.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}sprites.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/hypatia/${MODPY_PYCACHE}tiles.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/hypatia/actor.py -lib/python${MODPY_VERSION}/site-packages/hypatia/actor.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/animatedsprite.py -lib/python${MODPY_VERSION}/site-packages/hypatia/animatedsprite.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/constants.py -lib/python${MODPY_VERSION}/site-packages/hypatia/constants.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/controllers.py -lib/python${MODPY_VERSION}/site-packages/hypatia/controllers.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/dialog.py -lib/python${MODPY_VERSION}/site-packages/hypatia/dialog.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/game.py -lib/python${MODPY_VERSION}/site-packages/hypatia/game.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/physics.py -lib/python${MODPY_VERSION}/site-packages/hypatia/physics.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/player.py -lib/python${MODPY_VERSION}/site-packages/hypatia/player.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/render.py -lib/python${MODPY_VERSION}/site-packages/hypatia/render.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/resources.py -lib/python${MODPY_VERSION}/site-packages/hypatia/resources.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/sound.py -lib/python${MODPY_VERSION}/site-packages/hypatia/sound.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/sprites.py -lib/python${MODPY_VERSION}/site-packages/hypatia/sprites.pyc lib/python${MODPY_VERSION}/site-packages/hypatia/tiles.py -lib/python${MODPY_VERSION}/site-packages/hypatia/tiles.pyc lib/python${MODPY_VERSION}/site-packages/hypatia_engine-${GH_TAGNAME}-py${MODPY_VERSION}.egg-info/ lib/python${MODPY_VERSION}/site-packages/hypatia_engine-${GH_TAGNAME}-py${MODPY_VERSION}.egg-info/PKG-INFO lib/python${MODPY_VERSION}/site-packages/hypatia_engine-${GH_TAGNAME}-py${MODPY_VERSIO
Re: Question about lang/ghc module (trying to port git-annex)
Hi Greg, > >> I'll dig into this a bit. I simply didn't need to worry about this up > >> until now as all the other ports don't do much custom Setup.hs work. > > > > I don't know if there will be any cases other than man pages and > > git-annex's command aliases. Not sure how much effort it's worth. > > The default action of doing nothing is valid :) Incidentally, I asked the maintainer how man pages are supposed to be installed, and they said it's best to use the Makefile if you want a complete installation. Probably not worth changing our port, but something to keep in mind in case this turns out to be a pattern. https://git-annex.branchable.com/bugs/__91__Patch__93___fix___34__mdwn2man__58___cannot_execute_-_...__34__/ A few notes / questions: * I fixed a couple of typos in https://github.com/falsifian/ports/commit/98111e702634842865a3d27675b6848e3fb2b7ca * I added example usage for cabal-bundler. I hope I got it right: https://github.com/falsifian/ports/commit/f21cb097f215831b1d08443f9074073895a13731 * If I find more time to work on this, should I polish my git-annex port, or is there something more useful I could be doing with your Cabal infrastructure? (I installed darcs and it seems to work.) * I tried to enable tests, partly because Darcs has a comprehensive test suite. I ran into some trouble. My WIP is here: https://github.com/falsifian/ports/commit/99cb0e33e2263cf15979a19bf068d345630c One problem is that cabal-bundler doesn't seem to be outputting test dependencies. (I tried manually adding some, not included in my commit.) Another is that, even if I add test dependencies manually, I end up with strange results like this: falsifian moth darcs $ make test ===> Regression tests for darcs-2.16.2 cd /usr/local/ports/pobj/darcs-2.16.2/darcs-2.16.2 && /usr/bin/env -i PORTSDIR="/usr/ports" LIBTOOL="/usr/bin/libtool" PATH='/usr/local/ports/pobj/darcs-2.16.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/darcs-2.16.2_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=644 BSD_INSTALL_PROGRAM="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -s -m 755" BSD_INSTALL_SCRIPT="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 755" BSD_INSTALL_DATA="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 644" BSD_INSTALL_MAN="/usr/local/ports/pobj/darcs-2.16.2/bin/install -c -m 644" BSD_INSTALL_PROGRAM_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_SCRIPT_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_DATA_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" BSD_INSTALL_MAN_DIR="/usr/local/ports/pobj/darcs-2.16.2/bin/install -d -m 755" HOME=/usr/local/ports/pobj/darcs-2.16.2 /usr/local/bin/cabal v2-test --offline --disable-benchmarks -w /usr/local/bin/ghc -j1 --flags="curl -library" Warning: No remote package servers have been specified. Usually you would have one specified in the config file. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: random-1.2.0 (user goal) [__1] trying: splitmix-0.1.0.3 (user goal) [__2] trying: splitmix:!bench [__3] rejecting: splitmix:*test (cyclic dependencies; conflict set: random, splitmix) [__1] fail (backjumping, conflict set: random, splitmix) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: random, splitmix splitmix's test target depends on random and random depends on splitmix. Normally this doesn't cause any problem; I don't know why it's a problem here. * It's a pity that your approach doesn't allow Cabal-based ports to share dependencies. Some thoughts on mitigating or solving this, in decreasing order of plausability: * Is it possible to hand-pick some particularly slow ones, make packages for them, and then tell Cabal to use those packages? E.g. aeson takes a while to build. * nixpkgs (the only package system I'm really familiar with) deals with Cabal by automatically generating package descriptions for everything on hackage. I wonder if something along those lines would be do-able. I guess it would be ugly to fill the ports tree with hundreds(?) of directories each with an auto-generated package. I'm not sure if there's a way to smoosh it all into one big file. E.g. I see there's something called "multi-packages", but I'm guessing that's not designed to handle hundreds of subpackages. * Is it possible to cheat, by having all the Cabal-based ports share their Cabal directory? So if I build darcs then git-annex, Cabal has access to all the build products from da
Re: REMOVE: games/prboom
On 2021/02/13 23:15, Klemens Nanni wrote: > On Sat, Feb 13, 2021 at 10:25:55PM +0100, Christian Weisgerber wrote: > > Ryan Freeman: > > > > > > anything I've forgotten for removal? > > > > > > Thanks naddy, kn, edd for the hints on Quirks and the main category > > > unhook. > > > This more like it? > > > > devel/quirks needs a version bump when an entry is added. > As any other package does whenever its content changes. quirks is special as it has @option always-update, so it _could_ be skipped, but we haven't being doing that. > > Also... > > > > > --- devel/quirks/files/Quirks.pm 10 Feb 2021 12:49:31 - 1.1173 > > > +++ devel/quirks/files/Quirks.pm 11 Feb 2021 22:50:06 - > > > @@ -539,6 +539,7 @@ my $stem_extensions = { > > > 'py-sphinx-intl' => 'py3-sphinx-intl', > > > 'stegcracker' => 'stegseek', > > > 'py-ldap3' => 'py3-ldap3', > > > + 'prboom' => 'prboom-plus', > > > }; > > > > > > my $obsolete_reason = { > > > @@ -2077,6 +2078,7 @@ my $obsolete_reason = { > > > 'icinga-web' => 38, > > > 'icinga-cgi' => 38, > > > 'icinga-idoutils' => 38, > > > + 'prboom' => 3, > > > }; > > > > > > # reasons for obsolete packages > > > > ... I think when a port is replaced ($stem_extenions), it doesn't > > get another entry in $obsolete_reason. > Correct, OK kn for the first hunk, the second hunk must not be there. > +1
Remove misc/viz
It fails with `-fno-common', there's been no update in more than twenty years, MASTER_SITES is already missing and we fall back to our cdn; finally, there's a pledged vis(1) in base.
REMOVE: editors/beaver? (-fno-common fix)
Hi ports -- I looked into fixing editors/beaver with -fno-common and it looks like it will be a lot of effort for a port that has been dead for over 10 years at this point. Plus, we have lots of other lightweight text editors and if you build with -fcommon, beaver segfaults when trying to select plugins. I searched through the other beaver packages that repology.org knows about and could not find an -fno-common fix (not even someone saying to just use -fcommon). Is anyone using it? Should we remove it? ~Brian
Re: REMOVE: games/prboom
On Sat, Feb 13, 2021 at 10:25:55PM +0100, Christian Weisgerber wrote: > Ryan Freeman: > > > > anything I've forgotten for removal? > > > > Thanks naddy, kn, edd for the hints on Quirks and the main category unhook. > > This more like it? > > devel/quirks needs a version bump when an entry is added. As any other package does whenever its content changes. > Also... > > > --- devel/quirks/files/Quirks.pm10 Feb 2021 12:49:31 - 1.1173 > > +++ devel/quirks/files/Quirks.pm11 Feb 2021 22:50:06 - > > @@ -539,6 +539,7 @@ my $stem_extensions = { > > 'py-sphinx-intl' => 'py3-sphinx-intl', > > 'stegcracker' => 'stegseek', > > 'py-ldap3' => 'py3-ldap3', > > + 'prboom' => 'prboom-plus', > > }; > > > > my $obsolete_reason = { > > @@ -2077,6 +2078,7 @@ my $obsolete_reason = { > > 'icinga-web' => 38, > > 'icinga-cgi' => 38, > > 'icinga-idoutils' => 38, > > + 'prboom' => 3, > > }; > > > > # reasons for obsolete packages > > ... I think when a port is replaced ($stem_extenions), it doesn't > get another entry in $obsolete_reason. Correct, OK kn for the first hunk, the second hunk must not be there.
Re: REMOVE: editors/beaver? (-fno-common fix)
On Sat, Feb 13, 2021 at 06:15:12PM +, Brian Callahan wrote: > I looked into fixing editors/beaver with -fno-common and it looks like > it will be a lot of effort for a port that has been dead for over 10 > years at this point. Plus, we have lots of other lightweight text > editors and if you build with -fcommon, beaver segfaults when trying > to select plugins. I looked at beaver and it worked with "-fcommon", hence I didn't propose removal. But if things crash with existing code and upstream hasn't been active in eleven years I don't see a point in keeping this. > I searched through the other beaver packages that repology.org knows > about and could not find an -fno-common fix (not even someone saying > to just use -fcommon). > > Is anyone using it? Should we remove it? OK kn for removal in case noone objects.
Re: FIX games/atomix -fno-common
On Sat 13/02/2021 21:57, Christian Weisgerber wrote: > Bjorn Ketelaars: > > > Fix taken from > > https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch > > There also seem to be much newer versions available. > > https://download.gnome.org/sources/atomix/3.34/ > atomix-3.34.0.tar.xz 519.6 KiB 2019-Sep-09 19:16 > > That will still need the patch, but might be worth an update anyway? > To catch up with 13 years of changes? Yes, you are right, it is worth an update. For now update to 3.22.0 as newer versions depend on libgnome-games-support, which - I think - is not in ports. Upstream provided the -fno-common fix. Run tested on amd64. OK? diff --git Makefile Makefile index bb1a981256b..3ab05350380 100644 --- Makefile +++ Makefile @@ -2,39 +2,27 @@ COMMENT= build molecules out of single atoms -DISTNAME= atomix-2.14.0 -REVISION= 14 +DISTNAME= atomix-3.22.0 CATEGORIES=games -EXTRACT_SUFX= .tar.bz2 -MASTER_SITES= ${MASTER_SITE_GNOME:=/sources/atomix/2.14/} - -HOMEPAGE = https://wiki.gnome.org/Apps/Atomix +HOMEPAGE= https://wiki.gnome.org/Apps/Atomix # GPLv2+ PERMIT_PACKAGE=Yes -WANTLIB = GL ICE ORBit-2 SM X11 Xcomposite Xcursor Xdamage Xext Xfixes -WANTLIB += Xi Xinerama Xrandr Xrender art_lgpl_2 atk-1.0 bonobo-2 -WANTLIB += bonobo-activation bonoboui-2 c cairo expat fontconfig -WANTLIB += freetype gconf-2 gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 -WANTLIB += gmodule-2.0 gnome-2 gnomecanvas-2 gnomeui-2 gnomevfs-2 -WANTLIB += gobject-2.0 gthread-2.0 gtk-x11-2.0 iconv intl m pango-1.0 -WANTLIB += pangocairo-1.0 pangoft2-1.0 pixman-1 png popt pthread xcb -WANTLIB += xcb-render xcb-shm xml2 z +WANTLIB += atk-1.0 c cairo cairo-gobject gdk-3 gdk_pixbuf-2.0 +WANTLIB += gio-2.0 glib-2.0 gobject-2.0 gtk-3 harfbuzz intl m +WANTLIB += pango-1.0 pangocairo-1.0 pthread + +MASTER_SITES= ${MASTER_SITE_GNOME:=/sources/atomix/3.22/} +EXTRACT_SUFX= .tar.xz MODULES= textproc/intltool -LIB_DEPENDS= x11/gnome/libgnome \ - x11/gnome/libgnomeui +LIB_DEPENDS= x11/gtk+3 RUN_DEPENDS= devel/desktop-file-utils USE_GMAKE= Yes CONFIGURE_STYLE=gnu - -post-install: - ${INSTALL_DATA} ${WRKINST}/var/games/atomix.scores \ - ${PREFIX}/share/atomix/atomix.scores - .include diff --git distinfo distinfo index 9ebf8d06b74..09769f729de 100644 --- distinfo +++ distinfo @@ -1,2 +1,2 @@ -SHA256 (atomix-2.14.0.tar.bz2) = XU4HPCnn0j1Jsb/M6e3x6PDAS9uR2zaOBehU4rJja7g= -SIZE (atomix-2.14.0.tar.bz2) = 284987 +SHA256 (atomix-3.22.0.tar.xz) = lcr3kYE4HswXJfx2uTeiRAZAc5u0z7r/kdt55xTnQn8= +SIZE (atomix-3.22.0.tar.xz) = 551424 diff --git patches/patch-src_Makefile_in patches/patch-src_Makefile_in deleted file mode 100644 index 637ae21fac8..000 --- patches/patch-src_Makefile_in +++ /dev/null @@ -1,14 +0,0 @@ -$OpenBSD: patch-src_Makefile_in,v 1.1 2017/11/05 11:31:29 espie Exp $ - -Index: src/Makefile.in src/Makefile.in.orig -+++ src/Makefile.in -@@ -236,7 +236,7 @@ atomix_SOURCES = \ - atomix_DEPENDENCIES = libatomix.a - atomix_LDADD = \ - libatomix.a \ -- $(ATOMIX_LIBS) -+ $(ATOMIX_LIBS) -lm - - noinst_LIBRARIES = libatomix.a - libatomix_a_SOURCES = \ diff --git patches/patch-src_level_c patches/patch-src_level_c new file mode 100644 index 000..6ae181a9516 --- /dev/null +++ patches/patch-src_level_c @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix -fno-common build error. Taken from +https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b + +Index: src/level.c +--- src/level.c.orig src/level.c +@@ -31,7 +31,7 @@ static void level_class_init (GObjectClass *class); + static void level_init (Level *level); + static void level_finalize (GObject *object); + +-GObjectClass *parent_class; ++static GObjectClass *parent_class; + + /*= + diff --git patches/patch-src_main_c patches/patch-src_main_c deleted file mode 100644 index fce2b056a25..000 --- patches/patch-src_main_c +++ /dev/null @@ -1,25 +0,0 @@ -$OpenBSD: patch-src_main_c,v 1.1.1.1 2008/01/14 23:21:04 simon Exp $ src/main.c.origSun Jan 13 01:47:06 2008 -+++ src/main.c Sun Jan 13 01:53:34 2008 -@@ -149,6 +149,11 @@ static void verb_EditPreferences_cb (BonoboUIComponent - #endif - } - -+static void verb_CloseAbout_cb (GtkWidget *dialog, gpointer user_data) -+{ -+ gtk_widget_destroy (dialog); -+} -+ - static void verb_HelpAbout_cb (BonoboUIComponent *uic, gpointer user_data, - const char *cname) - { -@@ -175,6 +180,9 @@ static void verb_HelpAbout_cb (BonoboUIComponent *uic, - gtk_about_dialog_set_authors (GTK_ABOUT_DIALOG(dlg), authors); - gtk_about_dialog_set_artists (GTK_ABOUT_DIALOG(dlg), artists); - gtk_about_dialog_set_translator_credits (GTK_ABOUT_DIALOG(dlg), _("translator-credits")); -+ -+ g_signal_connect (dlg, "close", G_CALLBACK(verb_CloseAbout_cb)
Re: Remove multimedia/audiopreview
Rafael Sadowski: > Next victim of "-fno-common". The project is dead and I don't think we > should save this application. Alternatives are available. Similar history on FreeBSD and OpenBSD: kevlo@ imported it in July 2010, and since then the respective ports have only received mechanical infrastructure commits. FreeBSD expired it in 2019. I think this can be deleted, but I'm cc'ing kevlo@, just in case. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX x11/compiz/plugins-main -fno-common
Bjorn Ketelaars: > Fix taken from > https://github.com/compiz-reloaded/compiz-plugins-main/commit/1f39291442513c08930bef308d0ce9dccea74589 That enum isn't used anywhere?! Oh well, no point in diverging from upstream. ok naddy@ -- Christian "naddy" Weisgerber na...@mips.inka.de
UPDATE: games/opentyrian 2.1.20130907 => 2.1.20201204 (incl. -fno-common fixes)
Hi ports -- Attached is a diff to update games/opentyrian. Among other things, it includes -fno-common fixes. While there has been no new official releases, development has moved to GitHub, where there has been activity ever since the last release. I chose to move there, and grab the latest head of their git tree. This additionally sees the game move from SDL to SDL2. I kept the same installation structure as before. Works on amd64. OK? ~Brian opentyrian-20201204.diff Description: Binary data
Re: REMOVE: games/prboom
Ryan Freeman: > > anything I've forgotten for removal? > > Thanks naddy, kn, edd for the hints on Quirks and the main category unhook. > This more like it? devel/quirks needs a version bump when an entry is added. Also... > --- devel/quirks/files/Quirks.pm 10 Feb 2021 12:49:31 - 1.1173 > +++ devel/quirks/files/Quirks.pm 11 Feb 2021 22:50:06 - > @@ -539,6 +539,7 @@ my $stem_extensions = { > 'py-sphinx-intl' => 'py3-sphinx-intl', > 'stegcracker' => 'stegseek', > 'py-ldap3' => 'py3-ldap3', > + 'prboom' => 'prboom-plus', > }; > > my $obsolete_reason = { > @@ -2077,6 +2078,7 @@ my $obsolete_reason = { > 'icinga-web' => 38, > 'icinga-cgi' => 38, > 'icinga-idoutils' => 38, > + 'prboom' => 3, > }; > > # reasons for obsolete packages ... I think when a port is replaced ($stem_extenions), it doesn't get another entry in $obsolete_reason. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX games/atomix -fno-common
Bjorn Ketelaars: > Fix taken from > https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch There also seem to be much newer versions available. https://download.gnome.org/sources/atomix/3.34/ atomix-3.34.0.tar.xz519.6 KiB 2019-Sep-09 19:16 That will still need the patch, but might be worth an update anyway? To catch up with 13 years of changes? -- Christian "naddy" Weisgerber na...@mips.inka.de
UPDATE: lang/snobol4 2.0 => 2.2.1 (incl. -fno-common fixes)
Hello -- Attached is a patch to update snobol4 to its latest version, which (among other things) fixes -fno-common issues. I added the COMPILER line because I ended up ^C'ing trying to build snobol4 with base-gcc on amd64 for taking way too long. The build times are reasonable with clang and ports-gcc. I added SUBST_VARS += V to help reduce PLIST churn in the future. Things work as expected on amd64. OK? ~Brian snobol-221.diff Description: Binary data
Re: Build failures from -fno-common (2021-02-10)
> On Feb 13, 2021, at 8:58 AM, Stuart Henderson wrote: > > On 2021/02/13 16:24, Yozo TODA wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >>> Here is an updated list of ports that fail to build with -fno-common: >>> >> >>> graphics/ocaml-cairoUPDATEports@openbsd.org >> >> please import the update to 1.6.2 I sent on February 6th. >> >>> From: Yozo TODA >>> To: ports@openbsd.org >>> Subject: update graphics/ocaml-cairo to 0.6.2 (Re: -fno-common update: >>> broken ports) >>> Date: Sat, 06 Feb 2021 21:37:36 +0900 >> >> it works on amd64-current usual and non-native configurations. >> no problem with lablgtk3 and coq. > > It is already committed and packages are on the mirrors now. > lablgtk3 also needed a fix for -fno-common and that’s committed as well. There was a new point release of lablgtk3 specifically for this issue. coq and compcert work fine following those two updates.
Re: UPDATE: math/pspp 1.2.0 => 1.4.1 (incl. -fno-common fixes)
On Sunday, February 7th, 2021 at 8:48 PM, Brian Callahan wrote: > Hi ports -- > > Attached is an update to math/pspp. > > The major upstream changelog (to 1.4.0) is here: > > http://savannah.gnu.org/forum/forum.php?forum_id=9795 > > Also fixes -fno-common errors. > > All tests pass on amd64. > > OK? > > ~Brian Ping.
Re: UPDATE: textproc/lowdown 0.8.1
On Wed, Feb 10, 2021 at 09:28:48PM -0800, Bryan Vyhmeister wrote: > On Tue, Feb 09, 2021 at 06:15:06PM +0100, Caspar Schutijser wrote: > > Hi, > > > > Below is a diff that updates textproc/lowdown to 0.8.1. Tested on amd64. > > OK maintainer > > Thank you for doing this. Committed, thanks!
FIX x11/compiz/plugins-main -fno-common
Fix taken from https://github.com/compiz-reloaded/compiz-plugins-main/commit/1f39291442513c08930bef308d0ce9dccea74589 OK? diff --git Makefile Makefile index f5147232342..efe8ceebb55 100644 --- Makefile +++ Makefile @@ -4,7 +4,7 @@ COMMENT = main plugins for compiz V =0.8.8 DISTNAME = compiz-plugins-main-${V} -REVISION = 4 +REVISION = 5 MASTER_SITES = http://releases.compiz.org/${V}/ diff --git patches/patch-src_colorfilter_parser_h patches/patch-src_colorfilter_parser_h new file mode 100644 index 000..fcba0040208 --- /dev/null +++ patches/patch-src_colorfilter_parser_h @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix -fno-common build error. Taken from +https://github.com/compiz-reloaded/compiz-plugins-main/commit/1f39291442513c08930bef308d0ce9dccea74589 + +Index: src/colorfilter/parser.h +--- src/colorfilter/parser.h.orig src/colorfilter/parser.h +@@ -21,7 +21,7 @@ + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ + +-enum ++extern enum + { + NoOp, + DataOp,
FIX games/atomix -fno-common
Fix taken from https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch OK? diff --git Makefile Makefile index bb1a981256b..600af72aa64 100644 --- Makefile +++ Makefile @@ -3,7 +3,7 @@ COMMENT= build molecules out of single atoms DISTNAME= atomix-2.14.0 -REVISION= 14 +REVISION= 15 CATEGORIES=games EXTRACT_SUFX= .tar.bz2 diff --git patches/patch-src_level_c patches/patch-src_level_c new file mode 100644 index 000..c74c726e8ab --- /dev/null +++ patches/patch-src_level_c @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix -fno-common build error. Taken from +https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch + +Index: src/level.c +--- src/level.c.orig src/level.c +@@ -30,7 +30,7 @@ static void level_class_init (GObjectClass *class); + static void level_init (Level *level); + static void level_finalize (GObject *object); + +-GObjectClass *parent_class; ++static GObjectClass *parent_class; + + /*= + diff --git patches/patch-src_theme_c patches/patch-src_theme_c new file mode 100644 index 000..3d435f1bd36 --- /dev/null +++ patches/patch-src_theme_c @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix -fno-common build error. Taken from +https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch + +Index: src/theme.c +--- src/theme.c.orig src/theme.c +@@ -32,7 +32,7 @@ static void theme_init (Theme *theme); + static void theme_finalize (GObject *object); + static void destroy_theme_image (gpointer data); + +-GObjectClass *parent_class; ++static GObjectClass *parent_class; + + GType theme_get_type (void) + {
Re: prometheus 2.24.1 update
On 2021/02/13 12:01, Claudio Jeker wrote: > This is an update for prometheus to 2.24.1. > The react UI that needs to be built for prometheus is an extra distfile. > Building the react UI is a nightmare and did not work on OpenBSD last time > I tried. > > The tsdb tool got merged into promtool so one less binary to install. > > I run this on my collector since this morning and it seems to work. OK. Could you switch HOMEPAGE to https please? > +The react build is provided via extra distfile I think this is the only sane way.
Build failures from -fno-common (2021-02-13)
Here is an updated list of ports that fail to build with -fno-common: audio/audacity UPDATEports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/rsp-cxd4 - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/atomix- ports@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/heroes- anth...@anjbe.name games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/onew - es...@openbsd.org lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org lang/snobol4UPDATEst...@wb8wsf.org mail/avengerUPDATEports@openbsd.org mail/mlmmj - ports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org math/foma - ports@openbsd.org math/mcl- ports@openbsd.org math/pspp UPDATEbcal...@openbsd.org misc/geekcode - ports@openbsd.org misc/hfsplus- ports@openbsd.org misc/logjam - ports@openbsd.org misc/plan - ports@openbsd.org misc/viz- ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives
Re: FIX: games/xboing -fno-common
Stuart Henderson: > naddy had a similar diff and same problem. Looking at the compiler > warnings it doesn't exactly seem LP64-clean (or, well, clean at all); Speaking in general terms: A lot of the crufty X11 code in the ports tree has a pattern where they use callback APIs that take a pointer argument, and if they just want to pass an int, they cast it to a pointer and back (instead of allocating an int and passing a pointer to it). That works out fine, no truncation, despite scary compiler warnings. IIRC we mostly cleaned up the actual LP64 problems years ago. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX: games/xboing -fno-common
Ryan Freeman: > From FreeBSD, a bit hard to follow as their commit (re)touched the > original patches > > Once this builds, the game doesn't seem very playable. I already looked at this. If you build it with -fcommon, it already isn't playable. That needs to be fixed first--or the port should be removed. This is a case where the no-common fix is not obvious. If you look at the code, the intent appears to have been to have local waitMode variables in each module. However, they are all merged into a single common. If you follow the likely intent, the different instances of waitMode should be declared static. However, it's entirely possible that the game logic has come to rely on the accidental merging of the variables. So this needs testing... for which the game needs to be playable in the first place. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [UPDATE] x11/i3 4.19.1
Thanks Stuart and Rafael. Le 13/02/2021 à 09:48, Stuart Henderson a écrit : Oh the xxCONFIGURE_ARGS should just be removed, it was from testing. > The dependencies are not needed unless those args are set. With a git > checkout they are needed in order to generate docs but with a > released tarball they are not. >
Re: Build failures from -fno-common (2021-02-10)
On 2021/02/13 16:24, Yozo TODA wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > Here is an updated list of ports that fail to build with -fno-common: > > > > > graphics/ocaml-cairoUPDATEports@openbsd.org > > please import the update to 1.6.2 I sent on February 6th. > > > From: Yozo TODA > > To: ports@openbsd.org > > Subject: update graphics/ocaml-cairo to 0.6.2 (Re: -fno-common update: > > broken ports) > > Date: Sat, 06 Feb 2021 21:37:36 +0900 > > it works on amd64-current usual and non-native configurations. > no problem with lablgtk3 and coq. It is already committed and packages are on the mirrors now.
Re: Collision in py-sip-4.19.19p0v0->4.19.24v0
On 2021/02/13 07:51, Rafael Sadowski wrote: > On Mon Feb 01, 2021 at 11:26:35PM +, Mikolaj Kucharski wrote: > > Hi, > > > > This happens for a while, but recently I don't have good chunk of time > > to dive and provide a diff. Decided to finally sent an email. > > > > (I do have some not committed port on my machine) > > > > # pkg_add -Dupdate -Dupdatedepends -Drepair -u -U -V > > quirks-3.524 signed on 2021-01-30T16:42:18Z > > Collision in py-sip-4.19.19p0v0->4.19.24v0: the following files already > > exist > > /usr/local/lib/python2.7/site-packages/PyQt5/sip.pyi > > (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) > > /usr/local/lib/python2.7/site-packages/PyQt5/sip.so > > (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) > > Can't install > > py-qt5-5.13.2p1+py3-sip-qt5-5.5.0->py-qt5-5.15.2+py3-sip-qt5-5.5.0p0: can't > > resolve py-sip-4.19.24v0 > > Couldn't find updates for github-cli-1.5.0 promplot-0.17.0 py-qt5-5.13.2p1 > > py-sip-4.19.19p0v0 py-sip-qt5-4.19.19p0 py3-hvac-0.10.6pre0 > > py3-sip-qt5-5.5.0 > > Couldn't install py-qt5-5.15.2 py-sip-4.19.24v0 py3-sip-qt5-5.5.0p0 > > > > -- > > Regards, > > Mikolaj > > > > > I think we forgot the py2 conflict in devel/py-sip. > > diff --git a/devel/py-sip/Makefile b/devel/py-sip/Makefile > index 2fa86521b49..edf7b384b6a 100644 > --- a/devel/py-sip/Makefile > +++ b/devel/py-sip/Makefile > @@ -10,6 +10,7 @@ EPOCH= 0 > DISTNAME=sip-${MODPY_EGG_VERSION} > PKGNAME= py-${DISTNAME} > CATEGORIES= devel > +REVISION=0 > > HOMEPAGE=https://www.riverbankcomputing.com/software/sip/intro > > diff --git a/devel/py-sip/pkg/PLIST b/devel/py-sip/pkg/PLIST > index 410b31651e2..4c0fcdcad29 100644 > --- a/devel/py-sip/pkg/PLIST > +++ b/devel/py-sip/pkg/PLIST > @@ -1,5 +1,6 @@ > @comment $OpenBSD: PLIST,v 1.12 2021/01/19 06:26:49 rsadowski Exp $ > @conflict py3-sip-qt5-<5.5.0 > +@conflict py-sip-qt5-<5.5.0 > @bin bin/sip${MODPY_BIN_SUFFIX} > include/python${MODPY_VERSION}${MODPY_LIB_SUFFIX}/sip.h > lib/python${MODPY_VERSION}/site-packages/PyQt5/ > The two ports seem totally the wrong way round. Why are the sip tools in py-sip-qt5 and not py-sip, why are the qt5 related things in py-sip?
Re: FIX: games/xboing -fno-common
On 2021/02/12 16:39, Ryan Freeman wrote: > > From FreeBSD, a bit hard to follow as their commit (re)touched the > original patches > > https://svnweb.freebsd.org/ports?view=revision&revision=548113 > > Once this builds, the game doesn't seem very playable. Seems like > it might be running /way/ too fast on modern systems. Tried stock > fvwm with no fancy stuff to see if compositing was problematic, no > improvement. > > Does this work for anyone else? Should it get booted? naddy had a similar diff and same problem. Looking at the compiler warnings it doesn't exactly seem LP64-clean (or, well, clean at all); I wonder if it might do better on a 32-bit arch. That said, there are alternatives like kbreakout / lbreakout2, I'd be OK with just rm'ing.
Re: UPDATE/FIX: net/ocserv
On 2021/02/12 17:51, Marc West wrote: > On 2021-02-11 21:32:08, Stuart Henderson wrote: > > thanks, i've adapted it to -current and then merged that (with the > > 1.1.1 update) back to 6.8-stable. > > Thanks for the MFC. On OPENBSD_6_8, patch-src_config_c and > patch-src_main_c are still present after a fresh checkout from a couple > different mirrors which patch appears to be reversing since those > changes are in the upstream 1.1.1 release. This builds on 6.8 but does > not run properly due to the procfs errors that those patches fixed prior > to 1.1.1. > > ocserv-1.1.1 runs correctly on 6.8-stable with patch-src_config_c and > patch-src_main_c removed. > Thanks, I've just committed a fix, packages will show up later.
Re: [UPDATE] misc/gpsd
On Fri, May 15, 2020 09:41, Kirill Bychkov wrote: > Hi! > Here is an update to gpsd-3.20. > gpsd has some API changes so it's consumers need fixes. See my > previous mail. > Comments? OKs? > Hi, All consumers were fixed already and gpsd 3.21 is out. It's not the latest version but 3.22 requires some more work which I want to do separately. All dependent ports are building fine, regression tests are passing. OK? Index: Makefile === RCS file: /cvs/ports/misc/gpsd/Makefile,v retrieving revision 1.79 diff -u -p -u -p -r1.79 Makefile --- Makefile4 Jan 2021 14:06:35 - 1.79 +++ Makefile12 Feb 2021 14:41:30 - @@ -4,14 +4,14 @@ COMMENT-main= service daemon that monit COMMENT-x11= GUI test apps using gpsd COMMENT-php= web-based gpsd monitor in php -VERSION= 3.19 +VERSION= 3.21 DISTNAME= gpsd-${VERSION} PKGNAME-main= gpsd-${VERSION} PKGNAME-x11= gpsd-x11-${VERSION} PKGNAME-php= gpsd-php-${VERSION} -REVISION= 2 -SHARED_LIBS += gps 20.0 # 25.0 +SHARED_LIBS += gps 21.0# 27.0 +SHARED_LIBS += gpsdpacket 0.0 # 21.0 CATEGORIES=misc geo HOMEPAGE = https://gpsd.gitlab.io/gpsd/index.html @@ -41,6 +41,7 @@ MODSCONS_FLAGS += gpsd_user=_gpsd \ MULTI_PACKAGES = -main -php -x11 BUILD_DEPENDS= devel/py-gobject3${MODPY_FLAVOR} \ + devel/py-serial${MODPY_FLAVOR} \ textproc/xmlto \ textproc/libxslt \ textproc/docbook \ Index: distinfo === RCS file: /cvs/ports/misc/gpsd/distinfo,v retrieving revision 1.10 diff -u -p -u -p -r1.10 distinfo --- distinfo31 Jul 2019 15:44:30 - 1.10 +++ distinfo12 Feb 2021 14:41:30 - @@ -1,2 +1,2 @@ -SHA256 (gpsd-3.19.tar.gz) = J90k1Fsqxpuqt5M9or9q5fsL6QEw9n51PBEKNHcVXzk= -SIZE (gpsd-3.19.tar.gz) = 10581777 +SHA256 (gpsd-3.21.tar.gz) = ZVBMOvjTsMzjwHQFuIFddzDS0r4tp9KNJ18anFfG/pE= +SIZE (gpsd-3.21.tar.gz) = 3984157 Index: patches/patch-SConstruct === RCS file: /cvs/ports/misc/gpsd/patches/patch-SConstruct,v retrieving revision 1.2 diff -u -p -u -p -r1.2 patch-SConstruct --- patches/patch-SConstruct22 Sep 2020 15:16:20 - 1.2 +++ patches/patch-SConstruct12 Feb 2021 14:41:30 - @@ -2,8 +2,8 @@ $OpenBSD: patch-SConstruct,v 1.2 2020/09 Index: SConstruct --- SConstruct.orig +++ SConstruct -@@ -72,8 +72,7 @@ gpsd_version = "3.19" - libgps_version_current = 25 +@@ -264,8 +264,7 @@ api_version_minor = 14 + libgps_version_current = 27 libgps_version_revision = 0 libgps_version_age = 0 -libgps_version = "%d.%d.%d" % (libgps_version_current, libgps_version_age, @@ -12,7 +12,7 @@ Index: SConstruct # # Release identification ends here -@@ -546,7 +545,7 @@ def CheckPKG(context, name): +@@ -754,7 +753,7 @@ def CheckPKG(context, name): # Stylesheet URLs for making HTML and man pages from DocBook XML. @@ -21,7 +21,7 @@ Index: SConstruct docbook_man_uri = docbook_url_stem + 'manpages/docbook.xsl' docbook_html_uri = docbook_url_stem + 'html/docbook.xsl' -@@ -1090,6 +1089,10 @@ else: +@@ -1374,6 +1373,10 @@ else: # if not, force qt to off if config.env["qt"]: qt_net_name = 'Qt%sNetwork' % config.env["qt_versioned"] @@ -32,40 +32,33 @@ Index: SConstruct qt_network = config.CheckPKG(qt_net_name) if not qt_network: config.env["qt"] = False -@@ -1584,25 +1587,6 @@ else: - } +@@ -1500,20 +1503,6 @@ elif config.env['python']: + + config.env['xgps_deps'] = True - if env['xgps']: -# check for pycairo --try: --imp.find_module('cairo') --except ImportError: --# no pycairo, don't build xgps, xgpsspeed --announce("WARNING: Python module pycairo not found.\n" -- "xgps and xgpsspeed will not be installed") --env['xgps'] = False +-if not config.GetPythonValue('module cairo (pycairo)', +- 'import cairo', '"found"'): +-# no pycairo, used by xgps, xgpsspeed +-config.env['xgps_deps'] = False +-announce("WARNING: Python module cairo (pycairo) not found.") - --# check for pygobject --try: --imp.find_module('gi') --except ImportError: --# no pycairo, don't build xgps, xgpsspeed --announce("WARNING: Python module pygobject not found.\n" -- "xgps and xgpsspeed will not be installed") --env['xgps'] = False +-# check for pycairo +-if not config.GetPythonValue('module gi (pygobject)', +-
prometheus 2.24.1 update
This is an update for prometheus to 2.24.1. The react UI that needs to be built for prometheus is an extra distfile. Building the react UI is a nightmare and did not work on OpenBSD last time I tried. The tsdb tool got merged into promtool so one less binary to install. I run this on my collector since this morning and it seems to work. -- :wq Claudio Index: Makefile === RCS file: /cvs/ports/sysutils/prometheus/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile20 Nov 2020 21:17:21 - 1.9 +++ Makefile13 Feb 2021 10:35:38 - @@ -2,10 +2,10 @@ COMMENT = systems monitoring and alerting toolkit +V =2.24.1 GH_ACCOUNT = prometheus GH_PROJECT = prometheus -GH_TAGNAME = v2.13.1 -REVISION = 0 +GH_TAGNAME = v${V} CATEGORIES = sysutils @@ -13,9 +13,14 @@ HOMEPAGE = http://prometheus.io/ MAINTAINER = Claudio Jeker +DISTFILES += prometheus-${V}.tar.gz \ + prometheus-reactui-${V}.tar.gz:0 + # Apache 2.0 PERMIT_PACKAGE = Yes +MASTER_SITES0 =https://www.zyd.ch/distfiles/ + WANTLIB = c pthread BUILD_DEPENDS =devel/promu @@ -38,7 +43,6 @@ do-install: ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/prometheus/console_libraries ${INSTALL_PROGRAM} ${WRKSRC}/prometheus ${PREFIX}/bin ${INSTALL_PROGRAM} ${WRKSRC}/promtool ${PREFIX}/bin - ${INSTALL_PROGRAM} ${WRKSRC}/tsdb/tsdb ${PREFIX}/bin ${INSTALL_DATA} ${WRKSRC}/consoles/* \ ${PREFIX}/share/examples/prometheus/consoles/ ${INSTALL_DATA} ${WRKSRC}/console_libraries/{menu.lib,prom.lib} \ @@ -47,6 +51,7 @@ do-install: ${PREFIX}/share/examples/prometheus/prometheus.yml ${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/prometheus/ ${INSTALL_DATA} ${WRKSRC}/NOTICE ${PREFIX}/share/doc/prometheus/ + ${INSTALL_DATA} ${WRKSRC}/npm_licenses.tar.bz2 ${PREFIX}/share/doc/prometheus/ do-test: cd ${WRKSRC} && ${MAKE_ENV} ${MAKE_PROGRAM} test Index: distinfo === RCS file: /cvs/ports/sysutils/prometheus/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo29 Oct 2019 12:37:54 - 1.4 +++ distinfo13 Feb 2021 10:38:39 - @@ -1,2 +1,4 @@ -SHA256 (prometheus-2.13.1.tar.gz) = ViTBZyhnk2LPpGt27B0kcBgQaYnyJg01WDxCxJxRQrU= -SIZE (prometheus-2.13.1.tar.gz) = 15249891 +SHA256 (prometheus-2.24.1.tar.gz) = ngi6zehpxsS2ip40xwdLgSvhORsz0DPTBypeGtLevYc= +SHA256 (prometheus-reactui-2.24.1.tar.gz) = ex9rOmybKeT9/eyP67WxU44asPen5ZL/Yh4hKxUGX/o= +SIZE (prometheus-2.24.1.tar.gz) = 14633738 +SIZE (prometheus-reactui-2.24.1.tar.gz) = 1897337 Index: patches/patch-Makefile === RCS file: patches/patch-Makefile diff -N patches/patch-Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-Makefile 13 Feb 2021 10:13:25 - @@ -0,0 +1,16 @@ +$OpenBSD$ + +The react build is provided via extra distfile + +Index: Makefile +--- Makefile.orig Makefile +@@ -38,7 +38,7 @@ $(REACT_APP_OUTPUT_DIR): $(REACT_APP_NODE_MODULES_PATH + @$(REACT_APP_BUILD_SCRIPT) + + .PHONY: assets +-assets: $(REACT_APP_OUTPUT_DIR) ++assets: + @echo ">> writing assets" + # Un-setting GOOS and GOARCH here because the generated Go code is always the same, + # but the cached object code is incompatible between architectures and OSes (which Index: patches/patch-Makefile_common === RCS file: /cvs/ports/sysutils/prometheus/patches/patch-Makefile_common,v retrieving revision 1.2 diff -u -p -r1.2 patch-Makefile_common --- patches/patch-Makefile_common 16 Oct 2019 06:47:12 - 1.2 +++ patches/patch-Makefile_common 20 Jan 2021 12:28:01 - @@ -5,7 +5,7 @@ Don't fetch promu form internet. This is Index: Makefile.common --- Makefile.common.orig +++ Makefile.common -@@ -236,11 +236,7 @@ common-docker-manifest: +@@ -261,11 +261,7 @@ common-docker-manifest: promu: $(PROMU) $(PROMU): Index: patches/patch-_promu_yml === RCS file: /cvs/ports/sysutils/prometheus/patches/patch-_promu_yml,v retrieving revision 1.1 diff -u -p -r1.1 patch-_promu_yml --- patches/patch-_promu_yml16 Oct 2019 06:47:12 - 1.1 +++ patches/patch-_promu_yml20 Jan 2021 12:03:58 - @@ -5,7 +5,7 @@ Don't include user and hostname into bui Index: .promu.yml --- .promu.yml.orig +++ .promu.yml -@@ -17,7 +17,7 @@ build: +@@ -15,7 +15,7 @@ build: -X github.com/prometheus/common/version.Version={{.Version}} -X github.com/prometheus/common/version.Revision={{.
Re: [UPDATE] x11/i3 4.19.1
Oh the xxCONFIGURE_ARGS should just be removed, it was from testing. The dependencies are not needed unless those args are set. With a git checkout they are needed in order to generate docs but with a released tarball they are not. -- Sent from a phone, apologies for poor formatting. On 13 February 2021 06:03:54 Rafael Sadowski wrote: On Fri Feb 12, 2021 at 11:16:32PM +, Stuart Henderson wrote: On 2021/02/12 09:29, Guy Godfroy wrote: > I ended up by almost duplicating i3-mousedrag. So now i3-sensible-* > stuff are back in the game. > > Let me know what you think about it. thanks, some of the diff didn't apply but I have got it into shape, and adapted a few things (some parts only relevant for builds from git which isn't needed for proper releases) and committed. it looks like the upstream ticket with i3-mousedrag is moving again, so I'm hoping that we'll be able to get rid of i3-mousedrag and merge into the main port before too long, so it's good to have things in sync. Looks like xxCONFIGURE_ARGS is a mistake and it hides build dependencies. Index: Makefile === RCS file: /cvs/ports/x11/i3/Makefile,v retrieving revision 1.127 diff -u -p -u -p -r1.127 Makefile --- Makefile12 Feb 2021 23:14:04 - 1.127 +++ Makefile13 Feb 2021 05:55:21 - @@ -3,6 +3,7 @@ COMMENT = improved dynamic tiling window manager DISTNAME = i3-4.19.1 +REVISION = 0 CATEGORIES =x11 @@ -36,13 +37,15 @@ RUN_DEPENDS = devel/desktop-file-utils \ x11/dmenu \ x11/i3status \ x11/p5-AnyEvent-I3 +BUILD_DEPENDS =textproc/asciidoc \ + textproc/xmlto MODULES = devel/meson # Tests now use the X11::XCB Perl module, not yet in ports and a bit complex #TEST_DEPENDS= x11/p5-AnyEvent-I3 NO_TEST=Yes -xxCONFIGURE_ARGS= -Dmans=true \ +CONFIGURE_ARGS=-Dmans=true \ -Ddocs=true CONFIGURE_ENV= CPPFLAGS="-I${X11BASE}/include -I${LOCALBASE}/include" \ LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib"