Re: UPDATE: net/snort 2.9.14
Fixes it for me! Need to also regen WANTLIB, then OK abiener@ PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE > On Jul 22, 2019, at 9:13 PM, Lawrence Teo wrote: > > On Sun, Jul 21, 2019 at 11:38:06PM -0600, Aaron Bieber wrote: >>> On Fri, 19 Jul 2019 at 22:01:53 -0400, Lawrence Teo wrote: >>> This updates Snort to 2.9.14. >>> >>> https://blog.snort.org/2019/07/snort-29140-has-been-released.html >>> >>> ok? >> >> Builds and runs fine here! When I start it with "-d" I see: >> >> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_GetCFA' >> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol >> '_Unwind_DeleteException' >> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_SetGR' >> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_SetIP' >> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol >> '_Unwind_RaiseException' >> >> I think this might be a combo of the packages / snapshot I have. I will >> update >> and report back. >> >> If you aren't seeing the undefined symbols, OK abieber@ > > Thanks for testing! > > It looks like those Unwind errors are due to libsf_appid_preproc.so > which links against luajit, which in turn needs access to libunwind > symbols. > > I found another port games/tome4 that had the same issue. In that port > the issue was resolved by linking against libc++abi (in > games/tome4/patches/lld-linking). > > Here's an updated diff that does the same thing for > libsf_appid_preproc.so. I made it link against libc++abi in > src/dynamic-preprocessors/appid/Makefile.in. I'm not certain that that > is the right place to fix it, but it does resolve those errors for me. >
Re: lang/gcc fails on -current
On 22/07/2019 14:06, Stuart Henderson wrote: > On 2019/07/22 13:36, Nigel Taylor wrote: >> On 22/07/2019 12:21, Stuart Henderson wrote: >>> On 2019/07/22 08:36, Pavel Korovin wrote: On 07/20, Nigel Taylor wrote: > I can get past the sinfo.h error, treeprs.ads and osnames errors, but > there are more afterwards. Too many errors to fix by hand. > > The problem I think lies in opening files for writing when they don't > exist, it fails to create an empty file. So I manually touch sinfo.h to > create the empty file. Same for other missing files. > > Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada > > > Not sure where the error is could be with the ada bootstrap file, needs > regenerating. The same problem here, please find the diff for gcc8 attached. >>> >>> Yet the Makefiles are presumably OK on other systems, and are OK on i386. >>> >>> Has anyone figured out what triggered this to start failing and what is >>> actually going on? >>> >>> Wondering if there's an LP64 related problem. The only other 64-bit arch >>> building ada support in ports/lang/gcc/8 is mips64. Anyone know if that >>> still works? >>> >>> The most obvious candidate to my eyes would be realpath, if there's some >>> problem with this it could impact many many ports. So I think we should >>> figure out what's really going on before committing workarounds to gcc >>> which take the whole thing off the radar. >>> >>> >> >> This is a ktrace/kdump side by side of grep CALL's one with and one >> without sinfo.h present. >> >> 70692 xsinfo CALL write(1,0x444b5f5cc1f,0x1) >>│ >> 76912 xsinfo CALL write(1,0x97722da4c1f,0x1) >> 70692 xsinfo CALL write(1,0x7f7d8580,0x35) >>│ >> 76912 xsinfo CALL write(1,0x7f7a5ce0,0x35) >> 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) >>│ >> 76912 xsinfo CALL __realpath(0x7f7bbd90,0x7f7bb550) >> 70692 xsinfo CALL >> open(0x7f7ee630,0x601,0666) >> │ 76912 xsinfo CALL kbind(0x7f7bb8a0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL fstat(4,0x7f7ee150) >>│ >> 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) >>│ >> 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) >> 70692 xsinfo CALL open(0x7f7ee630,0) >>│ >> 76912 xsinfo CALL >> mmap(0,0x4000,0x3,0x1002,-1,0) >> 70692 xsinfo CALL fstat(5,0x7f7ee150) >>│ >> 76912 xsinfo CALL >> mmap(0,0x4000,0x3,0x1002,-1,0) >> >> Only when the file exists after the __realpath call is open called, >> suggesting __realpath is returning an error for the missing file, >> causing the open to be skipped. Could be realpath returning wrong error >> in this case or runtime looking for the wrong error or not expecting an >> error. >> >> As a quick check I reverted back to a kernel I built 15 July, with that >> kernel xsinfo works when sinfo.h is missing. >> >> >> Which looks, this change might be the cause of problems. but only >> guessing. But doesn't seem to tie up with your later email. >> >> cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c >> Index: vfs_syscalls.c >> === >> RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v >> retrieving revision 1.321 >> retrieving revision 1.323 >> diff -u -p -r1.321 -r1.323 >> --- vfs_syscalls.c 12 Jul 2019 13:56:27 - 1.321 >> +++ vfs_syscalls.c 15 Jul 2019 15:05:21 - 1.323 >> @@ -1,4 +1,4 @@ >> -/* $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp >> $ */ >> +/* $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */ >> /* $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $ >>*/ >> >> /* >> @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v, >> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH, >> UIO_SYSSPACE, pathname, p); >> else >> - NDINIT(, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT | >> SAVENAME | >> + NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT | >> SAVENAME | >> REALPATH, UIO_SYSSPACE, pathname, p); >> >> nd.ni_cnd.cn_rpbuf = rpbuf; >> >> >> I'll look at building kernel with this reverted. Not saying the change >> isn't right, but may have exposed error checking which is wrong. >> > > Hmm. Well based on the ktrace it's likely that this will
Re: UPDATE: net/snort 2.9.14
On Sun, Jul 21, 2019 at 11:38:06PM -0600, Aaron Bieber wrote:
> On Fri, 19 Jul 2019 at 22:01:53 -0400, Lawrence Teo wrote:
> > This updates Snort to 2.9.14.
> >
> > https://blog.snort.org/2019/07/snort-29140-has-been-released.html
> >
> > ok?
>
> Builds and runs fine here! When I start it with "-d" I see:
>
> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_GetCFA'
> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol
> '_Unwind_DeleteException'
> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_SetGR'
> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol '_Unwind_SetIP'
> snort:/usr/local/lib/libluajit-5.1.so.1.0: undefined symbol
> '_Unwind_RaiseException'
>
> I think this might be a combo of the packages / snapshot I have. I will update
> and report back.
>
> If you aren't seeing the undefined symbols, OK abieber@
Thanks for testing!
It looks like those Unwind errors are due to libsf_appid_preproc.so
which links against luajit, which in turn needs access to libunwind
symbols.
I found another port games/tome4 that had the same issue. In that port
the issue was resolved by linking against libc++abi (in
games/tome4/patches/lld-linking).
Here's an updated diff that does the same thing for
libsf_appid_preproc.so. I made it link against libc++abi in
src/dynamic-preprocessors/appid/Makefile.in. I'm not certain that that
is the right place to fix it, but it does resolve those errors for me.
Index: Makefile
===
RCS file: /cvs/ports/net/snort/Makefile,v
retrieving revision 1.103
diff -u -p -r1.103 Makefile
--- Makefile12 Jul 2019 20:48:49 - 1.103
+++ Makefile19 Jul 2019 20:17:17 -
@@ -2,8 +2,8 @@
COMMENT = highly flexible sniffer/NIDS
-DISTNAME = snort-2.9.13
-RULESV = 29130
+DISTNAME = snort-2.9.14
+RULESV = 29140
SUBST_VARS = RULESV
CATEGORIES = net security
Index: distinfo
===
RCS file: /cvs/ports/net/snort/distinfo,v
retrieving revision 1.39
diff -u -p -r1.39 distinfo
--- distinfo2 Jun 2019 02:07:44 - 1.39
+++ distinfo19 Jul 2019 20:17:52 -
@@ -1,2 +1,2 @@
-SHA256 (snort-2.9.13.tar.gz) = MURzk9FShrhIgQ3XirLLOtIx/NHxZj+VlYdpDu6nVBM=
-SIZE (snort-2.9.13.tar.gz) = 6553425
+SHA256 (snort-2.9.14.tar.gz) = wDBtuc5k9FzHxkya/HCr6WidqoYAIDRew7oJmSi3Rks=
+SIZE (snort-2.9.14.tar.gz) = 6688482
Index: patches/patch-src_dynamic-preprocessors_appid_Makefile_in
===
RCS file:
/cvs/ports/net/snort/patches/patch-src_dynamic-preprocessors_appid_Makefile_in,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_dynamic-preprocessors_appid_Makefile_in
--- patches/patch-src_dynamic-preprocessors_appid_Makefile_in 2 Jun 2019
02:07:44 - 1.2
+++ patches/patch-src_dynamic-preprocessors_appid_Makefile_in 23 Jul 2019
01:51:20 -
@@ -1,14 +1,19 @@
$OpenBSD: patch-src_dynamic-preprocessors_appid_Makefile_in,v 1.2 2019/06/02
02:07:44 lteo Exp $
+
+libsf_appid_preproc.so needs to link against libc++abi so that luajit can
access
+libunwind symbols.
Index: src/dynamic-preprocessors/appid/Makefile.in
--- src/dynamic-preprocessors/appid/Makefile.in.orig
+++ src/dynamic-preprocessors/appid/Makefile.in
-@@ -586,7 +586,7 @@ APPID_SOURCES = $(APPID_SRC_DIR)/commonAppMatcher.c \
+@@ -586,8 +586,8 @@ APPID_SOURCES = $(APPID_SRC_DIR)/commonAppMatcher.c \
$(APPID_SRC_DIR)/util/sfutil.c $(APPID_SRC_DIR)/util/sfutil.h
dynamicpreprocessordir = ${libdir}/snort_dynamicpreprocessor
dynamicpreprocessor_LTLIBRARIES = libsf_appid_preproc.la
-libsf_appid_preproc_la_LDFLAGS = -export-dynamic -module @XCCFLAGS@
+-@SO_WITH_STATIC_LIB_FALSE@libsf_appid_preproc_la_LIBADD = $(LUA_LIBS)
+libsf_appid_preproc_la_LDFLAGS = -export-dynamic -module -avoid-version
@XCCFLAGS@
- @SO_WITH_STATIC_LIB_FALSE@libsf_appid_preproc_la_LIBADD = $(LUA_LIBS)
++@SO_WITH_STATIC_LIB_FALSE@libsf_appid_preproc_la_LIBADD = $(LUA_LIBS) -lc++abi
@SO_WITH_STATIC_LIB_TRUE@libsf_appid_preproc_la_LIBADD =
../libsf_dynamic_preproc.la ../libsf_dynamic_utils.la $(LUA_LIBS)
@SO_WITH_STATIC_LIB_FALSE@nodist_libsf_appid_preproc_la_SOURCES = \
+ @SO_WITH_STATIC_LIB_FALSE@../include/sf_dynamic_preproc_lib.c \
Index: patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c
===
RCS file:
/cvs/ports/net/snort/patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c,v
retrieving revision 1.7
diff -u -p -r1.7 patch-src_preprocessors_Stream6_snort_stream_tcp_c
--- patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c 2 Jun 2019
02:07:44 - 1.7
+++ patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c 19 Jul 2019
20:18:18 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-src_preprocessors_Stream
[Patch] mail/p5-Mail-Milter-Authentication : Fix DEPENDS
Hi,
Here is a patch for mail/p5-Mail-Milter-Authentication to fix RUN_DEPENDS.
After install this port, when run:
perl -e "use Mail::Milter::Authentication;"
It will fail because lacking of mail/p5-Mail-SPF as DEPENDS.
With this patch, the port build well and passed all tests on amd64-head
system.
Comments? OK?
wen
Index: Makefile
===
RCS file: /cvs/ports/mail/p5-Mail-Milter-Authentication/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile12 Jul 2019 20:47:34 - 1.4
+++ Makefile23 Jul 2019 02:52:57 -
@@ -6,7 +6,7 @@ V = 1.1.0
DISTNAME = Mail-Milter-Authentication-v${V}
PKGNAME = p5-Mail-Milter-Authentication-${V}
CATEGORIES = mail
-REVISION = 0
+REVISION = 1
MAINTAINER = Giovanni Bechis
@@ -26,6 +26,7 @@ RUN_DEPENDS = devel/p5-List-MoreUtils \
mail/p5-Email-Address \
mail/p5-Email-Date-Format \
mail/p5-Mail-DMARC>=1.20150908 \
+ mail/p5-Mail-SPF \
sysutils/p5-Proc-ProcessTable
TEST_DEPENDS = devel/p5-Test-CheckManifest \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: l...@cvs.openbsd.org2019/07/22 20:52:58
Modified files:
security/ghidra: Makefile
Log message:
Take maintainership; ok rpointel@
Add a comment that ST4-${ST4_VER}.jar is only needed during build for antlr;
it is not needed at runtime and therefore does not need to be packed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: l...@cvs.openbsd.org2019/07/22 20:09:20
Modified files:
security/ghidra: Makefile distinfo
security/ghidra/pkg: PLIST
Added files:
security/ghidra/files: repos.gradle
security/ghidra/patches: patch-GPL_CabExtract_build_gradle
patch-GPL_DemanglerGnu_Module_manifest
patch-GPL_DemanglerGnu_build_gradle
patch-GPL_nativeBuildProperties_gradle
patch-Ghidra_Features_Decompiler_build_gradle
patch-Ghidra_Features_Decompiler_src_decompile_cpp_Makefile
patch-Ghidra_Features_Decompiler_src_decompile_cpp_types_h
patch-Ghidra_Features_FunctionID_build_gradle
patch-Ghidra_Framework_Generic_src_main_java_ghidra_framework_Platform_java
patch-Ghidra_Framework_Help_src_main_java_help_GHelpBuilder_java
patch-Ghidra_Framework_SoftwareModeling_Module_manifest
patch-Ghidra_Framework_SoftwareModeling_build_gradle
patch-Ghidra_Framework_Utility_src_main_java_ghidra_framework_OperatingSystem_java
patch-Ghidra_RuntimeScripts_Linux_support_launch_sh
patch-build_gradle
patch-gradleScripts_distribution_gradle
patch-gradleScripts_ip_gradle
Removed files:
security/ghidra/patches: patch-support_launch_sh
Log message:
Build and pack native components so that Ghidra can decompile programs on
OpenBSD. This is based on a pull request from Jeremy O'Brien at
https://github.com/NationalSecurityAgency/ghidra/pull/490 and the Ghidra
build guide at
https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md .
In addition, I have made these changes to make Ghidra work better as an OpenBSD
port:
1. I removed the explicit check for Gradle 5.0 because I was able to build
Ghidra with latest versions of Gradle. At the time of commit, our
java/gradle port is 5.5.1 which is the latest version of Gradle.
2. By default, the Ghidra build process tries to fetch dependent files on demand
while building. This will cause the build to fail if the port is built using
the _pbuild user. To fix this, I made the port fetch all the dependent .jar
files prior to building. I also used gradle's --offline flag which
explicitly tells gradle to "Execute the build without accessing network
resources".
3. To prevent the build process from touching $HOME, I made gradle use
${WRKDIR}/gradle as its home and also modified GHelpBuilder.java
(the program that builds help files during build) to log to ${WRKDIR}
instead of $HOME/.ghidra.
4. One of the Gradle scripts (ip.gradle) scans the Ghidra source tree so
I had to explicitly tell it to exclude *.orig and *.beforesubst.
help from bentley@ and Jeremy O'Brien
ok bentley@ rpointel@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: l...@cvs.openbsd.org2019/07/22 20:04:32 ports/security/ghidra/files Update of /cvs/ports/security/ghidra/files In directory cvs.openbsd.org:/tmp/cvs-serv45298/files Log Message: Directory /cvs/ports/security/ghidra/files added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 17:15:39 Modified files: devel/jdk/1.8 : Makefile distinfo Removed files: devel/jdk/1.8/patches: patch-hotspot_src_os_bsd_vm_os_bsd_cpp patch-jdk_src_share_native_java_lang_System_c patch-jdk_src_share_native_java_lang_java_props_h patch-jdk_src_solaris_native_java_lang_childproc_c patch-jdk_src_solaris_native_java_lang_java_props_md_c Log message: Update to u222: * Contains many upstream bug fixes and security fixes which can be mined from u212-u222 release notes here: https://adoptopenjdk.net/release_notes.html * Removed patches merged upstream
Re: lang/gcc fails on -current
On 22/07/2019 12:21, Stuart Henderson wrote: > On 2019/07/22 08:36, Pavel Korovin wrote: >> On 07/20, Nigel Taylor wrote: >>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but >>> there are more afterwards. Too many errors to fix by hand. >>> >>> The problem I think lies in opening files for writing when they don't >>> exist, it fails to create an empty file. So I manually touch sinfo.h to >>> create the empty file. Same for other missing files. >>> >>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada >>> >>> >>> Not sure where the error is could be with the ada bootstrap file, needs >>> regenerating. >> >> The same problem here, please find the diff for gcc8 attached. > > Yet the Makefiles are presumably OK on other systems, and are OK on i386. > > Has anyone figured out what triggered this to start failing and what is > actually going on? > > Wondering if there's an LP64 related problem. The only other 64-bit arch > building ada support in ports/lang/gcc/8 is mips64. Anyone know if that > still works? > > The most obvious candidate to my eyes would be realpath, if there's some > problem with this it could impact many many ports. So I think we should > figure out what's really going on before committing workarounds to gcc > which take the whole thing off the radar. > > This is a ktrace/kdump side by side of grep CALL's one with and one without sinfo.h present. 70692 xsinfo CALL write(1,0x444b5f5cc1f,0x1) │ 76912 xsinfo CALL write(1,0x97722da4c1f,0x1) 70692 xsinfo CALL write(1,0x7f7d8580,0x35) │ 76912 xsinfo CALL write(1,0x7f7a5ce0,0x35) 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) │ 76912 xsinfo CALL __realpath(0x7f7bbd90,0x7f7bb550) 70692 xsinfo CALL open(0x7f7ee630,0x601,0666) │ 76912 xsinfo CALL kbind(0x7f7bb8a0,24,0x494ab4884a3e974f) 70692 xsinfo CALL fstat(4,0x7f7ee150) │ 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) │ 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) 70692 xsinfo CALL open(0x7f7ee630,0) │ 76912 xsinfo CALL mmap(0,0x4000,0x3,0x1002,-1,0) 70692 xsinfo CALL fstat(5,0x7f7ee150) │ 76912 xsinfo CALL mmap(0,0x4000,0x3,0x1002,-1,0) Only when the file exists after the __realpath call is open called, suggesting __realpath is returning an error for the missing file, causing the open to be skipped. Could be realpath returning wrong error in this case or runtime looking for the wrong error or not expecting an error. As a quick check I reverted back to a kernel I built 15 July, with that kernel xsinfo works when sinfo.h is missing. Which looks, this change might be the cause of problems. but only guessing. But doesn't seem to tie up with your later email. cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c Index: vfs_syscalls.c === RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.321 retrieving revision 1.323 diff -u -p -r1.321 -r1.323 --- vfs_syscalls.c 12 Jul 2019 13:56:27 - 1.321 +++ vfs_syscalls.c 15 Jul 2019 15:05:21 - 1.323 @@ -1,4 +1,4 @@ -/* $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp $ */ +/* $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */ /* $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $ */ /* @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v, NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH, UIO_SYSSPACE, pathname, p); else - NDINIT(, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT | SAVENAME | + NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT | SAVENAME | REALPATH, UIO_SYSSPACE, pathname, p); nd.ni_cnd.cn_rpbuf = rpbuf; I'll look at building kernel with this reverted. Not saying the change isn't right, but may have exposed error checking which is wrong.
Re: lang/gcc fails on -current
On Mon, 22 Jul 2019 21:44:06 +0100, Stuart Henderson wrote: > On 2019/07/22 22:05, Christian Weisgerber wrote: > > Mark Patruck: > > > > > lang/gcc always fails with the following error on amd64 -current (~6 > > > hours old) > > > > > > > > > Check for missing set procedures in body > > > OK > > > > > > All tests completed successfully, no errors detected > > > > > > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory > > > > The problem is in libgnat and triggered by the recent change to > > make realpath() POSIX-ly correct. > > > > In libgnat/s-fileio.adb, the System.File_IO Open function calls > > full_name() on all pathnames, including when creating files that > > don't exist yet. > > > > full_name() maps to __gnat_full_name(). > > > > In cstreams.c, __gnat_full_name() calls realpath(). > > > > Upstream doesn't notice because... > > > > /* Use realpath function which resolves links and references to . and .. > > on those Unix systems that support it. Note that GNU/Linux provides it > > but > > cannot handle more than 5 symbolic links in a full name, so we use the > > getcwd approach instead. */ > > > > ... Linux uses a different code path. > > > > The trivial patch below makes us use that same codepath. Unfortunately, > > it also requires building a new adastrap (on a system without the > > realpath change). > > > > With the new adastrap, gcc/8 will then build fine on -current. > > BTW I am building a new adastrap with this on i386. Will also need > hppa/mips64/macppc. I still have these machines before the realpath switch, I can do those. > It might be worth adding a comment to the Makefile explaining what's > needed in case someone wants to work on updating arches currently > stuck with adastrap from old GCC versions later (building on 6.5 > will be easiest, I guess) > > > RCS file: patches/patch-gcc_ada_cstreams_c > > diff -N patches/patch-gcc_ada_cstreams_c > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ patches/patch-gcc_ada_cstreams_c22 Jul 2019 19:58:35 - > > @@ -0,0 +1,17 @@ > > +$OpenBSD$ > > + > > +System.File_IO.Open calls full_name() for Create. Use getcwd() approach > > +instead of realpath() since the latter fails if the file doesn't exist. > > + > > +Index: gcc/ada/cstreams.c > > +--- gcc/ada/cstreams.c.orig > > gcc/ada/cstreams.c > > +@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer) > > + *p = '\\'; > > + } > > + > > +-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined > > (__OpenBSD__) > > ++#elif defined (__FreeBSD__) || defined (__DragonFly__) > > + > > + /* Use realpath function which resolves links and references to . and .. > > + on those Unix systems that support it. Note that GNU/Linux provides > > it but > > -- > > Christian "naddy" Weisgerber na...@mips.inka.de > >
Re: lang/gcc fails on -current
On 2019/07/22 22:05, Christian Weisgerber wrote: > Mark Patruck: > > > lang/gcc always fails with the following error on amd64 -current (~6 hours > > old) > > > > > > Check for missing set procedures in body > > OK > > > > All tests completed successfully, no errors detected > > > > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory > > The problem is in libgnat and triggered by the recent change to > make realpath() POSIX-ly correct. > > In libgnat/s-fileio.adb, the System.File_IO Open function calls > full_name() on all pathnames, including when creating files that > don't exist yet. > > full_name() maps to __gnat_full_name(). > > In cstreams.c, __gnat_full_name() calls realpath(). > > Upstream doesn't notice because... > > /* Use realpath function which resolves links and references to . and .. > on those Unix systems that support it. Note that GNU/Linux provides it > but > cannot handle more than 5 symbolic links in a full name, so we use the > getcwd approach instead. */ > > ... Linux uses a different code path. > > The trivial patch below makes us use that same codepath. Unfortunately, > it also requires building a new adastrap (on a system without the > realpath change). > > With the new adastrap, gcc/8 will then build fine on -current. BTW I am building a new adastrap with this on i386. Will also need hppa/mips64/macppc. It might be worth adding a comment to the Makefile explaining what's needed in case someone wants to work on updating arches currently stuck with adastrap from old GCC versions later (building on 6.5 will be easiest, I guess) > RCS file: patches/patch-gcc_ada_cstreams_c > diff -N patches/patch-gcc_ada_cstreams_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-gcc_ada_cstreams_c 22 Jul 2019 19:58:35 - > @@ -0,0 +1,17 @@ > +$OpenBSD$ > + > +System.File_IO.Open calls full_name() for Create. Use getcwd() approach > +instead of realpath() since the latter fails if the file doesn't exist. > + > +Index: gcc/ada/cstreams.c > +--- gcc/ada/cstreams.c.orig > gcc/ada/cstreams.c > +@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer) > + *p = '\\'; > + } > + > +-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined > (__OpenBSD__) > ++#elif defined (__FreeBSD__) || defined (__DragonFly__) > + > + /* Use realpath function which resolves links and references to . and .. > + on those Unix systems that support it. Note that GNU/Linux provides it > but > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: lang/gcc fails on -current
Mark Patruck: > lang/gcc always fails with the following error on amd64 -current (~6 hours > old) > > > Check for missing set procedures in body > OK > > All tests completed successfully, no errors detected > > raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such file or directory The problem is in libgnat and triggered by the recent change to make realpath() POSIX-ly correct. In libgnat/s-fileio.adb, the System.File_IO Open function calls full_name() on all pathnames, including when creating files that don't exist yet. full_name() maps to __gnat_full_name(). In cstreams.c, __gnat_full_name() calls realpath(). Upstream doesn't notice because... /* Use realpath function which resolves links and references to . and .. on those Unix systems that support it. Note that GNU/Linux provides it but cannot handle more than 5 symbolic links in a full name, so we use the getcwd approach instead. */ ... Linux uses a different code path. The trivial patch below makes us use that same codepath. Unfortunately, it also requires building a new adastrap (on a system without the realpath change). With the new adastrap, gcc/8 will then build fine on -current. Index: patches/patch-gcc_ada_cstreams_c === RCS file: patches/patch-gcc_ada_cstreams_c diff -N patches/patch-gcc_ada_cstreams_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-gcc_ada_cstreams_c22 Jul 2019 19:58:35 - @@ -0,0 +1,17 @@ +$OpenBSD$ + +System.File_IO.Open calls full_name() for Create. Use getcwd() approach +instead of realpath() since the latter fails if the file doesn't exist. + +Index: gcc/ada/cstreams.c +--- gcc/ada/cstreams.c.orig gcc/ada/cstreams.c +@@ -190,7 +190,7 @@ __gnat_full_name (char *nam, char *buffer) + *p = '\\'; + } + +-#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined (__OpenBSD__) ++#elif defined (__FreeBSD__) || defined (__DragonFly__) + + /* Use realpath function which resolves links and references to . and .. + on those Unix systems that support it. Note that GNU/Linux provides it but -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [patch] net/icbirc: Correct IRC parsing
On 2019/07/11 12:40, Matthew Martin wrote:
> Seems some icbirc users started having : prefixed nicks after updating
> weechat. Even though weechat added a workaround, I think it would be
> best to fix the IRC protocol parsing in icbirc to conform to the RFC.
>
> I special cased RAWICB to bypass the correct parsing; I assumed people
> manually typed those commands and I shouldn't break finger memory.
>
> I don't use ICB, so this has only been compile tested. Once tested, this
> should go upstream rather than living in the tree.
>
> - Matthew Martin
Could someone who uses icbirc test and commit this please, the bug is
slightly annoying for other people on the channel :)
Diff forwarded below for ease of applying...
diff --git Makefile Makefile
index d7bb3f1160b..a7b292d43da 100644
--- Makefile
+++ Makefile
@@ -3,7 +3,7 @@
COMMENT= proxy IRC client with ICB server
DISTNAME= icbirc-2.1
-REVISION= 2
+REVISION= 3
CATEGORIES=net
MASTER_SITES= http://www.benzedrine.ch/
diff --git patches/patch-irc_c patches/patch-irc_c
new file mode 100644
index 000..ceb5f0172a0
--- /dev/null
+++ patches/patch-irc_c
@@ -0,0 +1,200 @@
+$OpenBSD$
+
+Index: irc.c
+--- irc.c.orig
irc.c
+@@ -42,7 +42,7 @@ extern void scan(const char **, char *, size_t, const
+ const char *);
+ extern int sync_write(int, const char *, int);
+
+-static voidirc_cmd(const char *, int, int);
++static voidirc_cmd(char *, int, int);
+
+ static voidirc_send_pong(int, const char *);
+
+@@ -93,44 +93,55 @@ irc_recv(const char *buf, unsigned len, int client_fd,
+ }
+
+ static void
+-irc_cmd(const char *cmd, int client_fd, int server_fd)
++irc_cmd(char *cmd, int client_fd, int server_fd)
+ {
+- if (!strncasecmp(cmd, "PASS ", 5)) {
+- cmd += 5;
+- scan(, irc_pass, sizeof(irc_pass), " ", " ");
+- } else if (!strncasecmp(cmd, "USER ", 5)) {
+- cmd += 5;
+- scan(, irc_ident, sizeof(irc_ident), " ", " ");
++ if (!strncasecmp(cmd, "RAWICB ", 7)) {
++ icb_send_raw(server_fd, cmd + 7);
++ return;
++ }
++
++ char *argv[10], *p;
++ int argc = 1;
++
++ for (p = cmd, argv[0] = p; argc < 10 && (p = strchr(p, ' ')) != NULL;
++ argc++) {
++ *p = 0;
++ p++;
++ while (*p == ' ')
++ p++;
++ if (*p == ':') {
++ argv[argc] = p + 1;
++ argc++;
++ break;
++ }
++ argv[argc] = p;
++ }
++
++ if (!strcasecmp(argv[0], "PASS")) {
++ strlcpy(irc_pass, argv[1], sizeof(irc_pass));
++ } else if (!strcasecmp(argv[0], "USER")) {
++ strlcpy(irc_ident, argv[1], sizeof(irc_ident));
+ if (!icb_logged_in && irc_nick[0] && irc_ident[0])
+ icb_send_login(server_fd, irc_nick,
+ irc_ident, irc_pass);
+- } else if (!strncasecmp(cmd, "NICK ", 5)) {
+- cmd += 5;
+- scan(, irc_nick, sizeof(irc_nick), " ", " ");
++ } else if (!strcasecmp(argv[0], "NICK")) {
++ strlcpy(irc_nick, argv[1], sizeof(irc_nick));
+ if (icb_logged_in)
+ icb_send_name(server_fd, irc_nick);
+ else if (irc_nick[0] && irc_ident[0])
+ icb_send_login(server_fd, irc_nick,
+ irc_ident, irc_pass);
+- } else if (!strncasecmp(cmd, "JOIN ", 5)) {
+- char group[128];
+-
+- cmd += 5;
+- if (*cmd == '#')
+- cmd++;
+- scan(, group, sizeof(group), " ", " ");
+- icb_send_group(server_fd, group);
+- } else if (!strncasecmp(cmd, "PART ", 5)) {
++ } else if (!strcasecmp(argv[0], "JOIN")) {
++ icb_send_group(server_fd,
++ argv[1] + (argv[1][0] == '#' ? 1 : 0));
++ } else if (!strcasecmp(argv[0], "PART")) {
+ in_irc_channel = 0;
+- } else if (!strncasecmp(cmd, "PRIVMSG ", 8) ||
+- !strncasecmp(cmd, "NOTICE ", 7)) {
+- char dst[128];
++ } else if (!strcasecmp(argv[0], "PRIVMSG") ||
++ !strcasecmp(argv[0], "NOTICE")) {
+ char msg[8192];
+ unsigned i, j;
+
+- cmd += strncasecmp(cmd, "NOTICE ", 7) ? 8 : 7;
+- scan(, dst, sizeof(dst), " ", " ");
+- scan(, msg, sizeof(msg), " ", "");
++ strlcpy(msg, argv[2], sizeof(msg));
+ /* strip \001 found in CTCP messages */
+ i = 0;
+ while (msg[i]) {
+@@ -141,73 +152,52 @@ irc_cmd(const char *cmd, int client_fd, int server_fd)
+ } else
+ i++;
+ }
+- if (!strcmp(dst, irc_channel))
+-
Re: [UPDATE] www/honk
Update Makefile
- change NO_TEST=yes to NO_TEST=Yes
On 7/12/19, Horia Racoviceanu wrote:
> Update patch to Makefile rev. 1.7
>
> On 7/11/19, Horia Racoviceanu wrote:
>> Update to v0.7.4
>> - add admin.txt
>>
>> Changelog:
>> + Ever more bug fixes.
>> + Collapse posts based on custom regex match.
>> + Tonks are now honk backs.
>> + Show both avatars for bonks. Other minor refinements to UI.
>> + Minimal support for Video activity and PeerTube compat.
>> + Support for some user selectable styling. Currently, skinny column
>> mode.
>> + webp image transcoding.
>>
>>
>> On 6/27/19, Horia Racoviceanu wrote:
>>> Update to v0.7.3
>>>
>>> Changelog:
>>> -- 0.7.3
>>> + Better fedicompat so bonks are visible to pleroma followers.
>>> -- 0.7.2
>>> + Add the funzone. Minor other UI tweaks.
>>>
>>> On 6/21/19, Horia Racoviceanu wrote:
Update to v0.7.1
Changelog:
+ Fix bug preventing unfollow from working.
On 6/18/19, Horia Racoviceanu wrote:
> - add memes directory
>
> On 6/18/19, Horia Racoviceanu wrote:
>> - add emus directory
>>
>> On 6/17/19, Horia Racoviceanu wrote:
>>> Update to v0.7.0
>>> - codename Father Mother Maiden Crone Honker Bonker Zonker
>>>
>>> Changelog:
>>> +++ Auto fetching and inlining of hoots.
>>> ++ A new xzone to view and import data not otherwise visible.
>>> ++ Preview before honking.
>>> ++ Some extra commands for better database retention management.
>>> ++ A changelog.
>>> + Default robots.txt.
>>> + Misc UI touchups.
>>> + Read only support for qonks.
>>> + About page.
>>> + More reliable (retries) meta messages such as follow requests.
>>> + Better thread support for missing context.
>>> + Upgrade image library for cleaner screenshots.
>>> + Not all summaries need labels.
>>> + Add max-width for video tag.
>>>
>>> On 6/14/19, Aaron Bieber wrote:
On Wed, 12 Jun 2019 at 22:53:45 -0400, Horia Racoviceanu wrote:
> - bump REVISION
> - change PERMIT_PACKAGE_CDROM to PERMIT_PACKAGE
> - change user _honk home directory mode, no longer group writable
> - update README, add icon and favicon
Tests fine here! OK abieber@ if anyone wants to commit.
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D
62A9
ADCE
>>>
>>
>
>>>
>>
>
Index: Makefile
===
RCS file: /cvs/ports/www/honk/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:50:46 - 1.7
+++ Makefile22 Jul 2019 16:18:52 -
@@ -2,7 +2,7 @@
COMMENT = federated status updater
-DISTNAME = honk-0.6.0
+DISTNAME = honk-0.7.4
CATEGORIES = www
HOMEPAGE = https://humungus.tedunangst.com/r/honk
@@ -18,7 +18,7 @@ EXTRACT_SUFX =.tgz
MODULES = lang/go
LIB_DEPENDS = databases/sqlite3
-NO_TEST = yes
+NO_TEST = Yes
ALL_TARGET = humungus.tedunangst.com/r/honk
SUBST_VARS += VARBASE
Index: distinfo
===
RCS file: /cvs/ports/www/honk/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo4 Jun 2019 02:41:49 - 1.4
+++ distinfo22 Jul 2019 16:18:52 -
@@ -1,2 +1,2 @@
-SHA256 (honk-0.6.0.tgz) = OjBaohbkm8Y/i1RawsOG/qF7dQluuKIGxvnApf+gwGE=
-SIZE (honk-0.6.0.tgz) = 166970
+SHA256 (honk-0.7.4.tgz) = uWqlp89q+ADDcBMGU6Sf9614wKGQDc5PdTO8sUKSc4k=
+SIZE (honk-0.7.4.tgz) = 213790
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/honk/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 4 Jun 2019 02:41:50 - 1.3
+++ pkg/PLIST 22 Jul 2019 16:18:52 -
@@ -5,28 +5,32 @@
@bin bin/honk
share/doc/honk/
share/doc/honk/README
+share/doc/honk/admin.txt
+share/doc/honk/changelog.txt
share/doc/honk/manual.txt
share/doc/honk/ping.txt
share/doc/honk/security.txt
share/doc/honk/spec.txt
share/doc/pkg-readmes/${PKGSTEM}
-@mode 770
+@mode 750
@owner _honk
@group _honk
@sample ${VARBASE}/honk/
-@mode 750
+@sample ${VARBASE}/honk/emus/
+@sample ${VARBASE}/honk/memes/
@sample ${VARBASE}/honk/views/
-@mode
-@owner
-@group
share/examples/honk/
share/examples/honk/schema.sql
@sample ${VARBASE}/honk/schema.sql
share/examples/honk/views/
+share/examples/honk/views/about.html
+@sample ${VARBASE}/honk/views/about.html
share/examples/honk/views/account.html
@sample ${VARBASE}/honk/views/account.html
share/examples/honk/views/combos.html
@sample ${VARBASE}/honk/views/combos.html
+share/examples/honk/views/funzone.html
+@sample ${VARBASE}/honk/views/funzone.html
share/examples/honk/views/header.html
@sample
Re: [update] devel/flake8 (and dependencies)
Ping ?
On Sun, 23 Jun 2019, Paco Esteban wrote:
> On Thu, 20 Jun 2019, Kurt Mosiejczuk wrote:
>
> > It helps be sure one didn't break anything in my experience. I usually just
> > run the tests which will install the test dependencies and then run tests.
> > "pkg_delete -a" is your friends after rounds of tests like that. It deletes
> > things that were installed automatically but aren't needed now.
>
> Ok, I'll do that in the future.
>
> > > dependent on devel/flake8 (all of them TEST_DEPENDS):
> > > www/youtube-dl
> > > it took hours ...
> > > Ran 2386 tests in 18354.702s
> > > FAILED (errors=826, failures=322)
> > > sysutils/ranger
> > > Test crashes with: https://onna.be/paste/ranger_crash.txt
> > > net/py-libcloud
> > > 2 failed, 9165 passed, 19 skipped, 534 warnings
> > > seems related to paramikossh ??
> >
> > This is fine. I re-ran these tests (both py and py3) and they all passed.
>
> I think I'll try some of those again (both on my machine and a fresh
> vm). Not sure why they do not pass for me. Maybe I have something broken
> in my environment ...
>
> > The only thing I'd change on these diffs is make sure to convert the
> > PERMIT_PACKAGE_CDROM lines to PERMIT_PACKAGE lines while we're doing
> > the updates.
>
> Ok. I've included the modified diffs at the end.
>
> > Thanks for the nice work on these updates.
>
> Thank you for taking the time to review this :-)
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/flake8/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile 15 May 2019 12:04:35 - 1.15
> +++ Makefile 23 Jun 2019 14:54:57 -
> @@ -2,9 +2,8 @@
>
> COMMENT =modular python code checker wrapping pep8 and pyflakes
>
> -MODPY_EGG_VERSION = 3.5.0
> +MODPY_EGG_VERSION = 3.7.7
> DISTNAME = flake8-${MODPY_EGG_VERSION}
> -REVISION = 0
>
> CATEGORIES = devel
>
> @@ -13,7 +12,7 @@ HOMEPAGE = https://gitlab.com/pycqa/fla
> MAINTAINER = Bertrand Janin
>
> # MIT
> -PERMIT_PACKAGE_CDROM = Yes
> +PERMIT_PACKAGE = Yes
>
> MODULES =lang/python
>
> @@ -26,6 +25,7 @@ MODPY_PYTEST_ARGS = tests
> TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR}
>
> RUN_DEPENDS =devel/py-codestyle${MODPY_FLAVOR} \
> + devel/py-entrypoints${MODPY_FLAVOR} \
> devel/py-mccabe${MODPY_FLAVOR} \
> devel/pyflakes${MODPY_FLAVOR}
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/flake8/distinfo,v
> retrieving revision 1.7
> diff -u -p -r1.7 distinfo
> --- distinfo 21 Jan 2018 23:49:25 - 1.7
> +++ distinfo 23 Jun 2019 14:54:57 -
> @@ -1,2 +1,2 @@
> -SHA256 (flake8-3.5.0.tar.gz) = clMmX3q9izE+OJKUQESjZeP0rD/Nz7Qpj1Xund8Yi6A=
> -SIZE (flake8-3.5.0.tar.gz) = 140608
> +SHA256 (flake8-3.7.7.tar.gz) = hZmWBz80HyZwdBtR7B5noB2hQoMaof3GJC2/iN/75mE=
> +SIZE (flake8-3.7.7.tar.gz) = 148457
> Index: patches/patch-setup_py
> ===
> RCS file: patches/patch-setup_py
> diff -N patches/patch-setup_py
> --- patches/patch-setup_py21 Jan 2018 23:49:25 - 1.7
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,13 +0,0 @@
> -$OpenBSD: patch-setup_py,v 1.7 2018/01/21 23:49:25 danj Exp $
> -
> -Index: setup.py
> setup.py.orig
> -+++ setup.py
> -@@ -24,7 +24,6 @@ requires = [
> - "pyflakes >= 1.5.0, < 1.7.0",
> - "pycodestyle >= 2.0.0, < 2.4.0",
> - "mccabe >= 0.6.0, < 0.7.0",
> --"setuptools >= 30",
> - ]
> -
> - extras_require = {
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/flake8/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -r1.5 PLIST
> --- pkg/PLIST 21 Jan 2018 23:49:25 - 1.5
> +++ pkg/PLIST 23 Jun 2019 14:54:57 -
> @@ -10,7 +10,7 @@ lib/python${MODPY_VERSION}/site-packages
>
> lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> lib/python${MODPY_VERSION}/site-packages/flake8/__init__.py
> lib/python${MODPY_VERSION}/site-packages/flake8/__main__.py
> -lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}/
> +${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}/
>
> lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}checker.${MODPY_PYC_MAGIC_TAG}pyc
> @@ -22,7 +22,7 @@ lib/python${MODPY_VERSION}/site-packages
>
> lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}pyc
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/07/22 10:13:08 Modified files: sysutils/libsmdev: Makefile Log message: Missing BDEP on devel/gettext,-tools. /bin/sh: /usr/local/bin/xgettext: not found
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/07/22 10:10:27 Modified files: mail/kopano: Makefile.inc mail/kopano/core: Makefile distinfo mail/kopano/core/patches: patch-Makefile_in patch-common_ECChannel_cpp patch-configure_ac patch-installer_linux_server_cfg patch-provider_libserver_ECAttachmentStorage_cpp patch-provider_server_ECServer_cpp patch-provider_server_ECSoapServerConnection_cpp patch-spooler_DAgent_cpp mail/kopano/core/pkg: PLIST-main Log message: update to 8.7.82.59
Re: ipv6 nmap breakage under 6.5-STABLE ?
On 2019-07-22 09:51, Adam Thompson wrote: Hi, [Cross-posted to misc & ports as I'm not sure if there's a bug in software or in wetware.] I'm trying to run nmap (from ports) on 6.5-STABLE but am getting an ungoogle-able error message every time: Forgot to mention - this occurs under OpenBSD, but not Linux (CentOS 7.6.1810 & nmap 6.40). Obviously that's not an apples-to-apples comparison, but it's what I've got access to from here right now. -Adam
ipv6 nmap breakage under 6.5-STABLE ?
Hi, [Cross-posted to misc & ports as I'm not sure if there's a bug in software or in wetware.] I'm trying to run nmap (from ports) on 6.5-STABLE but am getting an ungoogle-able error message every time: root@bgpmirror:~# nmap -Pn -A -n --top-ports=100 -6 2620:132:300e:700::113 Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-22 09:43 CDT sendmsg: Message too long sendmsg: Message too long [...continues like this for a really long time...] Interspersed semi-randomly (not always at the same point) I also see mixed in there a single occurrence: sendmsg: Message too long sendmsg: Bad address Unable to send packet in probe_transmission_handler: Bad address (14) sendmsg: Invalid argument Unable to send packet in probe_transmission_handler: Invalid argument (22) sendmsg: Message too long Unable to send packet in probe_transmission_handler: Message too long (40) sendmsg: Message too long Performing a similar scan on an IPv4 address works as expected. This appears to be a v6-specific problem. Known issue? Workarounds? Thanks, -Adam
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 07:08:18 Modified files: www/py-mako: Makefile distinfo Log message: Update www/py-mako to 1.0.14 Switched test runner from py-nose to py-test. Updated dependencies to reflect new version. Tweak and ok sthen@
Re: lang/gcc fails on -current
On 2019/07/22 13:36, Nigel Taylor wrote: > On 22/07/2019 12:21, Stuart Henderson wrote: > > On 2019/07/22 08:36, Pavel Korovin wrote: > >> On 07/20, Nigel Taylor wrote: > >>> I can get past the sinfo.h error, treeprs.ads and osnames errors, but > >>> there are more afterwards. Too many errors to fix by hand. > >>> > >>> The problem I think lies in opening files for writing when they don't > >>> exist, it fails to create an empty file. So I manually touch sinfo.h to > >>> create the empty file. Same for other missing files. > >>> > >>> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada > >>> > >>> > >>> Not sure where the error is could be with the ada bootstrap file, needs > >>> regenerating. > >> > >> The same problem here, please find the diff for gcc8 attached. > > > > Yet the Makefiles are presumably OK on other systems, and are OK on i386. > > > > Has anyone figured out what triggered this to start failing and what is > > actually going on? > > > > Wondering if there's an LP64 related problem. The only other 64-bit arch > > building ada support in ports/lang/gcc/8 is mips64. Anyone know if that > > still works? > > > > The most obvious candidate to my eyes would be realpath, if there's some > > problem with this it could impact many many ports. So I think we should > > figure out what's really going on before committing workarounds to gcc > > which take the whole thing off the radar. > > > > > > This is a ktrace/kdump side by side of grep CALL's one with and one > without sinfo.h present. > > 70692 xsinfo CALL write(1,0x444b5f5cc1f,0x1) >│ > 76912 xsinfo CALL write(1,0x97722da4c1f,0x1) > 70692 xsinfo CALL write(1,0x7f7d8580,0x35) >│ > 76912 xsinfo CALL write(1,0x7f7a5ce0,0x35) > 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) >│ > 76912 xsinfo CALL __realpath(0x7f7bbd90,0x7f7bb550) > 70692 xsinfo CALL > open(0x7f7ee630,0x601,0666) > │ 76912 xsinfo CALL kbind(0x7f7bb8a0,24,0x494ab4884a3e974f) > 70692 xsinfo CALL fstat(4,0x7f7ee150) >│ > 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) > 70692 xsinfo CALL __realpath(0x7f7ee630,0x7f7eddf0) >│ > 76912 xsinfo CALL kbind(0x7f7bb7f0,24,0x494ab4884a3e974f) > 70692 xsinfo CALL open(0x7f7ee630,0) >│ > 76912 xsinfo CALL > mmap(0,0x4000,0x3,0x1002,-1,0) > 70692 xsinfo CALL fstat(5,0x7f7ee150) >│ > 76912 xsinfo CALL > mmap(0,0x4000,0x3,0x1002,-1,0) > > Only when the file exists after the __realpath call is open called, > suggesting __realpath is returning an error for the missing file, > causing the open to be skipped. Could be realpath returning wrong error > in this case or runtime looking for the wrong error or not expecting an > error. > > As a quick check I reverted back to a kernel I built 15 July, with that > kernel xsinfo works when sinfo.h is missing. > > > Which looks, this change might be the cause of problems. but only > guessing. But doesn't seem to tie up with your later email. > > cvs -R -q diff -uNp -r 1.321 vfs_syscalls.c > Index: vfs_syscalls.c > === > RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v > retrieving revision 1.321 > retrieving revision 1.323 > diff -u -p -r1.321 -r1.323 > --- vfs_syscalls.c 12 Jul 2019 13:56:27 - 1.321 > +++ vfs_syscalls.c 15 Jul 2019 15:05:21 - 1.323 > @@ -1,4 +1,4 @@ > -/* $OpenBSD: vfs_syscalls.c,v 1.321 2019/07/12 13:56:27 solene Exp > $ */ > +/* $OpenBSD: vfs_syscalls.c,v 1.323 2019/07/15 15:05:21 beck Exp $ */ > /* $NetBSD: vfs_syscalls.c,v 1.71 1996/04/23 10:29:02 mycroft Exp $ >*/ > > /* > @@ -928,7 +928,7 @@ sys___realpath(struct proc *p, void *v, > NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME | REALPATH, > UIO_SYSSPACE, pathname, p); > else > - NDINIT(, CREATE, FOLLOW | LOCKLEAF | LOCKPARENT | > SAVENAME | > + NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | LOCKPARENT | > SAVENAME | > REALPATH, UIO_SYSSPACE, pathname, p); > > nd.ni_cnd.cn_rpbuf = rpbuf; > > > I'll look at building kernel with this reverted. Not saying the change > isn't right, but may have exposed error checking which is wrong. > Hmm. Well based on the ktrace it's likely that this will avoid the problem. *ponders* We've already seen different codepaths taken in other ports (augeas) due to
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 07:00:01 Modified files: devel/py-fasteners: Makefile distinfo Added files: devel/py-fasteners/patches: patch-fasteners__utils_py patch-fasteners__utils_py.orig patch-setup_py patch-setup_py.orig Log message: Update devel/py-fasteners to 0.15 Added a missing TEST_DEPENDS on devel/py-pbr Patched to use built-in time.monotonic rather than py-monotonic for the python3 flavor. A pull request has been made with upstream to integrate this change. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 06:57:46 ports/devel/py-fasteners/patches Update of /cvs/ports/devel/py-fasteners/patches In directory cvs.openbsd.org:/tmp/cvs-serv35798/patches Log Message: Directory /cvs/ports/devel/py-fasteners/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 06:55:10 Modified files: textproc/py-MarkupSafe: Makefile distinfo Log message: Update MarkupSafe to version 1.1.1 "Fix segfault when __html__ method raises an exception when using the C speedups. The exception is now propagated correctly. (#109)" ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/22 06:51:59 Modified files: net/py-idna: Makefile distinfo net/py-idna/pkg: PLIST Log message: Update net/py-idna 2.5 -> 2.8 Bring py-idna current. Updates the code to Unicode 11.0.0 and provides other fixes. All tests pass for both python2 and python3 on amd64. OK sthen@
Re: lang/gcc fails on -current
On 22/07/2019 06:36, Pavel Korovin wrote: > On 07/20, Nigel Taylor wrote: >> I can get past the sinfo.h error, treeprs.ads and osnames errors, but >> there are more afterwards. Too many errors to fix by hand. >> >> The problem I think lies in opening files for writing when they don't >> exist, it fails to create an empty file. So I manually touch sinfo.h to >> create the empty file. Same for other missing files. >> >> Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada >> >> >> Not sure where the error is could be with the ada bootstrap file, needs >> regenerating. > > The same problem here, please find the diff for gcc8 attached. > I've done much the same already, but the resulting gnat package is broken. The diff gets around the problem of building, but not the fact the runtime produced is then broken. That is the ada Create fails to work when the file is missing sinfo/xsinfo.adb: Create (Ofile, Out_File, "sinfo.h"); As no other packages use ada, to build the my set of packages, the no_ada flavor can be used. Building a non working gnat package only helps others looking into the problem. Not for general release. While the diff helps and thanks very much, just don't anyone put it into CVS. Don't use unless you understand the gnat runtime package will still be broken. The ada runtime/OpenBSD needs fixing for amd64, not the building of the package. If the runtime needs fixing a new bootstrap will be required.
Re: [Update] databases/p5-DBIx-Connector : Update to 0.56
On Monday, July 22, 2019, wen heping wrote: > Hi, > >Here is a patch for databases/p5-DBIx-Connector: >i) Update to 0.56 >ii) Remove p5-Test-Pod and p5-Test-Pod-Coverage from > TEST_DEPENDS, because there is no pod tests in this version. >iii) Change p5-Test-MockModule from BUILD_DEPENDS to TEST_DEPENDS. > >It build well and passed all tests on amd64-head system. >No other ports depends on it. > > Comments? OK? > Looks good to me OK > wen >
Re: lang/gcc fails on -current
On 2019/07/22 12:21, Stuart Henderson wrote: > On 2019/07/22 08:36, Pavel Korovin wrote: > > On 07/20, Nigel Taylor wrote: > > > I can get past the sinfo.h error, treeprs.ads and osnames errors, but > > > there are more afterwards. Too many errors to fix by hand. > > > > > > The problem I think lies in opening files for writing when they don't > > > exist, it fails to create an empty file. So I manually touch sinfo.h to > > > create the empty file. Same for other missing files. > > > > > > Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada > > > > > > > > > Not sure where the error is could be with the ada bootstrap file, needs > > > regenerating. > > > > The same problem here, please find the diff for gcc8 attached. > > Yet the Makefiles are presumably OK on other systems, and are OK on i386. Oh, I spoke too soon. : cp -p /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.ads-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.adb-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/snames.h-tmpl /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xsnamest.adb /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xutil.ads /usr/obj/ports/gcc-8.3.0/gcc-8.3.0/gcc/ada/xutil.adb ada/bldtools/snamest : (cd ada/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest ) : /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_os_filename': : /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:701: warning: strcpy() is almost always misused, please use strlcpy() : /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_tmp_name': : /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:1205: warning: sprintf() is often misused, please use snprintf() : /usr/obj/ports/gcc-8.3.0/bootstrap/lib/gcc/i386-unknown-openbsd6.4/8.2.0/adalib/libgnat.a(adaint.o): In function `__gnat_readdir': : /home/pascal/ports/pobj/gcc-8.2.0/build-i386/gcc/ada/rts/adaint.c:1300: warning: stpcpy() is dangerous; do not use it : : raised ADA.IO_EXCEPTIONS.USE_ERROR : treeprs.ads: No such file or directory Started between these two: OpenBSD 6.5-current (GENERIC.MP) #0: Wed Jul 17 10:20:06 MDT 2019 OpenBSD 6.5-current (GENERIC.MP) #0: Sat Jul 20 12:32:52 MDT 2019 Self built -current kernels; cvs checkout would have been about 4-5 hours before the kernel timestamp. > Has anyone figured out what triggered this to start failing and what is > actually going on? > > Wondering if there's an LP64 related problem. The only other 64-bit arch > building ada support in ports/lang/gcc/8 is mips64. Anyone know if that > still works? > > The most obvious candidate to my eyes would be realpath, if there's some > problem with this it could impact many many ports. So I think we should > figure out what's really going on before committing workarounds to gcc > which take the whole thing off the radar. >
Re: lang/gcc fails on -current
On 2019/07/22 08:36, Pavel Korovin wrote: > On 07/20, Nigel Taylor wrote: > > I can get past the sinfo.h error, treeprs.ads and osnames errors, but > > there are more afterwards. Too many errors to fix by hand. > > > > The problem I think lies in opening files for writing when they don't > > exist, it fails to create an empty file. So I manually touch sinfo.h to > > create the empty file. Same for other missing files. > > > > Add env FLAVOR=no_ada to the make or if using dpb lang/gcc/8,no_ada > > > > > > Not sure where the error is could be with the ada bootstrap file, needs > > regenerating. > > The same problem here, please find the diff for gcc8 attached. Yet the Makefiles are presumably OK on other systems, and are OK on i386. Has anyone figured out what triggered this to start failing and what is actually going on? Wondering if there's an LP64 related problem. The only other 64-bit arch building ada support in ports/lang/gcc/8 is mips64. Anyone know if that still works? The most obvious candidate to my eyes would be realpath, if there's some problem with this it could impact many many ports. So I think we should figure out what's really going on before committing workarounds to gcc which take the whole thing off the radar.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2019/07/22 05:21:08 Modified files: textproc/py-pygments: Makefile distinfo textproc/py-pygments/pkg: PLIST Log message: Update py-pygments 2.1.3 -> 2.4.2 Changelog: http://pygments.org/docs/changelog/ ok sthen@
Re: [UPDATE] textproc/py-pygments
On 2019/07/22 10:25, Pavel Korovin wrote: > Dear all, > > Please find update for the latest py-pygments attached. > 2.3.1 version we have in ports is very outdated (Mar 2, 2016). > > 1 test fails for python2 flavor, python3 tests are OK (with 2.1.3 > 4 tests fail for both flavors). > > OK to update? I've reviewed the changelog and don't see anything that looks like an incompatible update, and tested trac which still works correctly. OK sthen@
[maintainer update] www/p5-Mojo 8.22
Hello, this diff updates www/p5-Mojo to the latest version, 8.22. https://metacpan.org/release/SRI/Mojolicious-8.22 All test pass. While here also switch to PERMIT_PACKAGE, as suggested by Charlene Wendling. Index: Makefile === RCS file: /cvs/ports/www/p5-Mojo/Makefile,v retrieving revision 1.34 diff -u -p -r1.34 Makefile --- Makefile30 Apr 2019 02:11:35 - 1.34 +++ Makefile22 Jul 2019 10:21:04 - @@ -4,13 +4,13 @@ COMMENT = next generation web framework MODULES = cpan PKG_ARCH = * -DISTNAME = Mojolicious-8.15 +DISTNAME = Mojolicious-8.22 CATEGORIES = www MAINTAINER = Manolis Tzanidakis # Perl -PERMIT_PACKAGE_CDROM = Yes +PERMIT_PACKAGE=Yes HOMEPAGE = https://mojolicious.org/ Index: distinfo === RCS file: /cvs/ports/www/p5-Mojo/distinfo,v retrieving revision 1.26 diff -u -p -r1.26 distinfo --- distinfo30 Apr 2019 02:11:35 - 1.26 +++ distinfo22 Jul 2019 10:21:04 - @@ -1,2 +1,2 @@ -SHA256 (Mojolicious-8.15.tar.gz) = yFArI+TyE1RIYfIECjTf6nLj0QkzVcJMcPEtZdB37Ns= -SIZE (Mojolicious-8.15.tar.gz) = 755156 +SHA256 (Mojolicious-8.22.tar.gz) = huNKUPfa63r0NlXXs7/kO7CRJCFr+vMBbm/ZdcPySFQ= +SIZE (Mojolicious-8.22.tar.gz) = 764431
[Update] devel/p5-SUPER : Update to 1.20190531
Hi, ports@:
Here is a patch for devel/p5-SUPER:
i) Update to 1.20190531
ii) Remove the line BUILD_DEPENDS= ${RUN_DEPENDS}, the port
could build without p5-Sub-Identify.
It build well and passed all tests on amd64-head system.
Only one port depends on p5-SUPER : devel/p5-Test-MockModule,
it build well and passed all tests with this patch.
Comments? OK?
wen
Index: Makefile
===
RCS file: /cvs/ports/devel/p5-SUPER/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile12 Jul 2019 21:02:17 - 1.10
+++ Makefile22 Jul 2019 09:05:34 -
@@ -2,8 +2,7 @@
COMMENT= module for controlling superclass method dispatch
-DISTNAME= SUPER-1.17
-REVISION= 1
+DISTNAME= SUPER-1.20190531
CATEGORIES=devel
@@ -12,7 +11,7 @@ PERMIT_PACKAGE= Yes
MODULES= cpan
PKG_ARCH= *
-BUILD_DEPENDS= ${RUN_DEPENDS}
+
RUN_DEPENDS= devel/p5-Sub-Identify
CONFIGURE_STYLE=modbuild
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-SUPER/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:13:33 - 1.3
+++ distinfo22 Jul 2019 09:05:34 -
@@ -1,2 +1,2 @@
-SHA256 (SUPER-1.17.tar.gz) = AlAXLmcSi4DnastPKASBxaLOe9dKH06WaEoYxYp0wuI=
-SIZE (SUPER-1.17.tar.gz) = 8096
+SHA256 (SUPER-1.20190531.tar.gz) = aF0e525/DpAGlCkjv334sRwQcTKZKRdZPc9zl9QX05o=
+SIZE (SUPER-1.20190531.tar.gz) = 14909
[Update] databases/p5-DBIx-Connector : Update to 0.56
Hi,
Here is a patch for databases/p5-DBIx-Connector:
i) Update to 0.56
ii) Remove p5-Test-Pod and p5-Test-Pod-Coverage from
TEST_DEPENDS, because there is no pod tests in this version.
iii) Change p5-Test-MockModule from BUILD_DEPENDS to TEST_DEPENDS.
It build well and passed all tests on amd64-head system.
No other ports depends on it.
Comments? OK?
wen
Index: Makefile
===
RCS file: /cvs/ports/databases/p5-DBIx-Connector/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:43:56 - 1.3
+++ Makefile22 Jul 2019 08:44:04 -
@@ -4,7 +4,7 @@ COMMENT = fast, safe DBI connection and
MODULES = cpan
PKG_ARCH = *
-DISTNAME = DBIx-Connector-0.53
+DISTNAME = DBIx-Connector-0.56
CATEGORIES = databases
CPAN_AUTHOR = DWHEELER
@@ -13,10 +13,8 @@ MAINTAINER = Abel Abraham Camarillo Oje
# Artistic
PERMIT_PACKAGE = Yes
-BUILD_DEPENDS =devel/p5-Test-MockModule>=0.05
RUN_DEPENDS = databases/p5-DBI>=1.605
-TEST_DEPENDS = devel/p5-Test-Pod>=1.41 \
- devel/p5-Test-Pod-Coverage>=1.06
+TEST_DEPENDS = devel/p5-Test-MockModule>=0.05
CONFIGURE_STYLE = perl modbuild
Index: distinfo
===
RCS file: /cvs/ports/databases/p5-DBIx-Connector/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo18 Mar 2014 09:09:03 - 1.1.1.1
+++ distinfo22 Jul 2019 08:44:04 -
@@ -1,2 +1,2 @@
-SHA256 (DBIx-Connector-0.53.tar.gz) =
PEr5/tmgmoQ4qa6ktIK2EClG9xnEv13g+gbbfFJcGKU=
-SIZE (DBIx-Connector-0.53.tar.gz) = 35777
+SHA256 (DBIx-Connector-0.56.tar.gz) =
V8CNLBlRSGy5XPuD9Rj0YqPb8g01Pz7uT0avRPoZw1k=
+SIZE (DBIx-Connector-0.56.tar.gz) = 36770
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/p5-DBIx-Connector/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 18 Mar 2014 09:09:03 - 1.1.1.1
+++ pkg/PLIST 22 Jul 2019 08:44:04 -
@@ -4,6 +4,7 @@ ${P5SITE}/DBIx/Connector/
${P5SITE}/DBIx/Connector.pm
${P5SITE}/DBIx/Connector/Driver/
${P5SITE}/DBIx/Connector/Driver.pm
+${P5SITE}/DBIx/Connector/Driver/Firebird.pm
${P5SITE}/DBIx/Connector/Driver/MSSQL.pm
${P5SITE}/DBIx/Connector/Driver/Oracle.pm
${P5SITE}/DBIx/Connector/Driver/Pg.pm
@@ -11,6 +12,7 @@ ${P5SITE}/DBIx/Connector/Driver/SQLite.p
${P5SITE}/DBIx/Connector/Driver/mysql.pm
@man man/man3p/DBIx::Connector.3p
@man man/man3p/DBIx::Connector::Driver.3p
+@man man/man3p/DBIx::Connector::Driver::Firebird.3p
@man man/man3p/DBIx::Connector::Driver::MSSQL.3p
@man man/man3p/DBIx::Connector::Driver::Oracle.3p
@man man/man3p/DBIx::Connector::Driver::Pg.3p
[UPDATE] textproc/py-pygments
Dear all,
Please find update for the latest py-pygments attached.
2.3.1 version we have in ports is very outdated (Mar 2, 2016).
1 test fails for python2 flavor, python3 tests are OK (with 2.1.3
4 tests fail for both flavors).
OK to update?
--
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/textproc/py-pygments/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile12 Jul 2019 20:50:12 - 1.28
+++ Makefile22 Jul 2019 07:15:23 -
@@ -2,12 +2,11 @@
COMMENT= Python syntax highlighter
-MODPY_EGG_VERSION = 2.1.3
+MODPY_EGG_VERSION = 2.4.2
DISTNAME= Pygments-${MODPY_EGG_VERSION}
PKGNAME= ${DISTNAME:L:S/^/py-/}
CATEGORIES=textproc devel
-REVISION= 1
HOMEPAGE= http://pygments.org/
Index: distinfo
===
RCS file: /cvs/ports/textproc/py-pygments/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo31 May 2016 06:06:20 - 1.12
+++ distinfo22 Jul 2019 07:15:23 -
@@ -1,2 +1,2 @@
-SHA256 (Pygments-2.1.3.tar.gz) = iOTIqRsq9ZYr+l6iRH7G3TVwGOhulMfRS9jKy8W1XYE=
-SIZE (Pygments-2.1.3.tar.gz) = 2116434
+SHA256 (Pygments-2.4.2.tar.gz) = iBxMFX5F8wrxhcH/6NVJ1IrJEnQz8sOAwkuEVyrWYpc=
+SIZE (Pygments-2.4.2.tar.gz) = 9405880
Index: pkg/PLIST
===
RCS file: /cvs/ports/textproc/py-pygments/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- pkg/PLIST 31 May 2016 06:06:20 - 1.11
+++ pkg/PLIST 22 Jul 2019 07:15:23 -
@@ -78,23 +78,32 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_scilab_builtins.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_sourcemod_builtins.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_stan_builtins.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_stata_builtins.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_tsql_builtins.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_vbscript_builtins.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}_vim_builtins.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}actionscript.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}agile.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}algebra.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}ambient.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}ampl.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}apl.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}archetype.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}asm.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}automation.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}basic.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}bibtex.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}boa.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}business.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}c_cpp.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}c_like.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}capnproto.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}chapel.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}clean.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}compiled.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}configs.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}console.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/pygments/lexers/${MODPY_PYCACHE}crystal.${MODPY_PYC_MAGIC_TAG}pyc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/07/22 00:56:33 Modified files: multimedia/x264: Makefile distinfo multimedia/x264/patches: patch-configure Removed files: multimedia/x264/patches: patch-common_x86_cabac-a_asm patch-common_x86_cpu-a_asm patch-common_x86_mc-a_asm patch-common_x86_pixel-a_asm patch-common_x86_predict-a_asm patch-common_x86_quant-a_asm patch-common_x86_sad-a_asm patch-common_x86_trellis-64_asm Log message: Update to x264-20190720. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/07/22 00:55:41 Modified files: multimedia/libass: Makefile distinfo Log message: Update to libass-0.14.0. from Brad (maintainer)
