Re: [NEW] textproc/lucene++
On Fri, Jun 26, 2020 at 10:00:12PM +0200, Omar Polo wrote: > > Landry Breuil writes: > > > > > with that chunk added to patch-CMakeLists.txt, no need to patch the .cmake > > files to fiddle with prefix/LIB_DESTINATION, and the resulting .pc look > > correct. > > I really like this. Update tarball with this applied. this version is ok landry@ to import - thanks!
[update] audio/lmms enable ZynAddSubFX
Currently, lmms is disabling the ZynAddSubFX plugin.
This diff enables it.
- remove patches/patch-plugins_CMakeLists_txt to build zynaddsubfx
- add required libraries to WANTLIB and LIB_DEPENDS
- bump up REVISION to 1
In this diff, I just delete all lines in patch-plugins_CMakeLists_txt.
I would like to 'cvs remove' it if this diff is ok.
I had confirmed that build and install on my OpenBSD 6.7 (amd64) succeeded.
And I could play ZynAddSubFX within lmms.
ok?
Kinichiro Inoguchi
Index: Makefile
===
RCS file: /cvs/ports/audio/lmms/Makefile,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 Makefile
--- Makefile30 Jan 2020 14:13:47 - 1.23
+++ Makefile27 Jun 2020 06:34:22 -
@@ -5,7 +5,7 @@ COMMENT = music studio with tracking, s
# rolled from git; requires submodules
# git clone --recurse-submodules -b v1.2.0 https://github.com/lmms/lmms
DISTNAME = lmms-1.2.0
-REVISION = 0
+REVISION = 1
EXTRACT_SUFX = .tar.xz
CATEGORIES = audio
@@ -18,9 +18,10 @@ MASTER_SITES = https://spacehopper.org/
PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Widgets Qt5Xml
-WANTLIB += c curses fftw3f fluidsynth jack m mp3lame ogg portaudio
-WANTLIB += readline samplerate sndfile sndio vorbis vorbisenc
-WANTLIB += vorbisfile
+WANTLIB += Xau Xcursor Xdmcp Xext Xfixes Xft Xinerama
+WANTLIB += c curses fftw3 fftw3f fluidsynth fltk fontconfig jack lo
+WANTLIB += m mp3lame mxml ogg portaudio readline samplerate sndfile sndio
+WANTLIB += vorbis vorbisenc vorbisfile z
COMPILER = base-clang ports-gcc
@@ -32,13 +33,18 @@ BUILD_DEPENDS = shells/bash
RUN_DEPENDS = devel/desktop-file-utils \
misc/shared-mime-info \
x11/gtk+3,-guic
+
LIB_DEPENDS = audio/fluidsynth \
audio/jack \
audio/lame \
+ audio/liblo \
audio/libsamplerate \
audio/libvorbis \
audio/portaudio-svn \
- math/fftw3,float
+ math/fftw3 \
+ math/fftw3,float \
+ textproc/mxml \
+ x11/fltk
CONFIGURE_ENV =CFLAGS="${CFLAGS} -I${X11BASE}/include
-I${LOCALBASE}/include" \
CXXFLAGS="${CXXFLAGS} -I${X11BASE}/include
-I${LOCALBASE}/include" \
Index: patches/patch-plugins_CMakeLists_txt
===
RCS file: /cvs/ports/audio/lmms/patches/patch-plugins_CMakeLists_txt,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-plugins_CMakeLists_txt
--- patches/patch-plugins_CMakeLists_txt24 Jun 2018 11:57:13 -
1.1
+++ patches/patch-plugins_CMakeLists_txt27 Jun 2020 06:34:22 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-plugins_CMakeLists_txt,v 1.1 2018/06/24 11:57:13 sthen Exp $
-
-Index: plugins/CMakeLists.txt
plugins/CMakeLists.txt.orig
-+++ plugins/CMakeLists.txt
-@@ -80,7 +80,7 @@ IF("${PLUGIN_LIST}" STREQUAL "")
- watsyn
- waveshaper
- vibed
-- zynaddsubfx
-+# zynaddsubfx
- )
-
- ENDIF("${PLUGIN_LIST}" STREQUAL "")
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/lmms/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 PLIST
--- pkg/PLIST 30 Jan 2020 14:13:47 - 1.7
+++ pkg/PLIST 27 Jun 2020 06:34:22 -
@@ -1,7 +1,9 @@
@comment $OpenBSD: PLIST,v 1.7 2020/01/30 14:13:47 sthen Exp $
@bin bin/lmms
lib/lmms/
+@bin lib/lmms/RemoteZynAddSubFx
@so lib/lmms/libOPL2.so
+@so lib/lmms/libZynAddSubFxCore.so
@so lib/lmms/libamplifier.so
@so lib/lmms/libaudiofileprocessor.so
@so lib/lmms/libbassbooster.so
@@ -38,6 +40,7 @@ lib/lmms/
@so lib/lmms/libvibedstrings.so
@so lib/lmms/libwatsyn.so
@so lib/lmms/libwaveshaper.so
+@so lib/lmms/libzynaddsubfx.so
@man man/man1/lmms.1
share/applications/lmms.desktop
share/bash-completion/completions/lmms
NEW: math/rstudio
Hi ports -- Attached is a new port, math/rstudio. RStudio is the IDE for R. --- pkg/DESCR: RStudio is an integrated development environment (IDE) for R. It includes a console, syntax-highlighting editor that supports direct code execution, as well as tools for plotting, history, debugging and workspace management. --- This is a rather big port, and I am not certain that it is ready for import just yet. But it is clearly at the point where it needs to be shared. Looking for comments and suggestions. Some notes/caveats: 1. The binary lives as /usr/local/lib/rstudio/bin/rstudio. A simple script exists to allow console users easy access. 2. There are no precompiled packages other than what comes with the IDE. Trying to build some (igraph, notably) exposed some potential issues with R--like how R thinks the fortran compiler is named gfortran when it should be egfortran. 3. Fonts don't render in the Plots window. Not sure why. Help appreciated. 4. I am only a Desktop user but I did provide the Server as well. If you use the server I'd be interested in knowing how it works. 5. There are undoubtedly improvements to be made here, so I'm open to whatever comes down the pipeline. OK? ~Brian rstudio.tgz Description: application/compressed-tar
Re: redis-sentinel segfault workaround
Theo Buehler writes:
> 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:
Here is a diff resolving the out-of-bounds memory access.
Thank you for the reproducer and the debug information. I was able to
also trigger a crash within 2-10 minutes.
> I get similar results using printf debugging, so I don't think the
> debugger lies to me.
As I have discovered, gdb can be deceptive with the line number.
I sprinkled printf debugging. I thought maybe a memory barrier could
help, so I added membar_sync(), but this turns out to be a red herring.
I added BEGIN and END statements to the beginning/end of the loop along
with the index (e.g., 145).
2221 printf("NAM MASTER_LINK_DOWN BEFORE %s len: %d\n", l,
sdslen(l));
/* master_link_down_since_seconds: */
2223 cond = sdslen(l) >= 32 && \
2224 !memcmp(l,"master_link_down_since_seconds",30);
2225 printf("NAM cond: %d\n", cond);
2226 membar_sync();
2227 if (cond)
2228 {
2229 printf("NAM MASTER_LINK_DOWN %s\n", l);
2230 ri->master_link_down_time = strtoll(l+31,NULL,10)*1000;
2231 }
2232
2233 printf("NAM ROLE BEFORE\n");
2234 /* role: */
2235 if (!memcmp(l,"role:master",11)) role = SRI_MASTER;
2236 else if (!memcmp(l,"role:slave",10)) role = SRI_SLAVE;
2237
2238 printf("NAM SRI_SLAVE BEFORE\n");
2239 if (role == SRI_SLAVE) {
2240 printf("NAM SRI_SLAVE AFTER\n");
NAM BEGIN 145
NAM RUN_ID BEFORE # Cluster
NAM SRI BEFORE # Cluster
NAM MASTER_LINK_DOWN BEFORE # Cluster len: 9
NAM cond: 0
NAM ROLE BEFORE
NAM SRI_SLAVE BEFORE
NAM END
NAM BEGIN 146
NAM RUN_ID BEFORE cluster_enabled:0
NAM SRI BEFORE cluster_enabled:0
NAM MASTER_LINK_DOWN BEFORE cluster_enabled:0 len: 17
NAM cond: 0
NAM ROLE BEFORE
NAM SRI_SLAVE BEFORE
NAM END
NAM BEGIN 147
NAM RUN_ID BEFORE
NAM SRI BEFORE
NAM MASTER_LINK_DOWN BEFORE len: 0
NAM cond: 0
NAM ROLE BEFORE
[New thread 279273]
[New thread 593859]
[New thread 463858]
Thread 1 received signal SIGSEGV, Segmentation fault.
0x1ba2086d67ef in sentinelRefreshInstanceInfo (ri=0x1ba4f37d4608,
info=) at sentinel.c:2233
2233sentinel.c: No such file or directory.
What is line 2233?
2233 printf("NAM ROLE BEFORE\n");
Before it would consistently crash "at" strtoll, as you had
reported. After adding so many printf()'s I got a lucky break and gdb
somehow reported 2233. I read the following lines and saw that the
memcmp() was accessing invalid memory for l, similarly to the gdb print
command you had with vm.malloc_conf=J.
> 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.
To resolve this issue, add sdslen() to check for string length before
memcmp() like everywhere else.
I got to learn about flexible array members in C in verifying your debug
report and that the debugger sometimes lies.
Feedback and tests are welcome. With the reproducer, it has been stable
for 45 minutes on an older version of this diff (with membar_sync()).
Index: Makefile
===
RCS file: /cvs/ports/databases/redis/Makefile,v
retrieving revision 1.113
diff -u -p -u -p -r1.113 Makefile
--- Makefile14 Jun 2020 07:35:36 - 1.113
+++ Makefile27 Jun 2020 04:35:55 -
@@ -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_sentinel_c
===
RCS file: patches/patch-src_sentinel_c
diff -N patches/patch-src_sentinel_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_sentinel_c27 Jun 2020 04:35:55 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+redis-sentinel out of bounds memory access from memcmp
+
+Index: src/sentinel.c
+--- src/sentinel.c.orig
src/sentinel.c
+@@ -2217,8 +2217,8 @@ void sentinelRefreshInstanceInfo(sentinelRedisInstance
+ }
+
+ /* role: */
+-if (!memcmp(l,"role:master",11)) role = SRI_MASTER;
+-else if (!memcmp(l,"role:slave",10)) role = SRI_SLAVE;
++if (sdslen(l) >= 11 && !memcmp(l,"role:master",11)) role = SRI_MASTER;
++else if (sdslen(l) >= 10 && !memcmp(l,"ro
Re: editors/emacs fix to use posix_openpt
On Sat, 27 Jun 2020 00:29:05 +0200
Jeremie Courreges-Anglas wrote:
> On Fri, Jun 26 2020, YASUOKA Masahiko wrote:
>> Hi,
>>
>> Currently emacs is using an old way to create a process with a pty.
>> OpenBSD has posix_openpt(3) now, so emacs should use it.
>>
>> I actually hit a problem that Mew could not start gnupg properly.
>
> Makes sense.
>
>> # I sent a bug report to the upstream as well.
>
> I think you reversed configure.ac and configure.ac.orig in the patch in
> your bug report:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42059
Thanks, it was reversed. I corrected the diff by a reply.
> Regarding the ports tree patch, the order of the operating systems list
> is different from your patch for upstream. I would expect "openbsd" to
> go between "freebsd" and "netbsd", but I can live with that. :)
:)
>> ok?
>
> Works for me, let's see if it introduces any issue. ok jca@
committed. Thanks,
>> Index: Makefile
>> ===
>> RCS file: /disk/cvs/openbsd/ports/editors/emacs/Makefile,v
>> retrieving revision 1.93
>> diff -u -p -r1.93 Makefile
>> --- Makefile 10 Nov 2019 21:50:23 - 1.93
>> +++ Makefile 26 Jun 2020 10:02:29 -
>> @@ -3,7 +3,7 @@
>> COMMENT=GNU editor: extensible, customizable, self-documenting
>>
>> VERSION=26.3
>> -REVISION= 1
>> +REVISION= 2
>> DISTNAME= emacs-${VERSION}
>>
>> CATEGORIES= editors
>> Index: patches/patch-configure
>> ===
>> RCS file: /disk/cvs/openbsd/ports/editors/emacs/patches/patch-configure,v
>> retrieving revision 1.17
>> diff -u -p -r1.17 patch-configure
>> --- patches/patch-configure 25 Sep 2019 22:10:51 - 1.17
>> +++ patches/patch-configure 26 Jun 2020 10:02:29 -
>> @@ -13,3 +13,18 @@ Index: configure
>> ;;
>> esac
>>
>> +@@ -18602,12 +18600,12 @@ case $opsys in
>> +
>> + ;;
>> +
>> +- gnu | openbsd | qnxnto )
>> ++ gnu | qnxnto )
>> + $as_echo "#define FIRST_PTY_LETTER 'p'" >>confdefs.h
>> +
>> + ;;
>> +
>> +- gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd | darwin | nacl )
>> ++ openbsd | gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd |
>> darwin | nacl )
>> + if test "x$ac_cv_func_grantpt" = xyes; then
>> +
>> + $as_echo "#define UNIX98_PTYS 1" >>confdefs.h
>>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[sparc64/base-gcc] Fix build of x11/gnome/seahorse
Another port that uses C99 so base-gcc needs to be told to use it.
This diff adds -std=gnu99 for base-gcc arches and fixes the build
on at least sparc64.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/x11/gnome/seahorse/Makefile,v
retrieving revision 1.121
diff -u -p -r1.121 Makefile
--- Makefile21 Jun 2020 09:39:05 - 1.121
+++ Makefile27 Jun 2020 01:03:04 -
@@ -21,6 +21,11 @@ MODULES= devel/dconf \
MODGNOME_TOOLS=desktop-file-utils gtk-update-icon-cache vala yelp
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
LIB_DEPENDS= databases/openldap \
devel/libsoup \
net/avahi \
[sparc64/base-gcc] Fix build of sysutils/usmb
This patch drops -Werror from the build because all the deprecation
warnings for glib-2.0 make the build abort. It fixes the build on
sparc64.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/sysutils/usmb/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile12 Jul 2019 20:49:54 - 1.10
+++ Makefile9 Nov 2019 10:20:29 -
@@ -3,7 +3,7 @@
COMMENT= mount SMB shares from userland via FUSE
DISTNAME= usmb-20130204
-REVISION= 6
+REVISION= 7
CATEGORIES=sysutils
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/sysutils/usmb/patches/patch-Makefile_in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-Makefile_in
--- patches/patch-Makefile_in 5 Jun 2014 15:40:09 - 1.1.1.1
+++ patches/patch-Makefile_in 9 Nov 2019 10:20:29 -
@@ -1,7 +1,8 @@
$OpenBSD: patch-Makefile_in,v 1.1.1.1 2014/06/05 15:40:09 sthen Exp $
Makefile.in.orig Mon Feb 4 19:32:17 2013
-+++ Makefile.inTue Jun 3 10:36:28 2014
-@@ -22,7 +22,7 @@ prefix = ${DESTDIR}@prefix@
+Index: Makefile.in
+--- Makefile.in.orig
Makefile.in
+@@ -22,10 +22,10 @@ prefix = ${DESTDIR}@prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
datarootdir = @datarootdir@
@@ -9,7 +10,11 @@
+mandir = ${DESTDIR}@mandir@
man1dir = $(mandir)/man1
- CFLAGS = @CFLAGS@ -I@srcdir@ -I@builddir@ -Werror
+-CFLAGS = @CFLAGS@ -I@srcdir@ -I@builddir@ -Werror
++CFLAGS = @CFLAGS@ -I@srcdir@ -I@builddir@
+ LDFLAGS = @LDFLAGS@
+ LIBS = @LIBS@
+
@@ -65,7 +65,7 @@ install-strip: STRIPFLAGS = -s
install install-strip: $(PROGRAM)
@MKDIR_P@ $(bindir) $(man1dir)
[sparc64/base-hcc] Fix build of devel/glade
Another C99 port. Needs the following to compile on sparc64 and other
base-gcc arches.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/glade/Makefile,v
retrieving revision 1.88
diff -u -p -r1.88 Makefile
--- Makefile14 May 2020 15:13:34 - 1.88
+++ Makefile27 Jun 2020 00:52:33 -
@@ -45,6 +45,11 @@ MODGNOME_TOOLS += gobject-introspection
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS += --disable-webkit2gtk
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
DEBUG_PACKAGES = ${BUILD_PACKAGES}
post-install:
Re: add OpenMP to ports-gcc
Thanks Stuart and Pascal for the help. I'm not sure what happened with my original patch and my inability to see some obvious issues. I have a patch ready but just noticed it doesn't have the @static-lib entries for the Ada libraries. I'll submit that later then. John
Re: editors/emacs fix to use posix_openpt
On Fri, Jun 26 2020, YASUOKA Masahiko wrote:
> Hi,
>
> Currently emacs is using an old way to create a process with a pty.
> OpenBSD has posix_openpt(3) now, so emacs should use it.
>
> I actually hit a problem that Mew could not start gnupg properly.
Makes sense.
> # I sent a bug report to the upstream as well.
I think you reversed configure.ac and configure.ac.orig in the patch in
your bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42059
Regarding the ports tree patch, the order of the operating systems list
is different from your patch for upstream. I would expect "openbsd" to
go between "freebsd" and "netbsd", but I can live with that. :)
> ok?
Works for me, let's see if it introduces any issue. ok jca@
> Index: Makefile
> ===
> RCS file: /disk/cvs/openbsd/ports/editors/emacs/Makefile,v
> retrieving revision 1.93
> diff -u -p -r1.93 Makefile
> --- Makefile 10 Nov 2019 21:50:23 - 1.93
> +++ Makefile 26 Jun 2020 10:02:29 -
> @@ -3,7 +3,7 @@
> COMMENT= GNU editor: extensible, customizable, self-documenting
>
> VERSION= 26.3
> -REVISION=1
> +REVISION=2
> DISTNAME=emacs-${VERSION}
>
> CATEGORIES= editors
> Index: patches/patch-configure
> ===
> RCS file: /disk/cvs/openbsd/ports/editors/emacs/patches/patch-configure,v
> retrieving revision 1.17
> diff -u -p -r1.17 patch-configure
> --- patches/patch-configure 25 Sep 2019 22:10:51 - 1.17
> +++ patches/patch-configure 26 Jun 2020 10:02:29 -
> @@ -13,3 +13,18 @@ Index: configure
> ;;
> esac
>
> +@@ -18602,12 +18600,12 @@ case $opsys in
> +
> + ;;
> +
> +- gnu | openbsd | qnxnto )
> ++ gnu | qnxnto )
> + $as_echo "#define FIRST_PTY_LETTER 'p'" >>confdefs.h
> +
> + ;;
> +
> +- gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd | darwin | nacl )
> ++ openbsd | gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd |
> darwin | nacl )
> + if test "x$ac_cv_func_grantpt" = xyes; then
> +
> + $as_echo "#define UNIX98_PTYS 1" >>confdefs.h
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: UPDATE: GLEW 2.2.0
ping.
On 5/16/2020 6:37 PM, Brad Smith wrote:
Here is an update to GLEW 2.2.0.
Index: Makefile
===
RCS file: /home/cvs/ports/graphics/glew/Makefile,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 Makefile
--- Makefile12 Jul 2019 20:46:59 - 1.18
+++ Makefile29 Mar 2020 04:20:55 -
@@ -5,13 +5,12 @@ NOT_FOR_ARCHS=m88k
COMMENT= GL Extension Wrangler library
-DISTNAME= glew-2.0.0
-REVISION= 0
+DISTNAME= glew-2.2.0
CATEGORIES= graphics
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=glew/}
EXTRACT_SUFX= .tgz
-SHARED_LIBS= GLEW 8.0
+SHARED_LIBS= GLEW9.0
HOMEPAGE= http://glew.sourceforge.net/
Index: distinfo
===
RCS file: /home/cvs/ports/graphics/glew/distinfo,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 distinfo
--- distinfo30 Dec 2016 13:57:51 - 1.8
+++ distinfo29 Mar 2020 04:08:19 -
@@ -1,2 +1,2 @@
-SHA256 (glew-2.0.0.tgz) = xXLDCk5kaJw0K6FiQTCsmJNtevkMMQP5zhK4oMVzZ2Q=
-SIZE (glew-2.0.0.tgz) = 667340
+SHA256 (glew-2.2.0.tgz) = 1PyCiTz7ABCVeNChojN/uMozWzzsz5e5flzH8I5DU+E=
+SIZE (glew-2.2.0.tgz) = 835861
Index: patches/patch-Makefile
===
RCS file: /home/cvs/ports/graphics/glew/patches/patch-Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 patch-Makefile
--- patches/patch-Makefile 30 Dec 2016 13:57:51 - 1.8
+++ patches/patch-Makefile 29 Mar 2020 04:08:55 -
@@ -1,6 +1,8 @@
$OpenBSD: patch-Makefile,v 1.8 2016/12/30 13:57:51 sthen Exp $
Makefile.orig Sat Jul 23 20:43:37 2016
-+++ Makefile Sat Dec 17 18:41:07 2016
+
+Index: Makefile
+--- Makefile.orig
Makefile
@@ -81,7 +81,7 @@ else
OPT = $(POPT)
endif
Index: patches/patch-include_GL_glew_h
===
RCS file: patches/patch-include_GL_glew_h
diff -N patches/patch-include_GL_glew_h
--- patches/patch-include_GL_glew_h 28 Jan 2019 08:26:17 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,25 +0,0 @@
-$OpenBSD: patch-include_GL_glew_h,v 1.3 2019/01/28 08:26:17 jsg Exp $
-
-7f65a36866f4e24dd1446fe1c9d21424f28bcabd
-Fixed compilation with current mesa versions.
-
-Index: include/GL/glew.h
include/GL/glew.h.orig
-+++ include/GL/glew.h
-@@ -93,7 +93,7 @@
- #if defined(__REGAL_H__)
- #error Regal.h included before glew.h
- #endif
--#if defined(__glext_h_) || defined(__GLEXT_H_)
-+#if defined(__glext_h_) || defined(__GLEXT_H_) || defined(__gl_glext_h_)
- #error glext.h included before glew.h
- #endif
- #if defined(__gl_ATI_h_)
-@@ -109,6 +109,7 @@
- #define __X_GL_H
- #define __glext_h_
- #define __GLEXT_H_
-+#define __gl_glext_h_
- #define __gl_ATI_h_
-
- #if defined(_WIN32)
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/graphics/glew/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST 30 Dec 2016 13:57:51 - 1.6
+++ pkg/PLIST 29 Mar 2020 04:19:11 -
@@ -6,7 +6,7 @@ include/GL/eglew.h
include/GL/glew.h
include/GL/glxew.h
include/GL/wglew.h
-lib/libGLEW.a
+@static-lib lib/libGLEW.a
@lib lib/libGLEW.so.${LIBGLEW_VERSION}
lib/pkgconfig/glew.pc
share/doc/glew/
Re: add OpenMP to ports-gcc
On 2020/06/26 15:57, j...@bitminer.ca wrote: > > > On 2020-06-26 15:48, Stuart Henderson wrote: > > > > > +lib/libgomp.a > > > > This update was not done on -current > > thanks, I'll recheck, but the kernel is -current > > snap1$ sysctl kern.version > kern.version=OpenBSD 6.7-current (GENERIC.MP) #272: Mon Jun 15 01:54:58 MDT > 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > "make plist" should have put an @static-lib on that line.
Re: add OpenMP to ports-gcc
On 2020-06-26 15:48, Stuart Henderson wrote: > > +lib/libgomp.a This update was not done on -current thanks, I'll recheck, but the kernel is -current snap1$ sysctl kern.version kern.version=OpenBSD 6.7-current (GENERIC.MP) #272: Mon Jun 15 01:54:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Re: add OpenMP to ports-gcc
On Fri, 19 Jun 2020 11:50:48 -0700 (PDT), j...@bitminer.ca wrote:
> This patch adjusts gcc-ports to add the various OpenMP libraries
> already built to PLIST(s).
>
> Since ports were already patched to disable OpenMP this change
> should likely result in no issues.
>
>
> John
Comment is unnecessary, otherwise looks good gcc-portwise. Are we
positive this has no ill effects anywhere at this point? Have you done
a bulk on sparc64?
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> retrieving revision 1.31
> diff -u -p -r1.31 Makefile
> --- Makefile 5 Apr 2020 15:44:52 - 1.31
> +++ Makefile 19 Jun 2020 18:36:56 -
> @@ -16,7 +16,7 @@ USE_LLD = No
> DPB_PROPERTIES = parallel
>
> V = 8.3.0
> -REVISION = 5
> +REVISION = 6
> FULL_VERSION = $V
> FULL_PKGVERSION = $V
>
> @@ -42,6 +42,7 @@ SHARED_LIBS = estdc++ 19.0 \
> lto_plugin 5.0 \
> itm 4.0 \
> atomic 3.0 \
> + gomp1.0 \
> quadmath3.0 \
> cc1 1.0 \
> cc1plugin 1.0 \
> @@ -117,13 +118,13 @@ MAKE_ENV += ${EXTRA_ENV}
>
> CFLAGS = -O2 -g
>
> +## disable=libgomp off
> CONFIGURE_ARGS += \
> --verbose \
> --program-transform-name=s,^,e, \
> --disable-nls \
> --with-system-zlib \
> --disable-libmudflap \
> - --disable-libgomp \
> --disable-libssp \
> --disable-tls \
> --with-gnu-ld \
> Index: pkg/PLIST-f95
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-f95,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-f95
> --- pkg/PLIST-f95 27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-f95 19 Jun 2020 18:36:56 -
> @@ -11,6 +11,9 @@ lib/gcc/${CONFIG}/${V}/finclude/
> lib/gcc/${CONFIG}/${V}/finclude/ieee_arithmetic.mod
> lib/gcc/${CONFIG}/${V}/finclude/ieee_exceptions.mod
> lib/gcc/${CONFIG}/${V}/finclude/ieee_features.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib_kinds.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.h
> lib/gcc/${CONFIG}/${V}/libcaf_single.a
> lib/gcc/${CONFIG}/${V}/libcaf_single.la
> lib/libgfortran.a
> Index: pkg/PLIST-libs
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-libs,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-libs
> --- pkg/PLIST-libs27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-libs19 Jun 2020 18:36:56 -
> @@ -13,5 +13,9 @@ lib/libobjc.la
> @lib lib/libobjc.so.${LIBobjc_VERSION}
> lib/libcc1.la
> @lib lib/libcc1.so.${LIBcc1_VERSION}
> +lib/libgomp.la
> +@lib lib/libgomp.so.${LIBgomp_VERSION}
> +lib/libgomp.a
> +lib/libgomp.spec
> %%ITM%%
> %%QUADMATH%%
> Index: pkg/PLIST-main
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-main,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-main
> --- pkg/PLIST-main27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-main19 Jun 2020 18:36:56 -
> @@ -29,6 +29,7 @@ lib/gcc/${CONFIG}/${V}/include-fixed/REA
> lib/gcc/${CONFIG}/${V}/include-fixed/limits.h
> lib/gcc/${CONFIG}/${V}/include-fixed/syslimits.h
> lib/gcc/${CONFIG}/${V}/include/gcov.h
> +lib/gcc/${CONFIG}/${V}/include/omp.h
> lib/gcc/${CONFIG}/${V}/include/stdalign.h
> lib/gcc/${CONFIG}/${V}/include/stdatomic.h
> lib/gcc/${CONFIG}/${V}/include/stdfix.h
>
Re: add OpenMP to ports-gcc
On 2020/06/26 15:45, j...@bitminer.ca wrote: > > > > Sorry, further comment: .a and .spec should go into PLIST-main. > > > > Could you perhaps explain why? These would seem to me to be unused > unless gcc-libs was installed for the shared image. They are useless without the compiler. No need to bloat the gcc-libs package which is installed as a dependency of many other packages (especially on base-gcc arches).
Re: add OpenMP to ports-gcc
> > > +lib/libgomp.a This update was not done on -current
Re: add OpenMP to ports-gcc
Hi Pascal,
On 2020-06-26 15:03, Pascal Stumpf wrote:
On Fri, 26 Jun 2020 23:01:29 +0200, Pascal Stumpf wrote:
On Fri, 19 Jun 2020 11:50:48 -0700 (PDT), j...@bitminer.ca wrote:
> This patch adjusts gcc-ports to add the various OpenMP libraries
> already built to PLIST(s).
>
> Since ports were already patched to disable OpenMP this change
> should likely result in no issues.
>
>
> John
Comment is unnecessary, otherwise looks good gcc-portwise. Are we
positive this has no ill effects anywhere at this point? Have you
done
a bulk on sparc64?
I did a check of all ports using various means like github search,
source checks, sqlports reviews etc last August and most should be
immune to having OpenMP become available (where "immune" means
they continue to operate single-threaded). I've also been
watching ports-cvs. Doubtless some have slipped through.
See
https://marc.info/?l=openbsd-ports&m=156470447814218&w=2
for more details.
I don't have access to a sparc nor a bulk-build capability.
Sorry, further comment: .a and .spec should go into PLIST-main.
Could you perhaps explain why? These would seem to me to be unused
unless gcc-libs was installed for the shared image.
thanks
John
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> retrieving revision 1.31
> diff -u -p -r1.31 Makefile
> --- Makefile 5 Apr 2020 15:44:52 - 1.31
> +++ Makefile 19 Jun 2020 18:36:56 -
> @@ -16,7 +16,7 @@ USE_LLD = No
> DPB_PROPERTIES = parallel
>
> V = 8.3.0
> -REVISION = 5
> +REVISION = 6
> FULL_VERSION = $V
> FULL_PKGVERSION = $V
>
> @@ -42,6 +42,7 @@ SHARED_LIBS =estdc++ 19.0 \
>lto_plugin 5.0 \
>itm 4.0 \
>atomic 3.0 \
> + gomp1.0 \
>quadmath3.0 \
>cc1 1.0 \
>cc1plugin 1.0 \
> @@ -117,13 +118,13 @@ MAKE_ENV += ${EXTRA_ENV}
>
> CFLAGS = -O2 -g
>
> +## disable=libgomp off
> CONFIGURE_ARGS += \
>--verbose \
>--program-transform-name=s,^,e, \
>--disable-nls \
>--with-system-zlib \
>--disable-libmudflap \
> - --disable-libgomp \
>--disable-libssp \
>--disable-tls \
>--with-gnu-ld \
> Index: pkg/PLIST-f95
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-f95,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-f95
> --- pkg/PLIST-f95 27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-f95 19 Jun 2020 18:36:56 -
> @@ -11,6 +11,9 @@ lib/gcc/${CONFIG}/${V}/finclude/
> lib/gcc/${CONFIG}/${V}/finclude/ieee_arithmetic.mod
> lib/gcc/${CONFIG}/${V}/finclude/ieee_exceptions.mod
> lib/gcc/${CONFIG}/${V}/finclude/ieee_features.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib_kinds.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.mod
> +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.h
> lib/gcc/${CONFIG}/${V}/libcaf_single.a
> lib/gcc/${CONFIG}/${V}/libcaf_single.la
> lib/libgfortran.a
> Index: pkg/PLIST-libs
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-libs,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-libs
> --- pkg/PLIST-libs 27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-libs 19 Jun 2020 18:36:56 -
> @@ -13,5 +13,9 @@ lib/libobjc.la
> @lib lib/libobjc.so.${LIBobjc_VERSION}
> lib/libcc1.la
> @lib lib/libcc1.so.${LIBcc1_VERSION}
> +lib/libgomp.la
> +@lib lib/libgomp.so.${LIBgomp_VERSION}
> +lib/libgomp.a
> +lib/libgomp.spec
> %%ITM%%
> %%QUADMATH%%
> Index: pkg/PLIST-main
> ===
> RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-main,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST-main
> --- pkg/PLIST-main 27 Apr 2019 21:26:35 - 1.2
> +++ pkg/PLIST-main 19 Jun 2020 18:36:56 -
> @@ -29,6 +29,7 @@ lib/gcc/${CONFIG}/${V}/include-fixed/REA
> lib/gcc/${CONFIG}/${V}/include-fixed/limits.h
> lib/gcc/${CONFIG}/${V}/include-fixed/syslimits.h
> lib/gcc/${CONFIG}/${V}/include/gcov.h
> +lib/gcc/${CONFIG}/${V}/include/omp.h
> lib/gcc/${CONFIG}/${V}/include/stdalign.h
> lib/gcc/${CONFIG}/${V}/include/stdatomic.h
> lib/gcc/${CONFIG}/${V}/include/stdfix.h
>
Re: add OpenMP to ports-gcc
On Fri, 26 Jun 2020 23:01:29 +0200, Pascal Stumpf wrote:
> On Fri, 19 Jun 2020 11:50:48 -0700 (PDT), j...@bitminer.ca wrote:
> > This patch adjusts gcc-ports to add the various OpenMP libraries
> > already built to PLIST(s).
> >
> > Since ports were already patched to disable OpenMP this change
> > should likely result in no issues.
> >
> >
> > John
>
> Comment is unnecessary, otherwise looks good gcc-portwise. Are we
> positive this has no ill effects anywhere at this point? Have you done
> a bulk on sparc64?
Sorry, further comment: .a and .spec should go into PLIST-main.
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 Makefile
> > --- Makefile5 Apr 2020 15:44:52 - 1.31
> > +++ Makefile19 Jun 2020 18:36:56 -
> > @@ -16,7 +16,7 @@ USE_LLD = No
> > DPB_PROPERTIES = parallel
> >
> > V = 8.3.0
> > -REVISION = 5
> > +REVISION = 6
> > FULL_VERSION = $V
> > FULL_PKGVERSION = $V
> >
> > @@ -42,6 +42,7 @@ SHARED_LIBS = estdc++ 19.0 \
> > lto_plugin 5.0 \
> > itm 4.0 \
> > atomic 3.0 \
> > + gomp1.0 \
> > quadmath3.0 \
> > cc1 1.0 \
> > cc1plugin 1.0 \
> > @@ -117,13 +118,13 @@ MAKE_ENV += ${EXTRA_ENV}
> >
> > CFLAGS = -O2 -g
> >
> > +## disable=libgomp off
> > CONFIGURE_ARGS += \
> > --verbose \
> > --program-transform-name=s,^,e, \
> > --disable-nls \
> > --with-system-zlib \
> > --disable-libmudflap \
> > - --disable-libgomp \
> > --disable-libssp \
> > --disable-tls \
> > --with-gnu-ld \
> > Index: pkg/PLIST-f95
> > ===
> > RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-f95,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 PLIST-f95
> > --- pkg/PLIST-f95 27 Apr 2019 21:26:35 - 1.2
> > +++ pkg/PLIST-f95 19 Jun 2020 18:36:56 -
> > @@ -11,6 +11,9 @@ lib/gcc/${CONFIG}/${V}/finclude/
> > lib/gcc/${CONFIG}/${V}/finclude/ieee_arithmetic.mod
> > lib/gcc/${CONFIG}/${V}/finclude/ieee_exceptions.mod
> > lib/gcc/${CONFIG}/${V}/finclude/ieee_features.mod
> > +lib/gcc/${CONFIG}/${V}/finclude/omp_lib_kinds.mod
> > +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.mod
> > +lib/gcc/${CONFIG}/${V}/finclude/omp_lib.h
> > lib/gcc/${CONFIG}/${V}/libcaf_single.a
> > lib/gcc/${CONFIG}/${V}/libcaf_single.la
> > lib/libgfortran.a
> > Index: pkg/PLIST-libs
> > ===
> > RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-libs,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 PLIST-libs
> > --- pkg/PLIST-libs 27 Apr 2019 21:26:35 - 1.2
> > +++ pkg/PLIST-libs 19 Jun 2020 18:36:56 -
> > @@ -13,5 +13,9 @@ lib/libobjc.la
> > @lib lib/libobjc.so.${LIBobjc_VERSION}
> > lib/libcc1.la
> > @lib lib/libcc1.so.${LIBcc1_VERSION}
> > +lib/libgomp.la
> > +@lib lib/libgomp.so.${LIBgomp_VERSION}
> > +lib/libgomp.a
> > +lib/libgomp.spec
> > %%ITM%%
> > %%QUADMATH%%
> > Index: pkg/PLIST-main
> > ===
> > RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-main,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 PLIST-main
> > --- pkg/PLIST-main 27 Apr 2019 21:26:35 - 1.2
> > +++ pkg/PLIST-main 19 Jun 2020 18:36:56 -
> > @@ -29,6 +29,7 @@ lib/gcc/${CONFIG}/${V}/include-fixed/REA
> > lib/gcc/${CONFIG}/${V}/include-fixed/limits.h
> > lib/gcc/${CONFIG}/${V}/include-fixed/syslimits.h
> > lib/gcc/${CONFIG}/${V}/include/gcov.h
> > +lib/gcc/${CONFIG}/${V}/include/omp.h
> > lib/gcc/${CONFIG}/${V}/include/stdalign.h
> > lib/gcc/${CONFIG}/${V}/include/stdatomic.h
> > lib/gcc/${CONFIG}/${V}/include/stdfix.h
> >
gobject-introspection: can't resolve dependencies
This happened out of blue, don't know how deal with this. This is repeatable, everytime. I came across it while installing ImageMagick. ===> gobject-introspection-1.64.1 depends on: py3-mako-* - not found ===> Verifying install for py3-mako-* in www/py-mako `/usr/portsdir/bulk/amd64/py3-mako-1.1.1' is up to date. ===> Installing py3-mako-1.1.1 from /usr/portsdir/packages/amd64/all/ Can't find gmp-6.2.0 Can't install py3-cryptodome-3.9.7: can't resolve gmp-6.2.0 Can't install py3-beaker-1.10.0p0: can't resolve py3-cryptodome-3.9.7 Can't install py3-mako-1.1.1: can't resolve py3-beaker-1.10.0p0 Couldn't install gmp-6.2.0 py3-beaker-1.10.0p0 py3-cryptodome-3.9.7 py3-mako-1.1.1 *** Error 1 in /usr/ports/www/py-mako (/usr/ports/infrastructure/mk/bsd.port.mk:2138 '/var/db/pkg/py3-mako-1.1.1/+CONTENTS': @/usr/bin/env -...) *** Error 2 in /usr/ports/www/py-mako (/usr/ports/infrastructure/mk/bsd.port.mk:2581 'install': @lock=py3-mako-1.1.1; export _LOCKS_HELD=" ...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2263 '/usr/portsdir/pobj/gobject-introspection-1.64.1/.dep-www-py-mako,python3') *** Error 2 in /usr/ports/devel/gobject-introspection (/usr/ports/infrastructure/mk/bsd.port.mk:2581 'prepare': @lock=gobject-introspection-...) This is my mk.conf, I don't know what more info I need to provide SUDO=sudo PORTS_PRIVSEP=Yes DISTDIR=/usr/distfiles BULK_COOKIES_DIR=/usr/portsdir/bulk/amd64 UPDATE_COOKIES_DIR=/usr/portsdir/update/amd64 WRKOBJDIR=/usr/portsdir/pobj PACKAGE_REPOSITORY=/usr/portsdir/packages PLIST_REPOSITORY=/usr/portsdir/plist
Re: move py-flask-principal to python3
On 6/26/20 12:10 PM, Stuart Henderson wrote:
> On 2020/06/26 11:48, Aisha Tammy wrote:
>> On 6/26/20 11:30 AM, Antoine Jacoutot wrote:
>>> On Fri, Jun 26, 2020 at 10:04:22AM -0400, Aisha Tammy wrote:
On 6/26/20 9:58 AM, Antoine Jacoutot wrote:
> On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
>> I've updated the port py-flask-principal to use
>> only python3.
>> There are no reverse dependencies so this should
>> not be breaking anything.
>
> You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
>
I thought as python2 is EOL and there are no reverse dependencies
it might be better to drop python 2 support, for any eventual cleanup?
>>>
>>> You enforce the python3 FLAVOR like this:
>>>
>>> FLAVORS=python3
>>> FLAVOR= python3
>>>
>>
>> Ah, thanks for that.
>> I only recently learnt that the MODPY_DEFAULT_VERSION_3 is not the
>> recommended method.
>
> For standalone packages (e.g. a program which happens to use Python),
> use MODPY_DEFAULT_VERSION_3.
>
> For Python modules, use FLAVOR/FLAVORS, then if any ports depend on them
> they can use e.g. "www/py-flask-principal${MODPY_FLAVOR}" rather than
> a mess of "www/py-foo" and "www/py-bar${MODPY_FLAVOR}"..
>
> There are still some Python modules in the tree using the
> MODPY_DEFAULT_VERSION_3 method because we haven't swept the tree to
> remove them yet.
MOAR KNOWLEDGE!
Well, learning lots of new things. This month has been interesting.
Thanks Stuart!
Aisha
>
>> Have attached new diff as seems like my thunderbird likes to mess up.
>>
>> Aisha
>>
>
>> diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
>> index d062e04f581..b3d80ecffd8 100644
>> --- www/py-flask-principal/Makefile
>> +++ www/py-flask-principal/Makefile
>> @@ -3,7 +3,7 @@
>> COMMENT = identity management for flask
>>
>> MODPY_EGG_VERSION = 0.4.0
>> -REVISION = 1
>> +REVISION = 2
>> DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
>> PKGNAME = py-${DISTNAME:L}
>>
>> @@ -16,11 +16,14 @@ MAINTAINER = Aaron Bieber
>>
>> # MIT
>> PERMIT_PACKAGE =Yes
>>
>> +FLAVORS = python3
>> +FLAVOR =python3
>> +
>> MODPY_PI = Yes
>>
>> MODULES = lang/python
>>
>> -RUN_DEPENDS += www/py-flask
>> +RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
>>
>> MODPY_SETUPTOOLS = Yes
>>
>> diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
>> index a7db0b09fcb..4193651f7f9 100644
>> --- www/py-flask-principal/pkg/PLIST
>> +++ www/py-flask-principal/pkg/PLIST
>> @@ -6,5 +6,5 @@
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
>> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
>> lib/python${MODPY_VERSION}/site-packages/flask_principal.py
>> -lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
>
Re: [NEW] textproc/lucene++
Landry Breuil writes:
> another way that implies less patching, as you already patch
> CMakeLists.txt for cotire:
>
> @@ -85,7 +80,7 @@ include(TestCXXAcceptsFlag)
> include(GNUInstallDirs)
>
> set(LIB_DESTINATION
> - "${CMAKE_INSTALL_FULL_LIBDIR}" CACHE STRING "Define lib output directory
> name"
> + "lib" CACHE STRING "Define lib output directory name"
> )
>
> if(ENABLE_CYCLIC_CHECK)
>
> with that chunk added to patch-CMakeLists.txt, no need to patch the .cmake
> files to fiddle with prefix/LIB_DESTINATION, and the resulting .pc look
> correct.
I really like this. Update tarball with this applied.
> On Fri, Jun 26, 2020 at 06:30:28PM +0200, Landry Breuil wrote:
>> On Fri, Jun 26, 2020 at 11:02:42AM +0200, Omar Polo wrote:
>> >
>> > Landry Breuil writes:
>
>
>> > unfortunately, after a while it core dumps:
>> >
>> > ...
>> > [--] 102 tests from IndexWriterTest
>> > [ RUN ] IndexWriterTest.testDocCount
>> > [ OK ] IndexWriterTest.testDocCount (7 ms)
>> > [ RUN ] IndexWriterTest.testAddIndexOnDiskFull
>> > Segmentation fault (core dumped)
>>
>> Tests are still running here, dunno if they will fail, but it's always good
>> to
>> have them at least available/running.
>
> Only one failed here, and it was properly handled by the framework:
>
> [--] Global test environment tear-down
> [==] 1472 tests from 201 test cases ran. (1152166 ms total)
> [ PASSED ] 1471 tests.
> [ FAILED ] 1 test, listed below:
> [ FAILED ] DateToolsTest.testParseDateLocale
>
> 1 FAILED TEST
> terminating with uncaught exception of type std::bad_cast: std::bad_cast
> Abort trap (core dumped)
>
> so that looks pretty good testing-wise.
>
> Landry
I've re-runned the test and I've got the same result as you. For the
record, the failing test tries to parse some dates in different locales
(en_GB and en_US.UTF-8):
...
97 DateTools::setDateOrder(DateTools::DATEORDER_LOCALE);
98 EXPECT_EQ(DateTools::parseDate(L"01122005", std::locale("en_GB.UTF-8")),
ptime(date(2005, 12, 01)));
99 EXPECT_EQ(DateTools::parseDate(L"011205", std::locale("en_GB.UTF-8")),
ptime(date(2005, 12, 01)));
100 EXPECT_EQ(DateTools::parseDate(L"01/12/2005", std::locale("en_GB.UTF-8")),
ptime(date(2005, 12, 01)));
101 EXPECT_EQ(DateTools::parseDate(L"01/12/05", std::locale("en_GB.UTF-8")),
ptime(date(2005, 12, 01)));
102 EXPECT_EQ(DateTools::parseDate(L"1/12/2005", std::locale("en_GB.UTF-8")),
ptime(date(2005, 12, 01)));
...
I don't have enough knowledge/time at the moment to fix this tbh.
luceneplusplus.tar.gz
Description: Binary data
Re: move py-flask-principal to python3
On 6/26/20 11:30 AM, Antoine Jacoutot wrote:
> On Fri, Jun 26, 2020 at 10:04:22AM -0400, Aisha Tammy wrote:
>> On 6/26/20 9:58 AM, Antoine Jacoutot wrote:
>>> On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
I've updated the port py-flask-principal to use
only python3.
There are no reverse dependencies so this should
not be breaking anything.
>>>
>>> You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
>>>
>>
>> I thought as python2 is EOL and there are no reverse dependencies
>> it might be better to drop python 2 support, for any eventual cleanup?
>
> You enforce the python3 FLAVOR like this:
>
> FLAVORS= python3
> FLAVOR= python3
>
Ah, thanks for that.
I only recently learnt that the MODPY_DEFAULT_VERSION_3 is not the
recommended method.
Have attached new diff as seems like my thunderbird likes to mess up.
Aisha
diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
index d062e04f581..b3d80ecffd8 100644
--- www/py-flask-principal/Makefile
+++ www/py-flask-principal/Makefile
@@ -3,7 +3,7 @@
COMMENT = identity management for flask
MODPY_EGG_VERSION = 0.4.0
-REVISION = 1
+REVISION = 2
DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:L}
@@ -16,11 +16,14 @@ MAINTAINER = Aaron Bieber
# MIT
PERMIT_PACKAGE = Yes
+FLAVORS = python3
+FLAVOR = python3
+
MODPY_PI = Yes
MODULES = lang/python
-RUN_DEPENDS += www/py-flask
+RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
MODPY_SETUPTOOLS = Yes
diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
index a7db0b09fcb..4193651f7f9 100644
--- www/py-flask-principal/pkg/PLIST
+++ www/py-flask-principal/pkg/PLIST
@@ -6,5 +6,5 @@ lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask_principal.py
-lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
Re: NEW: devel/bamf
On Friday, June 26, 2020 11:27 AM, Stuart Henderson wrote: > On 2020/06/26 14:11, Brian Callahan wrote: > > > On Friday, June 26, 2020 8:29 AM, Stuart Henderson s...@spacehopper.org > > wrote: > > > > > On 2020/06/26 11:00, Charlene Wendling wrote: > > > > > > > port-lib-depends-check complains about this on my macppc and amd64 > > > > machines: > > > > bamf-0.5.4(devel/bamf): > > > > Missing: png.18 from png-1.6.37 (/usr/local/libexec/bamf/bamfdaemon) > > > > Extra: XRes.5 gthread-2.0.4200 png16.18 > > > > WANTLIB += png > > > > It's weird because i thought we fixed such png WANTLIB issues a while > > > > ago. It's still packaging though, so once the situation is cleared > > > > up it's fine with me. > > > > > > We did, about a year ago. Guessing the wantlib for this port was > > > generated some time ago? > > > > It was. I have a huge backlog of ports and this is one of the downsides. > > Anyhow, here's a port with a fresh WANTLIB. > > ~Brian > > Please review them yourself before sending them out - it saves everyone > time if a port is already in good shape and can just be OK'd :) I normally do. This one slipped under the radar. Apologies.
Alphabetize sysutils/Makefile listings
Hi ports -- As I was about to commit sysutils/ugrep, I noticed that some of the ports in the sysutils/Makefile listing were not in alphabetical order. Attached is a diff to resort them. Do we care about such things? OK to go ahead? ~Brian Index: Makefile === RCS file: /cvs/ports/sysutils/Makefile,v retrieving revision 1.572 diff -u -p -r1.572 Makefile --- Makefile 19 Jun 2020 14:52:23 - 1.572 +++ Makefile 26 Jun 2020 14:32:21 - @@ -385,11 +385,12 @@ SUBDIR += ttyplot SUBDIR += u-boot SUBDIR += u-boot,aarch64 - SUBDIR += uefitool SUBDIR += udfclient + SUBDIR += uefitool + SUBDIR += ugrep SUBDIR += unionfs-fuse - SUBDIR += upower SUBDIR += upobsd + SUBDIR += upower SUBDIR += upt SUBDIR += uptimed SUBDIR += usbutil
Re: NEW: x11/elementary/dock
On Friday, June 26, 2020 5:30 AM, Charlene Wendling wrote: > On Fri, 26 Jun 2020 01:54:42 + > Brian Callahan wrote: > > > Hi ports -- > > Attached is a new port, x11/elementary/dock. This is the elementary OS > > dock app. The binary is named plank. > > > > pkg/DESCR: > > Plank is meant to be the simplest dock on the planet. The goal is to > > provide just what a dock needs and absolutely nothing more. It is, > > however, a library which can be extended to create other dock programs > > with more advanced features. > > > > --- > > > > Needs the bamf port sent earlier. Works well on amd64. Note that the > > CPU and battery docklets do not appear to work, but I believe I can > > get those working at some point. > > OK? > > ~Brian > > It builds and works fine on amd64 and macppc. It adds mupdf, but unlike > mpv it has no "drag file there to open it" dialog. Well, we still miss > some parts of the elementary puzzle anyway, so go ahead :) > > OK cwen@ I do plan on improving support for things so keep a running list! :) ~Brian
Re: NEW: devel/bamf
On Friday, June 26, 2020 8:29 AM, Stuart Henderson wrote: > On 2020/06/26 11:00, Charlene Wendling wrote: > > > port-lib-depends-check complains about this on my macppc and amd64 > > machines: > > bamf-0.5.4(devel/bamf): > > Missing: png.18 from png-1.6.37 (/usr/local/libexec/bamf/bamfdaemon) > > Extra: XRes.5 gthread-2.0.4200 png16.18 > > WANTLIB += png > > It's weird because i thought we fixed such png WANTLIB issues a while > > ago. It's still packaging though, so once the situation is cleared > > up it's fine with me. > > We did, about a year ago. Guessing the wantlib for this port was > generated some time ago? It was. I have a huge backlog of ports and this is one of the downsides. Anyhow, here's a port with a fresh WANTLIB. ~Brian bamf.tgz Description: application/compressed-tar
Re: move py-flask-principal to python3
On 6/26/20 9:58 AM, Antoine Jacoutot wrote:
> On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
>> I've updated the port py-flask-principal to use
>> only python3.
>> There are no reverse dependencies so this should
>> not be breaking anything.
>
> You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
>
I thought as python2 is EOL and there are no reverse dependencies
it might be better to drop python 2 support, for any eventual cleanup?
Or is the ports tree going to keep python2 for a while ?
Aisha
>
>>
>> Aisha
>>
>> diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
>>
>> index d062e04f581..4b9f6186750 100644
>>
>> --- www/py-flask-principal/Makefile
>>
>> +++ www/py-flask-principal/Makefile
>>
>> @@ -3,7 +3,7 @@
>>
>> COMMENT = identity management for flask
>>
>>
>>
>> MODPY_EGG_VERSION = 0.4.0
>>
>> -REVISION = 1
>>
>> +REVISION = 2
>>
>> DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
>>
>> PKGNAME = py-${DISTNAME:L}
>>
>>
>>
>> @@ -16,11 +16,13 @@ MAINTAINER = Aaron Bieber
>>
>>
>> # MIT
>>
>> PERMIT_PACKAGE =Yes
>>
>>
>>
>> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
>>
>> +
>>
>> MODPY_PI = Yes
>>
>>
>>
>> MODULES = lang/python
>>
>>
>>
>> -RUN_DEPENDS += www/py-flask
>>
>> +RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
>>
>>
>>
>> MODPY_SETUPTOOLS = Yes
>>
>>
>>
>> diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
>>
>> index a7db0b09fcb..4193651f7f9 100644
>>
>> --- www/py-flask-principal/pkg/PLIST
>>
>> +++ www/py-flask-principal/pkg/PLIST
>>
>> @@ -6,5 +6,5 @@
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
>>
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
>>
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>>
>>
>> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
>>
>> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
>>
>> lib/python${MODPY_VERSION}/site-packages/flask_principal.py
>>
>> -lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
>>
>
security/hitch: remove or update/take maintainer
I imported this port when I actively used it, but circumstances have
changed and I have no longer any use for this TLS proxy, so I won't put
any more effort into sending fixes upstream as well as maintaining our
port.
1.6.0 was recently released, contains a few of my fixes merged upstream,
but also brings new fixes and even features that seem to cause trouble
on OpenBSD, namely support for client certificate validation.
Below is a diff for starters to update hitch to 1.6.0 which already
takes care of the fact that upstream now ships manuals in their dist
tarballs such that we don't have to build them with rst2man (which
upstream now again just looks for as "rst2man"; I used to fix this such
that "rst2man-3" was preferred and picked up...).
"make build" fails for 1.6.0 with
cc -g -O2-fno-strict-aliasing -O2 -pipe -L/usr/local/lib -o
hitch hitch-configuration.o hitch-hitch.o hitch-hssl_locks.o hitch-logging.o
hitch-ocsp.o hitch-ringbuffer.o -lssl -lcrypto -lcrypto-lev libcfg.a
libforeign.a
ld: error: undefined symbol: SSL_CTX_set1_verify_cert_store
>>> referenced by hitch.c:949
(/usr/ports/pobj/hitch-1.6.0/hitch-1.6.0/src/hitch.c:949)
>>> hitch-hitch.o:(make_ctx_fr)
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
There might be more in the new release, both build and runtime, but as
mentioned above, I'll leave it here.
Given that it's a TLS proxy and its history of bugs/fixes, I very much
prefer to provide a well maintained port or none at all to either
sticking to 1.5.2 or rolling best-effort future updates.
So unless someone steps up to maintain this: is anyone actually using
it/would anyone object to removing the port in case it stays unmaintained?
Index: Makefile
===
RCS file: /cvs/ports/security/hitch/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile26 Jun 2020 17:41:14 - 1.8
+++ Makefile26 Jun 2020 17:54:28 -
@@ -2,9 +2,8 @@
COMMENT = libev-based high performance TLS proxy
-V =1.5.2
+V =1.6.0
DISTNAME = hitch-${V}
-REVISION = 0
CATEGORIES = security
@@ -17,25 +16,19 @@ MASTER_SITES = https://hitch-tls.org/so
WANTLIB = c crypto ev ssl
-MODULES = lang/python
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
-MODPY_RUNDEP = No
-
-BUILD_DEPENDS =textproc/py-docutils${MODPY_FLAVOR}
LIB_DEPENDS = devel/libev>=4
TEST_DEPENDS = ${PKGPATH}=${V} \
net/curl
SEPARATE_BUILD = Yes
CONFIGURE_STYLE = gnu
-CONFIGURE_ARGS = --with-rst2man=rst2man${MODPY_BIN_SUFFIX}
CONFIGURE_ENV =CPPFLAGS='${CPPFLAGS} -I${LOCALBASE}/include' \
LDFLAGS='${LDFLAGS} -L${LOCALBASE}/lib'
TEST_IS_INTERACTIVE = connects to hitch-tls.org:80 and 127.0.0.1:443
post-patch:
- ${SUBST_CMD} ${WRKSRC}/{hitch.conf.man.rst,src/configuration.c}
+ ${SUBST_CMD} ${WRKSRC}/{hitch.conf.5,src/configuration.c}
post-configure:
ln -sf ${WRKSRC}/src/cfg_{lex,parser}.[ch] ${WRKBUILD}/src/
Index: distinfo
===
RCS file: /cvs/ports/security/hitch/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo28 Nov 2019 20:00:44 - 1.3
+++ distinfo26 Jun 2020 17:54:28 -
@@ -1,2 +1,2 @@
-SHA256 (hitch-1.5.2.tar.gz) = saT9ZFhM1P+Ba4UT7lUi2zSkQxdHBXQhtuhw9yLG39o=
-SIZE (hitch-1.5.2.tar.gz) = 309626
+SHA256 (hitch-1.6.0.tar.gz) = TkfrSrt904CchCg1iK30Hd8Me8BlywDQkoJ0iJwHxwY=
+SIZE (hitch-1.6.0.tar.gz) = 321384
Index: patches/patch-hitch_conf_5
===
RCS file: patches/patch-hitch_conf_5
diff -N patches/patch-hitch_conf_5
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-hitch_conf_5 26 Jun 2020 17:54:28 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+Set correct ocsp_dir and default user.
+
+Index: hitch.conf.5
+--- hitch.conf.5.orig
hitch.conf.5
+@@ -214,7 +214,7 @@ Default is 0.
+ .SS ocsp\-dir =
+ .sp
+ Directory where Hitch will store and read OCSP responses for
+-stapling. Default is "/var/lib/hitch/".
++stapling. Default is "${LOCALSTATEDIR}/hitch/".
+ .sp
+ Directory must be readable and writable for the configured Hitch user, or
+ automatic retrieval and updating of OCSP responses will not take place.
+@@ -499,8 +499,8 @@ daemon = on
+
+ # We strongly recommend you create a separate non\-privileged hitch
+ # user and group
+-user = "hitch"
+-group = "hitch"
++user = "_hitch"
++group = "_hitch"
+
+ # Enable to let clients negotiate HTTP/2 with ALPN. (default off)
+ # alpn\-protos = "h2, http/1.1"
Index: patches/patch-hitch_conf_man_rst
===
Re: [NEW] textproc/lucene++
On Fri, Jun 26, 2020 at 06:30:28PM +0200, Landry Breuil wrote: > On Fri, Jun 26, 2020 at 11:02:42AM +0200, Omar Polo wrote: > > > > Landry Breuil writes: > > unfortunately, after a while it core dumps: > > > > ... > > [--] 102 tests from IndexWriterTest > > [ RUN ] IndexWriterTest.testDocCount > > [ OK ] IndexWriterTest.testDocCount (7 ms) > > [ RUN ] IndexWriterTest.testAddIndexOnDiskFull > > Segmentation fault (core dumped) > > Tests are still running here, dunno if they will fail, but it's always good to > have them at least available/running. Only one failed here, and it was properly handled by the framework: [--] Global test environment tear-down [==] 1472 tests from 201 test cases ran. (1152166 ms total) [ PASSED ] 1471 tests. [ FAILED ] 1 test, listed below: [ FAILED ] DateToolsTest.testParseDateLocale 1 FAILED TEST terminating with uncaught exception of type std::bad_cast: std::bad_cast Abort trap (core dumped) so that looks pretty good testing-wise. Landry
Re: [NEW] textproc/lucene++
On Fri, Jun 26, 2020 at 11:02:42AM +0200, Omar Polo wrote:
>
> Landry Breuil writes:
>
> > On Thu, Jun 25, 2020 at 06:08:56PM +0200, Omar Polo wrote:
> >>
> >> Hello there!
> >>
> >> Attached the port for Lucene++, a port of the java lucene library. It's
> >> required by newer version of devel/poedit.
> >>
> >> The patches against the three CMakefiles are to disable cotire, as it
> >> breaks the build. The patch against VariantUtils.h is to support newer
> >> version of boost. These patches are heavily inspired (read: copied)
> >> from the freebsd port.
> >>
> >> I'm not sure about the two patches against the .pc files, because by
> >> default it generates something like
> >>
> >>Libs: -L/usr/local//usr/local/lib
> >>
> >> which is broken. Comments appreciated.
> >
> > i had a look, and its indeed a bit strange - your fix makes sense but
> > why not consistently using LIB_DESTINATION in the patches ?
>
> I'm not entirely sure I've understand correctly what you mean, but I've
> changed that. I've killed the libdir variable and set
>
> Libs: -L@LIBDESTINATION@ -l${lib}
another way that implies less patching, as you already patch
CMakeLists.txt for cotire:
@@ -85,7 +80,7 @@ include(TestCXXAcceptsFlag)
include(GNUInstallDirs)
set(LIB_DESTINATION
- "${CMAKE_INSTALL_FULL_LIBDIR}" CACHE STRING "Define lib output directory
name"
+ "lib" CACHE STRING "Define lib output directory name"
)
if(ENABLE_CYCLIC_CHECK)
with that chunk added to patch-CMakeLists.txt, no need to patch the .cmake
files to fiddle with prefix/LIB_DESTINATION, and the resulting .pc look
correct.
> I've added a comment in the patches, do you think it's clear enough?
> I'm not too sure about the wording:
>
> disable cotire as it's deprecated and breaks the build with
> newer libc++
that's great, thanks for the details - your comment is fine.
> I totally missed that part of the readme and stopped at 'No test were
> found!!!'. The new tarball enables tests and add devel/gtests as
> BUILD_DEPENDS, since that binary is generated during the build.
>
> It seems that now it picks up gtest:
>
> $ ldd lucene++-tester | grep libgtest
> 03b213cf7000 03b213d53000 rlib 01 0
> /usr/local/lib/libgtest.so.1.0
good!
> unfortunately, after a while it core dumps:
>
> ...
> [--] 102 tests from IndexWriterTest
> [ RUN ] IndexWriterTest.testDocCount
> [ OK ] IndexWriterTest.testDocCount (7 ms)
> [ RUN ] IndexWriterTest.testAddIndexOnDiskFull
> Segmentation fault (core dumped)
Tests are still running here, dunno if they will fail, but it's always good to
have them at least available/running.
besides the patching bit that could be simplified as i proposed, the rest of
the port looks good to import to me.
Landry
Re: gobject-introspection: can't resolve dependencies
On 2020/06/26 16:13, deserter...@danwin1210.me wrote: > This happened out of blue, don't know how deal with this. > This is repeatable, everytime. I came across it while > installing ImageMagick. > > ===> gobject-introspection-1.64.1 depends on: py3-mako-* - not found > ===> Verifying install for py3-mako-* in www/py-mako > `/usr/portsdir/bulk/amd64/py3-mako-1.1.1' is up to date. > ===> Installing py3-mako-1.1.1 from /usr/portsdir/packages/amd64/all/ > Can't find gmp-6.2.0 > Can't install py3-cryptodome-3.9.7: can't resolve gmp-6.2.0 > Can't install py3-beaker-1.10.0p0: can't resolve py3-cryptodome-3.9.7 > Can't install py3-mako-1.1.1: can't resolve py3-beaker-1.10.0p0 > Couldn't install gmp-6.2.0 py3-beaker-1.10.0p0 py3-cryptodome-3.9.7 > py3-mako-1.1.1 > *** Error 1 in /usr/ports/www/py-mako > (/usr/ports/infrastructure/mk/bsd.port.mk:2138 > '/var/db/pkg/py3-mako-1.1.1/+CONTENTS': @/usr/bin/env -...) > *** Error 2 in /usr/ports/www/py-mako > (/usr/ports/infrastructure/mk/bsd.port.mk:2581 'install': > @lock=py3-mako-1.1.1; export _LOCKS_HELD=" ...) > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2263 > '/usr/portsdir/pobj/gobject-introspection-1.64.1/.dep-www-py-mako,python3') > *** Error 2 in /usr/ports/devel/gobject-introspection > (/usr/ports/infrastructure/mk/bsd.port.mk:2581 'prepare': > @lock=gobject-introspection-...) You have some mixture of /usr/ports and /usr/portsdir which might be confusing things. I sugggest just using /usr/ports (as a real directory not a symlink). > This is my mk.conf, I don't know what more info I need to provide > > SUDO=sudo SUDO=sudo -E and make sure the user has "setenv" permission in sudoers. > PORTS_PRIVSEP=Yes > DISTDIR=/usr/distfiles > BULK_COOKIES_DIR=/usr/portsdir/bulk/amd64 > UPDATE_COOKIES_DIR=/usr/portsdir/update/amd64 > WRKOBJDIR=/usr/portsdir/pobj > PACKAGE_REPOSITORY=/usr/portsdir/packages > PLIST_REPOSITORY=/usr/portsdir/plist > >
Re: [NEW] cad/qflow
This is OK sthen@ to import. On 2020/06/26 16:35, Alessandro De Laurenzis wrote: > Weekly ping. > > Tarball re-attached for your convenience. > > While there, I changed the master site from Github to > opencircuitdesign.com (so we can avoid the on-the-fly generated > archive). > > If you would like to play a bit with the port: > - make a new directory (e.g. ./qflow-trial) and copy there the enclosed > map9v3.v file; > - change to that dir and run 'qflow gui'; > - in the 'synthesys preparation' tab: > * select map9v3.v as Verilog source file; > * the 'Verilog module' field will be updated automatically; > * click on 'Set stop' after every synthesis step; > - click on 'Run' in the 'Preparation' row; > - then run the other steps in sequence; > - starting after the 'Placement', you'll be able to see the layout > clicking on 'Edit Layout' (type 'v' in Magic window to see the full > view).
Re: move py-flask-principal to python3
On 2020/06/26 11:48, Aisha Tammy wrote:
> On 6/26/20 11:30 AM, Antoine Jacoutot wrote:
> > On Fri, Jun 26, 2020 at 10:04:22AM -0400, Aisha Tammy wrote:
> >> On 6/26/20 9:58 AM, Antoine Jacoutot wrote:
> >>> On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
> I've updated the port py-flask-principal to use
> only python3.
> There are no reverse dependencies so this should
> not be breaking anything.
> >>>
> >>> You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
> >>>
> >>
> >> I thought as python2 is EOL and there are no reverse dependencies
> >> it might be better to drop python 2 support, for any eventual cleanup?
> >
> > You enforce the python3 FLAVOR like this:
> >
> > FLAVORS=python3
> > FLAVOR= python3
> >
>
> Ah, thanks for that.
> I only recently learnt that the MODPY_DEFAULT_VERSION_3 is not the
> recommended method.
For standalone packages (e.g. a program which happens to use Python),
use MODPY_DEFAULT_VERSION_3.
For Python modules, use FLAVOR/FLAVORS, then if any ports depend on them
they can use e.g. "www/py-flask-principal${MODPY_FLAVOR}" rather than
a mess of "www/py-foo" and "www/py-bar${MODPY_FLAVOR}"..
There are still some Python modules in the tree using the
MODPY_DEFAULT_VERSION_3 method because we haven't swept the tree to
remove them yet.
> Have attached new diff as seems like my thunderbird likes to mess up.
>
> Aisha
>
> diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
> index d062e04f581..b3d80ecffd8 100644
> --- www/py-flask-principal/Makefile
> +++ www/py-flask-principal/Makefile
> @@ -3,7 +3,7 @@
> COMMENT =identity management for flask
>
> MODPY_EGG_VERSION = 0.4.0
> -REVISION = 1
> +REVISION = 2
> DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME:L}
>
> @@ -16,11 +16,14 @@ MAINTAINER = Aaron Bieber
>
> # MIT
> PERMIT_PACKAGE = Yes
>
> +FLAVORS =python3
> +FLAVOR = python3
> +
> MODPY_PI = Yes
>
> MODULES =lang/python
>
> -RUN_DEPENDS += www/py-flask
> +RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
>
> MODPY_SETUPTOOLS = Yes
>
> diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
> index a7db0b09fcb..4193651f7f9 100644
> --- www/py-flask-principal/pkg/PLIST
> +++ www/py-flask-principal/pkg/PLIST
> @@ -6,5 +6,5 @@
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
> lib/python${MODPY_VERSION}/site-packages/flask_principal.py
> -lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
move py-flask-principal to python3
I've updated the port py-flask-principal to use
only python3.
There are no reverse dependencies so this should
not be breaking anything.
Aisha
diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
index d062e04f581..4b9f6186750 100644
--- www/py-flask-principal/Makefile
+++ www/py-flask-principal/Makefile
@@ -3,7 +3,7 @@
COMMENT = identity management for flask
MODPY_EGG_VERSION =0.4.0
-REVISION = 1
+REVISION = 2
DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:L}
@@ -16,11 +16,13 @@ MAINTAINER =Aaron Bieber
# MIT
PERMIT_PACKAGE = Yes
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+
MODPY_PI = Yes
MODULES = lang/python
-RUN_DEPENDS += www/py-flask
+RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
MODPY_SETUPTOOLS = Yes
diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
index a7db0b09fcb..4193651f7f9 100644
--- www/py-flask-principal/pkg/PLIST
+++ www/py-flask-principal/pkg/PLIST
@@ -6,5 +6,5 @@
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask_principal.py
-lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
update flask to 1.1.2
I've update flask to 1.1.2 latest
Haven't done a lot of testing but it seems to be working
fine with another small script I am using.
Would be nice to see it updated.
Also, there was no maintainer. I haven't added myself
because I didn't know if some dev was interested in
maintaining it but I am willing to take it if needed.
Aisha
diff --git www/py-flask/Makefile www/py-flask/Makefile
index 8af8b54fb3d..d393da6d921 100644
--- www/py-flask/Makefile
+++ www/py-flask/Makefile
@@ -2,10 +2,9 @@
COMMENT = microframework based on Werkzeug and Jinja 2
-MODPY_EGG_VERSION =0.12.3
+MODPY_EGG_VERSION =1.1.2
DISTNAME = Flask-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:L}
-REVISION = 1
CATEGORIES = www devel
diff --git www/py-flask/distinfo www/py-flask/distinfo
index 6b0b78b256c..313c05920d5 100644
--- www/py-flask/distinfo
+++ www/py-flask/distinfo
@@ -1,2 +1,2 @@
-SHA256 (Flask-0.12.3.tar.gz) = D0MQdqUJCPBITc3dDy/QJBEp75yhh2eZs+vhTYI/YN4=
-SIZE (Flask-0.12.3.tar.gz) = 531380
+SHA256 (Flask-1.1.2.tar.gz) = Tvoa4tfJhlr0iYbeiuuFBL8yx/PW/ck1PTSyH0sScGA=
+SIZE (Flask-1.1.2.tar.gz) = 637516
diff --git www/py-flask/pkg/PLIST www/py-flask/pkg/PLIST
index 53026e69325..ff3d142e657 100644
--- www/py-flask/pkg/PLIST
+++ www/py-flask/pkg/PLIST
@@ -5,107 +5,113 @@
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VE
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/entry_points.txt
-lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/Flask-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/flask/
lib/python${MODPY_VERSION}/site-packages/flask/__init__.py
+lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/__main__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}/
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}app.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}blueprints.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}cli.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}config.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}ctx.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}debughelpers.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}exthook.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}globals.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}helpers.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}json.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}logging.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}sessions.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}signals.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}templating.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}testing.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}views.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}wrappers.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/_compat.py
+lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/app.py
+lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}app.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/blueprints.py
+lib/python${MODPY_VERSION}/site-packages/flask/${MODPY_PYCACHE}blueprints.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flask/
Re: move py-flask-principal to python3
On Fri, Jun 26, 2020 at 10:04:22AM -0400, Aisha Tammy wrote:
> On 6/26/20 9:58 AM, Antoine Jacoutot wrote:
> > On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
> >> I've updated the port py-flask-principal to use
> >> only python3.
> >> There are no reverse dependencies so this should
> >> not be breaking anything.
> >
> > You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
> >
>
> I thought as python2 is EOL and there are no reverse dependencies
> it might be better to drop python 2 support, for any eventual cleanup?
You enforce the python3 FLAVOR like this:
FLAVORS=python3
FLAVOR= python3
> Or is the ports tree going to keep python2 for a while ?
>
> Aisha
>
> >
> >>
> >> Aisha
> >>
> >> diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
> >>
> >> index d062e04f581..4b9f6186750 100644
> >>
> >> --- www/py-flask-principal/Makefile
> >>
> >> +++ www/py-flask-principal/Makefile
> >>
> >> @@ -3,7 +3,7 @@
> >>
> >> COMMENT = identity management for flask
> >>
> >>
> >>
> >> MODPY_EGG_VERSION = 0.4.0
> >>
> >> -REVISION =1
> >>
> >> +REVISION =2
> >>
> >> DISTNAME =Flask-Principal-${MODPY_EGG_VERSION}
> >>
> >> PKGNAME = py-${DISTNAME:L}
> >>
> >>
> >>
> >> @@ -16,11 +16,13 @@ MAINTAINER = Aaron Bieber
> >>
> >>
> >> # MIT
> >>
> >> PERMIT_PACKAGE = Yes
> >>
> >>
> >>
> >> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> >>
> >> +
> >>
> >> MODPY_PI =Yes
> >>
> >>
> >>
> >> MODULES = lang/python
> >>
> >>
> >>
> >> -RUN_DEPENDS +=www/py-flask
> >>
> >> +RUN_DEPENDS +=www/py-flask${MODPY_FLAVOR}
> >>
> >>
> >>
> >> MODPY_SETUPTOOLS =Yes
> >>
> >>
> >>
> >> diff --git www/py-flask-principal/pkg/PLIST
> >> www/py-flask-principal/pkg/PLIST
> >>
> >> index a7db0b09fcb..4193651f7f9 100644
> >>
> >> --- www/py-flask-principal/pkg/PLIST
> >>
> >> +++ www/py-flask-principal/pkg/PLIST
> >>
> >> @@ -6,5 +6,5 @@
> >> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
> >>
> >>
> >> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
> >>
> >>
> >> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
> >>
> >>
> >> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> >>
> >> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
> >>
> >> lib/python${MODPY_VERSION}/site-packages/flask_principal.py
> >>
> >> -lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
> >>
> >
>
--
Antoine
Re: NEW: devel/bamf
On 2020/06/26 14:11, Brian Callahan wrote: > > On Friday, June 26, 2020 8:29 AM, Stuart Henderson > wrote: > > > On 2020/06/26 11:00, Charlene Wendling wrote: > > > > > port-lib-depends-check complains about this on my macppc and amd64 > > > machines: > > > bamf-0.5.4(devel/bamf): > > > Missing: png.18 from png-1.6.37 (/usr/local/libexec/bamf/bamfdaemon) > > > Extra: XRes.5 gthread-2.0.4200 png16.18 > > > WANTLIB += png > > > It's weird because i thought we fixed such png WANTLIB issues a while > > > ago. It's still packaging though, so once the situation is cleared > > > up it's fine with me. > > > > We did, about a year ago. Guessing the wantlib for this port was > > generated some time ago? > > It was. I have a huge backlog of ports and this is one of the downsides. > > Anyhow, here's a port with a fresh WANTLIB. > > ~Brian Please review them yourself before sending them out - it saves everyone time if a port is already in good shape and can just be OK'd :)
Re: [NEW] cad/qflow
Just a note: On 26/06/2020 16:35, Alessandro De Laurenzis wrote: [...] If you would like to play a bit with the port: - make a new directory (e.g. ./qflow-trial) and copy there the enclosed map9v3.v file; - change to that dir and run 'qflow gui'; - in the 'synthesys preparation' tab: * select map9v3.v as Verilog source file; * the 'Verilog module' field will be updated automatically; * click on 'Set stop' after every synthesis step; If you want to avoid issues with default settings during routing step, please select 'osu035' in the 'Technology' tab. - click on 'Run' in the 'Preparation' row; - then run the other steps in sequence; - starting after the 'Placement', you'll be able to see the layout clicking on 'Edit Layout' (type 'v' in Magic window to see the full view). On 21/06/2020 16:40, Tim Edwards wrote: Hello Alessandro, OSU 050/035/018 tech files have a proprietary license that says: [...] "Permission to use, copy, and modify this software and its documentation for research and educational purposes only and without fee or royalty is hereby granted..." [...] I don't know if this is too restrictive; if so, we should probably split the package; please let me know how to proceed; This should not be a problem. The technologies are based on the MOSIS SCMOS technologies (see www.mosis.com). Specifically, the process technology file for Magic is designed to be submitted to MOSIS for use with the TSMC foundry. However, as of about two years ago, MOSIS stopped supporting the SCMOS technology description for TSMC. Therefore, designs using these cells are, for all intents and purposes, purely educational, as there is no way to fabricate such a design. Regards, Tim ++-+ | R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com| | Open Circuit Design| web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | ++-+ -- Alessandro De Laurenzis [mailto:jus...@atlantide.mooo.com] Web: http://www.atlantide.mooo.com LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: [NEW] cad/qflow
Weekly ping.
Tarball re-attached for your convenience.
While there, I changed the master site from Github to
opencircuitdesign.com (so we can avoid the on-the-fly generated
archive).
If you would like to play a bit with the port:
- make a new directory (e.g. ./qflow-trial) and copy there the enclosed
map9v3.v file;
- change to that dir and run 'qflow gui';
- in the 'synthesys preparation' tab:
* select map9v3.v as Verilog source file;
* the 'Verilog module' field will be updated automatically;
* click on 'Set stop' after every synthesis step;
- click on 'Run' in the 'Preparation' row;
- then run the other steps in sequence;
- starting after the 'Placement', you'll be able to see the layout
clicking on 'Edit Layout' (type 'v' in Magic window to see the full
view).
On 21/06/2020 16:40, Tim Edwards wrote:
Hello Alessandro,
OSU 050/035/018 tech files have a proprietary license that says:
[...]
"Permission to use, copy, and modify this software and its
documentation for research and educational purposes only and without fee
or royalty is hereby granted..."
[...]
I don't know if this is too restrictive; if so, we should probably
split the package; please let me know how to proceed;
This should not be a problem. The technologies are based on the MOSIS
SCMOS technologies (see www.mosis.com). Specifically, the process
technology file for Magic is designed to be submitted to MOSIS for use
with the TSMC foundry. However, as of about two years ago, MOSIS stopped
supporting the SCMOS technology description for TSMC. Therefore, designs
using these cells are, for all intents and purposes, purely educational,
as there is no way to fabricate such a design.
Regards,
Tim
++-+
| R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com|
| Open Circuit Design| web: http://opencircuitdesign.com |
| 19601 Jerusalem Road | phone: (240) 489-3255 |
| Poolesville, MD 20837 | cell: (408) 828-8212 |
++-+
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis
qflow-1.4.83.tar.gz
Description: application/gzip
/*
*--
* This module converts a counter value N into a reset value
* for an 8-bit LFSR. The count is initialized by "reset" high
* or "start" transition high. When the count is valid, it is
* latched into "dp" and the signal "done" is raised to indicate
* a valid new value of "dp".
*--
*/
module map9v3(clock, reset, start, N, dp, done, counter, sr);
input clock;
input start; // run at rising edge of start
input reset; // high is reset case ( run after reset)
input [8:0] N; // the number to divide by
output [8:0] dp; // these outputs drive an LFSR counter
output done;
output [7:0] counter;
output [7:0] sr;
reg [8:0] dp;
reg [7:0] sr;
reg [7:0] counter;
reg [1:0] startbuf;
reg done;
reg [2:0] state;
parameter INIT = 3'b000;
parameter RUN = 3'b001;
parameter ALMOSTDONE = 3'b010;
parameter DONE = 3'b011;
parameter WAIT = 3'b100;
always @(posedge clock or posedge reset) begin
if (reset == 1) begin
dp <= 9'b0;
sr <= 8'b0;
counter <= 8'b0;
startbuf <= 2'b00;
done <= 0;
state <= INIT;
end else begin
if (state == INIT) begin
counter <= 255 - N[8:1] + 3;
sr <= 8'b0;
done <= 0;
state <= RUN;
end else if (state == RUN) begin
sr[7] <= sr[6];
sr[6] <= sr[5];
sr[5] <= sr[4];
sr[4] <= sr[3];
sr[3] <= sr[2];
sr[2] <= sr[1];
sr[1] <= sr[0];
sr[0] <= ~(sr[7] ^ sr[5] ^ sr[4] ^ sr[3]);
counter <= counter - 1;
if (counter == 0) begin
state <= ALMOSTDONE;
end
end else if (state == ALMOSTDONE) begin
dp[0] <= N[0];
dp[8:1] <= sr[7:0];
state <= DONE;
end else if (state == DONE) begin
done <= 1;
state <= WAIT;
end else if (state == WAIT) begin
if (startbuf == 2'b01) begin
state <= INIT;
end
end
startbuf <= {startbuf[0], start};
end
end
endmodule
Re: x11/sisctrl removable
On Fri, Jun 26 2020, Solene Rapenne wrote: > I propose to remove x11/sisctrl because sis driver was deleted a > few months ago from xenocara. > > No port depend on it. Sure. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: move py-flask-principal to python3
On Fri, Jun 26, 2020 at 08:08:24AM -0400, Aisha Tammy wrote:
> I've updated the port py-flask-principal to use
> only python3.
> There are no reverse dependencies so this should
> not be breaking anything.
You need to use the FLAVOR/FLAVORS combo, not MODPY_DEFAULT_VERSION_3.
>
> Aisha
>
> diff --git www/py-flask-principal/Makefile www/py-flask-principal/Makefile
>
> index d062e04f581..4b9f6186750 100644
>
> --- www/py-flask-principal/Makefile
>
> +++ www/py-flask-principal/Makefile
>
> @@ -3,7 +3,7 @@
>
> COMMENT =identity management for flask
>
>
>
> MODPY_EGG_VERSION = 0.4.0
>
> -REVISION = 1
>
> +REVISION = 2
>
> DISTNAME = Flask-Principal-${MODPY_EGG_VERSION}
>
> PKGNAME =py-${DISTNAME:L}
>
>
>
> @@ -16,11 +16,13 @@ MAINTAINER = Aaron Bieber
>
>
> # MIT
>
> PERMIT_PACKAGE = Yes
>
>
>
> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
>
> +
>
> MODPY_PI = Yes
>
>
>
> MODULES =lang/python
>
>
>
> -RUN_DEPENDS += www/py-flask
>
> +RUN_DEPENDS += www/py-flask${MODPY_FLAVOR}
>
>
>
> MODPY_SETUPTOOLS = Yes
>
>
>
> diff --git www/py-flask-principal/pkg/PLIST www/py-flask-principal/pkg/PLIST
>
> index a7db0b09fcb..4193651f7f9 100644
>
> --- www/py-flask-principal/pkg/PLIST
>
> +++ www/py-flask-principal/pkg/PLIST
>
> @@ -6,5 +6,5 @@
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py
>
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
>
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>
>
> lib/python${MODPY_VERSION}/site-packages/Flask_Principal-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
>
> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}flask_principal.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/flask_principal.py
>
> -lib/python${MODPY_VERSION}/site-packages/flask_principal.pyc
>
--
Antoine
[new] devel/olm 3.1.5
Hi, Here is a port of OLM ( https://gitlab.matrix.org/matrix-org/olm ), the Double Ratchet lib used by Matrix. This is needed by various Matrix clients to support end to end encryption. An upcoming update to net/mautrix-whatsapp will need this. It can also be used by various clients we don't have yet. DESCR: An implementation of the Double Ratchet cryptographic ratchet described by https://whispersystems.org/docs/specifications/doubleratchet/, written in C and C++11 and exposed as a C API. Cluestick? OK? Cheers, Aaron -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE olm.tgz Description: Binary data
x11/sisctrl removable
I propose to remove x11/sisctrl because sis driver was deleted a few months ago from xenocara. No port depend on it.
Re: NEW: devel/bamf
On 2020/06/26 11:00, Charlene Wendling wrote: > port-lib-depends-check complains about this on my macppc and amd64 > machines: > > bamf-0.5.4(devel/bamf): > Missing: png.18 from png-1.6.37 (/usr/local/libexec/bamf/bamfdaemon) > Extra: XRes.5 gthread-2.0.4200 png16.18 > WANTLIB += png > > It's weird because i thought we fixed such png WANTLIB issues a while > ago. It's still packaging though, so once the situation is cleared > up it's fine with me. We did, about a year ago. Guessing the wantlib for this port was generated some time ago?
Re: www/vteplugin removal
On Fri, Jun 26, 2020 at 01:50:01PM +0200, Solene Rapenne wrote: > I propose the removal of www/vteplugin > > I tried it on amd64 in the following browsers without success: > > - Firefox (unveil disabled) > - chromium (unveil disabled) > - vimb > - midori > - epiphany > - surf > > vimb, midor and epihpany complained a "Plugin missing" while a > ktrace -di did show that the file vteplugin.so was correctly found. > The others web browser didn't show anything. can you do the same test with www/mozplugger and the npapi plugin in the djview4 pkg ? if all those fails too, ok to drop the 3 of them. Landry
www/vteplugin removal
I propose the removal of www/vteplugin I tried it on amd64 in the following browsers without success: - Firefox (unveil disabled) - chromium (unveil disabled) - vimb - midori - epiphany - surf vimb, midor and epihpany complained a "Plugin missing" while a ktrace -di did show that the file vteplugin.so was correctly found. The others web browser didn't show anything.
editors/emacs fix to use posix_openpt
Hi,
Currently emacs is using an old way to create a process with a pty.
OpenBSD has posix_openpt(3) now, so emacs should use it.
I actually hit a problem that Mew could not start gnupg properly.
# I sent a bug report to the upstream as well.
ok?
Index: Makefile
===
RCS file: /disk/cvs/openbsd/ports/editors/emacs/Makefile,v
retrieving revision 1.93
diff -u -p -r1.93 Makefile
--- Makefile10 Nov 2019 21:50:23 - 1.93
+++ Makefile26 Jun 2020 10:02:29 -
@@ -3,7 +3,7 @@
COMMENT= GNU editor: extensible, customizable, self-documenting
VERSION= 26.3
-REVISION= 1
+REVISION= 2
DISTNAME= emacs-${VERSION}
CATEGORIES=editors
Index: patches/patch-configure
===
RCS file: /disk/cvs/openbsd/ports/editors/emacs/patches/patch-configure,v
retrieving revision 1.17
diff -u -p -r1.17 patch-configure
--- patches/patch-configure 25 Sep 2019 22:10:51 - 1.17
+++ patches/patch-configure 26 Jun 2020 10:02:29 -
@@ -13,3 +13,18 @@ Index: configure
;;
esac
+@@ -18602,12 +18600,12 @@ case $opsys in
+
+ ;;
+
+- gnu | openbsd | qnxnto )
++ gnu | qnxnto )
+ $as_echo "#define FIRST_PTY_LETTER 'p'" >>confdefs.h
+
+ ;;
+
+- gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd | darwin | nacl )
++ openbsd | gnu-linux | gnu-kfreebsd | dragonfly | freebsd | netbsd | darwin
| nacl )
+ if test "x$ac_cv_func_grantpt" = xyes; then
+
+ $as_echo "#define UNIX98_PTYS 1" >>confdefs.h
Re: x11/sisctrl removable
On Fri, 26 Jun 2020 11:13:50 +0200 Solene Rapenne wrote: > I propose to remove x11/sisctrl because sis driver was deleted a > few months ago from xenocara. > > No port depend on it. > OK cwen@
Re: NEW: x11/elementary/dock
On Fri, 26 Jun 2020 01:54:42 + Brian Callahan wrote: > Hi ports -- > > Attached is a new port, x11/elementary/dock. This is the elementary OS > dock app. The binary is named plank. > > --- > pkg/DESCR: > Plank is meant to be the simplest dock on the planet. The goal is to > provide just what a dock needs and absolutely nothing more. It is, > however, a library which can be extended to create other dock programs > with more advanced features. > --- > > Needs the bamf port sent earlier. Works well on amd64. Note that the > CPU and battery docklets do not appear to work, but I believe I can > get those working at some point. > > OK? > > ~Brian It builds and works fine on amd64 and macppc. It adds mupdf, but unlike mpv it has no "drag file there to open it" dialog. Well, we still miss some parts of the elementary puzzle anyway, so go ahead :) OK cwen@
Re: [NEW] textproc/lucene++
Landry Breuil writes:
> On Thu, Jun 25, 2020 at 06:08:56PM +0200, Omar Polo wrote:
>>
>> Hello there!
>>
>> Attached the port for Lucene++, a port of the java lucene library. It's
>> required by newer version of devel/poedit.
>>
>> The patches against the three CMakefiles are to disable cotire, as it
>> breaks the build. The patch against VariantUtils.h is to support newer
>> version of boost. These patches are heavily inspired (read: copied)
>> from the freebsd port.
>>
>> I'm not sure about the two patches against the .pc files, because by
>> default it generates something like
>>
>> Libs: -L/usr/local//usr/local/lib
>>
>> which is broken. Comments appreciated.
>
> i had a look, and its indeed a bit strange - your fix makes sense but
> why not consistently using LIB_DESTINATION in the patches ?
I'm not entirely sure I've understand correctly what you mean, but I've
changed that. I've killed the libdir variable and set
Libs: -L@LIBDESTINATION@ -l${lib}
> what's breaking with cotire ? care to add comments in the patches
> explaining the failures ?
yeah, I should have done so. There seems to be some incompatibility
between cotire and the c++ stdlib. This commit[0] from the freebsd port
tree says that's from libc++ 3.8.0 onwards.
This is an excerpt from the first failure:
FAILED: src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx.pch
cd
/usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/src/contrib &&
/usr/local/bin/cmake -DCOTIRE_BUILD_TYPE:STRING=Release -P
/usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/cmake/cotire.cmake
precompile
/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/lucene++-contrib_CXX_cotire.cmake
/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx
/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx.pch
/usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp
In file included from
/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx:4:
In file included from
/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.cxx:6:
/usr/include/c++/v1/wchar.h:137:77: error: use of undeclared identifier
'wcschr'
wchar_t* __libcpp_wcschr(const wchar_t* __s, wchar_t __c) {return
(wchar_t*)wcschr(__s, __c);}
^
/usr/include/c++/v1/wchar.h:144:87: error: use of undeclared identifier
'wcspbrk'
wchar_t* __libcpp_wcspbrk(const wchar_t* __s1, const wchar_t* __s2)
{return (wchar_t*)wcspbrk(__s1, __s2);}
^
/usr/include/c++/v1/wchar.h:151:78: error: use of undeclared identifier
'wcsrchr'; did you mean 'wcschr'?
wchar_t* __libcpp_wcsrchr(const wchar_t* __s, wchar_t __c) {return
(wchar_t*)wcsrchr(__s, __c);}
^
[...]
and thats is followed by similar errors with various wchar functions
(wcsstr, wmemmove, wmemcpy, ...)
This, plus the fact that cotire itself is deprecated was the reason I
didn't even try to fix it. from cotire readme[1]:
The functionality provided by cotire has been superseded by
features added to CMake 3.16. Support for pre-compiling and
unity builds is now built into CMake. Thus, there will not be
any further updates or support for this project.
I've added a comment in the patches, do you think it's clear enough?
I'm not too sure about the wording:
disable cotire as it's deprecated and breaks the build with
newer libc++
[0]: https://svnweb.freebsd.org/ports?view=revision&revision=414441
[1]: https://github.com/sakra/cotire
>> It builds on amd64, passes make port-lib-depends-check and portcheck.
>>
>> NO_TEST is Yes because the port doesn't contain tests, is it right?
>
> There are tests in src/test, using a bundled copy of gtest (that should
> be patched to use the gtest from the ports, which should be added as a
> build/test dependency i think).
>
> granted, if i uncomment NO_TEST, it defaults to use ctest from cmake
> which doesnt find any tests.
> /usr/ports/mystuff/textproc/luceneplusplus/ $make test
> ===> Regression tests for luceneplusplus-3.0.7
> [0/1] cd /usr/obj/ports/luceneplusplus-3.0.7/build-amd64 &&
> /usr/local/bin/ctest --force-new-ctest-process --exclude-regex
> "CMake.FileDownload|CTestTestUpload|RunCMake.ctest_submit"
> Test project /usr/obj/ports/luceneplusplus-3.0.7/build-amd64
> No tests were found!!!
>
> But README.rst points at lucene++-tester in the build dir, which indeed
> runs some unit testing:
I totally missed that part of the readme and s
Re: NEW: devel/bamf
Hi, On Fri, 26 Jun 2020 00:18:01 + Brian Callahan wrote: > Hi ports -- > > Attached is a new port, devel/bamf. Bamf is an application matching > library. > > --- > pkg/DESCR: > Bamf matches application windows to desktop files. It removes the > headache of applications matching into a simple DBus daemon and C > wrapper library. It currently features application matching at amazing > levels of accuracy (covering nearly every corner case). > --- > > This is needed for the elementary OS dock application. Builds ok on > amd64 and sparc64. The elementary OS dock app works fine on amd64 so > I assume this runs fine too. > > OK? > > ~Brian port-lib-depends-check complains about this on my macppc and amd64 machines: bamf-0.5.4(devel/bamf): Missing: png.18 from png-1.6.37 (/usr/local/libexec/bamf/bamfdaemon) Extra: XRes.5 gthread-2.0.4200 png16.18 WANTLIB += png It's weird because i thought we fixed such png WANTLIB issues a while ago. It's still packaging though, so once the situation is cleared up it's fine with me.
