CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/12/21 00:48:24 Modified files: graphics/graphite2: Makefile distinfo Log message: Update to graphite2-1.3.13.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2018/12/21 00:38:35 Modified files: archivers/ucl : Makefile Log message: Update license marker. Move homepage/master_sites to https.
Re: x11/gromit segfault
Solene Rapenne wrote: > on amd64/current, when starting gromit it produces a core dump. > > egdb backtrace reports this, kdump did not showed anything useful. > > #0 0x111993b96dbe in IA__gdk_cursor_new_from_pixmap > (source=0xe5a06aa0, mask=0xe5a06ad0, fg=0x11198b62bf70, > bg=0x1119397a9960, x=14, y=14) at gdkcursor-x11.c:376 > 376 gdkcursor-x11.c: No such file or directory. > (gdb) bt > #0 0x111993b96dbe in IA__gdk_cursor_new_from_pixmap > (source=0xe5a06aa0, mask=0xe5a06ad0, fg=0x11198b62bf70, > bg=0x1119397a9960, x=14, y=14) at gdkcursor-x11.c:376 > #1 0x111697f06c31 in ?? () > #2 0x111697f079ab in ?? () > #3 0x111697f04056 in ?? () > #4 0x in ?? () while it produce a core dump, the program doesn't even seem to respect its flag. README says: However: The window does not hide, if you erase everything with the eraser tool, you have to clear the screen explicitely with the "gromit --clear" command or hide Gromit with "gromit --visibility". solene@t480 ~ $ gromit --visiblity Unknown Option: "--visiblity" Please see the Gromit README for the correct usage solene@t480 ~ $ gromit --clear Unknown Option: "--clear" Please see the Gromit README for the correct usage It has not been updated since 2004. I propose its removal if nobody wants to fix it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2018/12/20 23:58:38 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm geo: Makefile Removed files: geo/emerillon : Makefile distinfo geo/emerillon/pkg: DESCR PLIST Log message: Remove emerillon superseded by gnome-maps ok landry@ jca@
Re: CVS: cvs.openbsd.org: ports
On Fri, Dec 21, 2018 at 01:06:50AM +0100, Matthias Kilian wrote: > On Wed, Dec 19, 2018 at 12:10:45AM +, Stuart Henderson wrote: > > > > Modified files: > > > > print/poppler : Makefile > > > > > > > > Log message: > > > > set USE_LLD=Yes on i386 to unbreak the bulk build for now. > > > > probably still broken on other ld.bfd arches, build log excerpts at > > > > https://marc.info/?l=openbsd-ports-cvs=154445446621320=2 > > > > > > macppc fails the same :) > > > > > > > My dirty commit unbroke the default build on i386, but still has a > > problem with print/poppler,,-qt4 : > > > > CMake Error at glib/cmake_install.cmake:47 (file): > > file INSTALL cannot find > > "/usr/obj/ports/poppler-0.61.1/build-i386/glib/libpoppler-glib.so.8.9". > > Call Stack (most recent call first): > > cmake_install.cmake:240 (include) > > poppler-qt4 will have to die, anyways. I support this death by snu-snu^Wcvs rm plan ! > If real live doesn't intervene again (as it did too often), I hope > to give Landrys disqble-poppler-qt4-diffs a try, unhook any remaining > ports using poppler-qt4 and look wether poppler-0.72 is any better > than 0.61.1. on the 5 ports iirc 2 are fixed, 1 has a pending diff to update.
Re: [NEW] net/sbws
ping George Rosamond: > Attached is a tarball for net/sbws, Tor's simple bandwidth scanner. > > While the function of a bandwidth scanner is limited to trusted hosts on > the Tor network, it can also be used as a research or testing tool on a > closed network. > > Tests are disabled for now, but they rely on shells/bash (but upstream > will be changing to posix shell). > > There is a conflict with www/buku, but assume it can be ignored: > > sbws-1.0.2 conflicts with buku-3.8 > (www/buku):/usr/local/lib/python3.6/site-packages/tests/__init__.py > /usr/local/lib/python3.6/site-packages/tests/__pycache__/__init__.cpython-36.pyc > > >
Re: CVS: cvs.openbsd.org: ports
On Wed, Dec 19, 2018 at 12:10:45AM +, Stuart Henderson wrote: > > > Modified files: > > > print/poppler : Makefile > > > > > > Log message: > > > set USE_LLD=Yes on i386 to unbreak the bulk build for now. > > > probably still broken on other ld.bfd arches, build log excerpts at > > > https://marc.info/?l=openbsd-ports-cvs=154445446621320=2 > > > > macppc fails the same :) > > > > My dirty commit unbroke the default build on i386, but still has a > problem with print/poppler,,-qt4 : > > CMake Error at glib/cmake_install.cmake:47 (file): > file INSTALL cannot find > "/usr/obj/ports/poppler-0.61.1/build-i386/glib/libpoppler-glib.so.8.9". > Call Stack (most recent call first): > cmake_install.cmake:240 (include) poppler-qt4 will have to die, anyways. If real live doesn't intervene again (as it did too often), I hope to give Landrys disqble-poppler-qt4-diffs a try, unhook any remaining ports using poppler-qt4 and look wether poppler-0.72 is any better than 0.61.1. Ciao, Kili
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/12/20 16:20:07 Modified files: games/xevil: Makefile games/xevil/patches: patch-cmn_actual_cpp patch-cmn_game_style_cpp patch-cmn_physical_cpp patch-cmn_utils_cpp patch-cmn_xetp_cpp Log message: Add missing header for ports-gcc. Use over because the latter is C++11, which ports-gcc 4.9 only supports with -std=c++11 and base-gcc 4.2 not at all.
[ports-gcc-6.4.0] Fix x11/rxvt-unicode build
Hi ports!
> http://build-failures.rhaalovely.net/powerpc/2018-11-20/x11/rxvt-unicode.log
URxvt won't build with the default c++14 standard of gcc 6.4. The diff
i'm proposing here just downgrades the standard to gnu++98 [0].
It builds properly with g++ 6.4 [1], i've still checked with 4.9 in case
there would be an issue but it's fine as well [2].
Charlène.
[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757#c0
[1] http://ix.io/1wsB
[2] http://ix.io/1wsA
Index: Makefile
===
RCS file: /cvs/ports/x11/rxvt-unicode/Makefile,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 Makefile
--- Makefile24 Oct 2018 14:28:13 - 1.44
+++ Makefile20 Dec 2018 19:00:54 -
@@ -3,7 +3,7 @@
COMMENT = clone of rxvt with Unicode and Xft support
DISTNAME = rxvt-unicode-9.22
-REVISION = 7
+REVISION = 8
CATEGORIES = x11
FIX_EXTRACT_PERMISSIONS=Yes
@@ -43,3 +43,9 @@ CONFIGURE_ENV += CPPFLAGS="-I${X11BASE}/
pt_cv_tty_group=yes
.include
+
+# fix rxvtperl.C:(.text+0x13c34): undefined reference
+# to `__cxa_throw_bad_array_new_length' with ports-gcc 6.4.
+.if ${CHOSEN_COMPILER} == "ports-gcc"
+CXXFLAGS += -std=gnu++98
+.endif
Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi,
unless i'm missing something, everything discussed in this thread
should be fixed now, with the commit appended below.
Ingo Schwarze wrote on Thu, Dec 20, 2018 at 07:35:22PM +0100:
> Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +:
[...]
>> Rebuilding whatis databases:
>> makewhatis: man7/cmake-properties.7: ERROR: No such file or directory
[...]
> 1. The line number is missing, even though it is relevant.
> 2. Mentioning the .so request would be useful.
> 3. Mentining the file that was not found would be useful.
> 4. Most importantly, makewhatis(8) is not supposed
> to print mandoc(1) errors in this manner.
[...]
> Bug number 6: duoplicate reporting, two messages about the same problem
> in the input file, both with incomplete information. Not sure i can fix
> that one, but i shall try.
Fixing all that required much smaller code changes than i expected,
but explaining why these small changes do the job needed a substantial
commit message...
Speak up if you still see issues!
Thanks,
Ingo
Log Message:
---
Move the full responsibility for reporting open(2) errors from
mparse_open() to the caller. That is better because only the caller
knows its preferred reporting method and format and only the caller
has access to all the data that should be included - like the column
number in .so processing or the current manpath in makewhatis(8).
Moving the mandoc_msg() call out is possible because the caller can
call strerror(3) just as easily as mparse_open() can.
Move mandoc_msg_setinfilename() closer to the parsing of the file
contents, to avoid problems *with* the file (like non-existence,
lack of permissions, etc.) getting misreported as problems *in*
the file.
Fix the column number reported for .so failure:
let it point to the beginning of the filename.
Taken together, this prevents makewhatis(8) from spewing confusing
messages about .so failures to stderr, a bug reported by
Raf Czlonka on ports@.
It also prevents mandoc(1) from issuing *two* messages for every
single .so failure.
Modified Files:
--
mandoc:
main.c
read.c
Revision Data
-
Index: main.c
===
RCS file: /home/cvs/mandoc/mandoc/main.c,v
retrieving revision 1.313
retrieving revision 1.314
diff -Lmain.c -Lmain.c -u -p -r1.313 -r1.314
--- main.c
+++ main.c
@@ -510,7 +510,6 @@ main(int argc, char *argv[])
} else
thisarg = *argv;
- mandoc_msg_setinfilename(thisarg);
fd = mparse_open(curp.mp, thisarg);
if (fd != -1) {
if (use_pager) {
@@ -523,11 +522,13 @@ main(int argc, char *argv[])
conf.output.tag : *argv;
}
+ mandoc_msg_setinfilename(thisarg);
if (resp == NULL || resp->form == FORM_SRC)
parse(, fd, thisarg);
else
passthrough(resp->file, fd,
conf.output.synopsisonly);
+ mandoc_msg_setinfilename(NULL);
if (ferror(stdout)) {
if (tag_files != NULL) {
@@ -545,8 +546,9 @@ main(int argc, char *argv[])
outdata_alloc();
terminal_sepline(curp.outdata);
}
- }
- mandoc_msg_setinfilename(NULL);
+ } else
+ mandoc_msg(MANDOCERR_FILE, 0, 0,
+ "%s", strerror(errno));
if (curp.wstop && mandoc_msg_getrc() != MANDOCLEVEL_OK)
break;
Index: read.c
===
RCS file: /home/cvs/mandoc/mandoc/read.c,v
retrieving revision 1.207
retrieving revision 1.208
diff -Lread.c -Lread.c -u -p -r1.207 -r1.208
--- read.c
+++ read.c
@@ -372,8 +372,9 @@ rerun:
mparse_readfd(curp, fd, ln.buf + of);
close(fd);
} else {
- mandoc_msg(MANDOCERR_SO_FAIL, curp->line,
- pos, ".so %s", ln.buf + of);
+ mandoc_msg(MANDOCERR_SO_FAIL,
+ curp->line, of, ".so %s: %s",
+ ln.buf + of, strerror(errno));
ln.sz = mandoc_asprintf(,
".sp\nSee the file %s.\n.sp",
ln.buf + of);
@@ -633,7 +634,6 @@ mparse_open(struct mparse *curp, const c
/* Neither worked, give up. */
- mandoc_msg(MANDOCERR_FILE, 0, 0, "%s", strerror(errno));
return -1;
}
update: py-cparser-2.18 -> 2.19
Here is an update for py-cparser-2.18 to 2.19.
From the CHANGES file:
+ Version 2.19 (2018.09.19)
- PR #277: Fix parsing of floating point literals
- PR #254: Add support for parsing empty structs
- PR #240: Fix enum formatting in generated C code (also #216)
- PR #222: Add support for #pragma in struct declarations
- There are reports that this release doesn't work with Python 2.6
(#281).
Please note that the minimal supported version is 2.7; the required
versions are listed in the README file.
I ran 'make test' with py2 and py3 and they gave the same
output (see below), I was curious so I ran the same tests on
Ubuntu, and the test script gave the same output there as well:
WARNING: 36 shift/reduce conflicts
WARNING: 1 reduce/reduce conflict
WARNING: reduce/reduce conflict in state 351 resolved using rule
(statement -> )
WARNING: rejected rule (empty -> ) in state 351
Ran 107 tests in 1.181s
OK (skipped=3)
-
I also created a simple.c file with a single printf statement and
ran it through cparser:
$ gcc -E -I./ -I/usr/ports/pobj/py-cparser-2.19-python3/pycprser-2.19/ \
utils/fake_libc_include simple.c > s.c
$ python3
import pycparser
pycparser.parse_file('s.c')
FileAST(ext=[Typedef(name=u'size_t',
[...]
It worked ok. Any feedback and/or oks?
Regards,
Mark
Index: Makefile
===
RCS file: /cvs/ports/devel/py-cparser/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile14 Nov 2017 06:52:56 - 1.7
+++ Makefile20 Dec 2018 18:35:33 -
@@ -2,7 +2,7 @@
COMMENT= C parser in pure Python
-MODPY_EGG_VERSION= 2.18
+MODPY_EGG_VERSION= 2.19
DISTNAME= pycparser-${MODPY_EGG_VERSION}
PKGNAME= ${DISTNAME:S/py/py-/}
CATEGORIES=devel textproc
Index: distinfo
===
RCS file: /cvs/ports/devel/py-cparser/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo14 Nov 2017 06:52:56 - 1.3
+++ distinfo20 Dec 2018 18:35:33 -
@@ -1,2 +1,2 @@
-SHA256 (pycparser-2.18.tar.gz) = majKA+KYUdlmFq0EBLSq19nuFvJcn5cIoR+vKBD3siY=
-SIZE (pycparser-2.18.tar.gz) = 245897
+SHA256 (pycparser-2.19.tar.gz) = qYhxir+tgLaxV6zOe/Ewowh20nYDc4rDnxQJkyRrJbM=
+SIZE (pycparser-2.19.tar.gz) = 158295
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/12/20 14:02:09 Modified files: databases/sqlports/files: Sql.pm Log message: add group_concat idiom add missing commas remove extra table name from select if there's just one table involved
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/12/20 13:39:24 Modified files: databases/sqlports/files: Sql.pm Log message: simplify origin sytnax
NEW: cad/xschem
This is my first port so please help me to get it right. Xschem < http://repo.hu/projects/xschem/ > is a schematic capture program. Its main target is simulation. It can also export netlist to pcb-rnd where to design the printed circuit board. My next port will be pcb-rnd. Best regards, Hannu Vuolasaho xschem.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/12/20 13:18:53 Added files: devel/ptlib/patches: patch-src_ptclib_pwavfile_cxx Log message: add missing include for big-endian archs; ok jca@ ajacoutot@
Re: UPDATE: devel/intellij 2018.2.4 -> 2018.3.2
Hi Eric and ports@,
On Wed, Dec 19, 2018 at 08:20:33PM -0600, Eric Brown wrote:
> Please find attachted a diff that updates devel/intellij to 2018.3.2.
>
> I have worked with the maintainer, whose suggestions I have incorporated
> into this diff.
I updated Eric's diff, see below. I regenerated PLIST such that
bin/libdbm64.so is not included in the package. I currently do not have
the time to do run-time testing but this diff looks fine to me. Eric
actually did some run-time testing.
Thanks to Eric who did the majority of the work.
Thanks,
Caspar Schutijser
Index: Makefile
===
RCS file: /cvs/ports/devel/intellij/Makefile,v
retrieving revision 1.55
diff -u -p -r1.55 Makefile
--- Makefile29 Sep 2018 09:49:13 - 1.55
+++ Makefile20 Dec 2018 19:56:30 -
@@ -2,7 +2,7 @@
COMMENT= IntelliJ IDEA Java IDE
-V= 2018.2.4
+V= 2018.3.2
DISTNAME= ideaIC-${V}
PKGNAME= intellij-${V}
CATEGORIES=devel
@@ -26,7 +26,7 @@ NO_TEST= Yes
SUBST_VARS+= JAVA_HOME
-WRKDIST= ${WRKDIR}/idea-IC-182.4505.22
+WRKDIST= ${WRKDIR}/idea-IC-183.4886.37
IJ=${PREFIX}/intellij
# If NO_BUILD is set, JAVA_HOME doesn't get defined. So do
@@ -37,6 +37,7 @@ do-build:
do-install:
${INSTALL_DATA_DIR} ${IJ}
@tar -czf - -C ${WRKDIST} . | tar xzf - -C ${IJ}
+ @rm -rf ${IJ}/bin/libdbm64.so
@rm -rf ${IJ}/jre
@rm -rf ${IJ}/jre64
@rm -rf ${IJ}/plugins/android
Index: distinfo
===
RCS file: /cvs/ports/devel/intellij/distinfo,v
retrieving revision 1.34
diff -u -p -r1.34 distinfo
--- distinfo29 Sep 2018 09:49:13 - 1.34
+++ distinfo20 Dec 2018 19:56:30 -
@@ -1,2 +1,2 @@
-SHA256 (ideaIC-2018.2.4.tar.gz) = Xn7XogYbKyPBxmAKBFEC3Ay7K3hQPAH6XiXNS+7s2es=
-SIZE (ideaIC-2018.2.4.tar.gz) = 522027117
+SHA256 (ideaIC-2018.3.2.tar.gz) = Qmel2sAYLmAEcA3J2Tw7jSbjabfjKNDW/LymfRnPsE4=
+SIZE (ideaIC-2018.3.2.tar.gz) = 541693312
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/intellij/pkg/PLIST,v
retrieving revision 1.35
diff -u -p -r1.35 PLIST
--- pkg/PLIST 4 Sep 2018 12:53:16 - 1.35
+++ pkg/PLIST 20 Dec 2018 19:56:30 -
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.35 2018/09/04 12:53:16 espie Exp $
+@comment $OpenBSD: PLIST,v$
bin/idea
bin/intellij
intellij/
@@ -14,6 +14,7 @@ intellij/bin/format.sh
intellij/bin/idea.png
intellij/bin/idea.properties
intellij/bin/idea.sh
+intellij/bin/idea.svg
intellij/bin/idea.vmoptions
intellij/bin/idea64.vmoptions
intellij/bin/inspect.sh
@@ -23,7 +24,6 @@ intellij/bin/restart.py
intellij/build.txt
intellij/idea.png
intellij/lib/
-intellij/lib/MultithreadedTC-1.01.jar
intellij/lib/aether-api-1.1.0.jar
intellij/lib/aether-connector-basic-1.1.0.jar
intellij/lib/aether-dependency-resolver.jar
@@ -92,13 +92,13 @@ intellij/lib/ant/lib/ant.jar
intellij/lib/ant/lib/ant.pom
intellij/lib/ant/lib/libraries.properties
intellij/lib/asm-5.0.3.jar
-intellij/lib/asm-all.jar
+intellij/lib/asm-all-7.0.jar
intellij/lib/asm-analysis-5.0.3.jar
intellij/lib/asm-tree-5.0.3.jar
intellij/lib/automaton-1.12-1.jar
intellij/lib/baksmali-2.2.1.jar
intellij/lib/batik-all-1.10.jar
-intellij/lib/bcprov-jdk15on-1.59.jar
+intellij/lib/bcprov-jdk15on-1.60.jar
intellij/lib/bootstrap.jar
intellij/lib/cglib-nodep-3.2.4.jar
intellij/lib/cli-parser-1.1.2.jar
@@ -106,8 +106,8 @@ intellij/lib/common-image-3.3.2.jar
intellij/lib/common-io-3.3.2.jar
intellij/lib/common-lang-3.3.2.jar
intellij/lib/commons-codec-1.10.jar
-intellij/lib/commons-collections-3.2.1.jar
-intellij/lib/commons-compress-1.16.1.jar
+intellij/lib/commons-collections-3.2.2.jar
+intellij/lib/commons-compress-1.17.jar
intellij/lib/commons-httpclient-3.1-patched.jar
intellij/lib/commons-imaging-1.0-RC-1.jar
intellij/lib/commons-io-2.6.jar
@@ -118,29 +118,26 @@ intellij/lib/commons-net-3.6.jar
intellij/lib/constraint-layout.jar
intellij/lib/cucumber-core-1.2.4.jar
intellij/lib/cucumber-java-1.2.5.jar
-intellij/lib/delight-rhino-sandbox-0.0.6.jar
+intellij/lib/delight-nashorn-sandbox-0.1.16.jar
intellij/lib/dexlib2-2.2.1.jar
intellij/lib/ecj-4.7.2.jar
intellij/lib/eddsa-0.2.0.jar
-intellij/lib/emma.jar
+intellij/lib/error_prone_annotations-2.3.1.jar
intellij/lib/extensions.jar
+intellij/lib/external-system-impl.jar
intellij/lib/external-system-rt.jar
-intellij/lib/fest-assert-1.5.0-SNAPSHOT.jar
-intellij/lib/fest-reflect-2.0-SNAPSHOT.jar
-intellij/lib/fest-swing-1.4.6.jar
-intellij/lib/fest-util-1.3.0-SNAPSHOT.jar
-intellij/lib/fluent-hc-4.5.5.jar
+intellij/lib/fluent-hc-4.5.6.jar
intellij/lib/forms-1.1-preview.jar
intellij/lib/forms_rt.jar
intellij/lib/fst-2.57.jar
intellij/lib/gherkin-2.12.2.jar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: juan...@cvs.openbsd.org 2018/12/20 11:50:04 Modified files: archivers/lzip/tarlz: Makefile distinfo Log message: Update to tarlz 0.8. From Sascha Paunovic.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2018/12/20 11:41:45 Modified files: lang/mruby : Makefile Added files: lang/mruby/patches: patch-include_mrbconf_h Log message: Fix build on big endian systems by defining MRB_ENDIAN_BIG Tested on sparc64 by jca@ OK jca@
Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi Raf, Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +: > Recently, I've noticed an odd-looking output from weekly(8): > > Rebuilding whatis databases: > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory You are right, there are a number of bugs here. I feel tempted to call it a cloud of mosquitoes. Thanks for the analysis. 1. The line number is missing, even though it is relevant. 2. Mentioning the .so request would be useful. 3. Mentining the file that was not found would be useful. 4. Most importantly, makewhatis(8) is not supposed to print mandoc(1) errors in this manner. The MANDOCERR_FILE enum item gets special handling in the code in several ways, but the effects are less than pretty. I think i have to revisit how this error item is generated and handled. > "Strange", I thought, especially since > /usr/local/man/man7/cmake-properties.7 is "alive" and well: > > $ ls -l /usr/local/man/man7/cmake-properties.7 > -rw-r--r-- 1 root bin 202877 Dec 20 14:00 > /usr/local/man/man7/cmake-properties.7 In general, the file name at the beginning of a mandoc(1) message is the name of the *input* file in which the error occurred, not the name of a file which mandoc tried to use. Here is bug number 5: That wasn't clearly stated in the manual page below: https://man.openbsd.org/mandoc#DIAGNOSTICS That's the first thing i fixed following your report, see the commit below. > I've rebuilt the mandoc.db I guess you mean "with makewhatis -D"? > and got an output which was stranger still: > > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory > /usr/local/man//man7/cmake-properties.7: Adding to database > > Huh!? Right, makewhatis is indexing the file even though the content of the file is buggy. But that's OK as far as it goes. > Time for 'mandoc -Tlint': Excellent idea. > $ mandoc -Tlint /usr/local/man/man7/cmake-properties.7 | head > mandoc: /usr/local/man/man7/cmake-properties.7:1131:2: WARNING: .so is > fragile, better use ln(1): so libraries. > mandoc: /usr/local/man/man7/cmake-properties.7: ERROR: No such file or > directory > mandoc: /usr/local/man/man7/cmake-properties.7:1131:15: ERROR: .so > request failed: .so libraries. > [...] Bug number 6: duoplicate reporting, two messages about the same problem in the input file, both with incomplete information. Not sure i can fix that one, but i shall try. > OK, let's see what on that line: > > $ sed -n 1131p /usr/local/man/man7/cmake-properties.7 > .so libraries. > > and including preceding line: > > Set the Android property that specifies directories to search for the > .so libraries. > > Right, so '.so' (unintentional pun) is treated as a macro here - No, not as a macro, as a roff(7) request - but that isn't what the author intended, either. > moving it to the line above, fixes the issue: > > Set the Android property that specifies directories to search for the > .so > libraries. > > Upstream uses reStructuredText but I hope this[0] does the trick. > > [0] https://gitlab.kitware.com/cmake/cmake/merge_requests/2756 That's not a fix but merely a workaround for a bug in reStructuredText. It is more important to report the bug to reStructuredText than to work around it in each and every project using reStructuredText. The reStructuredText program ought to emit Set the Android property that specifies directories to search for the \&.so libraries. for the input in question. > Anyway, thought this might be of interest. Indeed, thank you for reporting. Ingo Log Message: --- Explain what the fields in mandoc messages mean, rather than merely specifying the message syntax. Gap in documentation found while looking at a bug report from Raf Czlonka . Modified Files: -- mandoc: mandoc.1 Revision Data - Index: mandoc.1 === RCS file: /home/cvs/mandoc/mandoc/mandoc.1,v retrieving revision 1.232 retrieving revision 1.233 diff -Lmandoc.1 -Lmandoc.1 -u -p -r1.232 -r1.233 --- mandoc.1 +++ mandoc.1 @@ -714,13 +714,29 @@ Messages displayed by follow this format: .Bd -ragged -offset indent .Nm : -.Ar file : Ns Ar line : Ns Ar column : level : message : macro args +.Ar file : Ns Ar line : Ns Ar column : level : message : macro arguments .Pq Ar os .Ed .Pp -Line and column numbers start at 1. +The first three fields identify the +.Ar file +name, +.Ar line +number, and +.Ar column +number of the input file where the message was triggered. +The line and column numbers start at 1. Both are omitted for messages referring to an input file as a whole. -Macro names and arguments are omitted where meaningless. +All +.Ar level +and +.Ar message +strings are explained below. +The name of the +.Ar macro +triggering the message and its +.Ar arguments +are
Re: lang/mruby: 1.4.1 -> 2.0.0
On Thu, Dec 20 2018, Jeremy Evans wrote: > On 12/17 06:22, Jeremie Courreges-Anglas wrote: >> On Thu, Dec 13 2018, Jeremy Evans wrote: >> > Update to the latest release of mruby. Release announcement is >> > available at: >> > https://mruby.org/releases/2018/12/11/mruby-2.0.0-released.html >> > >> > Tested on amd64. Will be committing in a few days unless I hear >> > objections. >> > >> > If someone with sparc64 could test and see if it builds there now, I >> > would appreciate it. >> >> It packages and all tests pass except for 2 of them (endianness?) > > Jeremie, > > Could you please test this patch and see if it fixes the tests on sparc64: Yep, ok jca@ Skip: File.expand_path (with ENV) => (mrbgems: mruby-io) Skip: Struct.new removes existing constant => redefining Struct with same name cause warnings (mrbgems: mruby-struct) Total: 1077 OK: 1077 KO: 0 Crash: 0 Time: 4.38 seconds Total: 20 OK: 20 KO: 0 Crash: 0 Time: 3.35 seconds -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: lang/mruby: 1.4.1 -> 2.0.0
On 12/17 06:22, Jeremie Courreges-Anglas wrote:
> On Thu, Dec 13 2018, Jeremy Evans wrote:
> > Update to the latest release of mruby. Release announcement is
> > available at:
> > https://mruby.org/releases/2018/12/11/mruby-2.0.0-released.html
> >
> > Tested on amd64. Will be committing in a few days unless I hear
> > objections.
> >
> > If someone with sparc64 could test and see if it builds there now, I
> > would appreciate it.
>
> It packages and all tests pass except for 2 of them (endianness?)
Jeremie,
Could you please test this patch and see if it fixes the tests on sparc64:
Thanks,
Jeremy
Index: Makefile
===
RCS file: /cvs/ports/lang/mruby/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile17 Dec 2018 20:28:27 - 1.10
+++ Makefile20 Dec 2018 17:45:20 -
@@ -4,6 +4,7 @@ COMMENT = lightweight, embeddable imple
VERSION = 2.0.0
DISTNAME = mruby-${VERSION}
+REVISION = 0
CATEGORIES = lang
HOMEPAGE = https://github.com/mruby/mruby
Index: patches/patch-include_mrbconf_h
===
RCS file: patches/patch-include_mrbconf_h
diff -N patches/patch-include_mrbconf_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-include_mrbconf_h 20 Dec 2018 17:45:20 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+Index: include/mrbconf.h
+--- include/mrbconf.h.orig
include/mrbconf.h
+@@ -7,6 +7,7 @@
+ #ifndef MRUBYCONF_H
+ #define MRUBYCONF_H
+
++#include
+ #include
+ #include
+
+@@ -62,7 +63,9 @@
+ //#define MRB_NAN_BOXING
+
+ /* define on big endian machines; used by MRB_NAN_BOXING */
+-//#define MRB_ENDIAN_BIG
++#if (BYTE_ORDER == BIG_ENDIAN)
++#define MRB_ENDIAN_BIG
++#endif
+
+ /* represent mrb_value as a word (natural unit of data for the processor) */
+ //#define MRB_WORD_BOXING
[Update] GnuPG 2.2.12
Hi,
Small diff to update gnupg to it's latest version (2.2.12).
Comments, ok ?
Regards,
Index: Makefile
===
RCS file: /cvs/ports/security/gnupg2/Makefile,v
retrieving revision 1.62
diff -u -p -u -p -r1.62 Makefile
--- Makefile14 Nov 2018 20:48:22 - 1.62
+++ Makefile20 Dec 2018 17:42:45 -
@@ -2,9 +2,8 @@
COMMENT = GNU privacy guard - a free PGP replacement
-DISTNAME = gnupg-2.2.10
+DISTNAME = gnupg-2.2.12
CATEGORIES = security
-REVISION = 0
MASTER_SITES = ${MASTER_SITE_GNUPG:=gnupg/}
Index: distinfo
===
RCS file: /cvs/ports/security/gnupg2/distinfo,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 distinfo
--- distinfo18 Sep 2018 10:07:19 - 1.30
+++ distinfo20 Dec 2018 17:42:45 -
@@ -1,2 +1,2 @@
-SHA256 (gnupg-2.2.10.tar.bz2) = eZ3TeoahRIcy4zm9IEQPT17m5pdV9v16c+6K8whAyRU=
-SIZE (gnupg-2.2.10.tar.bz2) = 6659484
+SHA256 (gnupg-2.2.12.tar.bz2) = 2wMPi0yYZA6RMA021Rbx9Pj+CVFKlOqfx0Ee4aNAgss=
+SIZE (gnupg-2.2.12.tar.bz2) = 6682303
Re: net/wmnetload has a memory leak [patch]
On Wed, Dec 19 2018, Ed Hynan wrote: > On Wed, 19 Dec 2018, Jeremie Courreges-Anglas wrote: >> On Wed, Dec 19 2018, Ed Hynan wrote: >> > net/wmnetload has a memory leak [patch] >> > >> > wmnetload (6.4 release) repeatedly calls getifaddrs(3) >> > without freeifaddrs. >> >> Indeed. >> >> > The patch here fixes and would replace >> > net/wmnetload/patches/patch-src_ifstat_openbsd_c >> > not apply over it. >> >> Thanks. If you want to make it easier for people to pick up your >> patches, please try to submit patches using make update-patches and cvs >> diff. For more information on how to use update-patches, see item 11: >> >> https://www.openbsd.org/faq/ports/guide.html >> >> Since the fix changes what ends up in the package, it should include >> a REVISION bump. > > OK. I was concerned that I have 6.4 release and my ports are > cvs checkout -P -rOPENBSD_6_4 ports -- is this what ports folks > are working on? Nope, except for security backports on -stable, development happens on -current. [...] >> Could you please test this and report back? > > It's fine here. > > (I see your latest msg re. -w; pardon my late response.) Your response was not late, I was able to move fast thanks to Stuart. :) Thanks for confirming that it works for you. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2018/12/20 10:36:57 Modified files: textproc/nfoview: Makefile distinfo Log message: Tiny bugfix update to nfoview-1.26
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: l...@cvs.openbsd.org2018/12/20 10:31:21 Modified files: security/py-bcrypt: Makefile distinfo Log message: update to py-bcrypt-3.1.5 and add testing to Makefile. ok sthen@
Re: asterisk 13.24.0 - MWI notify error
On 2018/12/19 14:32, Mark Patruck wrote: > Hi, > > with the update to asterisk 13.24.0 you don't receive any MWI notifys > when a new voicemail got recorded. (tested with Yealink phones) > > Yesterday, ASTERISK-28215 has been opened and already closed today, but > as i don't know how long we have to wait for a new release, i've added > a patch to telephony/asterisk to temp fix this. > > Tested on amd64 (notifys are working again) Thanks, committed (plus comment header to show where the patch came from).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/12/20 10:02:24 Modified files: telephony/asterisk: Makefile Added files: telephony/asterisk/patches: patch-apps_app_voicemail_c Log message: Fix MWI for voicemail in asterisk; patch from upstream via Mark Patruck https://issues.asterisk.org/jira/browse/ASTERISK-28215
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/12/20 08:57:16 Modified files: databases/sqlports/files: Sql.pm Log message: a bit more fluff
cad/qucs (was: Re: sparc64 bulk build report)
On 2018-12-19, lan...@openbsd.org wrote: > http://build-failures.rhaalovely.net//sparc64/2018-12-09/cad/qucs.log gcc 6.4 fails even earlier with a similar ambiguity regarding pow(). This port should really be updated to the latest upstream version based on a newer Qt before anybody bothers with the details of support across various C++ compilers. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/12/20 08:10:13 Modified files: databases/sqlports/files: Inserter.pm Sql.pm Log message: Tweak table/view creation so that it will be able to use the new nicer way once it's ready
[devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi all, Recently, I've noticed an odd-looking output from weekly(8): Rebuilding whatis databases: makewhatis: man7/cmake-properties.7: ERROR: No such file or directory "Strange", I thought, especially since /usr/local/man/man7/cmake-properties.7 is "alive" and well: $ ls -l /usr/local/man/man7/cmake-properties.7 -rw-r--r-- 1 root bin 202877 Dec 20 14:00 /usr/local/man/man7/cmake-properties.7 I've rebuilt the mandoc.db and got an output which was stranger still: makewhatis: man7/cmake-properties.7: ERROR: No such file or directory /usr/local/man//man7/cmake-properties.7: Adding to database Huh!? Time for 'mandoc -Tlint': $ mandoc -Tlint /usr/local/man/man7/cmake-properties.7 | head mandoc: /usr/local/man/man7/cmake-properties.7:1131:2: WARNING: .so is fragile, better use ln(1): so libraries. mandoc: /usr/local/man/man7/cmake-properties.7: ERROR: No such file or directory mandoc: /usr/local/man/man7/cmake-properties.7:1131:15: ERROR: .so request failed: .so libraries. [...] OK, let's see what on that line: $ sed -n 1131p /usr/local/man/man7/cmake-properties.7 .so libraries. and including preceding line: Set the Android property that specifies directories to search for the .so libraries. Right, so '.so' (unintentional pun) is treated as a macro here - moving it to the line above, fixes the issue: Set the Android property that specifies directories to search for the .so libraries. Upstream uses reStructuredText but I hope this[0] does the trick. [0] https://gitlab.kitware.com/cmake/cmake/merge_requests/2756 Anyway, thought this might be of interest. Cheers, Raf
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2018/12/20 07:13:17 Modified files: security/keybase: Makefile distinfo Log message: Update for Keybase to 2.11.0 OK abieber@ (maintainer)
Re: [NEW] devel/py-wurlitzer 1.0.2
Sorry for pinging, I forgot to add: A issue has been opened in upstream's github about this 16 days ago, no reply until now: https://github.com/minrk/wurlitzer/issues/23 Just to see if they have a more python-sided way of handling this. Cheers. Elias. On Wed, Dec 19, 2018 at 11:02 AM Elias M. Mariani wrote: > > https://github.com/minrk/wurlitzer > https://pypi.org/project/wurlitzer/ > > Capture C-level stdout/stderr pipes in Python via os.dup2. > > This package is required to update devel/spyder/py-spyder-kernels and > devel/spyder/spyder. > > Taking Maintainership. > > > A weird patch has to be made in order to make this package to work properly: > The original script calls to the function fflush from libc with a > parameter to stdout or stderr, for that a pointer is needed. > In linux: > c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') > > But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an > array of FILE structs called __sF, where __sF[1] corresponds to stdout > and __sF[2] to stderr. > > So in order to bring this array to python we need to know the length > of FILE, create an array and then get a pointer for the elements 1 and > 2 of that array. > > The main problem is to get the length of FILE, is 152 bytes in amd64, > and 88 bytes in i386, no idea in other platforms, but given that this > lengths can change, hardcoding this numbers is ugly and bad... > > That's why I added a small C code and a sh script to get the > sizeof(__sF[1]) and passing that value to sed to then patch the python > script. > > Maybe there is a better way of handling the issue, I don't see it... > My only doubt is that libc is used by the package inside the python > script, and if the size of FILE changes, the package should be rebuilt > to refresh the value of the given size. > Should I add libc as a WANTLIB ? > > > Cheers. > Elias.
Re: NEW: security/ossec-hids
On Wed, Dec 19, 2018 at 01:19:31AM +, Stuart Henderson wrote: > On 2018/12/12 10:45, Paul Irofti wrote: > > Hi, > > > > Here is an updated port that I would like to import. > > > > This contains many fixes, mostly permissions tweaking but also an rc > > script, and wrappers for the inotify fiasco. It has been tested in > > production since before release and all seems to be running fine. > > > > OK? > > The wrappers fail to install for me (permission denied). But they > shouldn't really be necessary anyway - does the attached version work > for you? It uses -Wl,-rpath to hopefully fix up library paths instead, > and I passed CFLAGS across (you successfully removed upstreams > hardcoded values but didn't use ports ones, so it was building > without any -O flags). > > The UIDs need an update to free spots in infrastructure/db/user.list. > I haven't done that in the attached file to ease your testing, but > that will need doing before commit. > > (There are some other tweaks to make - hardcoded /usr/local in a couple > of places, and I think some chunks of patch are probably not needed - > but I don't think those are blockers and can be done after it's in tree). Hi Stuart, Thank you very much for the fixes. I have updated the tarbal you sent to include the necessary PLIST changes: removing the wrappers and updating the user and group IDs. Here is also a patch for the user.list Is it ok to import the port now? I will take care of the rest of the fixes suggested by you and Dan afterwards. Thanks, Paul Index: infrastructure/db/user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.334 diff -u -p -u -p -r1.334 user.list --- infrastructure/db/user.list 18 Dec 2018 19:28:52 - 1.334 +++ infrastructure/db/user.list 20 Dec 2018 12:59:44 - @@ -335,3 +335,6 @@ id usergroup port options 824 _traccar _traccargeo/traccar 825 _go-ipfs _go-ipfsnet/go-ipfs 826 _telegraf _telegraf sysutils/telegraf +827 _ossec _ossec security/ossec-hids +828 _ossecm_ossec security/ossec-hids +829 _ossecr_ossec security/ossec-hids ossec-hids.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/12/20 05:13:01 Modified files: databases/sqlports/files: Sql.pm Log message: make table aliases global, but trigger them later add "prepend" so that we can more easily tweak tables/views from both sides
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/12/20 05:01:52 Modified files: databases/xapian-bindings: Makefile Log message: Use python3 FLAVOR for dependencies. ok robert@
Re: CVS: cvs.openbsd.org: ports
Yes, that's exactly why the text got that bad format. Already talked with danj@ about it, next time I will follow the advice of just adding the message at the top. On Thu, Dec 20, 2018 at 4:46 AM Stuart Henderson wrote: > > On 2018/12/19 16:51, Elias M. Mariani wrote: > > CVSROOT: /cvs > > Module name: ports > > Changes by: mari...@cvs.openbsd.org 2018/12/19 16:51:57 > > > > Modified files: > > geo/openbsd-developers: Makefile Makefile files/OpenBSD Added > > myself to the list. OK danj@ > > geo/openbsd-developers/files: OpenBSD Makefile files/OpenBSD > > Added myself to the list. OK danj@ > > > > Log message: > > > > > > I think you removed "CVS:" prefix from the "Modified files" line and > added your commit message below. Don't do that :) Just add your message > at the top and leave the "CVS:" lines alone. >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2018/12/20 03:01:18 Modified files: mail/kopano/core: Makefile mail/kopano/core/patches: patch-common_platform_linux_cpp patch-configure_ac Log message: remove dep on lang/python/2.7,-bsddb and avoid using libexecinfo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2018/12/20 02:59:26 Modified files: databases/xapian-bindings: Makefile databases/xapian-bindings/pkg: PLIST-python PLIST-ruby Added files: databases/xapian-bindings/patches: patch-python3_Makefile_in Removed files: databases/xapian-bindings/patches: patch-python_Makefile_in Log message: move the python subpackage to python 3 as this is only used by kopano which is using python 3 already update plist of the ruby subpackage while here
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2018/12/20 01:29:04 Modified files: fonts : Makefile Log message: +mada
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2018/12/20 01:28:24 Log message: Import mada-1.3. Mada is a modernist, low-contrast Arabic typeface based largely on the typeface seen in Cairo metro old signage which was designed by Professor Fathi Gouda of Faculty of Applied Arts, Helwan University. Mada is characterised by low descenders, open contours and low-contrast forms making it suitable for small point sizes, user interfaces, signage or low resolution settings. Mada can work also as a display typeface giving modernist and simplistic feeling. Mada comes in 7 weights (ExtraLight, Light, Regular, Medium, SemiBold, Bold and Black), as well as an interpolatable variable font that can provide any intermediate weight on the fly. ok sthen@ From George Rosamond; thanks! Status: Vendor Tag: bentley Release Tags: bentley_20181220 N ports/fonts/mada/Makefile N ports/fonts/mada/distinfo N ports/fonts/mada/pkg/DESCR N ports/fonts/mada/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2018/12/20 01:19:31 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm net: Makefile Removed files: net/openafs/files: krb5.conf openafs-setup param.i386_obsd.h net/openafs/patches: patch-Makefile_in patch-src_afs_OBSD_osi_misc_c patch-src_afs_OBSD_osi_vfsops_c patch-src_afs_VNOPS_afs_vnop_lookup_c patch-src_afs_afs_osi_c patch-src_afs_afs_server_c patch-src_cf_osconf_m4 patch-src_comerr_error_table_y patch-src_config_afs_sysnames_h patch-src_gtx_curseswindows_c patch-src_kauth_Makefile_in patch-src_lwp_lwp_h patch-src_ptserver_map_c patch-src_ptserver_ptprocs_c patch-src_rx_rx_getaddr_c patch-src_sys_rmtsysc_c patch-src_ubik_utst_client_c patch-src_ubik_utst_server_c net/openafs/pkg: DESCR PLIST README Log message: Remove openafs Broken on i386 due to clang switch and was only for arch i386. ok todd@ naddy@
