Re: retire some python 2 ports

[Bryan Linton]

On 2024-02-17 11:51:05, Daniel Dickman  wrote:
> I would like to propose retiring these Python 2 ports:
> 
>   mail/archivemail
> 

FWIW, I use archivemail semi-regularly (3-4 times a year, to
compact and archive old mail out of my MBOXes), but if its
continued presence in the ports tree is holding back further
development, I can easily find a new tool to do what I need (or
maintain a locally-installed copy of archivemail).

-- 
Bryan

Re: Ping: [update patch] ledger v3.1.3 -> v3.2.1

[Bryan Linton]

Hello,

I tested your patch with my setup and everything works OK for me.

* Balances
* Budgets
* Commodities
* Multiple-file inclusion

All of the above work OK.

I don't know if it's too late to get in for 6.8 because of the
ports lock, but whether it goes in now or later, I didn't see any
regressions for any of my use cases.

-- 
Bryan

On 2020-09-28 14:55:05, Martin Ziemer  wrote:
> I hope, i am not too late, but i would really like to see the bug in
> ledger fixed for next -stable. (I run 3.2.1 since Aug 25 on all my four 
> amd64 machines with no problems and before there were the crashes mentioned
> in github as #1850)
> 
> On Wed, Sep 09, 2020 at 10:57:04AM +0200, Martin Ziemer wrote:
> > On Tue, Aug 25, 2020 at 12:29:26PM +0200, Martin Ziemer wrote:
> > > On Tue, Aug 25, 2020 at 10:06:29AM +0100, Stuart Henderson wrote:
> > > > On 2020/08/25 10:56, Martin Ziemer wrote:
> > > > > This patch updates ledger from v3.1.3 to v3.2.1
> > > >
> > > > > +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> > > >   ^
> > > > please mind spaces vs tabs
> > > I changed the spaces to tabs in the diff below.
> > >
> > > > Otherwise OK with me (I don't use this though so can't do any meaningful
> > > > testing).
> > > Testing is in my case using my private ledger, which has around 9000
> > > entries as of today. I have also some scripts, which interact with ledger.
> > 
> > Since the mail from 2020-08-25 there was no feedback from the
> > maintainer.
> > 
> > I used the new version since then on three amd64 systems at least every
> > second day. (One system each day)
> > 
> > I would really like to get the new version in, as it fixes some
> > regexp-based segfaults in our current version (bug #1850 in github).
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/productivity/ledger/Makefile,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 Makefile
> --- Makefile  22 Dec 2019 16:05:42 -  1.28
> +++ Makefile  25 Aug 2020 09:12:19 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT =command line double-entry accounting ledger
>  
> -GH_TAGNAME = v3.1.3
> +GH_TAGNAME = v3.2.1
>  GH_ACCOUNT = ledger
>  GH_PROJECT = ledger
>  
> @@ -23,6 +23,7 @@ WANTLIB += c gmp icuuc m mpfr pthread ${
>  
>  MODULES =devel/cmake \
>   lang/python
> +MODPY_VERSION =  ${MODPY_DEFAULT_VERSION_3}
>  COMPILER =   base-clang ports-gcc
>  
>  BUILD_DEPENDS =  devel/utfcpp
> @@ -57,7 +58,5 @@ post-install:
>  .for d in LICENSE.md doc/GLOSSARY.md
>   ${INSTALL_DATA} ${WRKSRC}/$d ${PREFIX}/share/doc/ledger/
>  .endfor
> - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/ledger
> - cd ${WRKSRC}/contrib && umask 022 && pax -rw . 
> ${PREFIX}/share/examples/ledger
>  
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/productivity/ledger/distinfo,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 distinfo
> --- distinfo  22 Dec 2019 16:05:42 -  1.7
> +++ distinfo  25 Aug 2020 09:12:19 -
> @@ -1,2 +1,2 @@
> -SHA256 (ledger-3.1.3.tar.gz) = skjJHWXHoQG51iJgJfK0vz2r6UwMSattUc6Eoio5Yis=
> -SIZE (ledger-3.1.3.tar.gz) = 800880
> +SHA256 (ledger-3.2.1.tar.gz) = kr8JvDhbFxmH9Fb+Pun6mY7V5AuXs6zdVitmOqNkOEo=
> +SIZE (ledger-3.2.1.tar.gz) = 790959
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/productivity/ledger/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 PLIST
> --- pkg/PLIST 22 Dec 2019 16:05:42 -  1.5
> +++ pkg/PLIST 25 Aug 2020 09:12:19 -
> @@ -65,73 +65,3 @@ info/ledger3.info
>  share/doc/ledger/
>  share/doc/ledger/GLOSSARY.md
>  share/doc/ledger/LICENSE.md
> -share/examples/ledger/
> -share/examples/ledger/CSVReader.cs
> -share/examples/ledger/Makefile
> -share/examples/ledger/ParseCcStmt.cs
> -share/examples/ledger/README
> -share/examples/ledger/bal
> -share/examples/ledger/bal-huquq
> -share/examples/ledger/compilation-ledger.el
> -share/examples/ledger/entry
> -share/examples/ledger/getquote-uk.py
> -share/examples/ledger/getquote.pl
> -share/examples/ledger/iso4127-commodities/
> -share/examples/ledger/iso4127-commodities/iso4217ledger.sh
> -share/examples/ledger/iso4127-commodities/iso4217ledger.xsl
> -share/examples/ledger/ledger-completion.bash
> -share/examples/ledger/ledger-du
> -share/examples/ledger/non-profit-audit-reports/
> -share/examples/ledger/non-profit-audit-reports/GPLv3
> -share/examples/ledger/non-profit-audit-reports/LICENSE
> -share/examples/ledger/non-profit-audit-reports/README
> -share/examples/ledger/non-profit-audit-reports/bank-reconcilation.plx
> -share/examples/ledger/non-profit-audit-reports/cash-receipts-and-disbursments-journals.plx
> -share/examples/ledger/non-profit-audit-reports/csv2ods.py
> 

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

3-week ping.

Patch re-attached for convenience.

It updates anthy from a decade-old release to one released from
last year.

In brief:

o Update anthy to newer version.
o Update master site.
o Update licence markers.
o Remove unneeded patch.
o Fix typo in DESCR.
o Users may need to switch uim to use UTF-8 because of
internal changes in anthy.

Any users who type in Japanese are encouraged to test.

Please let me know if any issues or regressions are spotted.

Thank you.

-- 
Bryan

On 2020-02-03 18:06:16, Bryan Linton  wrote:
> Ping.
> 
> I know there are likely not many people on ports@ who use this
> port, and it would have an impact on all users who use Japanese
> input if anything went wrong with it.  Both of which would suggest
> it get wider testing before being committed,
> 
> But because of the somewhat niche nature of this port, I'm not
> sure how to get wider testing.
> 
> If there's any way I can help move forward with this, please let
> me know.
> 
> I have another diff to anthy which changes its config directory to
> help with unveil(2) and Firefox compatibility, but I'd rather not
> combine an update to a 10-year-newer version with one that also
> makes changes to its internals like this.
> 
> However, if it would be preferred to do both at once, I can send a
> diff containing both the update and the config directory changes
> as well.
> 
> Previous diff re-attached for convenience.
> 
> -- 
> Bryan
> 
> On 2020-01-23 21:05:58, Bryan Linton  wrote:
> > On 2020-01-20 16:20:00, Omar Polo  wrote:
> > > Bryan, sorry for the double email, as always I forgot to CC ports.
> > > 
> > > On Sun, Jan 19, 2020 at 10:48:18AM +0900, Bryan Linton wrote:
> > > > On 2020-01-18 13:16:58, Omar Polo  wrote:
> > > > > Hi,
> > > > > 
> > > > > Thanks for working on this!  It compiles here, but I cannot judge
> > > > > the quality of the patch. Some comments after a bit of testing with
> > > > > inputmethod/uim:
> > > > >
> > > 
> > > Another thing that I've noticed, the description for anthy says
> > > 
> > >   With its complement package anthy-emacs, [...]
> > > 
> > > but here the package is emacs-anthy:
> > > 
> > >   $ pkg_info | grep emacs-anthy
> > >   emacs-anthy-0.4p4   emacs files for anthy
> > > 
> > > (patch below)
> > > 
> > 
> > Good catch!  Updated version of port attached.
> > 
> > -- 
> > Bryan
> > 
> 

Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 -  1.25
+++ Makefile21 Jan 2020 11:23:17 -
@@ -3,12 +3,14 @@
 COMMENT-main = japanese input method
 COMMENT-emacs =emacs files for anthy
 
-V =9100h
-DISTNAME = anthy-$V
+V =0.4
+DISTNAME = anthy_$V.orig
+WRKDIST =  ${WRKDIR}/anthy-$V
 PKGNAME-main = anthy-$V
 PKGNAME-emacs =emacs-anthy-$V
-REVISION-main = 2
-REVISION-emacs = 4
+REVISION-main = 0
+REVISION-emacs = 0
+EPOCH =0
 
 SHARED_LIBS += anthydic 1.0  # .1.0
 SHARED_LIBS += anthy1.0  # .1.0
@@ -16,14 +18,14 @@
 
 CATEGORIES =   inputmethods japanese
 
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
 
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
 PERMIT_PACKAGE =   Yes
 
 WANTLIB-main = c m
 
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
 
 FAKE_FLAGS =   sysconfdir=$(PREFIX)/share/examples/anthy
 
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 -  1.5
+++ distinfo21 Jan 2020 11:23:17 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
 src-util/anthy.el.orig Sat Nov 30 10:40:43 2

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

Ping.

I know there are likely not many people on ports@ who use this
port, and it would have an impact on all users who use Japanese
input if anything went wrong with it.  Both of which would suggest
it get wider testing before being committed,

But because of the somewhat niche nature of this port, I'm not
sure how to get wider testing.

If there's any way I can help move forward with this, please let
me know.

I have another diff to anthy which changes its config directory to
help with unveil(2) and Firefox compatibility, but I'd rather not
combine an update to a 10-year-newer version with one that also
makes changes to its internals like this.

However, if it would be preferred to do both at once, I can send a
diff containing both the update and the config directory changes
as well.

Previous diff re-attached for convenience.

-- 
Bryan

On 2020-01-23 21:05:58, Bryan Linton  wrote:
> On 2020-01-20 16:20:00, Omar Polo  wrote:
> > Bryan, sorry for the double email, as always I forgot to CC ports.
> > 
> > On Sun, Jan 19, 2020 at 10:48:18AM +0900, Bryan Linton wrote:
> > > On 2020-01-18 13:16:58, Omar Polo  wrote:
> > > > Hi,
> > > > 
> > > > Thanks for working on this!  It compiles here, but I cannot judge
> > > > the quality of the patch. Some comments after a bit of testing with
> > > > inputmethod/uim:
> > > >
> > 
> > Another thing that I've noticed, the description for anthy says
> > 
> > With its complement package anthy-emacs, [...]
> > 
> > but here the package is emacs-anthy:
> > 
> > $ pkg_info | grep emacs-anthy
> > emacs-anthy-0.4p4   emacs files for anthy
> > 
> > (patch below)
> > 
> 
> Good catch!  Updated version of port attached.
> 
> -- 
> Bryan
> 

Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 -  1.25
+++ Makefile21 Jan 2020 11:23:17 -
@@ -3,12 +3,14 @@
 COMMENT-main = japanese input method
 COMMENT-emacs =emacs files for anthy
 
-V =9100h
-DISTNAME = anthy-$V
+V =0.4
+DISTNAME = anthy_$V.orig
+WRKDIST =  ${WRKDIR}/anthy-$V
 PKGNAME-main = anthy-$V
 PKGNAME-emacs =emacs-anthy-$V
-REVISION-main = 2
-REVISION-emacs = 4
+REVISION-main = 0
+REVISION-emacs = 0
+EPOCH =0
 
 SHARED_LIBS += anthydic 1.0  # .1.0
 SHARED_LIBS += anthy1.0  # .1.0
@@ -16,14 +18,14 @@
 
 CATEGORIES =   inputmethods japanese
 
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
 
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
 PERMIT_PACKAGE =   Yes
 
 WANTLIB-main = c m
 
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
 
 FAKE_FLAGS =   sysconfdir=$(PREFIX)/share/examples/anthy
 
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 -  1.5
+++ distinfo21 Jan 2020 11:23:17 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
 src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
-+++ src-util/anthy.el  Sat Nov 30 10:40:55 2013
-@@ -892,7 +892,7 @@
-((event-matches-key-specifier-p event 'backspace) 8)
-(t
- (char-to-int (event-to-character event)
--last-command-char))
-+last-command-event))
- 
- ;;
- ;;
Index: pkg/DESCR-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/DESCR-main,v
retrieving revision 1.1
diff -u -r1.1 DESCR-main
--- pkg/DESCR-main  21 Nov 2006 00:12:40 -  1.1
+++ pkg/DESCR-main  21 Jan 2020 11:23:17 -
@@ -1,7 +1,7 @@
 Anthy is a japanese input method library that can be used
 from many setups.
 
-With its complement package anthy-emacs, it can be used with
+With its complement package emacs-anthy, it can be used with
 emacs, using the simple anthy-agent wedge for communication.
 
 It can also be acces

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

On 2020-01-20 16:20:00, Omar Polo  wrote:
> Bryan, sorry for the double email, as always I forgot to CC ports.
> 
> On Sun, Jan 19, 2020 at 10:48:18AM +0900, Bryan Linton wrote:
> > On 2020-01-18 13:16:58, Omar Polo  wrote:
> > > Hi,
> > > 
> > > Thanks for working on this!  It compiles here, but I cannot judge
> > > the quality of the patch. Some comments after a bit of testing with
> > > inputmethod/uim:
> > >
> 
> Another thing that I've noticed, the description for anthy says
> 
>   With its complement package anthy-emacs, [...]
> 
> but here the package is emacs-anthy:
> 
>   $ pkg_info | grep emacs-anthy
>   emacs-anthy-0.4p4   emacs files for anthy
> 
> (patch below)
> 

Good catch!  Updated version of port attached.

-- 
Bryan

Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 -  1.25
+++ Makefile21 Jan 2020 11:23:17 -
@@ -3,12 +3,14 @@
 COMMENT-main = japanese input method
 COMMENT-emacs =emacs files for anthy
 
-V =9100h
-DISTNAME = anthy-$V
+V =0.4
+DISTNAME = anthy_$V.orig
+WRKDIST =  ${WRKDIR}/anthy-$V
 PKGNAME-main = anthy-$V
 PKGNAME-emacs =emacs-anthy-$V
-REVISION-main = 2
-REVISION-emacs = 4
+REVISION-main = 0
+REVISION-emacs = 0
+EPOCH =0
 
 SHARED_LIBS += anthydic 1.0  # .1.0
 SHARED_LIBS += anthy1.0  # .1.0
@@ -16,14 +18,14 @@
 
 CATEGORIES =   inputmethods japanese
 
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
 
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
 PERMIT_PACKAGE =   Yes
 
 WANTLIB-main = c m
 
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
 
 FAKE_FLAGS =   sysconfdir=$(PREFIX)/share/examples/anthy
 
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 -  1.5
+++ distinfo21 Jan 2020 11:23:17 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
 src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
-+++ src-util/anthy.el  Sat Nov 30 10:40:55 2013
-@@ -892,7 +892,7 @@
-((event-matches-key-specifier-p event 'backspace) 8)
-(t
- (char-to-int (event-to-character event)
--last-command-char))
-+last-command-event))
- 
- ;;
- ;;
Index: pkg/DESCR-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/DESCR-main,v
retrieving revision 1.1
diff -u -r1.1 DESCR-main
--- pkg/DESCR-main  21 Nov 2006 00:12:40 -  1.1
+++ pkg/DESCR-main  21 Jan 2020 11:23:17 -
@@ -1,7 +1,7 @@
 Anthy is a japanese input method library that can be used
 from many setups.
 
-With its complement package anthy-emacs, it can be used with
+With its complement package emacs-anthy, it can be used with
 emacs, using the simple anthy-agent wedge for communication.
 
 It can also be accessed from uim.
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
retrieving revision 1.5
diff -u -r1.5 PLIST-main
--- pkg/PLIST-main  22 May 2015 11:31:16 -  1.5
+++ pkg/PLIST-main  21 Jan 2020 11:23:17 -
@@ -2,18 +2,17 @@
 @pkgpath inputmethods/anthy
 @bin bin/anthy-agent
 @bin bin/anthy-dic-tool
-@bin bin/anthy-morphological-analyzer
 include/anthy/
 include/anthy/anthy.h
 include/anthy/dicutil.h
 include/anthy/input.h
-lib/libanthy.a
+@static-lib lib/libanthy.a
 lib/libanthy.la
 @lib lib/libanthy.so.${LIBanthy_VERSION}
-lib/libanthydic.a
+@static-lib lib/libanthydic.a
 lib/libanthydic.la
 @lib lib/libanthydic.so.${LIBanthydic_VERSION}
-lib/libanthyinput.a
+@static-lib lib/libanthyinput.a
 lib/libanthyinput.la
 @lib lib/libanthyinput.so.${LIBanthyinput_VERSION}
 lib/pkgconfig/anthy.pc

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

On 2020-01-19 14:16:34, Stuart Henderson  wrote:
> On 2020/01/09 23:34, Bryan Linton wrote:
> > Hello ports@
> > 
> > I was attempting to make some changes to inputmethods/anthy for
> > another purpose when I noticed it was woefully out of date.
> > 
> > [...]
> >
> > Questions:
> 
> I've not otherwise looked at it, but answering questions:
> 
> > * Is setting "DISTFILES = anthy_$V.orig.tar.gz" the best way to cope
> > with the naming of the tarball?
> 
> This is better:
> 
> V = 0.4
> DISTNAME =  anthy_$V.orig
> WRKDIST =   ${WRKDIR}/anthy-$V
> 
> > * Does the version changing from 9100h to 0.4 require setting EPOCH?
> > It seems to have updated fine on my system, but I don't know the
> > details of when EPOCH is needed.
> 
> Yes. EPOCH is needed whenever the version number goes "backwards"
> according to packages-specs(7) format.
> 

Thanks for the tips.  Updated patch attached.

Changes from previous patch
===
* Add EPOCH to cope with version change (9100h -> 0.4)

* Use DISTNAME and WRKDIST instead of DISTFILES.

-- 
Bryan

Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 -  1.25
+++ Makefile20 Jan 2020 10:24:51 -
@@ -3,12 +3,14 @@
 COMMENT-main = japanese input method
 COMMENT-emacs =emacs files for anthy
 
-V =9100h
-DISTNAME = anthy-$V
+V =0.4
+DISTNAME = anthy_$V.orig
+WRKDIST =  ${WRKDIR}/anthy-$V
 PKGNAME-main = anthy-$V
 PKGNAME-emacs =emacs-anthy-$V
-REVISION-main = 2
-REVISION-emacs = 4
+REVISION-main = 0
+REVISION-emacs = 0
+EPOCH =0
 
 SHARED_LIBS += anthydic 1.0  # .1.0
 SHARED_LIBS += anthy1.0  # .1.0
@@ -16,14 +18,14 @@
 
 CATEGORIES =   inputmethods japanese
 
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
 
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
 PERMIT_PACKAGE =   Yes
 
 WANTLIB-main = c m
 
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
 
 FAKE_FLAGS =   sysconfdir=$(PREFIX)/share/examples/anthy
 
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 -  1.5
+++ distinfo20 Jan 2020 10:24:51 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
 src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
-+++ src-util/anthy.el  Sat Nov 30 10:40:55 2013
-@@ -892,7 +892,7 @@
-((event-matches-key-specifier-p event 'backspace) 8)
-(t
- (char-to-int (event-to-character event)
--last-command-char))
-+last-command-event))
- 
- ;;
- ;;
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
retrieving revision 1.5
diff -u -r1.5 PLIST-main
--- pkg/PLIST-main  22 May 2015 11:31:16 -  1.5
+++ pkg/PLIST-main  20 Jan 2020 10:24:51 -
@@ -2,18 +2,17 @@
 @pkgpath inputmethods/anthy
 @bin bin/anthy-agent
 @bin bin/anthy-dic-tool
-@bin bin/anthy-morphological-analyzer
 include/anthy/
 include/anthy/anthy.h
 include/anthy/dicutil.h
 include/anthy/input.h
-lib/libanthy.a
+@static-lib lib/libanthy.a
 lib/libanthy.la
 @lib lib/libanthy.so.${LIBanthy_VERSION}
-lib/libanthydic.a
+@static-lib lib/libanthydic.a
 lib/libanthydic.la
 @lib lib/libanthydic.so.${LIBanthydic_VERSION}
-lib/libanthyinput.a
+@static-lib lib/libanthyinput.a
 lib/libanthyinput.la
 @lib lib/libanthyinput.so.${LIBanthyinput_VERSION}
 lib/pkgconfig/anthy.pc

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

On 2020-01-18 13:16:58, Omar Polo  wrote:
> Hi,
> 
> On Thu, Jan 09, 2020 at 11:34:34PM +0900, Bryan Linton wrote:
> > Hello ports@
> > 
> > I was attempting to make some changes to inputmethods/anthy for
> > another purpose when I noticed it was woefully out of date.
> > 
> > Version 9100h was released in 2009.  Version 0.4 was released six
> > months ago (in 2019).
> > 
> > [snip]
> > 
> > Concerns:
> > 
> > * I have not tested the emacs module because I do not use emacs.  I
> > have however tested it in Firefox, leafpad, a Japanized xterm, and
> > editors/nvi running in said Japanized xterm.  More testing would
> > be appreciated though.
> 
> Thanks for working on this!  It compiles here, but I cannot judge
> the quality of the patch. Some comments after a bit of testing with
> inputmethod/uim:
>

Hello, thank you for testing!  Some comments follow inline.

>  - firefox (and possibly other programs) need some directories to
>be unveiled [0]. 
>

Yes, I was the one who sent that email too :)

It's not specific to this update though.  Even the old version of
anthy would need those directories unveiled.

I have another update to anthy that switches it to using a common
directory in line with what Theo suggested later in that thread.  But
I wanted to hopefully get this update in-tree before going forward
with that.

>  - with gajim (gtk3) and emacs (gtk3) works as expected
>

Great, thanks!  This was the one use-case I couldn't test myself
since I don't use emacs.

>  - xterm and emacs (compiled with the lucid toolkit) sort of.  While
>typing, the characters are displayed as rectangles (similarly
>to when a font is missing), but after pressing enter the whole
>word is displayed properly.  Also, the selection box does not
>appear in these programs (but these probably are issues with uim
>rather than anthy.)
> 

Yes, this definitely sounds like a uim issue.  To be clear, is
this a regression?  I.e. Did this work OK before, but broke with
this update?

Also as a follow-up, can you check whether you're using the
"Anthy" or the "Anthy (UTF-8)" input method in UIM?  If it's the
former, does it fix this if you switch it to UTF-8?

As I mentioned in the initial email, the internals of anthy have
switched to be completely UTF-8.  If you're using the old input
method, does switching to "Anthy (UTF-8)" in uim fix this?

Failing that, does running xterm with the script I've pasted in
below fix this?

> (note that I used emacs with the x input method, just like with
> firefox and gajim, not with uim.el)
> 
> With ibus the situation is a bit different: it recognize anthy, but
> it does not seems to work.  You can switch the input method, but
> nothing more.  Again, this might be simply a problem with ibus
> and/or my setup.
> 

I saw your followup email that this works OK, which is good to
know!

> P.S. I'm curious, what do you mean with "japanized xterm"?
> 

I use the following script to launch xterm when I want to use
Japanese in it.  I'm not sure if the line running uim-xim is
needed anymore, since I now launch uim from my .xsession file, but
the second line sets the locale to Japanese and changes the font
to a Japanese one.

-8<-
% cat bin/jxterm.sh
#!/bin/sh

env LC_CTYPE=ja_JP.UTF-8 uim-xim &
env LC_ALL=ja_JP.UTF-8 xterm -fa "Sazanami Gothic" -fs 16 $1

# Keep messages in English
#env LANG=ja_JP.UTF-8 LC_MESSAGES=en_US.UTF-8 xterm -fa "Sazanami Gothic" -fs 16

-8<-

This not only lets me see Japanese text displayed in xterm, but
sets any programs I run in it to be "Japanese" for lack of a
better way of explaining it.

I.e. in a normal xterm, when I run mutt the top line is:
q:Quit  d:Del  u:Undel  s:Save  m:Mail  r:Reply  g:Group ?:Help

However when I run it in a "Japanized" xterm (with LC_ALL set to
Japanese), the top line is instead:
q:中止  d:削除 u:削除を取り消し s:保存 m:メール r:返信 g:全員に返信 ?:ヘルプ
and all other messages are displayed in Japanese instead of
English.

The third line would retain messages in English instead of
localizing them as above.

Anyway, thank you again for testing!

-- 
Bryan


> [0] https://marc.info/?l=openbsd-ports=157811336612326=2
> 
> > * The IM I use on top of anthy (inputmethods/uim) produced utter
> > gibberish until I realized that I needed to switch it from "Anthy"
> > to "Anthy (UTF-8).  A note in current.html like the attached
> > should probably be added so that users have a smoother upgrade
> > path.
> > 
> > 
> > Please let me know if I can make any other improvements to the port.
> > 
> > Thank you!
> > 
> > -- 
> > Bryan
> > 
&g

Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

ping.

If you use OpenBSD to write any kind of Japanese text, odds are
you're using this port.

If so, please test and let me know if anything has broken.

Thanks.

-- 
Bryan

On 2020-01-09 23:34:34, Bryan Linton  wrote:
> Hello ports@
> 
> I was attempting to make some changes to inputmethods/anthy for
> another purpose when I noticed it was woefully out of date.
> 
> Version 9100h was released in 2009.  Version 0.4 was released six
> months ago (in 2019).
> 
> 
> Notable changes to the port:
> 
> * Old upstream is dead (no updates to website since 2004).  Switch
> to the Debian Anthy team since they have become the new upstream.
> 
> * Update licence marker to show it's now a mix of GPLv3, LGPLv3,
> and LGPLv2.
> 
> * Remove unneeded patch.
> 
> * All internal functions and dictionaries have been switched to
> use UTF-8 by default (instead of EUC-JP).  Users must switch their
> IMs to use the UTF-8 version of Anthy or they will produce only
> gibberish on output.
> 
> 
> Questions:
> 
> * Is setting "DISTFILES = anthy_$V.orig.tar.gz" the best way to cope
> with the naming of the tarball?
> 
> * Does the version changing from 9100h to 0.4 require setting EPOCH?
> It seems to have updated fine on my system, but I don't know the
> details of when EPOCH is needed.
> 
> 
> Concerns:
> 
> * I have not tested the emacs module because I do not use emacs.  I
> have however tested it in Firefox, leafpad, a Japanized xterm, and
> editors/nvi running in said Japanized xterm.  More testing would
> be appreciated though.
> 
> * The IM I use on top of anthy (inputmethods/uim) produced utter
> gibberish until I realized that I needed to switch it from "Anthy"
> to "Anthy (UTF-8).  A note in current.html like the attached
> should probably be added so that users have a smoother upgrade
> path.
> 
> 
> Please let me know if I can make any other improvements to the port.
> 
> Thank you!
> 
> -- 
> Bryan
> 

> Index: Makefile
> ===
> RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
> retrieving revision 1.25
> diff -u -r1.25 Makefile
> --- Makefile  12 Jul 2019 20:47:12 -  1.25
> +++ Makefile  9 Jan 2020 14:25:29 -
> @@ -3,8 +3,9 @@
>  COMMENT-main =   japanese input method
>  COMMENT-emacs =  emacs files for anthy
>  
> -V =  9100h
> +V =  0.4
>  DISTNAME =   anthy-$V
> +DISTFILES =  anthy_$V.orig.tar.gz
>  PKGNAME-main =   anthy-$V
>  PKGNAME-emacs =  emacs-anthy-$V
>  REVISION-main = 2
> @@ -16,14 +17,14 @@
>  
>  CATEGORIES = inputmethods japanese
>  
> -HOMEPAGE =   https://anthy.osdn.jp/
> +HOMEPAGE =   https://wiki.debian.org/Teams/DebianAnthy
>  
> -# GPL, part LGPL
> +# GPLv3, parts are LGPLv3 and/or LGPLv2+
>  PERMIT_PACKAGE = Yes
>  
>  WANTLIB-main =   c m
>  
> -MASTER_SITES =   ${MASTER_SITE_OSDN_JP:=anthy/37536/}
> +MASTER_SITES =   http://deb.debian.org/debian/pool/main/a/anthy/
>  
>  FAKE_FLAGS = sysconfdir=$(PREFIX)/share/examples/anthy
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
> retrieving revision 1.5
> diff -u -r1.5 distinfo
> --- distinfo  18 Jan 2015 03:14:16 -  1.5
> +++ distinfo  9 Jan 2020 14:25:29 -
> @@ -1,2 +1,2 @@
> -SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
> -SIZE (anthy-9100h.tar.gz) = 4446148
> +SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
> +SIZE (anthy_0.4.orig.tar.gz) = 5619024
> Index: patches/patch-src-util_anthy_el
> ===
> RCS file: patches/patch-src-util_anthy_el
> diff -N patches/patch-src-util_anthy_el
> --- patches/patch-src-util_anthy_el   7 Dec 2013 23:42:04 -   1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,12 +0,0 @@
> -$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
>  src-util/anthy.el.orig   Sat Nov 30 10:40:43 2013
> -+++ src-util/anthy.elSat Nov 30 10:40:55 2013
> -@@ -892,7 +892,7 @@
> -  ((event-matches-key-specifier-p event 'backspace) 8)
> -  (t
> -   (char-to-int (event-to-character event)
> --last-command-char))
> -+last-command-event))
> - 
> - ;;
> - ;;
> Index: pkg/PLIST-main
> ===
> RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
> retrieving revision 1.5
> diff -u -r1.5 PLIST-main
> --- pkg/PLIST-main22 May 2015 11:31:16 -   

[PATCH] Update inputmethods/anthy from 9100 to 0.4

[Bryan Linton]

Hello ports@

I was attempting to make some changes to inputmethods/anthy for
another purpose when I noticed it was woefully out of date.

Version 9100h was released in 2009.  Version 0.4 was released six
months ago (in 2019).


Notable changes to the port:

* Old upstream is dead (no updates to website since 2004).  Switch
to the Debian Anthy team since they have become the new upstream.

* Update licence marker to show it's now a mix of GPLv3, LGPLv3,
and LGPLv2.

* Remove unneeded patch.

* All internal functions and dictionaries have been switched to
use UTF-8 by default (instead of EUC-JP).  Users must switch their
IMs to use the UTF-8 version of Anthy or they will produce only
gibberish on output.


Questions:

* Is setting "DISTFILES = anthy_$V.orig.tar.gz" the best way to cope
with the naming of the tarball?

* Does the version changing from 9100h to 0.4 require setting EPOCH?
It seems to have updated fine on my system, but I don't know the
details of when EPOCH is needed.


Concerns:

* I have not tested the emacs module because I do not use emacs.  I
have however tested it in Firefox, leafpad, a Japanized xterm, and
editors/nvi running in said Japanized xterm.  More testing would
be appreciated though.

* The IM I use on top of anthy (inputmethods/uim) produced utter
gibberish until I realized that I needed to switch it from "Anthy"
to "Anthy (UTF-8).  A note in current.html like the attached
should probably be added so that users have a smoother upgrade
path.


Please let me know if I can make any other improvements to the port.

Thank you!

-- 
Bryan

Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 -  1.25
+++ Makefile9 Jan 2020 14:25:29 -
@@ -3,8 +3,9 @@
 COMMENT-main = japanese input method
 COMMENT-emacs =emacs files for anthy
 
-V =9100h
+V =0.4
 DISTNAME = anthy-$V
+DISTFILES =anthy_$V.orig.tar.gz
 PKGNAME-main = anthy-$V
 PKGNAME-emacs =emacs-anthy-$V
 REVISION-main = 2
@@ -16,14 +17,14 @@
 
 CATEGORIES =   inputmethods japanese
 
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
 
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
 PERMIT_PACKAGE =   Yes
 
 WANTLIB-main = c m
 
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
 
 FAKE_FLAGS =   sysconfdir=$(PREFIX)/share/examples/anthy
 
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 -  1.5
+++ distinfo9 Jan 2020 14:25:29 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
 src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
-+++ src-util/anthy.el  Sat Nov 30 10:40:55 2013
-@@ -892,7 +892,7 @@
-((event-matches-key-specifier-p event 'backspace) 8)
-(t
- (char-to-int (event-to-character event)
--last-command-char))
-+last-command-event))
- 
- ;;
- ;;
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
retrieving revision 1.5
diff -u -r1.5 PLIST-main
--- pkg/PLIST-main  22 May 2015 11:31:16 -  1.5
+++ pkg/PLIST-main  9 Jan 2020 14:25:29 -
@@ -2,18 +2,17 @@
 @pkgpath inputmethods/anthy
 @bin bin/anthy-agent
 @bin bin/anthy-dic-tool
-@bin bin/anthy-morphological-analyzer
 include/anthy/
 include/anthy/anthy.h
 include/anthy/dicutil.h
 include/anthy/input.h
-lib/libanthy.a
+@static-lib lib/libanthy.a
 lib/libanthy.la
 @lib lib/libanthy.so.${LIBanthy_VERSION}
-lib/libanthydic.a
+@static-lib lib/libanthydic.a
 lib/libanthydic.la
 @lib lib/libanthydic.so.${LIBanthydic_VERSION}
-lib/libanthyinput.a
+@static-lib lib/libanthyinput.a
 lib/libanthyinput.la
 @lib lib/libanthyinput.so.${LIBanthyinput_VERSION}
 lib/pkgconfig/anthy.pc
Index: current.html
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.1017
diff -u -r1.1017 current.html
--- current.html31 Dec 2019 02:18:01 -  1.1017

[PATCH] Firefox - Fix Japanese input by expanding unveiled directories

[Bryan Linton]

Hello ports@

After upgrading to Firefox 71, I was no longer able to input
Japanese due to the newly-added unveil and pledge support.  After
some debugging, I found that adding the following lines to
/etc/firefox/unveil.main allowed me to input Japanese as usual.

-8<--
--- /usr/local/lib/firefox/browser/defaults/preferences/unveil.main Sat Dec 
21 15:08:23 2019
+++ /etc/firefox/unveil.mainFri Jan  3 12:25:53 2020
@@ -3,6 +3,12 @@
 /dev/video rw
 /dev/video0 rw
 
+# for launching the anthy input method from uim
+/etc/anthy-conf r
+~/.anthy r
+~/.tomoe r
+~/.uim.d r
+
 /etc/fonts r
 /etc/machine-id r
-8<--

However, this raises some interesting questions.  How far down
this path do we want to go?  The above patch enables the UIM+Anthy
combination to work again, but what about SCIM+Anthy?  Ibus+Anthy?
SCIM+Pinyin?  There are 26 ports in ports/inputmethods; do all of
them get added to unveil.main?

While I'm aware that adding every possible contingency to unveil
largely defeats its purpose, I'm also concerned that the
alternative would be users simply disabling pledge+unveil
entirely if they find that they can no longer input CJK text.

Which then brings us full circle to the security model of unveil
being defeated...

That being the case, perhaps adding a short blurb like the
following to Firefox's pkg-readme would be a better way to go.

-8<--
--- README  Sat Jan  4 11:22:21 2020
+++ README.new  Sat Jan  4 11:25:11 2020
@@ -28,6 +28,23 @@
 Each file can be overridden by copying it to ${SYSCONFDIR}/firefox/
 and modifying it.
 
+CJK IMEs
+
+Due to unveil(2) limiting filesystem access, CJK IMEs will not
+work with the default unveil permissions.  To enable the use of
+CJK IMEs, one must first identify which files in /etc and /home
+that the IME uses, and then add them to unveil.main by following
+the instructions in the above section.
+
+For example, the UIM+Anthy combination needs the following lines
+added to unveil.main:
+
+   # for launching the anthy input method from uim
+   /etc/anthy-conf r
+   ~/.anthy r
+   ~/.tomoe r
+   ~/.uim.d r
+
 3rd-Party MIME Handlers
 ===
 Due to unveil(2) limiting filesystem access, only the default MIME
-8<--

This would give users a hint of where and what to look for if they
find their IME no longer working, but would avoid going down the
rabbit hole of adding dozens upon dozens of exceptions to unveil.

Either way, I'm definitely grateful for all the work the
developers have put in to get pledge+unveil support added to
mainline Firefox.

Thank you for all the hard work!

-- 
Bryan

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2019-12-25 11:28:20, Jeremie Courreges-Anglas  wrote:
> On Tue, Dec 24 2019, Bryan Linton  wrote:
> > On 2019-12-22 09:05:42, Frederic Cambus  wrote:
> >> CVSROOT:   /cvs
> >> Module name:   ports
> >> Changes by:fcam...@cvs.openbsd.org 2019/12/22 09:05:42
> >> 
> >> Modified files:
> >>productivity/ledger: Makefile distinfo 
> >>productivity/ledger/patches: patch-src_CMakeLists_txt 
> >>productivity/ledger/pkg: PLIST 
> >> Removed files:
> >>productivity/ledger/patches: patch-src_item_h 
> >> 
> >> Log message:
> >> Update ledger to 3.1.3.
> >> 
> >> This fixes CVE-2017-2807, CVE-2017-2808, CVE-2017-12481, CVE-2017-12482.
> >> 
> >> OK jca@, Sergey Bronnikov (MAINTAINER)
> >> 
> >
> > This update causes ledger to segfault when processing commodities.
> >
> > I can reproduce this with a file consisting of the following
> > snippet from ledger's manual.
> >
> > -8<--
> >
> > 9/29  Get some stuff at the Inn
> > Places:Black's Tavern   -3 Apples
> > Places:Black's Tavern   -5 Steaks
> > EverQuest:Inventory
> >
> > -8<--
> >
> > To reproduce, simply copy the above 4 lines to a file and run
> > ledger.  E.g. "ledger --file test.txt balance"
> >
> > If I remove the commodities from my (much longer) journal, ledger
> > works fine when dealing with cash transactions so the bug must be
> > specific to commodities.
> >
> > Can anyone else reproduce this?
> 
> Using your testcase, nope:
> 
> --8<--
> ritchie ~/tmp$ ledger -f testcase  balance; echo "status: $?"; ledger 
> --version | head -n1
> 3 Apples
> 5 Steaks  EverQuest:Inventory
>-3 Apples
>-5 Steaks  Places:Black's Tavern
> 
>0
> status: 0
> Ledger 3.1.3-20190331, the command-line accounting tool
> -->8--
> 

It must have been a hiccup with my system then.

I updated packages again, removed old .libs-* packages, and
rebuilt ledger and now I can no longer reproduce it either.

Apologies for the false alarm.  And many thanks to the maintainers
of ledger for keeping it up to date!

-- 
Bryan

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2019-12-22 09:05:42, Frederic Cambus  wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   fcam...@cvs.openbsd.org 2019/12/22 09:05:42
> 
> Modified files:
>   productivity/ledger: Makefile distinfo 
>   productivity/ledger/patches: patch-src_CMakeLists_txt 
>   productivity/ledger/pkg: PLIST 
> Removed files:
>   productivity/ledger/patches: patch-src_item_h 
> 
> Log message:
> Update ledger to 3.1.3.
> 
> This fixes CVE-2017-2807, CVE-2017-2808, CVE-2017-12481, CVE-2017-12482.
> 
> OK jca@, Sergey Bronnikov (MAINTAINER)
> 

This update causes ledger to segfault when processing commodities.

I can reproduce this with a file consisting of the following
snippet from ledger's manual.

-8<--

9/29  Get some stuff at the Inn
Places:Black's Tavern   -3 Apples
Places:Black's Tavern   -5 Steaks
EverQuest:Inventory

-8<--

To reproduce, simply copy the above 4 lines to a file and run
ledger.  E.g. "ledger --file test.txt balance"

If I remove the commodities from my (much longer) journal, ledger
works fine when dealing with cash transactions so the bug must be
specific to commodities.

Can anyone else reproduce this?

Unfortunately, I don't see any commits in ledger's GitHub that
stand out as fixing this issue.  I do see several commits to
commodity handling in between the previous 3.1.1 release and the
current 3.1.3 release.  However, I don't currently have time to
attempt to bisect this.

Backtrace follows.

% sysctl kern.version
kern.version=OpenBSD 6.6-current (GENERIC.MP) #559: Sun Dec 22 23:03:43 MST 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

% ledger bal
zsh: segmentation fault (core dumped)  ledger bal

% egdb `which ledger` ledger.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/ledger...done.
[New process 605898]
Core was generated by `ledger'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00dbd4413389 in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::__deallocate_node (this=0xddd5619520, __np=0x2)
at /usr/include/c++/v1/__hash_table:1584
1584__next_pointer __next = __np->__next_;
(gdb) bt
#0  0x00dbd4413389 in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::__deallocate_node (this=0xddd5619520, __np=0x2)
at /usr/include/c++/v1/__hash_table:1584
#1  0x00dbd441332c in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::~__hash_table (this=0xddd5619520)
at /usr/include/c++/v1/__hash_table:1540
#2  0x00dbd44132cf in std::__1::unordered_map, 
std::__1::equal_to, 
std::__1::allocator > >::~unordered_map (this=0xddd5619520)
at /usr/include/c++/v1/unordered_map:842
#3  0x00dbd441328f in ledger::balance_t::~balance_t (this=0xddd5619520)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/balance.h:140
#4  0x00dbd4413144 in boost::checked_delete 
(x=0xddd5619520)
at /usr/local/include/boost/core/checked_delete.hpp:34
#5  0x00dbd44130b2 in ledger::value_t::storage_t::destroy 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:219
#6  0x00dbd4412ff6 in ledger::value_t::storage_t::~storage_t 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:172
#7  0x00dbd4412fa4 in boost::checked_delete (x=0xde5ab16300)
at /usr/local/include/boost/core/checked_delete.hpp:34
#8  0x00dbd4412f4c in ledger::value_t::storage_t::release 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:203
#9  0x00dbd4412eef in ledger::intrusive_ptr_release 
(storage_ptr=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:210
#10 0x00dbd4404977 in 
boost::intrusive_ptr::~intrusive_ptr (
this=0x7f7dc510) at 
/usr/local/include/boost/smart_ptr/intrusive_ptr.hpp:98
#11 0x00de062bcf76 in ledger::xact_base_t::finalize() () 

Re: New: The Dark Mod - a stealth game inspired by the Thief series, derived from Doom3 engine

[Bryan Linton]

On 2019-08-16 11:24:22, Thomas Frohwein  wrote:
> Hi,
> 
> I'm pleased to present a port of The Dark Mod, born out of
> modifications of the Doom 3 engine and designed to run user-/fan-
> created stealth game missions in the vein of the venerable Thief game
> series. Unlike Doom 3, the focus is on staying undetected and avoiding
> guards using stealth tools like the blackjack or water arrows.
> 
> It is visually very impressive and was awarded "Mod of the Year" by the
> PC Gamer magazine in 2013.
> 
> I've been working my way through boost and scons issues for about 1.5
> years until I got this to run with the 2.07 update.
> 
> I have played through some of the tutorial and most of the 1st training
> mission on my Skylake laptop (amdgpu is known buggy/defective in this
> version). I don't know if radeon works or not. A recording of my test
> session with The Dark Mod on OpenBSD is on YouTube:
> 
> https://www.youtube.com/watch?v=2xAR26RjYuU
> 
> Caveats/good to know:
> 
> - The game needs data files before starting it the first time. Run
> $ tdm_update
> first, before running thedarkmod. This downloads several GB of content;
> I think it was about 4GB.
> - It doesn't launch properly on amgpu - screen flickers, and eventually
> the game crashes. Upstream has released a hotfix, but only in binary
> form.
> - The config in $FILESDIR launches with fullscreen disabled because
> only windowed mode works on my install with cwm. I have received
> reports that fullscreen isn't an issue in another WM/DE (xfce IIRC).
> 
> Testing, feedback, and/or oks appreciated!
>

Hello,

Sorry for the delay in responding to this.

I tried out the game and it works well for me with only one
caveat.

What works:
o Sound plays smoothly.
o Full-screen works fine.
o I get reasonable performance on what would otherwise be
a somewhat dated system.  (A Thinkpad T440p with a Haswell 
i7-4800MQ, and "Intel HD Graphics 4600").

What doesn't work:
Remapping keys doesn't seem to persist between runs of the
game.  Changing any other settings in the game (Video,
sound, difficulty, etc.) are saved without problem, but
changing any of the default keys doesn't save between
sessions.

If I change any keys, they work fine for so long as I run
the game.  But if I quit the game and relaunch it, the
keys reset to their defaults.

I also noticed an odd thing where one action defaulted to
the semicolon key.  However, pressing it did not work.
Upon going into the settings UI to change it, I noticed it
was already being displayed as "semicolon" (I.e. the word
was spelled out).

When I remapped it to the semicolon again, the UI showed
"semicolon or ;" (I.e. It showed the word "semicolon"
spelled out in full, in addition to showing the symbol for
it).

AFAICT, the UI normally only does this when two different
keys are mapped to the same action.  E.g. If "Scroll
forward in inventory" were mapped to both "page up" and
"mouse-wheel forward" it would say, "Page up or mouse-wheel
forward".

I'm not really sure how to troubleshoot this, so if you have any
suggestions or patches I would be willing to test them.

Anyway, thank you again for bringing another game to OpenBSD!

-- 
Bryan

Re: UPDATE: devel/fox 1.6.50 => 1.6.57

[Bryan Linton]

On 2019-07-25 11:59:45, Brian Callahan  wrote:
> Hi Marc and ports --
> 
> Attached is a small update to devel/fox, updating it from the 5+ year old
> version we have.
> 

I've updated and rebuilt devel/fox with your patch and x11/xfe
still works fine on amd64.

No regressions seen so far.

-- 
Bryan

Re: NEW: audio/timgm6mb && make timidity and sdl{,2}-mixer use it

[Bryan Linton]

On 2019-05-15 10:13:46, Brian Callahan  wrote:
> Hi ports --
> 
> We currently have a less than ideal situation regarding where audio
> patchsets are located for programs that need them. Right now, they are
> bundled into the timidity package. Which does make sense, that way when you
> install timidity you get the needed audio patches. However, sdl{,2}-mixer
> both come with their own bundled copies of timidity but do not come with the
> patches, meaning that unless a user also just happens to have the timidity
> package installed, they don't have midi playback with sdl{,2}-mixer.
> 
> This manifests in the ports tree with some games (corsixth, openxcom,
> prboom) having an RDEP on the timidity package solely in order for sdl-mixer
> to use the patches. There might be other packages that are missing out on
> midi audio support for the same reason.
> 
> So I propose we split the patchset off from timidity. The attached new port
> (audio/timgm6mb) is the patchset plus the needed configuration files. The
> patches set timgm6mb as an RDEP of the ports that need it.
> 
> After this goes in, I'll remove the RDEP on timidity from those 3 games.
> 

Hello,

It's nice to see Timidity getting some love!

I've tested that playing a few random MIDI files works with
Timidity with your patches.

sdl{,2}-mixer also compiled and installed just fine too.

I installed games/prboom to test if music played with it, but
didn't hear any actual music play.  Sound effects worked just
fine, but no music.

I rolled back to the original version of sdl-mixer and there was
no change, so I may simply be missing something in prboom's
configuration file or something.

Whatever the case may be, I saw no regressions in my (admittedly
light) testing.


On a related note, I don't mean to start a bikeshedding event, but
I'm curious about the history behind Timidity's FLAVORs.  I
presume that the default (of not building a graphical version) was
done because Timidity was a dependency of so many other ports and
presume the intention was to keep it as small and light as
possible.

I use Timidity's XaW flavor because it's the only one that shows a
piano keyboard and what notes are playing, which is useful to me
sometimes.

Since XaW is a relatively lightweight toolkit (at least, compared
to the gtk2 FLAVOR) would there be any chance at making the XaW
flavor the default (and thereby removing it as a FLAVOR option)?

This would slightly simplify the port, and since the patchsets
would now have been moved into their own separate port, only
people who actually wanted to have timidity installed for itself
would be installing it, so there would be less of a reason to keep
the default as small and minimal as possible.

Of course, this is only a minor suggestion.  If there's a good
reason for the FLAVORs being set up this way, then it doesn't take
much extra time on my part to manually compile and install Timidity
when necessary, so it's not a critical change.


Other options might include:

* Switch the port to use only X11 and non-X11 (I.e. build both
GTK2 and XaW together, without the option of selecting only one).
This would not be a problem for end users since Timidity allows
the user to select which toolkit to use at runtime.

-iddumb interface

-inncurses interface

-iaX Athena Widget interface

-igGTK+ interface

Indeed, I build it with FLAVOR="gtk2 xaw" and can select either
one at runtime.


* Just build everything all together regardless (I.e. remove ALL
FLAVORs from the Makefile).

This would pull in GTK2 and all of its dependencies, but I would
assume that most people working with MIDI files would likely have
GTK2 pulled in by some other graphical program somewhere anyway.

Timidity itself doesn't become very large.  The
timidity-2.15.0p0-gtk2-xaw.tgz package weighs in at only 610K


Either way, thank you for putting in the effort to improve
Timidity (and related ports)!

-- 
Bryan

Re: UPDATE: FFmpeg 4.1.1

[Bryan Linton]

On 2019-02-21 17:47:07, Brad Smith  wrote:
> I have patched as far as I know the whole ports tree for API issues
> that were found with newer FFmpeg. So I am now able to send out a
> proper update to FFmpeg.
> 
> Here is an update to FFmpeg 4.1.1 and coupled ports updates.
> 
> Any and all testing welcome.
> 

The new FFmpeg update worked fine to convert some dashcam footage
from MJPEG+WAV to h265+FLAC.

The new mplayer update also seems to be working similarly well.

Thank you for putting in so much work to update FFmpeg!

-- 
Bryan

Re: update security/sshlockout

[Bryan Linton]

On 2019-01-30 19:04:39, Solene Rapenne  wrote:
> here is an update for sshlockout. I took last code from git and hosted it on 
> my
> server. This version adds support for max attempts exceeded.
> 
> [...]
> 
> works fine on amd64
> 

Also tested on amd64.

Seems to be working fine.  Both a "tail -f /var/log/authlog" and a
"pfctl -t lockout -T show" indicate that IPs are being detected
and successfully locked out.

-- 
Bryan

Re: [update] mpd 0.21, mpc, libmpdclient, ncmpc

[Bryan Linton]

On 2018-12-09 22:29:33, Landry Breuil  wrote:
> Hi,
> 
> here's 4 updates for the mpd gang, libmpdclient, mpc & ncmpc are more or
> less trivial, mpd was harder:
> - switched from autotools to meson. I tried as hard as i could to select
>   the same featureset as was used with autohell.
> - we cant update to 0.21.3 (latest) because ffmpeg>=57 is required since
>   
> https://github.com/MusicPlayerDaemon/MPD/commit/08272cdee2b886f759ffe632c3310e3ead095b62
> - so the diff is for the latest version before this commit. I tried
>   updating to the latest mpd by disabling ffmpeg crap and use mpg123
> instead, but it fails to link against libmpg123.
> - remove the hicolor svg icon to avoid depending on gtk+3,-guic
> - patches here and there to install manpages and all, disable broken
>   ucred detection, etc.
> - in ncmpc, cast Style::FOO to int otherwise the ncurses macro complains
>   about it.
> 
> totally untested, will test them in the coming days. Note that mpd 0.21
> requires gcc6 so it will probably give bad results on non-clang archs -
> but other than that this branch has shitloads of fixes & new features
> per https://raw.githubusercontent.com/MusicPlayerDaemon/MPD/v0.21/NEWS
> 
> on the other hand, we can also update to mpd 0.20.23...
> 
> testing & feedback welcome.
> 

I primarily use mpd with audio/ario, and everything works fine.  I had
to update my database before songs would play, but I generally do that
as a matter of course whenever new major versions of mpd are released anyway.

Also lightly tested mpc and ncmpc, and no regressions seen with them.

-- 
Bryan

Re: UPDATE: inputmethods/uim

[Bryan Linton]

On 2018-12-16 17:11:28, "Anthony J. Bentley"  wrote:
> Bryan Linton writes:
> > I removed those lines and got farther, but the build still fails for me.
> > Build logs attached below.  If I've done something wrong, feel free to
> > hit me with a cluebat.
> 
> As far as I can tell there's no actual error in the logs you attached.
> I can't reproduce; for me everything builds fine even on a fresh
> -current vmm(4) VM.
>

Whoops, it looks like I cut and pasted the log from the wrong area.  I think
the actual error is:

gmake[5]: Entering directory 
'/usr/obj/ports/uim-1.8.8/uim-1.8.8/qt4/toolbar/build'
gmake[5]: *** No rule to make target '../../../uim/.libs/libuim.so', needed by 
'lib/plasma_applet_uim.so'.  Stop.

> It would be helpful if you could test removing packages one by one until
> you find the one that's breaking your build.
> 

% pkg_info -a | wc -l
1035

That's going to take a long time... more time than I have currently.

But if you can't reproduce this and it works fine for you, it may be better
to just go ahead and commit it since it clearly seems to be a problem on my end.


-- 
Bryan

Re: UPDATE: inputmethods/uim

[Bryan Linton]

On 2018-12-10 01:21:49, "Anthony J. Bentley"  wrote:
> Hi,
>=20
> Here is an update to uim-1.8.8.
>=20
> Release notes: https://github.com/uim/uim/releases
>=20

First, thank you for sending an update to uim!  I use it daily
and I'm happy to see that it's getting an update given that 1.8.6
was released all the way back in 2013.

Unfortunately, I had a few problems getting it to build.

The first thing I noticed was that the qt4 MULTI_PACKAGE wouldn't
continue building until I manually installed devel/automoc, so it=20
probably needs adding to the Makefile as either a BUILD or LIB_DEPEND.

But even after doing so, I still get build failures with both the
base version as well as the MULTI_PACKAGES.=20

Considering that all the build failures end with the same error, which is:

gmake[1]: Entering directory '/usr/obj/ports/uim-1.8.8/uim-1.8.8/scm'
if test -n "/usr/local/bin/csi"; then \
/usr/local/bin/csi -R syntax-case -q json-parser-expander.scm > 
json-p=
arser-expanded.scm; \
fi
error CS2006: Command-line syntax error: Missing '' for '-R' 
option
error CS2001: Source file 
'/usr/obj/ports/uim-1.8.8/uim-1.8.8/scm/syntax-c=
ase' could not be found.

It looks like it's related to this:=20

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229674
Summary: textproc/uim: does not build when mono is installed

For reference:
% csi
Microsoft (R) Visual C# Interactive Compiler version 2.7.0.62620
Copyright (C) Microsoft Corporation. All rights reserved.
=09
Type "#help" for more information.
>=20

It looks like FreeBSD simply deleted the offending lines from the Makefile:
https://svnweb.freebsd.org/ports?view=3Drevision=3D474523

https://svnweb.freebsd.org/ports/head/textproc/uim/files/patch-scm_Makefil=
e.in?view=3Dmarkup=3D474523

I removed those lines and got farther, but the build still fails for me.
Build logs attached below.  If I've done something wrong, feel free to
hit me with a cluebat.


Also, as a side note, would it be possible to add a qt5 MULTI_PACKAGE
as well?  I don't use many qt applications, but I remember that gtk3
applications didn't work without the gtk3 subpackage many years ago.

Or, they sort of did if you added an environment hack, but they were
very buggy.  I remember I pestered^W asked a developer nicely to add
the gtk3 MULTI_PACKAGE and everything's been working fine since then.

I'm not sure if qt{3,4,5} are as picky about things as gtk{2,3} are,
so it may not be necessary, but probably wouldn't hurt to have.

Anyway, thanks again for sending the patch!

-8<-

% sysctl kern.version
kern.version=3DOpenBSD 6.4-current (GENERIC.MP) #494: Sat Dec  8 16:58:39 M=
ST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

% pkg_info | grep libgcroots
libgcroots-0.3.1garbage collector library

% make package
[...]
/usr/obj/ports/uim-1.8.8/bin/c++  -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=3D38 -DK=
DE_DEPRECATED_WARNINGS -DMAKE_PLASMA_APPLET_UIM_LIB -DPLASMA_APPLET_UIM -DQ=
T_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -=
DQT_NO_STL -DQT_SVG_LIB -D_REENTRANT -I/usr/obj/ports/uim-1.8.8/uim-1.8.8/q=
t4/toolbar/build -I/usr/obj/ports/uim-1.8.8/uim-1.8.8/qt4/toolbar -I/usr/ob=
j/ports/uim-1.8.8/uim-1.8.8/qt4/toolbar/../.. -I/usr/obj/ports/uim-1.8.8/ui=
m-1.8.8/qt4/toolbar/../../uim -I/usr/obj/ports/uim-1.8.8/uim-1.8.8/qt4/tool=
bar/../../replace -I/usr/obj/ports/uim-1.8.8/uim-1.8.8/qt4/toolbar/.. -I/us=
r/obj/ports/uim-1.8.8/uim-1.8.8/qt4/toolbar/build/../../../uim -I/usr/local=
/include/kde4 -I/usr/local/include/kde4/KDE -I/usr/local/include/X11/qt4/Qt=
Designer -I/usr/local/include/X11/qt4/QtDeclarative -I/usr/local/include/X1=
1/qt4/QtScriptTools -isystem /usr/local/include/X11/qt4/QtDBus -I/usr/local=
/include/X11/qt4/QtXml -I/usr/local/include/X11/qt4/QtSql -I/usr/local/incl=
ude/X11/qt4/QtOpenGL -I/usr/local/include/X11/qt4/QtMultimedia -I/usr/local=
/include/X11/qt4/QtNetwork -I/usr/local/include/X11/qt4/phonon -I/usr/local=
/include/X11/qt4/QtXmlPatterns -I/usr/local/include/X11/qt4/QtWebKit -I/usr=
/local/include/X11/qt4/QtHelp -I/usr/local/include/X11/qt4/QtUiTools -I/usr=
/local/include/X11/qt4/QtTest -I/usr/local/include/X11/qt4/QtScript -isyste=
m /usr/local/include/X11/qt4/QtSvg -I/usr/local/include/X11/qt4/Qt3Support =
-isystem /usr/local/include/X11/qt4/QtGui -isystem /usr/local/include/X11/q=
t4/QtCore -isystem /usr/local/lib/qt4/mkspecs/default -isystem /usr/local/i=
nclude/X11/qt4 -I/usr/X11R6/include  -O2 -pipe -W -Wall -Wchar-subscripts -=
Wnon-virtual-dtor -Wno-long-long -Wcast-align  -Wpointer-arith -Wwrite-stri=
ngs -Wformat-security -DNDEBUG  -I/usr/X11R6/include -Wnon-virtual-dtor -Wn=
o-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith=
 -Wformat-security -Woverloaded-virtual -fno-common -fvisibility=3Dhidden -=
Werror=3Dreturn-type -fvisibility-inlines-hidden 

Re: Update emulators/mednafen 0.9.48 -> 1.21.3

[Bryan Linton]

On 2018-08-25 11:54:05, Jeremy Evans  wrote:
> On 08/20 05:53, Bryan Linton wrote:
> > Sound doesn't work though.
> > 
> > Initializing sound...
> > Using "OpenBSD(/dev/audio*)" audio driver with SexyAL's default
> > device selection.OpenBSD Audio Error: fd = open(id ? id :
> > "/dev/audio", O_WRONLY) No such file or directory
> > Error opening a sound device.
> > 
> > [...]
> > 
> > % ls -la /dev/audio
> > ls: /dev/audio: No such file or directory
> 
> I did some more work on this and found out the reason it worked for me
> was not related to this change, but because I use the sdl sound driver.
> I think sdl should be the default, because it works with sndiod, while
> the openbsd driver does not.
> 
> Here's a patch that does that.  It also updates the default device from
> from /dev/audio to /dev/audio0.
> 
> You can modify the mednafen sound driver and sound device using
> the appropriate settings in the mednafen configuration file.
> 

Everything seems to work well for me.  No regressions seen in my
use-case at least.

-- 
Bryan

Re: UPDATE games/wesnoth

[Bryan Linton]

On 2018-08-12 21:21:18, Bryan Linton  wrote:
> On 2018-08-12 12:44:11, Tom Murphy  wrote:
> > 
> > Hi,
> > 
> > I'd love to test this as I do enjoy playing Wesnoth.
> > 
> > The patch Kirill posted for 1.14.4 appears to require devel/boost 1.66.0p0 
> > or
> > later, however boost 1.66.0 is the latest version in the tree. I've looked 
> > but couldn't find 1.66.0 revision 0 patches.
> > 
> > Is there an update to devel/boost for 1.66.0p0 somewhere?
> > 
> 
> Yes, he also sent a seperate update to boost which adds ICU
> support, which is required for the Wesnoth update.
> 
> If you can't find it in your mailer, you could try pulling the
> patch from the archives here:
>   https://marc.info/?l=openbsd-ports=153293983402845=2
> 

It looks like the boost ICU patch was committed recently
https://marc.info/?l=openbsd-ports-cvs=153504230123256=2
so the Wesnoth update should work by itself with an up-to-date
ports tree.

I've been continuing to play and test the Wesnoth update itself.
I haven't encountered any bugs or regressions yet.

Barring no other issues, I'd love to see this go in now that the
ICU patch has been committed.

If anyone else enjoys turn-based strategy games, particularly ones
with a fantasy theme (elves, orcs, undead, etc.) I highly
recommend it.

If traditional strategy games (controlling many players with
varying skills and abilities, like chess) aren't your thing, a
common variation played on the multiplayer server is one where
instead you choose a single character and level it to extremely
high levels as you fight through hoards of creeps (AI controlled
characters) with your teammates.

Wesnoth is free and open-source (no external assets required),
cross-platform (Windows, Mac, Linux, BSD) and was recently added
to Steam, so if you have any friends on non-unix platforms who
would like to play, it should be easy for them to install and start
playing.

I've been playing Wesnoth since it was at version 1.4 (released
all the way back in 2008!) so it definitely has staying power.

I encourage anyone interested to test the new port and enjoy
playing it!

-- 
Bryan

Re: Update emulators/mednafen 0.9.48 -> 1.21.3

[Bryan Linton]

On 2018-08-19 10:34:51, Jeremy Evans  wrote:
> This upgrades mednafen to the latest released version.  Initial diff
> from an...@disroot.org, some changes by me.  I tested most of the
> emulator types, and all appear to work except SNES, which crashes for me
> right after the window opens, with no useful debug output.  Not sure if
> that is a regression or not, or if it is due to my video card. I
> generally use snes9x for SNES emulation.
> 
> Ports-wise, the main change is that mednafen now requires SDL2.
> 
> OKs?
> 

I see the same crash with SNES emulation, but the old version
crashed too, so that's not a regression.

Sound doesn't work though.

Initializing sound...
Using "OpenBSD(/dev/audio*)" audio driver with SexyAL's default
device selection.OpenBSD Audio Error: fd = open(id ? id :
"/dev/audio", O_WRONLY) No such file or directory
Error opening a sound device.

[...]

% ls -la /dev/audio
ls: /dev/audio: No such file or directory

I removed this link according to current.html which says the
following:

2018/07/29 - Remove /dev/audio and /dev/audioctl

The /dev/audio and /dev/audioctl symbolic links are not
used anymore and can be removed:
# rm /dev/audio /dev/audioctl

So I had to apply the following patch to get sound.

Index: src/sexyal/drivers/openbsd.cpp
--- src/sexyal/drivers/openbsd.cpp.orig
+++ src/sexyal/drivers/openbsd.cpp
@@ -165,7 +165,7 @@ SexyAL_device* SexyALI_OpenBSD_Open(const char* id, Se
 
  AUDIO_INITPAR();
 
- OBSD_TRY(fd = open(id ? id : "/dev/audio", O_WRONLY));
+ OBSD_TRY(fd = open(id ? id : "/dev/audio0", O_WRONLY));
 
  par.bits = SAMPFORMAT_BITS(format->sampformat);
  par.bps = SAMPFORMAT_BYTES(format->sampformat);

This got sound working for me, but I'm not sure how good of a
solution it actually is.  If anyone has multiple sound cards, then
it would hardcode it to only work with /dev/audio0

A proper solution would probably be writing a proper sndio backend
for it, but I'm not sure how much work that would actually entail.

Failing that, I suppose another option would be to leave things
as-is, and adding a MESSAGE telling the user to create the
/dev/audio link manually.


A final, and somewhat hackish solution (but still probably the
best option if it could be made to work) would be to add something
like the following patch (NOT WORKING IN ITS CURRENT STATE!).

Index: src/sexyal/drivers/openbsd.cpp
--- src/sexyal/drivers/openbsd.cpp.orig
+++ src/sexyal/drivers/openbsd.cpp
@@ -165,7 +165,7 @@ SexyAL_device* SexyALI_OpenBSD_Open(const char* id, Se
 
  AUDIO_INITPAR();
 
  OBSD_TRY(fd = open(id ? id : "/dev/audio", O_WRONLY));
+ OBSD_TRY(fd = open(id ? id : "/dev/audio0", O_WRONLY));
+ OBSD_TRY(fd = open(id ? id : "/dev/audio1", O_WRONLY));
+ OBSD_TRY(fd = open(id ? id : "/dev/audio2", O_WRONLY));
+ OBSD_TRY(fd = open(id ? id : "/dev/audio3", O_WRONLY));
 
  par.bits = SAMPFORMAT_BITS(format->sampformat);
  par.bps = SAMPFORMAT_BYTES(format->sampformat);

So that it would check the /dev/audio link first, and then choose
the first audio device that sucessfully opens if there's no
/dev/audio link.

That way, it would work for most people by choosing audio0, but
could be overridden with a /dev/audio link for those who want to
point it to a different device.


All in all, I've lightly tested the update, and it seems to work
fine for me with NES emulation at least.  With my patch, audio
works, as well as video, a USB gamepad, and everything else.

Since you're the maintainer, I'll defer to your judgement on how
to best handle the audio patching.

Anyway, thanks for the update!

-- 
Bryan

Re: UPDATE games/wesnoth

[Bryan Linton]

On 2018-08-12 12:44:11, Tom Murphy  wrote:
> >On 2018-08-01 17:11:58, Bryan Linton  wrote:
> >> On 2018-07-30 11:26:38, Kirill Bychkov  wrote:
> >> > Hi!
> >> > This is a long standing update for wesnoth. Current version includes
> >> > security fixes (which were backported to 1.12.6 in our tree).
> >> > 1.14.x requires boost with icu support. Without it the game crashes
> >> > on preferences dialog and add-on list.
> >> > See my next mail with the patch for boost.
> >> > 
> >> 
> >> No problems here.
> >> 
> >> I've been able to successfully download and install several
> >> add-ons, and play games on the multi-player server.
> >> 
> >
> >I know that this update is still waiting on the boost ICU support
> >to go through a bulk and be thoroughly tested because of how high
> >up in the dependency chain boost is, but I just wanted to add an
> >update that I haven't experienced any problems with Wesnoth or the
> >boost ICU patch in the last two weeks.
> >
> >I've played several dozen (if not closer to a hundred) games,
> >added and used several add-ons/maps/etc., played both single and
> >multiplayer, and haven't encountered any bugs or issues yet.
> >
> >So if and when the boost ICU update gets committed, this Wesnoth
> >update works fine for me on amd64 at least.
> >
> >Many thanks again to Kirill for the update!
> >
> 
> Hi,
> 
> I'd love to test this as I do enjoy playing Wesnoth.
> 
> The patch Kirill posted for 1.14.4 appears to require devel/boost 1.66.0p0 or
> later, however boost 1.66.0 is the latest version in the tree. I've looked 
> but couldn't find 1.66.0 revision 0 patches.
> 
> Is there an update to devel/boost for 1.66.0p0 somewhere?
> 

Yes, he also sent a seperate update to boost which adds ICU
support, which is required for the Wesnoth update.

If you can't find it in your mailer, you could try pulling the
patch from the archives here:
https://marc.info/?l=openbsd-ports=153293983402845=2

-- 
Bryan

Re: UPDATE games/wesnoth

[Bryan Linton]

On 2018-08-01 17:11:58, Bryan Linton  wrote:
> On 2018-07-30 11:26:38, Kirill Bychkov  wrote:
> > Hi!
> > This is a long standing update for wesnoth. Current version includes
> > security fixes (which were backported to 1.12.6 in our tree).
> > 1.14.x requires boost with icu support. Without it the game crashes
> > on preferences dialog and add-on list.
> > See my next mail with the patch for boost.
> > 
> 
> No problems here.
> 
> I've been able to successfully download and install several
> add-ons, and play games on the multi-player server.
> 

I know that this update is still waiting on the boost ICU support
to go through a bulk and be thoroughly tested because of how high
up in the dependency chain boost is, but I just wanted to add an
update that I haven't experienced any problems with Wesnoth or the
boost ICU patch in the last two weeks.

I've played several dozen (if not closer to a hundred) games,
added and used several add-ons/maps/etc., played both single and
multiplayer, and haven't encountered any bugs or issues yet.

So if and when the boost ICU update gets committed, this Wesnoth
update works fine for me on amd64 at least.

Many thanks again to Kirill for the update!

-- 
Bryan

Re: UPDATE games/wesnoth

[Bryan Linton]

On 2018-07-30 11:26:38, Kirill Bychkov  wrote:
> Hi!
> This is a long standing update for wesnoth. Current version includes
> security fixes (which were backported to 1.12.6 in our tree).
> 1.14.x requires boost with icu support. Without it the game crashes
> on preferences dialog and add-on list.
> See my next mail with the patch for boost.
> 
> Main changes from porters POV:
>  - upstream stopped supporting of lowmem machunes so lite FLAVOR removed
>  - upstream switched to c++11
>  - upstream switched to SDL2
> 
> Changelog: https://github.com/wesnoth/wesnoth/blob/1.14/changelog.md
>

No problems here.

I've been able to successfully download and install several
add-ons, and play games on the multi-player server.

Barring no other problems, I'd love to see this go in.  The 1.12.x
series isn't compatible with the 1.14.x series, so it's next to
impossible to find other players who are still using the 1.12.x
series.

The player base is still small, but there are enough people
playing the 1.14.x series that it's possible to find people to
play against again with this update.

Many thanks to Kirill for putting the effort in to getting the new
release ported!

-- 
Bryan

Re: NEW: net/bitcoin

[Bryan Linton]

On 2018-06-23 09:07:38, Thomas Frohwein  wrote:
> On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote:
> > I think the blockchain size is a deterrent. I can test it when I'm back 
> > from traveling in ~ 10 days and have access to additional GB on my external 
> > drive, in case that helps.
> > 
> > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  
> > wrote:
> > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > >
> > >It's not evil! It's NOT mining. ;)
> 
> I installed it and tried to sync the 200GB blockchain to my external HDD
> (because that's the only one that got this much space available). It
> synced fine for 1-2 days with the bitcoin-qt client, but then at about
> 30-40% of the blockchain synced, it now starts throwing an error:
> 
> ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread 
> failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, 
> nPos=6513581)
> 
> When this happens, the following lines appear in dmesg:
> 
> sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>   SENSE KEY: Media Error
>   ASC/ASCQ: Unrecovered Read Error
> 
> Fortunately, the drive still seems to be functional otherwise, can be
> mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> whenever mounting or unmounting said drive until I disconnect and
> reconnect the drive from the USB port.
> 

This is almost certainly a problem with the drive.  I've had
several hard drives fail over the ~13 years or so I've been using
OpenBSD, and this is exactly the kind of error I see when the
drive is wearing out.

The message means that the kernel could not read a sector on the
drive despite trying to do so.  I've had drives continue to
otherwise work for years after throwing errors like that (though I
made sure to back them up and only used them as "scratch" drives).
Another time I had a drive fail within weeks of throwing an error
like that.

If it's still under warranty, I'd recommend sending it in for
replacement.  If it's not, I'd *highly* recommend backing up
anything on there to another drive.

Sometimes, sectors can be "weak" and if you give the drive enough
time it will be able to read it, so if it can't be backed up
entirely, back up as much as you can, then let the drive sit for a
few days and try again.

Some ports that may help:
sysutils/ddrescue
sysutils/testdisk
sysutils/e2fsprogs (for the "badblocks" program)
net/rsync (probably obvious, but still worth mentioning)

Modern drives keep "spare sectors" in which to remap failing ones
like this, but they usually only do so when *writing* to the
sector, not when *reading* it.

You could try backing up the drive, then writing zeros to the
entire drive with dd(1) to try to see if it helps.  You could also
try running "badblocks -n" on the drive (from sysutils/e2fsprogs).

-nUse non-destructive read-write mode.  By default only a non-
  destructive read-only test is done.  This option must not be
  combined with the -w option, as they are mutually exclusive.

"badblocks -n" will read all sectors on the drive and write back
the same data to the sector.  If it's "weak", and the program can
manage to read the sector, the drive may then remap that sector to
a spare.

But!  How much do you really trust a drive that has started to
fail?  Drives are cheap.  Cheaper than they've ever been.  If this
drive contains the only copy of family photos of your dearly
departed grandmother, are you willing to risk it?

sd4 at scsibus4 targ 1 lun 0:  SCSI4 0/direct 
fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors

I see a 3TB Western Digital My Book on a very popular online
retailer for only $89.99 USD with free shipping as I type this.

Is the data on that drive worth more than that?  Is the amount of
time you'd spend trying to squeeze a little more life out of the
drive worth it?  How much do you value your free time?  If you
enjoy tinkering with things like this and don't have valuable data
on it, it may be worth trying.  If you'd rather spend that time
outside hiking or seeing friends and family, then it may be more
economical to just buy a new one.  

Ultimately, only you can decide.

> I can't resume syncing the blockchain though because the error appears
> again.
> 

While I'm here, I poked around bitcoin's manpage and found this:

 -prune=

  Reduce storage requirements by enabling pruning (deleting) of
  old blocks. This allows the pruneblockchain RPC to be called to
  delete specific blocks, and enables automatic pruning of old
  blocks if a target size in MiB is provided. This mode is
  incompatible with -txindex and -rescan. Warning: Reverting this
  setting requires re-downloading the entire blockchain. (default:
  0 = disable pruning blocks, 1 = allow manual pruning via RPC,
  >550 

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-13 12:01:52, Landry Breuil  wrote:
> 
> Sadly, this trace doesnt really help, since it seems to be a signal
> handler that catches the SIGABRT, or the signal handler is in the main
> process and the abort is in the content process, and not the trace of
> the codepath that triggers this SIGABRT...
> 
> How about trying it live (if you can) within egdb following all
> processes, with a breakpoint on signal or SYS_access ?
> 

Hello,

I tried to run firefox in egdb but I'm having some difficulty.
egdb seems to crash and then takes my entire system down with it.
Mouse, keyboard, CTRL+ALT+DEL, CTRL+ALT+BKSP, all stop working.

I saw your recent mail to ports@ about how to help debug the new
pledged firefox, and what other info may help too (ktrace etc.).

I'll try to see if I can figure out why egdb is crashing and
provide some more information soon, but I may not be able to do so
until this weekend.  (The first thing I'll try is updating to a
newer snapshot.)

Until then, please don't let this bug report hold you back from
doing any work you had planned.  For the meantime at least,
firefox runs fine with the getpw pledge added.  That and the fact
that I seem to be the only one experiencing this crash tells me
that this bug is probably only affecting me at the moment.

Anyway, thanks again for all the work you've put in to pledging
firefox!

-- 
Bryan

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-12 20:02:40, Landry Breuil <lan...@openbsd.org> wrote:
> On Sat, May 12, 2018 at 08:07:17PM +0900, Bryan Linton wrote:
> > 
> > Adding the "getpw" pledge to "security.sandbox.pledge.content"
> > doesn't fix it.  However adding it to "security.sandbox.pledge.main"
> > lets everything run just fine again.
> 
> Well, i can't reproduce it here, and i have no issue calling 'save link
> as' or 'save page as' dialogs without getpw pledge on main process.
> Though i havent tried *actually* saving the image/page.
> 
> I'll need a bit more context.. can you look at the coredump with egdb
> from ports and try to get the backtrace for the pledge abort, so that we
> figure out if it's within firefox or the glib layers ?
>

% dmesg | grep GENERIC | tail -2
OpenBSD 6.3-current (GENERIC.MP) #14: Thu Apr 26 21:03:52 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

% ls -la /etc/malloc.conf
ls: /etc/malloc.conf: No such file or directory

% firefox -profilemanager
[create new, blank profile with no add-ons or extensions installed]

[firefox gets killed by pledge() upon "Right-click -> Save link as..."]
firefox[99269]: pledge "getpw", syscall 33

% egdb `which firefox` firefox.core 
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/firefox...done.
[New process 127256]
[New process 197917]
[New process 278895]
[New process 359186]
[New process 490001]
[New process 121875]
[New process 569901]
[New process 262854]
[New process 185179]
[New process 532300]
[New process 186272]
[New process 495833]
[New process 422756]
[New process 195461]
[New process 114351]
[New process 372828]
[New process 596628]
[New process 415519]
[New process 596946]
[New process 181949]
[New process 235073]
Core was generated by `firefox'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x in ?? ()
[Current thread is 1 (process 127256)]
(gdb) bt
#0  0x in ?? ()
#1  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2  
#3  0x in ?? ()
#4  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#5  
#6  0x in ?? ()
#7  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#8  
#9  0x in ?? ()
#10 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0

[...many identical lines deleted]

#2323 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2324 
#2325 0x in ?? ()
#2326 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2327 
#2328 0x0fea53142659 in 
mozilla::ipc::MessageChannel::OnChannelErrorFromLink() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2329 0x0fea53143c31 in non-virtual thunk to 
mozilla::ipc::ProcessLink::OnChannelError() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2330 0x0fea53127a2e in event_persist_closure ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1580
#2331 event_process_active_single_queue ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1639
#2332 0x0fea531251fe in event_process_active ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1741
#2333 event_base_loop () at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1961
#2334 0x0fea531129c5 in 
base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2335 0x0fea53111417 in MessageLoop::Run() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2336 0x0fea5311bf35 in base::Thread::ThreadMain() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2337 0x0fea53116f0a in ThreadFunc(void*) () from 
/usr/local/

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-11 14:00:57, Landry Breuil  wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   lan...@cvs.openbsd.org  2018/05/11 14:00:57
> 
> [...]
> 
> Log message:
> Update to firefox 60.
>
> [...]
>
> If you encounter crashes due to pledge, look into your kernel log, and
> try to figure out what missing pledge is needed or what firefox codepath
> hits it.
> 
> [...]
>
> So far i know 'getpw' might be needed when uploading files but i havent
> hit it, and 'proc' might be needed by the content process when there's
> no dbus daemon running, but they're not needed in the 'common case', and
> too broad.
> 

Hello,

I've found that a simple "Right-click -> Save image as" or
"Right-click -> Save link as" causes Firefox to crash.

firefox[77259]: pledge "getpw", syscall 33
firefox[11365]: pledge "getpw", syscall 33
firefox[11365]: pledge "stdio", syscall 29
firefox[76277]: pledge "getpw", syscall 33
firefox[10702]: pledge "getpw", syscall 33

I tried four separate times.  All of them showed a "getpw" pledge
error.  For some reason, one of the trials also caused it to emit
an "stdio" pledge error too.

I see that stdio is already pledged, so I have no idea why or
where that error came from.

FWIW, /usr/src/sys/kern/syscalls.master says that syscalls 29 and 33 are
the following:

29  STD { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
int flags, struct sockaddr *from, \
socklen_t *fromlenaddr); }

33  STD { int sys_access(const char *path, int amode); }

Adding the "getpw" pledge to "security.sandbox.pledge.content"
doesn't fix it.  However adding it to "security.sandbox.pledge.main"
lets everything run just fine again.


I'd also like to take this opportunity to thank you (and all the
others!) who put in all the effort to pledge Firefox.  Thank you! 

-- 
Bryan

Re: mpd 0.20.18, mpc 0.29 & libmpdclient 2.14

[Bryan Linton]

On 2018-04-06 21:42:35, Landry Breuil  wrote:
> Hi,
> 
> small updates, i only fought a bit with meson in the mpc update. Using
> it now on amd64, probably needs testing on other archs.
> 

Everything seems to work fine when paired with audio/ario on my amd64
system as well.

-- 
Bryan

Re: update SDL2 to 2.0.8 and security update of sdl2-image to 2.0.3

[Bryan Linton]

It looks like the patch for sdl2 and sdl2-image got commingled.
After separating them out, they applied successfully and
everything seems to be OK.

I tested with games/manaplus, games/scummvm, and
emulators/retroarch and didn't see any regressions.

-- 
Bryan

On 2018-03-10 10:16:48, Thomas Frohwein  wrote:
> Ping... and double-ping for the sdl2-image security fix
> 
> On Thu, Mar 01, 2018 at 07:52:03PM -0800, Thomas Frohwein wrote:
> > Hi,
> > 
> > Here the diff for updating both sdl2 and sdl2-image. Note that sdl2-image 
> > is a
> > security update for some buffer overflows and crashes by maliciously-crafted
> > data (see details below).
> > 
> > The diff below updates sdl2 to 2.0.8. This includes the optional mapping of 
> > the
> > Gamecontroller API via the SDL_GAMECONTROLLERCONFIG env var. To recap, there
> > are 2 joystick/gamepad APIs in SDL2. The old joystick API was not an issue, 
> > but
> > the newer gamecontroller API did not work before the 2.0.7 update. The 2.0.7
> > updated included a workaround that mapped the gamecontroller API based on 
> > the
> > fallback part that was already there for Linux, but that was set at compile
> > time only. This update includes a slightly expanded workaround that checks 
> > for
> > the SDL_GAMECONTROLLERCONFIG env var and maps based on that if found.
> > 
> > Also bump minor. Runs stone-soup, neverball, megaglest, and FNA games as
> > before on brief testing, including sound, graphics, and gamepad.
> > 
> > The sdl2-image update to 2.0.3 was released today and contains a series of
> > security patches. Grab maintainer while at it.
> > NOTE: the sdl2-image update needs sdl2 version 2.0.8.
> > Also tested with above ports without issues.
> > 
> > The official release notes:
> > 
> > Thanks to all the people who contributed code and feedback, SDL 2.0.8 is 
> > now available!
> > http://www.libsdl.org/download-2.0.php
> > In addition to lots of bug fixes and build improvements, here are the major 
> > changes in this release:
> > General:
> > Added SDL_fmod() and SDL_log10()
> > Each of the SDL math functions now has the corresponding float version
> > Added SDL_SetYUVConversionMode() and SDL_GetYUVConversionMode() to control 
> > the formula used when converting to and from YUV colorspace. The options 
> > are JPEG, BT.601, and BT.709
> > Windows:
> > Implemented WASAPI support on Windows UWP and removed the deprecated 
> > XAudio2 implementation
> > Added resampling support on WASAPI on Windows 7 and above
> > Windows UWP:
> > Added SDL_WinRTGetDeviceFamily() to find out what type of device your 
> > application is running on
> > Mac OS X:
> > Added support for the Vulkan SDK for Mac:
> > https://www.lunarg.com/lunarg-releases-vulkan-sdk-1-0-69-0-for-mac/
> > Added support for OpenGL ES using ANGLE when it's available
> > Mac OS X / iOS / tvOS:
> > Added a Metal 2D render implementation
> > Added SDL_RenderGetMetalLayer() and SDL_RenderGetMetalCommandEncoder() to 
> > insert your own drawing into SDL rendering when using the Metal 
> > implementation
> > iOS:
> > Added the hint SDL_HINT_IOS_HIDE_HOME_INDICATOR to control whether the home 
> > indicator bar on iPhone X should be hidden. This defaults to dimming the 
> > indicator for fullscreen applications and showing the indicator for 
> > windowed applications.
> > iOS / Android:
> > Added the hint SDL_HINT_RETURN_KEY_HIDES_IME to control whether the return 
> > key on the software keyboard should hide the keyboard or send a key event 
> > (the default)
> > Android:
> > SDL now supports building with Android Studio and Gradle by default, and 
> > the old Ant project is available in android-project-ant
> > SDL now requires the API 19 SDK to build, but can still target devices down 
> > to API 14 (Android 4.0.1)
> > Added SDL_IsAndroidTV() to tell whether the application is running on 
> > Android TV
> > Android / tvOS:
> > Added the hint SDL_HINT_TV_REMOTE_AS_JOYSTICK to control whether TV remotes 
> > should be listed as joystick devices (the default) or send keyboard events.
> > Linux:
> > Added the hint SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR to control 
> > whether the X server should skip the compositor for the SDL application. 
> > This defaults to "1"
> > Added the hint SDL_HINT_VIDEO_DOUBLE_BUFFER to control whether the 
> > Raspberry Pi and KMSDRM video drivers should use double or triple buffering 
> > (the default)
> > 
> > 
> > 
> > SDL_image 2.0.3 is now available:
> > http://www.libsdl.org/projects/SDL_image/
> > 
> > This is a security update release, fixing the following security reports:
> > TALOS-2017-0488
> > TALOS-2017-0489
> > TALOS-2017-0490
> > TALOS-2017-0491
> > TALOS-2017-0497
> > TALOS-2017-0498
> > TALOS-2017-0499
> > 
> > You'll need to get SDL 2.0.8 for this release of SDL_image.
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/devel/sdl2/Makefile,v
> > retrieving 

Re: UPDATE fonts/junicode

[Bryan Linton]

On 2018-02-19 16:13:00, George Rosamond  wrote:
> George Rosamond:
> > portroach seems to have missed the jump from 0.7.8 to 1.001, which also
> > simplifies the Makefile a bit. https only works for sourceforge.net but
> > not subdomains.
> > 
> 
> ping.
> 

patch(1) wasn't able to find[1] pkg/PLIST and prompted me to enter it
manually.  Could this possibly be because of the double slashes
between "junicode" and "pkg"?  

---8<---
   VV
> > Index: junicode//Makefile
> > ===
   VV
> > Index: junicode//distinfo
> > ===
   VV
> > Index: junicode//pkg/PLIST
> > ===

---8<---

Other than that, after manually entering the path, everything seems
to work fine when I set Firefox's default font to junicode and go
to the test page here: http://junicode.sourceforge.net/juntest.html


[1]

% patch < ~/patches/junicode-1.001.diff 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|portroach seems to have missed the jump from 0.7.8 to 1.001, which also
|simplifies the Makefile a bit. https only works for sourceforge.net but
|not subdomains.
|
|Index: junicode//Makefile
|===
|RCS file: /cvs/ports/fonts/junicode/Makefile,v
|retrieving revision 1.2
|diff -u -p -r1.2 Makefile
|--- junicode//Makefile 25 Sep 2015 12:50:08 -  1.2
|+++ junicode//Makefile 13 Feb 2018 20:16:32 -
--
Patching file Makefile using Plan A...
Hunk #1 succeeded at 3.
Hunk #2 succeeded at 18.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: junicode//distinfo
|===
|RCS file: /cvs/ports/fonts/junicode/distinfo,v
|retrieving revision 1.1.1.1
|diff -u -p -r1.1.1.1 distinfo
|--- junicode//distinfo 28 Aug 2015 17:51:18 -  1.1.1.1
|+++ junicode//distinfo 13 Feb 2018 20:16:32 -
--
Patching file distinfo using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: junicode//pkg/PLIST
|===
|RCS file: /cvs/ports/fonts/junicode/pkg/PLIST,v
|retrieving revision 1.1.1.1
|diff -u -p -r1.1.1.1 PLIST
|--- junicode//pkg/PLIST28 Aug 2015 17:51:18 -
1.1.1.1
|+++ junicode//pkg/PLIST13 Feb 2018 20:16:32 -
--
File to patch: pkg/PLIST
Patching file pkg/PLIST using Plan A...
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done

-- 
Bryan

Re: [UPDATE] emulators/snes9x to 1.55

[Bryan Linton]

On 2017-12-30 18:39:42, Frederic Cambus  wrote:
> Hi ports@,
> 
> Here is a diff to update snes9x to 1.55.
> 
> Notable changes:
> 
> - Switch to GTK+ 3 and regenerate WANTLIB
> - Remove now useless CONFIGURE_ENV directive and pre-configure target
> - Fix PERMIT_PACKAGE_CDROM marker
> - Take MAINTAINER
> 
> Comments? OK?
> 

Moderately tested on amd64.  No regressions seen.

-- 
Bryan

Re: NEW: fonts/hanazono

[Bryan Linton]

On 2017-11-13 23:48:44, "Anthony J. Bentley"  wrote:
> Hi,
> 
> Hanazono is a Ming-style Japanese font containing over 100,000 characters
> defined in the ISO/IEC 10646 standard / the Unicode standard.
> 

Seems to work OK for me.  I'm always happy to see another
well-rounded CJK font made available.

-- 
Bryan

Re: [NEW] comms/qodem

[Bryan Linton]

On 2017-11-06 11:30:22, Frederic Cambus  wrote:
> Hi ports@,
> 
> Here is a new port: comms/qodem
> 
> Comments? OK?
> 
> >From DESCR:
> 
> Qodem is a from-scratch clone implementation of the Qmodem
> communications program made popular in the days when Bulletin Board
> Systems ruled the night. Qodem emulates the dialing directory and the
> terminal screen features of Qmodem over both modem and Internet
> connections.
>

Lightly tested on amd64.  No problems seen.

-- 
Bryan

Re: Take 2: Spin TimGM6mb into its own port, update timidity, sdl{,2}-mixer

[Bryan Linton]

On 2017-10-15 14:03:32, Brian Callahan  wrote:
> Hi ports --
> 
> I would like to bring up spinning the MIDI patchset we use for timidity into
> its own port. This is because sdl-mixer and sdl2-mixer both have their own
> internal versions of timidity and it would be nice to not have to install
> timidity to use the MIDI functionality of sdl-mixer and sdl2-mixer, and also
> allow these ports to finally have full functionality out of the box. This
> setup will also permit ports that happen to need a MIDI patchset or
> SoundFont2 file for audio playback to use this new port as an RDEP and just
> be ready to go.
> 
> Attached to this email are the following:
> 
> 1. New port, audio/timgm6mb, the MIDI patchset (and the original soundfont
> file as well, at the suggestion of sthen@)
> 2. Update to audio/timidity to add an RDEP on audio/timgm6mb
> 3. Update to devel/sdl-mixer to add an RDEP on audio/timgm6mb
> 4. Update to devel/sdl2-mixer to add an RDEP on audio/timgm6mb. Also, I'll
> take MAINTAINER of this.
> 
> After these changes are committed, I will send additional diffs to allow
> existing ports to take advantage of this new system.
> I've been running with this setup for a while now.
> 

I've tested plain timidity with your patches and all is well for
me.

I've tested games/wesnoth (which uses sdl-mixer) and it seems to
work fine music-wise (it still has graphical corruption I noticed
a long time ago and then forgot about, but that's not related to
your patch).  I'm not sure if it actually uses MIDI functionality
in any way, but at the very least nothing is broken with your
patches.

I don't have any installed ports which use sdl2-mixer, but I
figured I'd at least report back that everything works with what I
do use.

-- 
Bryan

Re: IMPROVE MORE: timidity, sdl-mixer, sdl2-mixer, and GUS patchsets

[Bryan Linton]

On 2017-08-17 01:34:37, Brian Callahan  wrote:
> 
> > Attached is a tarball, now named audio/timgm6mb, that includes the
> > SoundFont with the GUS patchset. And a diff to convert timidity and
> > sdl{,2}-mixer to consumers of timgm6mb.
> > 
> > OK?
> > 
> > ~Brian
> > 
> 
> Ping. I'd like to get this new port and associated changes in, as it is now
> (amazingly) blocking a Timidity update.
> 
> ~Brian
> 

Apologies for the long delay.  I put this on my todo list, but I
got swamped.

I've briefly tested timidity's GTK and XAW flavors, and everything
seems to work OK for me.

I mostly only invoke timidity as "timidity -iat" to get a visual
keyboard display of whatever is playing (this feature doesn't seem
to be available in the GTK version) and it still works as
expected.

No regressions seen in how I use timidity at least.

-- 
Bryan

Re: mednafen 0.9.39.2 -> 0.9.46

[Bryan Linton]

On 2017-09-22 12:38:32, Martin Pieuchot  wrote:
> On 20/09/17(Wed) 09:13, Anthony J. Bentley wrote:
> > Martin Pieuchot writes:
> > > Do you know if the games are multi-threaded?  Could you run "top -H" and
> > > "kdump -H"?
> > 
> > top -H shows a single line for gambatte.
> 
> Thanks.  Could you try the diff below?  It includes some debug stuff and
> a potential fix.
> 

I can confirm that this patch fixes dgen, mgba, and desmume for
me!  I assume that other SDL programs would be fixed as well.  I
encourage others to share their results.

FWIW, my dmesg is filled with things like the following (only the
last few lines pasted in):

   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidread
   1 uhidread: got 7 chars
   1 uhidclose: sc=0x805cd000

> I'm guessing that the problem is that my last change made uhid_do_ioctl()
> return an error for FIOASYNC.  This makes the following syscall fall:
> 
> 390:  /* The poll blocks the event thread. */
> 391:  fcntl(fd, F_SETFL, O_NONBLOCK)
> 
> 
> As a result FNONBLOCK is not set on the 'struct file' and uhid_do_read()
> block, or "freeze", when there's nothing to read instead of returning
> EWOULDBLOCK.
> 
> 

Hmm, it's interesting to know how the solution was arrived at :)

Thank you very much for taking the time to look into this!

-- 
Bryan

Re: mednafen 0.9.39.2 -> 0.9.46

[Bryan Linton]

[ I'm forwarding this email to the list, sans the kdump output
which I already mailed privately. ]

2017-09-20 07:47:37, Martin Pieuchot <m...@openbsd.org> wrote:
> On 20/09/17(Wed) 01:02, Anthony J. Bentley wrote:
> >
> > Once it's frozen ktrace seems to show no output. Here's the last few
> > lines if I run ktrace from the start:
> > [...]
> >  90169 gambatte_sdl CALL  read(5,0x18f94585a804,0x4)
>
> So it seems that the sleeping thread isn't awaken.  Bryan Linton
> provided some additional information, he said that emulators/mednafen
> still work for him.
>
> Do you know if the games are multi-threaded?  Could you run "top -H" and
> "kdump -H"?
>

Running top gives the following:

  PID  TID PRI NICE  SIZE   RES STATE WAIT  TIME CPU COMMAND
62482   253828   00   97M   25M sleep/0   uhidrea   0:08 12.40% dgen
62482   448260   20   97M   25M sleep/2   poll  0:00 2.54% dgen


  PID  TID PRI NICE  SIZE   RES STATE WAIT  TIME CPU COMMAND
31892   243344   00   34M   24M sleep/3   uhidrea   0:01 0.49% mgba


The entire "kdump -H" output was mailed privately.

> Could you also run a kernel compiled with the following diff and see if
> something is printed in the dmesg when the program "freeze"?
>

When I run dgen (the one with two threads) I get the entire dmesg
buffer filled with "uhidread" over and over again.  After I "pkill -9"
it, I get the following two lines at the end:

uhidclose: sc=0x8057be00
xhci0: NULL xfer pointer

Running mgba (the single threaded one), I get the same output of
"uhidread" over and over again, with only the following printed
after pkilling it.

uhidclose: sc=0x8057be00

The following dmesg output was from multiple runs followed by
"pkill -9" of dgen and mgba.  It looks like some other diagnostics
are getting printed in between the "uhidread" messages as well.

% wc -l dmesg-uhid.txt
7215 dmesg-uhid.txt
% uniq -c dmesg-uhid.txt
   1 d
3593 uhidread
   1 uhidclose: sc=0x8057be00
   1 xhci0: NULL xfer pointer
   1 uhidopen: sc=0x8057be00
   1 uhidioctl: cmd=44045515
   1 uhidioctl: cmd=40045519
   1 uhidioctl: cmd=8004667e
   1 uhidioctl: cmd=8004667d
   1 uhidioctl: cmd=8004667e
   1 uhidclose: sc=0x8057be00
   1 uhidopen: sc=0x8057be00
   1 uhidioctl: cmd=44045515
   1 uhidioctl: cmd=40045519
   1 uhidioctl: cmd=8004667e
   1 uhidioctl: cmd=8004667d
   1 uhidioctl: cmd=8004667e
1777 uhidread
   1 uhidclose: sc=0x8057be00
   1 xhci0: NULL xfer pointer
   1 uhidopen: sc=0x8057be00
   1 uhidioctl: cmd=44045515
   1 uhidioctl: cmd=40045519
   1 uhidioctl: cmd=8004667e
%

Also, for the archives, when I went back and bisected snapshots from
https://ftp.hostserver.de/archive/, I ended up with the following
in my notes:

2017-07-30 NOT WORKING!
2017-07-25 NOT WORKING!
2017-07-22 NOT WORKING!
2017-07-21 Works!
2017-07-20 Works!
2017-07-15 Works!
2017-07-10 Works!

So the 07-21 snapshot was the last one that worked for me.  I
figured it would probably be worth mentioning just in case.

I already said this privately, but I'd like state again my
thanks to mpi@ for taking the time to look into this issue.

Thank you!  :)

-- 
Bryan

Re: mednafen 0.9.39.2 -> 0.9.46

[Bryan Linton]

[ CCing all potentially involved parties, because I'd rather CC
more people than necessary than leave out an interested party.
Please ignore this mail if it's not relevant to you. ]

On 2017-08-30 09:55:12, Bryan Linton <b...@shoshoni.info> wrote:
> 
> If I can find the time, I'll try to see if I can bisect it by date
> at the very least, but if someone else wants to beat me to it,
> please be my guest! :)
> 

So I've found the commit that caused this issue.  To briefly recap
for the new developers being CCed, the following commit completely
disabled the ability to use joysticks in what appears to be all
SDL programs.  Ones I've confirmed to be non-working are: dgen
(SDL1), desmume (SDL1), mgba (SDL2), fceux (SDL1), and retroarch (SDL2).

--8<-

CVSROOT:/cvs
Module name:src
Changes by: m...@cvs.openbsd.org 2017/07/20 10:54:45

Modified files:
sys/dev/usb: uhid.c

Log message:
Remove SIGIO support.  Base tools do not implement it and ports relying
on libusbhid, generally via SDL, shouldn't do it either since it's not
portable.

Suggested by deraadt@ after Ilja van Sprundel reported an issue with a
stale struct proc pointer in similar code.

ok kettenis@, deraadt@

--8<-


Reverting the above commit fixes the issue for me.  Without the
reversion, SDL games freeze at a black screen if a joypad is
connected.  Invoking "kill -9" or unplugging the joypad is the
only way to unfreeze the program. 

For jeremy@, he reports that even without a joypad plugged in, his
system *thinks* he has one (because of some uhid buttons on his
keyboard), so none of these programs work for him at all.

>From looking at the commit message, it appears that it may have been
done to fix a bug, but the effect it's had is to render several SDL
programs unusable with a joypad, and unusable at all in jeremy@'s
case.

Unfortunately I cannot suggest a workaround other than a reversion,
but I'm willing to test any patches that attempt to fix this issue.

-- 
Bryan

Re: mednafen 0.9.39.2 -> 0.9.46

[Bryan Linton]

On 2017-08-13 23:44:55, Jeremy Evans  wrote:
> >
> > With that patch, mednafen 0.9.46 now works even when a gamepad is
> > plugged in. But I can't get mednafen to recognize the gamepad; it
> > doesn't let me map any of its keys.
> >
> > Also, I can say that mgba (the sdl version) has the same problem as the
> > unpatched mednafen. If a controller is plugged in, it shows only a black
> > screen and has to be killed. Works fine without a controller.
> >
> 
> It certainly appears as though this is an issue in sdl or below.  Looking
> at the devel/sdl history, there's no recent changes to it.  I tried
> recompiling mednafen and sdl with gcc to make sure it isn't a compiler
> issue, but got the same results.  The problem may be lower level. I'd like
> to look into this, but I probably won't have the necessary time for a few
> months.  If anyone else can work on it before then, I'd appreciate it.
> 

I can confirm seeing this in other SDL programs too.  dgen (SDL1),
desmume (SDL1), mgba (SDL2), fceux (SDL1), and retroarch (SDL2)
all display the same symptoms.

I tried to do some basic digging, but didn't have much luck.  I
noticed that there's an SDL_malloc() call right before joystick
initialization occurs in SDL1.  

Thinking that this as good a place to start as any, I patched
SDL_malloc() to just call malloc() directly but it didn't change
the behavior at all.

So then I tried to get a better backtrace, and got the following
from desmume:

[Switching to thread 521665]
futex () at -:3
3   -: No such file or directory.
in -
Current language:  auto; currently asm
(gdb) bt
#0  futex () at -:3
#1  0x05e1e50f5f85 in _rthread_cond_timedwait
(cond=0x5e1e5d8a4f0, 
mutexp=0x5e169916990, abs=0x0)
at /usr/src/lib/librthread/rthread_cond.c:106
#2  0x05df312ea13b in _ZL8taskProcPv (arg=0x5e169916980)
at utils/task.cpp:219
#3  0x05e1e50f7b9e in _rthread_start (v=Variable "v" is not available.)
at /usr/src/lib/librthread/rthread.c:115
#4  0x05e22b79460b in __tfork_thread ()
at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#5  0x in ?? ()
(gdb)

This seemed to point a finger at the new futex implementation, but
reverting the only recent commit there didn't change the behavior
at all.

So next I looked at utils/task.cpp:219 which is the following:

pthread_cond_wait(>condWork, >mutex);

So based on that and the rest of the above backtrace, as well as
the backtrace from mednafen previously posted in the thread which
was the following:

Thread 2 (thread 532442):
#0  _thread_sys_read () at -:3
#1  0x00021b23400f in _libc_read_cancel (fd=Variable "fd" is not available.)
at /usr/src/lib/libc/sys/w_read.c:27
#2  0x0002618d445d in SDL_SYS_JoystickUpdate () from
/usr/local/lib/libSDL.so.8.0
#3  0x0002618b9a35 in SDL_JoystickUpdate () from
/usr/local/lib/libSDL.so.8.0
#4  0x008ea7bb in __register_frame_info ()

It seems like looking at librthread would be the next logical
place.  Digging around in the CVS history, there were a lot of
recent commits to try testing and reverting though.

If I can find the time, I'll try to see if I can bisect it by date
at the very least, but if someone else wants to beat me to it,
please be my guest! :)

-- 
Bryan

Re: NEW: fonts/migmix, fonts/migu

[Bryan Linton]

On 2017-08-08 02:51:04, "Anthony J. Bentley"  wrote:
> On Sat, Feb 11, 2017 at 4:18 AM, Anthony J. Bentley  
> wrote:
> > Hi,
> >
> > The migmix and migu fonts are a mixture of M+ and IPA Gothic fonts,
> > focused on kanji coverage.
> 
> Ping?
>

They seem to work fine for me in LibreOffice.  Though one minor
thing I noticed is that, when opening the font selection drop-down
menu in LibreOffice, they don't seem to have the language
indicated to the right of the font the way the Sazanami and IPA
fonts do.

Other than that, they seem to work fine.

-- 
Bryan

Re: Qt 5.9.1 update

[Bryan Linton]

On 2017-07-22 20:43:44, Vadim Zhukov  wrote:
> 
> BTW, I won't recommend using neither qutebrowser or otter-browser on
> wild Internet: they're using QtWebkit which is a heavily outdated
> component, security-wise. The proper solution would be switch them to
> use QtWebEngine, but it is not ported yet, unfortunately. I'd
> recommend chromium/iridium or firefox/seamonkey - landry@ and robert@
> are successfully putting a lot of effort into those.
> 

Ah, good to know.  I'm aware that the older WebKit1 code is not
secure (former Xombrero neé XXXTerm user here.  Was sad to
see it go, but old code is old code so it can't be helped some
times).  I was under the impression qutebrowser was using the
newer, more secure and actively developed WebKit2 branch.

While I keep both Firefox and Iridium installed because some sites
like them better, I prefer more minimal browsers for regular
browsing.  Maybe I'll give luakit a try.  ISTR that it was updated
recently because they switched to the newer WebKit2 branch.

Anyway, thanks for the heads up!  And thanks for all the work you
put in to bringing the latest version of QT to OpenBSD! :)

-- 
Bryan

Re: Qt 5.9.1 update

[Bryan Linton]

On 2017-07-22 14:40:48, Vadim Zhukov  wrote:
> 
> Yes, I see problems, too. I suspect some problems with gstreamer,
> though - do you see gst-plugin-scanner crash when starting qutebrowser
> with --debug?
> 

Unfortunatly, I don't.  I ran "qutebrowser --debug" inside of a
/usr/bin/script session and the resulting output was 6,281 lines
long.

I get no hits grepping for "gst-plugin-scanner", "gst", "plugin",
"scanner", or "gstreamer".

In case it's relevant, I have the following gstreamer packages
installed:

% pkg_info -a | grep gst
clutter-gst-3.0.24  clutter GStreamer integration library
gstreamer-0.10.36p10 framework for streaming media
gstreamer-plugins-base-0.10.36p15 base elements for GStreamer
gstreamer1-1.12.2   framework for streaming media
gstreamer1-plugins-bad-1.12.2 bad elements for GStreamer
gstreamer1-plugins-base-1.12.2 base elements for GStreamer
gstreamer1-plugins-good-1.12.2 good elements for GStreamer
gstreamer1-plugins-libav-1.12.2 ffmpeg elements for GStreamer
gstreamer1-plugins-pulse-1.12.2 pulseaudio(1) element for GStreamer
gstreamer1-plugins-ugly-1.12.2 ugly elements for GStreamer
gstreamer1mm-1.8.0p2 C++ bindings for GStreamer

Is there anything else I can do to help debug this?

-- 
Bryan

Re: Qt 5.9.1 update

[Bryan Linton]

On 2017-07-21 18:33:51, Vadim Zhukov  wrote:
> Yep.
> 
> The issue was in QSslSocket, actually. The Qt library handles OpenSSL
> and his brothers specially, detecting features at run-time rather than
> at compile time. Thus breakage was not noticed earlier. I've just
> committed the fix in x11/qt5/qtbase port; the package should arrive in
> a few days on mirrors, or you could build it manually:
> 
>  cd /usr/ports/x11/qt5/qtbase
>  env MAKE_JOBS=$(sysctl hw.ncpu) make update
> 

Hello,

I recently updated to the latest snapshot and experienced the same
issue mentioned above.  Applying your patch fixes the TLS issue
described, but now when I run qutebrowser it immediately crashes
whenever I access a website.

It will start and run, but as soon as any site is loaded it
crashes with the following error:

13:41:48 ERROR: Uncaught exception
ValueError: list.remove(x): x not in list

qutebrowser's interal crash handler then launches, but if I click
"Don't report" it simply prints 

--- Logging error ---

to the terminal it was launched from and the window doesn't close.
I have to +c it to get it to stop, whereupon it dumps core.

I can open the settings menu from within qutebrowser just fine,
it's only accessing websites themselves that causes a crash.

I've attached a gdb backtrace, but it seems like it gets stuck in
a loop.  I've only attached a trace going back about 200 levels
deep.  I managed to hold down the enter key and see that it got
to over 8,000 (all the exact same line like the below) before I
gave up.

I've tried mv'ing my config files out of the way, and it doesn't
affect the behavior at all.

--8<
no debugging symbols found)
Core was generated by `python3.6'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.23.0...done.
Loaded symbols for /usr/lib/libpthread.so.23.0
Loaded symbols for /usr/local/bin/python3.6
Reading symbols from /usr/local/lib/libpython3.6m.so.0.0...done.
Loaded symbols for /usr/local/lib/libpython3.6m.so.0.0
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Symbols already loaded for /usr/lib/libpthread.so.23.0
Reading symbols from /usr/lib/libutil.so.12.2...done.
Loaded symbols for /usr/lib/libutil.so.12.2
Reading symbols from /usr/lib/libm.so.10.0...done.
Loaded symbols for /usr/lib/libm.so.10.0
Reading symbols from /usr/lib/libc.so.89.6...done.
Loaded symbols for /usr/lib/libc.so.89.6
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_heapq.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_heapq.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/zlib.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/zlib.so
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_bz2.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_bz2.so
Reading symbols from /usr/local/lib/libbz2.so.10.4...done.
Loaded symbols for /usr/local/lib/libbz2.so.10.4
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_lzma.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_lzma.so
Reading symbols from /usr/local/lib/liblzma.so.2.1...done.
Loaded symbols for /usr/local/lib/liblzma.so.2.1
Reading symbols from /usr/local/lib/python3.6/lib-dynload/grp.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/grp.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_struct.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_struct.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/binascii.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/binascii.so
Reading symbols from 
/usr/local/lib/python3.6/lib-dynload/_posixsubprocess.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_posixsubprocess.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/select.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/select.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/math.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/math.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_datetime.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/_datetime.so
Reading symbols from /usr/local/lib/python3.6/lib-dynload/pyexpat.so...done.
Loaded symbols for /usr/local/lib/python3.6/lib-dynload/pyexpat.so
Reading symbols from /usr/lib/libexpat.so.12.0...done.
Loaded symbols for /usr/lib/libexpat.so.12.0
Reading symbols from /usr/local/lib/python3.6/lib-dynload/_hashlib.so...done.
Loaded symbols for 

Re: [PATCH] textproc/ispell segfaults immediately on being run

[Bryan Linton]

On 2017-06-03 14:02:55, Stuart Henderson <s...@spacehopper.org> wrote:
> Ah good, it's the same with older libc so qsort isn't implicated.
> 
> On 2017/06/03 19:54, Bryan Linton wrote:
> > Hopefully this will allow you to duplicate this behavior.  If not,
> > please let me know what else I can do to help.
> 
> It does, thanks. I see the same if I update it to 3.4.00 (I've updated
> the port anyway as that was overdue).
> 
> I don't see where keywordbuf is intentionally getting set to anything
> other than a fresh malloc though, and don't know where to start looking
> to find something else that might be scribbling over it.
> 
> Simple replication of the problem: just run
> 
> DICTIONARY=/usr/local/lib/ispell/american.hash ispell
> 

Ah well, at least now I know what was causing it and a simple way
to avoid the crash, so I thank you for prodding me to dig a little
deeper :)

-- 
Bryan

Re: [PATCH] textproc/ispell segfaults immediately on being run

[Bryan Linton]

On 2017-06-03 10:59:17, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2017/06/03 17:59, Bryan Linton wrote:
> > On 2017-06-03 09:23:18, Stuart Henderson <s...@spacehopper.org> wrote:
> > > On 2017/06/03 15:50, Bryan Linton wrote:
> > > > 
> > > > Ping?  No users of ispell here?
> > > > 
> > > 
> > > It works here, can you build with symbols (make clean && make repackage
> > > DEBUG=-g) and get a backtrace?
> > > 
> > 
> > Sure, here it is, along with some more information that may be relevant.
> > 
> > % ispell
> > ispell(84800) in free(): bogus pointer (double free?) 0x687361
> > zsh: abort (core dumped)  ispell
> 
> > #2  0x19945ba50566 in wrterror (d=0x7f7ea720, 
> > msg=0x19945bb82168 "bogus pointer (double free?) %p")
> > at /usr/src/lib/libc/stdlib/malloc.c:306
> > #3  0x19945ba51c8d in ofree (argpool=0x19946bab8c60, p=0x687361, 
> > clear=0,
> > check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1411
> > #4  0x19945ba51f03 in free (ptr=0x687361)
> > at /usr/src/lib/libc/stdlib/malloc.c:1444
> > #5  0x1991e3c07711 in init_keyword_table (rawtags=Variable "rawtags" is 
> > not available.
> > ) at defmt.c:1316
> > #6  0x1991e3c01a66 in main (argc=0, argv=0x7f7ebb30) at ispell.c:889
> 
> 0x687361 (keywordbuf) seems unlikely to be a correct address and the
> fact that it's a representation of ascii chars "ash" seems like it could
> be more than a coincidence.
> 
> It would be really nice to be able to replicate this, let's try to
> figure out what's different about your setup.
> 
> Do you have any .ispell* files?
>

Yes, however mv'ing them away does not change the behavior.  But
see below.

> Do you have any of the other dictionary packages (ispell-dutch,
> ispell-french, etc) installed?
>

% pkg_info -a | grep ispell
ispell-3.2.06p9 interactive spelling checker
%

> Does it happen with a clean environment ("env -i ispell") as well?
> If not, what's in your usual environment?
> 

"env -i ispell" works just fine for me, so I did some digging.

% env | grep ispell
DICTIONARY=/usr/local/lib/ispell/american.hash
% ispell 
ispell(4541) in free(): bogus pointer (double free?) 0x687361
zsh: abort (core dumped)  ispell
% DICTIONARY=/usr/local/lib/ispell/british.hash 
% ispell
ispell(22859) in free(): bogus pointer (double free?) 0x6873
zsh: abort (core dumped)  ispell
% DICTIONARY=/usr/local/lib/ispell/default.hash 
% ispell
ispell(87738) in free(): bogus pointer (double free?) 0x6873
zsh: abort (core dumped)  ispell
% DICTIONARY=/usr/local/lib/ispell/americanmed+.hash
% ispell
ispell(57185) in free(): bogus pointer (double free?) 0x68736168002b64
zsh: abort (core dumped)  ispell

0x68736168002b64 would appear to be "hsah+d" when read
forwards and "d+hash" when read backwards.

It would appear that the hash files are somehow causing this
behavior.  Also, to reiterate, when ispell is compiled with clang,
this crash does not happen.  I'm not sure what clang might be
doing differently, but I figure it might be pertinent information
to have.

Hopefully this will allow you to duplicate this behavior.  If not,
please let me know what else I can do to help.

-- 
Bryan

Re: [PATCH] textproc/ispell segfaults immediately on being run

[Bryan Linton]

On 2017-06-03 09:23:18, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2017/06/03 15:50, Bryan Linton wrote:
> > 
> > Ping?  No users of ispell here?
> > 
> 
> It works here, can you build with symbols (make clean && make repackage
> DEBUG=-g) and get a backtrace?
> 

Sure, here it is, along with some more information that may be relevant.

% ispell
ispell(84800) in free(): bogus pointer (double free?) 0x687361
zsh: abort (core dumped)  ispell

% gdb `which ispell` ispell.core 
Core was generated by `ispell'.
Program terminated with signal 6, Aborted.
Loaded symbols for /usr/local/bin/ispell
Reading symbols from /usr/lib/libtermcap.so.14.0...done.
Loaded symbols for /usr/lib/libtermcap.so.14.0
Reading symbols from /usr/lib/libc.so.89.5...done.
Loaded symbols for /usr/lib/libc.so.89.5
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x19945ba0a2da in thrkill () at {standard input}:5
5   {standard input}: No such file or directory.
in {standard input}
(gdb) bt
#0  0x19945ba0a2da in thrkill () at {standard input}:5
#1  0x19945ba24429 in *_libc_abort ()
at /usr/src/lib/libc/stdlib/abort.c:52
#2  0x19945ba50566 in wrterror (d=0x7f7ea720, 
msg=0x19945bb82168 "bogus pointer (double free?) %p")
at /usr/src/lib/libc/stdlib/malloc.c:306
#3  0x19945ba51c8d in ofree (argpool=0x19946bab8c60, p=0x687361, clear=0,
check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1411
#4  0x19945ba51f03 in free (ptr=0x687361)
at /usr/src/lib/libc/stdlib/malloc.c:1444
#5  0x1991e3c07711 in init_keyword_table (rawtags=Variable "rawtags" is not 
available.
) at defmt.c:1316
#6  0x1991e3c01a66 in main (argc=0, argv=0x7f7ebb30) at ispell.c:889
Current language:  auto; currently asm
(gdb) quit

% ls -la /etc/malloc.conf
ls: /etc/malloc.conf: No such file or directory

% env | grep MALLOC
% dmesg
OpenBSD 6.1-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #11: Tue May 23 
19:10:56 JST 2017

shoshon...@shoshoni-m.shoshoni.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS
real mem = 12539871232 (11958MB)
avail mem = 12154036224 (11590MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbcc0d000 (67 entries)
bios0: vendor LENOVO version "GLET85WW (2.39 )" date 09/29/2016
bios0: LENOVO 20AWS27D00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4) XHCI(S3) 
EHC1(S3) EHC2(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2594.33 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2594330880 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2594.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2594.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2594.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,M

Re: [PATCH] textproc/ispell segfaults immediately on being run

[Bryan Linton]

On 2017-05-27 18:02:54, Bryan Linton <b...@shoshoni.info> wrote:
> Hello ports@
> 
> I noticed that somehow, ispell now segfaults immediately upon
> being run with an error such as:
> 
>   ispell(67135) in free(): bogus pointer (double free?) 0x687361
> 
> [...]
> 
> ispell Just Works(TM) when compiled with clang.
> 
> [...]
>

Ping?  No users of ispell here?

-- 
Bryan

[PATCH] textproc/ispell segfaults immediately on being run

[Bryan Linton]

Hello ports@

I noticed that somehow, ispell now segfaults immediately upon
being run with an error such as:

ispell(67135) in free(): bogus pointer (double free?) 0x687361

I compiled it with debug symbols, and attemped to debug it with gdb.
However, I'm still in the process of learning how to debug things,
and couldn't fix it even after poking at a few things here and there.

I attemped to compile ispell with clang, since IMO clang sometimes
gives better error messages than GCC and surprisingly enough,
ispell Just Works(TM) when compiled with clang.

Yes, I know this is probably just painting over a real problem in
ispell that should be fixed, but it gets ispell working for me.

I also realized after making the attached patch, that ispell
3.4.00 has been released, whereas the current version in ports is
3.2.06.  It may be easier to just update the port.  I'll attempt
to do so myself if I can find some extra time soon.

-- 
Bryan

Index: Makefile
===
RCS file: /cvs/ports/textproc/ispell/Makefile,v
retrieving revision 1.64
diff -u -r1.64 Makefile
--- Makefile3 Dec 2015 21:24:32 -   1.64
+++ Makefile27 May 2017 09:01:10 -
@@ -14,6 +14,10 @@
 DISTNAME=  ispell-${VERSION}
 CATEGORIES=textproc
 
+MODULES=   lang/clang
+MODCLANG_ARCHS=*
+MODCLANG_LANGS= c c++
+
 HOMEPAGE=  http://fmg-www.cs.ucla.edu/geoff/ispell.html
 
 MASTER_SITES=  http://fmg-www.cs.ucla.edu/geoff/tars/ \
@@ -57,7 +61,7 @@
 SUBST_VARS+=   VERSION
 
 PKGNAME-main=  ${DISTNAME}
-REVISION-main= 9
+REVISION-main= 10
 MULTI_PACKAGES=-main -dutch -french -german -swedish -russian 
-portuguese \
-slovak -spanish
 .for i in ${MULTI_PACKAGES}

Re: [UPDATE] net/irssi 1.0.2

[Bryan Linton]

On 2017-05-20 22:15:27, viq  wrote:
> Long overdue and very simple patch bringing irssi to latest 1.0.2
> Lightly tested on amd64.
>

Works for me on amd64 -CURRENT.  No regressions seen with any of
the various scripts I use from the irssi website either.

-- 
Bryan

Re: [NEW] emulators/ucon64

[Bryan Linton]

On 2017-04-13 15:55:06, Frederic Cambus  wrote:
> Hi ports@,
> 
> Here is a new port: emulators/ucon64
> 
> Comments? OK?
> 
> >From DESCR:
> 
> uCON64 is the emulator Swiss Army knife program.
> 
> It supports almost every video game system (Consoles, Handheld, Arcade),
> as well as all common patch file formats like IPS (with RLE compression),
> APS, BSL (Baseline Patch format), PPF (Playstation Patch File), and Game
> Genie.
>

Compiles and runs fine for me on amd64 -CURRENT.

-- 
Bryan

Re: NEW: textproc/omegat computer-assisted translation tool

[Bryan Linton]

Ping?  (One last time)

Even if this doesn't get committed, it'd be nice to know if
there's anything I could be doing better even if it only lives in
ports/mystuff...

-- 
Bryan

On 2017-02-03 22:51:43, Bryan Linton <b...@shoshoni.info> wrote:
> Ping?
> 
> I realize this is an extremely niche piece of software, but the
> port seems to be simple enough considering it's just a thin
> wrapper around a Java JAR file.
> 
> -- 
> Bryan
> 
> On 2017-01-29 15:08:23, Bryan Linton <b...@shoshoni.info> wrote:
> > Hello ports@,
> > 
> > Please find the attached tarball for OmegaT, a computer-assisted
> > translation (CAT) tool (not to be confused with machine
> > translation (MT).
> > 
> > >From DESCR:
> > 
> > ---8<--
> > 
> > OmegaT is a free translation memory application written in Java.
> > It is a tool intended for professional translators. It does not
> > translate for you! (Software that does this is called "machine
> > translation", and you will have to look elsewhere for it.)
> > 
> > ---8<--
> > 
> > I heavily ripped off^W^W based the Makefile on the one used for
> > devel/intellij so I'd appreciate any extra eyes looking out for
> > superfluous things that can be removed.
> > 
> > The only patch necessary was in the shell-script that launches
> > OmegaT.  I changed /bin/bash to /bin/sh and reduced the
> > pre-allocated Java heap from 1024 MB to 800 MB since it would
> > error out with the default.  I also forced anti-aliasing to be on
> > because the fonts were absolutely HIDEOUS and eye-strain inducing
> > without it.
> > 
> > I tried using it for basic functionality, and it seems no worse
> > for the wear, but importing 800+ MB of text to translate might be
> > a different story.  Though I would argue that if one had *that*
> > much text to translate, one would already be breaking it up into
> > smaller chunks anyway.
> > 
> > Anyway, any questions, comments, or suggestions are welcome.
> > 
> > -- 
> > Bryan
> > 
> 

Re: inputmethods/uim not working in www/qutebrowser, QT5 related?

[Bryan Linton]

On 2017-02-09 00:40:58, "Anthony J. Bentley" <anth...@anjbe.name> wrote:
> Bryan Linton writes:
> > I'm assuming this is probably because qutebrowser uses PyQt5 and
> > there is currently no QT5-based plugin for UIM being built.  From
> > looking at the source, it seems like the support is there [1] but
> > the qt5 directory is not bundled with the latest 1.8.6 release of
> > UIM.  It also looks like the last official release of UIM was in
> > 2013, even though the last commit was in Nov. 2016. [2]
> > 
> > It looks like Debian is pulling from a github snapshot to build
> > uim-qt5 [3].
> 
> Please try convincing upstream about making a new release... they can't
> reasonably expect packagers to know what's a good git revision to use as
> a snapshot.
> 

I just sent an email politely asking if a new release could be
made.  I'll keep the list informed.

-- 
Bryan

UPDATE: inputmethods/scim* HOMEPAGE is out of date

[Bryan Linton]

Hello ports@,

Please find the attached file which updates most all of the
inputmethods/scim* ports to a new updated HOMEPAGE.

It looks like the old domain name expired and now points to a
personal blog of some sort.

It looks like they also have a Github page which could be used
instead of Sourceforge, but I figured the port is using
Sourceforge in MASTER_SITES so I went with SF instead of GH.

I have no strong opinion either way, so if it would be better to
point it to Github instead, then that's fine too.

-- 
Bryan

Index: scim/Makefile
===
RCS file: /cvs/ports/inputmethods/scim/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- scim/Makefile   18 Mar 2016 23:12:18 -  1.25
+++ scim/Makefile   6 Feb 2017 11:39:49 -
@@ -11,7 +11,7 @@
 
 CATEGORIES =   inputmethods chinese japanese korean
 
-HOMEPAGE = http://www.scim-im.org/
+HOMEPAGE = http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM = Yes
Index: scim-chewing/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-chewing/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- scim-chewing/Makefile   18 Mar 2016 23:12:18 -  1.18
+++ scim-chewing/Makefile   6 Feb 2017 11:39:49 -
@@ -7,7 +7,7 @@
 
 CATEGORIES=inputmethods chinese
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: scim-fcitx/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-fcitx/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- scim-fcitx/Makefile 18 Mar 2016 21:38:24 -  1.9
+++ scim-fcitx/Makefile 6 Feb 2017 11:39:49 -
@@ -9,7 +9,7 @@
 
 CATEGORIES=inputmethods chinese
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: scim-hangul/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-hangul/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- scim-hangul/Makefile18 Mar 2016 21:38:24 -  1.18
+++ scim-hangul/Makefile6 Feb 2017 11:39:49 -
@@ -7,7 +7,7 @@
 
 CATEGORIES=inputmethods korean
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: scim-pinyin/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-pinyin/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- scim-pinyin/Makefile18 Mar 2016 21:38:24 -  1.15
+++ scim-pinyin/Makefile6 Feb 2017 11:39:49 -
@@ -7,7 +7,7 @@
 
 CATEGORIES=inputmethods chinese
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: scim-qtimm/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-qtimm/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- scim-qtimm/Makefile 18 Mar 2016 23:12:18 -  1.16
+++ scim-qtimm/Makefile 6 Feb 2017 11:39:49 -
@@ -7,7 +7,7 @@
 
 CATEGORIES=inputmethods
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: scim-tables/Makefile
===
RCS file: /cvs/ports/inputmethods/scim-tables/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- scim-tables/Makefile18 Mar 2016 21:38:24 -  1.17
+++ scim-tables/Makefile6 Feb 2017 11:39:49 -
@@ -7,7 +7,7 @@
 
 CATEGORIES=inputmethods chinese japanese korean
 
-HOMEPAGE=  http://www.scim-im.org/
+HOMEPAGE=  http://sourceforge.net/projects/scim/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes

inputmethods/uim not working in www/qutebrowser, QT5 related?

[Bryan Linton]

Hello,

Since several of the older, webkit-based browsers either have
been, or are currently in the process of being retired, I switched
from xombrero to qutebrowser and noticed a small issue.

I have inputmethods/uim working in all other applications by
virtue of having the following ports installed: 

uim-1.8.6p1 multilingual input method library
uim-gtk-1.8.6p1 uim for GTK+2
uim-gtk3-1.8.6p2uim for GTK+3
uim-qt-1.8.6p1  uim for QT3
uim-qt4-1.8.6p1 uim for QT4

However, UIM does not work at all in qutebrowser.

I'm assuming this is probably because qutebrowser uses PyQt5 and
there is currently no QT5-based plugin for UIM being built.  From
looking at the source, it seems like the support is there [1] but
the qt5 directory is not bundled with the latest 1.8.6 release of
UIM.  It also looks like the last official release of UIM was in
2013, even though the last commit was in Nov. 2016. [2]

It looks like Debian is pulling from a github snapshot to build
uim-qt5 [3].

I know that beggars can't be choosers, but if anyone on the QT5
porting team is willing to continue the great effort they've put
into getting so much of it working on OpenBSD by porting over the
QT5 module for UIM too, I (and probably other users) would be very
grateful.

[1] https://github.com/uim/uim/tree/master/qt5
[2] https://github.com/uim/uim/releases
[3] https://packages.debian.org/sid/uim-qt5

-- 
Bryan

Re: NEW: textproc/omegat computer-assisted translation tool

[Bryan Linton]

Ping?

I realize this is an extremely niche piece of software, but the
port seems to be simple enough considering it's just a thin
wrapper around a Java JAR file.

-- 
Bryan

On 2017-01-29 15:08:23, Bryan Linton <b...@shoshoni.info> wrote:
> Hello ports@,
> 
> Please find the attached tarball for OmegaT, a computer-assisted
> translation (CAT) tool (not to be confused with machine
> translation (MT).
> 
> >From DESCR:
> 
> ---8<--
> 
> OmegaT is a free translation memory application written in Java.
> It is a tool intended for professional translators. It does not
> translate for you! (Software that does this is called "machine
> translation", and you will have to look elsewhere for it.)
> 
> ---8<--
> 
> I heavily ripped off^W^W based the Makefile on the one used for
> devel/intellij so I'd appreciate any extra eyes looking out for
> superfluous things that can be removed.
> 
> The only patch necessary was in the shell-script that launches
> OmegaT.  I changed /bin/bash to /bin/sh and reduced the
> pre-allocated Java heap from 1024 MB to 800 MB since it would
> error out with the default.  I also forced anti-aliasing to be on
> because the fonts were absolutely HIDEOUS and eye-strain inducing
> without it.
> 
> I tried using it for basic functionality, and it seems no worse
> for the wear, but importing 800+ MB of text to translate might be
> a different story.  Though I would argue that if one had *that*
> much text to translate, one would already be breaking it up into
> smaller chunks anyway.
> 
> Anyway, any questions, comments, or suggestions are welcome.
> 
> -- 
> Bryan
> 

NEW: textproc/omegat computer-assisted translation tool

[Bryan Linton]

Hello ports@,

Please find the attached tarball for OmegaT, a computer-assisted
translation (CAT) tool (not to be confused with machine
translation (MT).

>From DESCR:

---8<--

OmegaT is a free translation memory application written in Java.
It is a tool intended for professional translators. It does not
translate for you! (Software that does this is called "machine
translation", and you will have to look elsewhere for it.)

---8<--

I heavily ripped off^W^W based the Makefile on the one used for
devel/intellij so I'd appreciate any extra eyes looking out for
superfluous things that can be removed.

The only patch necessary was in the shell-script that launches
OmegaT.  I changed /bin/bash to /bin/sh and reduced the
pre-allocated Java heap from 1024 MB to 800 MB since it would
error out with the default.  I also forced anti-aliasing to be on
because the fonts were absolutely HIDEOUS and eye-strain inducing
without it.

I tried using it for basic functionality, and it seems no worse
for the wear, but importing 800+ MB of text to translate might be
a different story.  Though I would argue that if one had *that*
much text to translate, one would already be breaking it up into
smaller chunks anyway.

Anyway, any questions, comments, or suggestions are welcome.

-- 
Bryan



omegat-4.1.0.tar.gz
Description: application/tar-gz

Re: openvpn-2.4.0

[Bryan Linton]

On 2017-01-17 09:29:18, Jeremie Courreges-Anglas  wrote:
> 
> Lots of improvements, seems to work fine here but please check that your
> use case still works.
> 

Only lightly tested, but works for me in my use-case at least.

-- 
Bryan

Re: Re: Re: [NEW] games/ags

[Bryan Linton]

On 2016-11-26 15:43:41, David Meier <d...@beginvest.ch> wrote:
>On 11/24/16 09:52, Bryan Linton wrote:
>>
>> The good news is that it builds successfully now, the bad news is
>> that it dumps core with an mprotect error.  "wxallowed" is set on
>> /usr/local from where it runs.
> 
> Thank you. I've updated the port with wxallow and tested it now
> successfully with several games on i386-current and amd64-current.
> 
> Ok?

Seems to work OK for me now.  Anyone else want to test it too?

-- 
Bryan

Re: Re: [NEW] games/ags

[Bryan Linton]

On 2016-11-23 02:11:36, David Meier <d...@beginvest.ch> wrote:
> On 11/22/16 10:28, Bryan Linton wrote:
> >
> >It won't build for me on i386.  I'm not sure if it may be a
> >problem with my system, or if it's i386 itself.
> 
> I've now set up a VM with i386-current to build it,
> and got a similar error. I've added:
> BUILD_DEPENDS = audio/dumb
> to the Makefile. Now it builds here on i386.
> 
> Ok?
> 

The good news is that it builds successfully now, the bad news is
that it dumps core with an mprotect error.  "wxallowed" is set on
/usr/local from where it runs.

The last few lines from ags:

Preparing graphics mode screen
Initializing colour conversion
Mouse control: on, base: 1.00, speed: 1.00
Check for preload image
Initialize sprites
Set up screen
Initialize game settings
Cannot open translation: default.tra
Prepare to start game
Mouse confined: (0,0)-(1599,1199) (1600x1200)
Audio is processed on the main thread
Checking replay status
Engine initialization complete
Starting game
allegro-error: mprotect failed during stretched blit!: Not supported
Shutting down Allegro due to signal #11
zsh: segmentation fault (core dumped)  ags

% which ags
/usr/local/bin/ags

% mount
/dev/sd1a on / type ffs (local)
mfs:42673 on /tmp type mfs (asynchronous, local, nodev, nosuid,
size=524288 512-blocks)
/dev/sd1d on /usr type ffs (local, nodev, softdep)
/dev/sd1e on /usr/X11R6 type ffs (local, nodev, softdep)
/dev/sd1f on /usr/local type ffs (local, nodev, wxallowed, softdep)
/dev/sd1g on /usr/obj type ffs (local, nodev, nosuid, wxallowed, softdep)
/dev/sd1h on /usr/src type ffs (local, nodev, nosuid, softdep)
/dev/sd1i on /var type ffs (local, nodev, nosuid)
/dev/sd1k on /home type ffs (NFS exported, local, nodev, nosuid, softdep)

(Hopefully) the relevant lines from ktrace:
% kdump -f ktrace.out |grep -C5 mprotect | tail -20
 18275 ags  RET   kbind 0
--
 18275 ags  RET   kbind 0
 18275 ags  CALL  kbind(0xcf7e9c58,12,0xb4bbe835d930fe69)
 18275 ags  RET   kbind 0
 18275 ags  CALL  kbind(0xcf7e9c78,12,0xb4bbe835d930fe69)
 18275 ags  RET   kbind 0
 18275 ags  CALL  
mprotect(0x7ed6c000,0x1800,0x7<PROT_READ|PROT_WRITE|PROT_EXEC>)
 18275 ags  RET   mprotect -1 errno 91 Not supported
 18275 ags  CALL  kbind(0xcf7e9c78,12,0xb4bbe835d930fe69)
 18275 ags  RET   kbind 0
 18275 ags  CALL  writev(2,0xcf7e9bb8,4)
 18275 ags  STRU  struct iovec [4] { base=0x231b2754, len=53 } { 
base=0x2b7c1bc0, len=2 } { base=0xcf7e9bd9, len=13 } { base=0x2b7c082b, len=1 }
 18275 ags  GIO   fd 2 wrote 53 bytes
   "allegro-error: mprotect failed during stretched blit!"
 18275 ags  GIO   fd 2 wrote 2 bytes
   ": "
 18275 ags  GIO   fd 2 wrote 13 bytes
   "Not supported"
 18275 ags  GIO   fd 2 wrote 1 bytes

If I can provide any further information, please let me know.

-- 
Bryan

Re: [NEW] games/ags

[Bryan Linton]

On 2016-11-22 00:21:29, David Meier  wrote:
> Hello
> 
> I've tested this port on amd64.
> Can anyone take a look or commit this port?
> If patches/files are ok, I try to push them upstream.
> 
> Some games need to be extracted with innoextract
> to play them with ags.
> 

It won't build for me on i386.  I'm not sure if it may be a
problem with my system, or if it's i386 itself.

Full-disclosure, while I *am* using a custom kernel, the only
difference is that I've enabled the PPPOE_TERM_UNKNOWN_SESSIONS
option.

OpenBSD 6.0-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #0: Sat Nov 12 
10:44:54 JST 2016

It's a fairly recent system, but if something drastic changed in
the last two weeks, I can try upgrading and trying to build it
again.

Build log:

platform/util/pe.o
platform/util/libc.o
../Common/core/asset.o
../Common/core/assetmanager.o
../Common/font/ttffontrenderer.o
../Common/font/fonts.o
../Common/font/wfnfont.o
../Common/font/wfnfontrenderer.o
../Common/game/customproperties.o
../Common/game/interactions.o
../Common/gui/guibutton.o
../Common/gui/guiinv.o
../Common/gui/guilabel.o
../Common/gui/guilistbox.o
../Common/gui/guiobject.o
../Common/gui/guimain.o
../Common/gui/guitextbox.o
../Common/gui/guislider.o
../Common/script/cc_treemap.o
../Common/util/compress.o
../Common/util/ini_util.o
../Common/util/filestream.o
../Common/util/alignedstream.o
../Common/util/inifile.o
Linking common library...
ar: common.a: Malformed archive
gmake: *** [Makefile:38: common.a] Error 1
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2682
'/usr/obj/ports/ags-3.4.0.13/.build_done')
*** Error 1 in /usr/ports/mystuff/games/ags
(/usr/ports/infrastructure/mk/bsd.port.mk:2389 'all')


-- 
Bryan

Re: Update emulators/mednafen 0.9.38.7 -> 0.9.39.2

[Bryan Linton]

On 2016-10-19 22:41:27, Jeremy Evans  wrote:
> Update to the latest medafen release.  The major change in this update
> is the addition of Saturn support, which I tested and does appear to
> work (at least with Shanghai Triple Threat).
> 

Lightly tested on i386.  No regressions seen.  Seems OK to me.

-- 
Bryan

Re: UPDATE: emulators/snes9x

[Bryan Linton]

On 2016-10-18 00:43:48, "Anthony J. Bentley"  wrote:
> Hi,
> 
> Here is an update to the recently released snes9x-1.54.1.
> 
> It looks like there is no longer any asm--would appreciate a test on i386.
> 
> ok?
> 

Lightly tested on i386.  Seems to work fine.  No regressions seen
so far.

-- 
Bryan

Re: openvpn broken caused by a change in route add and delete

[Bryan Linton]

I can confirm that this fixes OpenVPN in my use-case at least.

Thank you for the patch!

-- 
Bryan

On 2016-09-14 08:16:18, Brent Cook  wrote:
> phessler and I looked at this last week, and if I understand correctly,
> the indirect gateway address was the main problem here. We manually
> added a route via the tunnel address instead, and things seemed to work
> as expected.
> 
> So, would a patch like this make more sense?
> 
> Wed Sep 14 08:08:28 2016 ROUTE_GATEWAY 192.168.22.1
> Wed Sep 14 08:08:28 2016 TUN/TAP device /dev/tun0 opened
> Wed Sep 14 08:08:28 2016 do_ifconfig, tt->ipv6=0,
> tt->did_ifconfig_ipv6_setup=0
> Wed Sep 14 08:08:28 2016 /sbin/ifconfig tun0 10.8.0.4 10.8.0.4 mtu 1500
> netmask 255.255.255.0 up
> Wed Sep 14 08:08:28 2016 /sbin/route add -net 10.8.0.0 10.8.0.4 -netmask
> 255.255.255.0
> add net 10.8.0.0: gateway 10.8.0.4
> Wed Sep 14 08:08:28 2016 /sbin/route add -net 104.238.145.134 10.8.0.4
> -netmask 255.255.255.255
> add net 104.238.145.134: gateway 10.8.0.4
> Wed Sep 14 08:08:28 2016 /sbin/route add -net 0.0.0.0 10.8.0.4 -netmask
> 128.0.0.0
> add net 0.0.0.0: gateway 10.8.0.4
> Wed Sep 14 08:08:28 2016 /sbin/route add -net 128.0.0.0 10.8.0.4
> -netmask 128.0.0.0
> add net 128.0.0.0: gateway 10.8.0.4
> Wed Sep 14 08:08:28 2016 Initialization Sequence Completed
> ^CWed Sep 14 08:08:32 2016 event_wait : Interrupted system call (code=4)
> Wed Sep 14 08:08:32 2016 SIGTERM received, sending exit notification to
> peer
> Wed Sep 14 08:08:37 2016 /sbin/route delete -net 104.238.145.134
> 10.8.0.4 -netmask 255.255.255.255
> delete net 104.238.145.134: gateway 10.8.0.4
> Wed Sep 14 08:08:37 2016 /sbin/route delete -net 0.0.0.0 10.8.0.4
> -netmask 128.0.0.0
> delete net 0.0.0.0: gateway 10.8.0.4
> Wed Sep 14 08:08:37 2016 /sbin/route delete -net 128.0.0.0 10.8.0.4
> -netmask 128.0.0.0
> delete net 128.0.0.0: gateway 10.8.0.4
> Wed Sep 14 08:08:37 2016 Closing TUN/TAP interface
> Wed Sep 14 08:08:37 2016 SIGTERM[soft,exit-with-notification] received,
> process exiting
> 
> --- route.c.orig  Wed Sep 14 07:55:13 2016
> +++ route.c   Wed Sep 14 08:07:45 2016
> @@ -1301,6 +1301,7 @@
>const char *network;
>const char *netmask;
>const char *gateway;
> +  const char *local;
>bool status = false;
>int is_local_route;
> 
> @@ -1313,6 +1314,7 @@
>network = print_in_addr_t (r->network, 0, );
>netmask = print_in_addr_t (r->netmask, 0, );
>gateway = print_in_addr_t (r->gateway, 0, );
> +  local   = print_in_addr_t (tt->local, 0, );
> 
>is_local_route = local_route(r->network, r->netmask, r->gateway, rgi);
>if (is_local_route == LR_ERROR)
> @@ -1503,7 +1505,7 @@
> 
>argv_printf_cat (, "-net %s %s -netmask %s",
> network,
> -   gateway,
> +   local,
> netmask);
> 
>/* FIXME -- add on-link support for OpenBSD/NetBSD */
> @@ -1751,6 +1753,7 @@
>const char *network;
>const char *netmask;
>const char *gateway;
> +  const char *local;
>int is_local_route;
> 
>if ((r->flags & (RT_DEFINED|RT_ADDED)) != (RT_DEFINED|RT_ADDED))
> @@ -1762,6 +1765,7 @@
>network = print_in_addr_t (r->network, 0, );
>netmask = print_in_addr_t (r->netmask, 0, );
>gateway = print_in_addr_t (r->gateway, 0, );
> +  local   = print_in_addr_t (tt->local, 0, );
> 
>is_local_route = local_route(r->network, r->netmask, r->gateway, rgi);
>if (is_local_route == LR_ERROR)
> @@ -1883,7 +1887,7 @@
>argv_printf (, "%s delete -net %s %s -netmask %s",
>   ROUTE_PATH,
> network,
> -   gateway,
> +   local,
> netmask);
> 
>argv_msg (D_ROUTE, );
> 
> On Tue, Sep 13, 2016 at 11:45:22PM +0100, Stuart Henderson wrote:
> > There's clearly some problem, others have seen breakage too, but I don't see
> > why replacing -netmask to /prefix would change anything..
> >
> >
> > On 13 September 2016 22:35:54 Sander van Kranenburg 
> > wrote:
> >
> > > Hi,
> > >
> > > GMBL so it's probably my vpn provider that doesn't work with 6.0.
> > > Thx for your time and the great support.
> > >
> > > Best regards,
> > >
> > > Sander van Kranenburg
> > >
> > > -Oorspronkelijk bericht-
> > > Van: Stuart Henderson [mailto:s...@spacehopper.org]
> > > Verzonden: dinsdag 13 september 2016 23:26
> > > Aan: Sander van Kranenburg 
> > > CC: ports@openbsd.org
> > > Onderwerp: Re: openvpn broken caused by a change in route add and delete
> > >
> > > On 2016/09/13 21:20, Sander van Kranenburg wrote:
> > > > Hi,
> > > >
> > > > Are you at openbsd 6.0 at the moment?
> > > > This is my uname -a OpenBSD openbsd.HOME.local 6.0 GENERIC#0 i386.
> > > > -netmask doesn't work at all for me since i updated tot 6.0
> > >
> > > -current from a few days ago, but I just also tested it on 6.0 release.
> > >
> > >
> > > > Van: Stuart Henderson [mailto:s...@spacehopper.org]
> > > > Verzonden: dinsdag 13 september 2016 23:07
> > > > Aan: Sander 

Re: openvpn-2.3.11 segfaults, error "Too many levels of symbolic links"

[Bryan Linton]

On 2016-09-10 21:29:29, Jiri B  wrote:
> 
> Thanks I do not see segfaults anymore but issue about 'too many symbolic 
> links'
> is strange. I doubt they have changed anything on remote OpenVPN gw.
> 

I'm seeing this too.  From reading this thread on bugs@, it looks
like support for this was removed from the /sbin/route command (as
well as the kernel itself) to enable upcoming support for other
features.

Unfortunately, it doesn't look like support for having
non-directly-connected static routes is planned to be re-added
anytime soon, because it would interfere with the current efforts
to move the network stack to a more SMP-friendly design.

http://marc.info/?l=openbsd-bugs=147291674529119=2

If anyone has any suggestions for a workaround, please enlighten
me.  Unfortunately I don't have control over the server in my
case, so changing the "topology subnet" to "topology p2p" as
suggested previously in the thread isn't something I can do in my
case.

-- 
Bryan

Re: UPDATE: snes9x to 1.53

[Bryan Linton]

On 2016-05-07 16:59:38, Florian Stinglmayr <flor...@n0la.org> wrote:
> On Sat, May 07, 2016 at 09:32:15PM +0900, Bryan Linton wrote:
> > I tried to build it, but some patches fail to apply.  I'm running
> > a recent -current (it's just GENERIC.MP with the
> > PPPOE_TERM_UNKNOWN_SESSIONS option enabled due to my ISP.
> > OpenBSD 5.9-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #3: Tue 
> > May  3 11:41:06 JST 2016
> >
> > I'm running with a ports tree updated from a similar time frame,
> > and I tried updating emulators/snes9x before applying it and it
> > still gives me an error.  Am I doing something wrong?
> >
> 
> Below is an updated patch, could you apply it with -p0 to the current
> CVS of ports and try again to build it?
> 

Seems to build and work fine for me.

One minor nit: After updating, snes9x seemed to either lose
information about some filepaths I had set up, or maybe I never
set them up in the first place and the defaults changed.

Either way, it only took a second to set them back to where they
were supposed to be, and it seems to run fine for me.

Unless someone steps up saying this breaks something, I'd say it
works well enough to go in.

-- 
Bryan

Re: UPDATE: ledger 3.1.1

[Bryan Linton]

On 2016-05-08 20:52:24, Ray Lai  wrote:
> On Tue, 3 May 2016 19:24:00 +0200
> Florian Stinglmayr  wrote:
> 
> > On Mon, May 02, 2016 at 02:48:28PM +0800, Ray Lai wrote:
> >  [...]  
> > 
> > This patch works fine for me, and ledger works fine on my
> > ledger files. But someone with more complex files should also
> > probably take a look and test.
> 
> I've enabled the test suite. It doesn't pass completely; for some
> reason "ledger balance --time-report" always sets
> latest_checkout_cleared, which causes ansi codes to be printed, even
> with --no-color. I don't know enough C++ to debug the cause, but I
> suspect that latest_checkout_cleared is being used uninitialized.
> 
> For some reason the sort order also seems to be off a bit. But in terms
> of numbers, everything seems A-okay.
> 
> For more details, run "make test" and look at:
> /home/ports/pobj/ledger-3.1.1/build-amd64/test/Testing/Temporary/LastTest.log
> 

I'm just chiming in to quickly say that the 3.1.1 version works
for my usage case so far.  I added the following to .ledgerrc to
restore the behavior of the 2.x series and I'm happy with
everything so far:
--no-color 
--no-pager

-- 
Bryan

Re: UPDATE: snes9x to 1.53

[Bryan Linton]

On 2016-05-07 11:05:00, Florian Stinglmayr  wrote:
> ping?
> 

I tried to build it, but some patches fail to apply.  I'm running
a recent -current (it's just GENERIC.MP with the
PPPOE_TERM_UNKNOWN_SESSIONS option enabled due to my ISP.
OpenBSD 5.9-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #3: Tue 
May  3 11:41:06 JST 2016

I'm running with a ports tree updated from a similar time frame,
and I tried updating emulators/snes9x before applying it and it
still gives me an error.  Am I doing something wrong?


Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Hi,
|
|there's nothing better than Lufia II to fill those nights where the code
|just won't flow. So below is an update for snes9x to 1.53. The gettext
|module is no longer used as well.
|
|Regards,
|Florian
|
|Index: Makefile
|===
|RCS file: /cvs/ports/emulators/snes9x/Makefile,v
|retrieving revision 1.30
|diff -u -p -u -r1.30 Makefile
|--- Makefile   2 Apr 2015 14:14:33 -   1.30
|+++ Makefile   19 Apr 2016 21:49:40 -
--
Patching file Makefile using Plan A...
Hunk #1 succeeded at 4.
Hunk #2 succeeded at 20.
Hunk #3 failed at 32.
Hunk #4 failed at 45.
2 out of 4 hunks failed
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: distinfo
|===
|RCS file: /cvs/ports/emulators/snes9x/distinfo,v
|retrieving revision 1.6
|diff -u -p -u -r1.6 distinfo
|--- distinfo   18 Jan 2015 03:13:51 -  1.6
|+++ distinfo   19 Apr 2016 21:49:40 -
--
Patching file distinfo using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: patches/patch-gtk_configure
|===
|RCS file: /cvs/ports/emulators/snes9x/patches/patch-gtk_configure,v
|retrieving revision 1.4
|diff -u -p -u -r1.4 patch-gtk_configure
|--- patches/patch-gtk_configure1 Jun 2013 19:19:16 -   1.4
|+++ patches/patch-gtk_configure19 Apr 2016 21:49:40 -
--
Patching file patches/patch-gtk_configure using Plan A...
Hunk #1 failed at 1.
1 out of 1 hunks failed
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: pkg/PLIST
|===
|RCS file: /cvs/ports/emulators/snes9x/pkg/PLIST,v
|retrieving revision 1.6
|diff -u -p -u -r1.6 PLIST
|--- pkg/PLIST  15 Jun 2012 08:32:15 -  1.6
|+++ pkg/PLIST  19 Apr 2016 21:49:40 -
--
Patching file pkg/PLIST using Plan A...
Hunk #1 succeeded at 8.
Hunk #2 succeeded at 19.
Hmm...  Ignoring the trailing garbage.
done


-- 
Bryan

Re: Fix japanese/less

[Bryan Linton]

On 2016-03-22 20:42:40, Peter Kane <pwk...@gmail.com> wrote:
> On Mon, Mar 21, 2016 at 05:52:53PM +0900, Bryan Linton wrote:
> > On 2016-03-21 21:28:17, Peter Kane <pwk...@gmail.com> wrote:
> > > On Mon, Mar 21, 2016 at 06:59:18PM +1300, Peter Kane wrote:
> > > > 
> > > > Thanks for the detailed notes. I'll give it another go shortly.
> > > > 
> > > > Peter
> > > 
> > > OK, I take it all back, partly.
> > > 
> > > At first it wasn't working at all but after a few or more Xorg restarts 
> > > it began to show signs of life. I unloaded a lot of the conversion 
> > > engines that I didn't want and added "set encoding=utf-8" in a vimrc 
> > > file. However, the uim-toolbar-gtk often doesn't launch properly on 
> > > startup for me so I have to wait a while and try again (I would just get 
> > > a preferences icon). The keyboard switching also seemed erratic and 
> > > laggy. The anthy part runs as root.  
> > > 
> > > On the whole it wasn't a great user experience, but jvim isn't really any 
> > > better. Maybe I can refine the settings further to make it better. Thanks 
> > > again.
> > > 
> > 
> > To be honest, I'm not really sure what advice to offer.  For me,
> > switching between input methods is nigh instantaneous.  I also
> > don't have any anthy processes running according to pgrep or top;
> > UIM handles connections to it internally.
> > 
> > Can you post your entire .xinitrc file?  Obviously redacting any
> > information that needs to be.
> > 
> > Also, can you try the following:
> > 
> > 1) Launch uim-pref-gtk
> > 2) Under the first page that opens (Global settings), under
> > "Advanced settings", does checking/unchecking the "Enable lazy
> > input method loading for fast startup" have any effect on
> > anything?
> > 
> > On my setup, that option is checked and I don't have any problems,
> > but YMMV.
> > 
> > -- 
> > Bryan
> > 
> 
> I chose to include the following in my .xinitrc:
> 
> export XMODIFIERS=@im=uim
> export GTK_IM_MODULE="uim"
> uim-xim &
> exec /usr/X11R6/bin/cwm
> 
> I have streamlined the setup by turning off some things that I had enabled, 
> such as menu-based IM switcher and things seem to be a lot smoother now. 
> However, two problems remain.
> 
> 1. I still have to wait a while or have several goes at getting the full gtk 
> toolbar to appear. Toggling lazy startup doesn't seem to affect it. Since I 
> can start uim input without it it is just useful visual feedback on where the 
> settings are at.
> 

Since I don't use a toolbar, I can't help directly, but I may
still have some advice.  Since you're a CWM user, I assume you're
a fan of minimalism and keyboard shortcuts.  I'd recommend just
trying to memorize what the various keys do (e.g. F6 to convert to
Hiragana, F7 to convert to Katakana, F8 to convert to half-width
katakana etc.).

For a visual indicator, once again in the "General settings" tab,
under "Visual preference" I've enabled "Show input mode nearby
cursor" and have "Show input mode" set to "With time" and the time
length set to one second.  This shows a small box for one second
(just long enough to tell what the setting is at a glance) every
time you mouse-over a window.

If this is all you need, you can probably do away with the toolbar
entirely.

> 2. If I'm running in a now default UTF-8 xterm I don't see the correct kana 
> characters when I am in conversion mode. I seem to be getting unrelated 
> half-height characters instead. The final kana/kanji output is correct. Do 
> you know if I can fix this with the default fonts?
> If I switch to conversion mode in a Firefox html notepad 
> (data:text/html,) the kana fonts display during the 
> conversion input as expected.
> 

I've always seen the exact same thing since I've been using UIM,
and I don't have a fix.  I've just lived with it since it
otherwise works correctly.  It's called the "preedit area" in the
settings menu, so you may be able to poke around/search the 'net
for a solution.

If you find one, please send a message to the list since it'd be
nice to be able to change it to a bigger font (the XIM tab in the
preferences program only allows changing the font itself, not the
size from what I've tried) but it's not a major issue for me.

> Now that the startup is running better I haven't seen any anthy-related root 
> processes hanging around in top.
> 

That's good. :)


I'm glad you were able to at least get UIM set up as well as you
have.  Hopefully wit

Re: Fix japanese/less

[Bryan Linton]

On 2016-03-21 21:28:17, Peter Kane  wrote:
> On Mon, Mar 21, 2016 at 06:59:18PM +1300, Peter Kane wrote:
> > 
> > Thanks for the detailed notes. I'll give it another go shortly.
> > 
> > Peter
> 
> OK, I take it all back, partly.
> 
> At first it wasn't working at all but after a few or more Xorg restarts it 
> began to show signs of life. I unloaded a lot of the conversion engines that 
> I didn't want and added "set encoding=utf-8" in a vimrc file. However, the 
> uim-toolbar-gtk often doesn't launch properly on startup for me so I have to 
> wait a while and try again (I would just get a preferences icon). The 
> keyboard switching also seemed erratic and laggy. The anthy part runs as 
> root.  
> 
> On the whole it wasn't a great user experience, but jvim isn't really any 
> better. Maybe I can refine the settings further to make it better. Thanks 
> again.
> 

To be honest, I'm not really sure what advice to offer.  For me,
switching between input methods is nigh instantaneous.  I also
don't have any anthy processes running according to pgrep or top;
UIM handles connections to it internally.

Can you post your entire .xinitrc file?  Obviously redacting any
information that needs to be.

Also, can you try the following:

1) Launch uim-pref-gtk
2) Under the first page that opens (Global settings), under
"Advanced settings", does checking/unchecking the "Enable lazy
input method loading for fast startup" have any effect on
anything?

On my setup, that option is checked and I don't have any problems,
but YMMV.

-- 
Bryan

Re: Fix japanese/less

[Bryan Linton]

On 2016-03-19 19:05:00, YASUOKA Masahiko <yasu...@yasuoka.net> wrote:
> On Fri, 18 Mar 2016 20:13:14 +0900
> Bryan Linton <b...@shoshoni.info> wrote:
> > I'm not sure how much my opinion counts, since I'm not a native
> > speaker, but I'm able to use irssi, vim, mutt, and my shell of
> > choice (zsh) just fine with the following script (aliased to a
> > hotkey in CWM).
> > 
> > #!/bin/sh
> > env LC_CTYPE=ja_JP.UTF-8 uim-xim &
> > env LC_ALL=ja_JP.UTF-8 uxterm -fa "Sazanami Gothic" -fs 16 $1
> > 
> > The first line launches an IME (if it's not running already), and
> > the second uses a bigger font, and also switches it to one I
> > installed from ports.  It's the only font I've found so far that
> > can render *both* Japanese text and the Latin alphabet in a way
> > that's not uncomfortably ugly.  All the other ones I've tried
> > render Japanese text just fine, but output only full-width Latin
> > text, which is very tiring on the eyes after a minute or two.
> 
> As for xterm or uxterm, you can use -fa and -fd. -fd is for double
> sized fonts, like below.
> 
>xterm -fd 'IPAex Gothic' -fa 'DejaVu Sans Mono'
> 
> I think this solves the issue.
> 

Indeed it does!  Thank you very much for the tip!

-- 
Bryan

Re: Fix japanese/less

[Bryan Linton]

On 2016-03-20 11:17:25, Peter Kane  wrote:
> 
> I use jserver/kinput2 because it works with cwm and I can run it on a legacy 
> i386 system and connect over ssh from an amd64 machine (I was hoping the new 
> vmd development work would help there, but i386 support seems a way off). The 
> new UTF-8 desktop settings in -current work OK for me to display UTF-8 fonts, 
> it is just the occasional inputting of kanji that I need something for. If 
> someone can show how to use uim/anthy with cwm in a non-root manner I would 
> be grateful. 
> 
> uim does have appeal because it supports a wide range of languages and I 
> would like something for Chinese, too.
> 

It's been a long time since I installed and configured uim/anthy
(it Just Works), so I may not remember all the steps it took, but
it's fairly straightforward.

These are the installed ports I have:
anthy-9100hp1   japanese input method
uim-1.8.6p1 multilingual input method library
uim-gtk-1.8.6p1 uim for GTK+2
uim-gtk3-1.8.6p2uim for GTK+3
uim-kde-1.8.6p1 uim for KDE3
uim-qt4-1.8.6p1 uim for QT4
uim-tomoe-gtk-0.6.0 japanese handwriting

In .xinitrc (non-relevant lines omitted):
[...]
export XMODIFIERS=@im=uim
export GTK_IM_MODULE="uim"
export QT_IM_MODULE="uim"
env LC_CTYPE=ja_JP.UTF-8 uim-xim &
[...]
exec env LC_CTYPE="en_US.UTF-8" /usr/X11R6/bin/cwm

Quite frankly, I can't remember why I put the 
"env LC_CTYPE=ja_JP.UTF-8" and 'env LC_CTYPE="en_US.UTF-8"' lines
in there.  I think at one point they mattered, but with the base
system having/being switched to UTF-8 by default, they may no
longer be necessary.

After that, simply typing "startx" will bring up CWM with a
working IME.

Running /usr/local/bin/uim-pref-gtk will bring up a GUI you can
use to configure UIM.  There are probably *way* more options here
than you'll need.  Configuring the keyboard shortcut you want to
use to switch input methods is probably the only one you'll really
need at first.  I have mine set up to toggle between an IPA
keyboard (for inputting linguistics-related symbols), a regular
keyboard, and the anthy IME.

You can also run one of:
uim-toolbar-gtk
uim-toolbar-gtk3
uim-toolbar-qt4
uim-toolbar-gtk-systray
uim-toolbar-gtk3-systray

If you want a GUI-toolbar or systray application to run that lets
you click on buttons to toggle/switch between IMEs.  Though
personally, I find them to be superfluous, especially in a
minimalist windowmanager like CWM.

Please let me know if you're successful in setting up UIM/anthy
with this information; I can always try to offer better advice :)

-- 
Bryan

Re: Fix japanese/less

[Bryan Linton]

On 2016-03-17 18:20:12, Marc Espie  wrote:
> On Thu, Mar 17, 2016 at 10:42:21AM -0600, Anthony J. Bentley wrote:
> > I understand that people sometimes, even frequently, need to work with
> > non-UTF encodings. But you can get that effect on OpenBSD with a UTF-8
> > locale and using iconv on incoming and outgoing data. I've been doing
> > so for Japanese and European content for over six years.
> 
> I'm pretty sure you want to engage the japanese people directly over that
> issue.
> 
> I remember porting that software and struggling with it back when I needed
> japanese.  I have no idea what's still good or not, but it's best to let
> them decide, for the most part.
> 

I'm not sure how much my opinion counts, since I'm not a native
speaker, but I'm able to use irssi, vim, mutt, and my shell of
choice (zsh) just fine with the following script (aliased to a
hotkey in CWM).

#!/bin/sh
env LC_CTYPE=ja_JP.UTF-8 uim-xim &
env LC_ALL=ja_JP.UTF-8 uxterm -fa "Sazanami Gothic" -fs 16 $1

The first line launches an IME (if it's not running already), and
the second uses a bigger font, and also switches it to one I
installed from ports.  It's the only font I've found so far that
can render *both* Japanese text and the Latin alphabet in a way
that's not uncomfortably ugly.  All the other ones I've tried
render Japanese text just fine, but output only full-width Latin
text, which is very tiring on the eyes after a minute or two.

This allows me to both see and type Japanese text without issue
for the most part (there are some characters that end up
overlapping each other, like ○○ likely
because the terminal renders them as if they were half-width
characters when they're really full-width characters) but that's
an incredibly minor issue IMO.  Compared to how tedious it was to
set things up to work with Japanese text on the terminal ~15 years
ago when I first started, this is orders of magnitude better.

I haven't had a need to install anything else from ports to
accomplish what *I* need to, but then again, I have a very
UTF-centric workflow.

If someone were working with and depended upon using a terminal
program that used ISO-2022-JP or EUC-JP and wasn't UTF-8 capable,
then having a terminal that used those codesets natively would be
a requirement.


I'd still recommend waiting until several native speakers chime in
with their workflows, since mine is probably a limited subset of
what one would encounter in a Japanese office/datacenter, but I
still thought it worth chiming in to say that at least it's
possible to work with many programs from ports with the base uxterm.

-- 
Bryan

Re: UPDATE: ledger 3.1.1

[Bryan Linton]

On 2016-01-14 22:40:48, Florian Stinglmayr  wrote:
> Hello list,
> 
> here is an update for ledger. It updates ledger from 2. something to
> ledger 3.1.1. It has moved to github, and I need to patch the cmake
> a little to make it proper.
> 
> Could someone who's already using ledger confirm that it is working
> as it should, as I am just staring out to get my finances into ledger.
> 
> @Sergey Could you give your input?
> 
> Thanks,
> Florian
> 
> P.S.: I see the cmus patches still didn't make it in :-(
>

I can't get this to build correctly on my machine.  I've tried
updating to newer snapshots several times since you originally
sent it out and updated my ports tree each time, thinking that it
may be a local problem, but it still won't build.

This is what is output when I try resuming the build after it
fails.  It seems like the key line is probably:
/usr/bin/ld: cannot find -llibledger.so.3

Any ideas on how to fix this?  I've been using ledger for years
and it seems like the author wants to deprecate the 2.x series, so
I'd be happy to help test this so it can be upgraded to the 3.x
series.  (After the ports unlock of course)



Script started on Sat Feb 13 11:04:34 2016
% make
===>  Building for ledger-3.1.1
[1/4] : && /usr/local/bin/eg++   -O2 -pipe-DNDEBUG   
test/unit/CMakeFiles/MathTests.dir/t_amount.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_commodity.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_balance.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_expr.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_value.cc.o  -o MathTests 
-L/usr/obj/ports/ledger-3.1.1/build-i386 -llibledger.so.3 -lmpfr -lgmp 
-lboost_date_time-mt -lboost_filesystem-mt -lboost_system-mt 
-lboost_iostreams-mt -lboost_regex-mt -lboost_unit_test_framework-mt 
-Wl,-rpath,/usr/obj/ports/ledger-3.1.1/build-i386 
-Wl,-rpath-link,/usr/X11R6/lib && :
FAILED: : && /usr/local/bin/eg++   -O2 -pipe-DNDEBUG   
test/unit/CMakeFiles/MathTests.dir/t_amount.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_commodity.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_balance.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_expr.cc.o 
test/unit/CMakeFiles/MathTests.dir/t_value.cc.o  -o MathTests 
-L/usr/obj/ports/ledger-3.1.1/build-i386 -llibledger.so.3 -lmpfr -lgmp 
-lboost_date_time-mt -lboost_filesystem-mt -lboost_system-mt 
-lboost_iostreams-mt -lboost_regex-mt -lboost_unit_test_framework-mt 
-Wl,-rpath,/usr/obj/ports/ledger-3.1.1/build-i386 
-Wl,-rpath-link,/usr/X11R6/lib && :
/usr/bin/ld: cannot find -llibledger.so.3
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
*** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:31 'do-build': @cd 
/usr/obj/ports/ledger-3.1.1/build-i386 && exec /usr/bin/env -i LIB...)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2769 
'/usr/obj/ports/ledger-3.1.1/build-i386/.build_done')
*** Error 1 in /usr/ports/productivity/ledger 
(/usr/ports/infrastructure/mk/bsd.port.mk:2495 'all')
% 

Script done on Sat Feb 13 11:05:58 2016

-- 
Bryan

Re: emulators/pcsxr issues

[Bryan Linton]

On 2016-01-08 18:16:52, Jeremy Evans  wrote:
> I just had a report from a user that trying to use emulators/pcsxr
> raises a "GPUinit: File not found" error dialog box, then segfaults.
> I'm seeing identical behavior.  I'm not going to have the time to debug
> this before release, so unless someone else wants to have a look, I'm
> going to mark it BROKEN.
> 
> Alternatively, we could just remove it. I'm actually in favor of that.
> The reason pcsxr was imported was it was the only PSX emulator that
> would run on OpenBSD.  Since pcsxr was imported, emulators/mednafen
> gained PSX emulation ability, so we already have another emulator in
> ports that can emulate PSX.  Any OKs for removal?  If not, I'll just
> mark it BROKEN.
> 
> Thanks,
> Jeremy
> 

It works perfectly fine for me on the latest snapshot (dmesg attached).

Could this be a radeon vs. intel difference?  (My system has only
a radeon card in it).

Also, while mednafen can emulate a large number of systems, many
in the emulation community find that "kitchen-sink" emulators
tend to lack the accuracy and/or quality of dedicated emulators.

I can't say with any definiteness that the PSX emulation quality
is better or worse with mednafen, but I *can* say that many
system specific features are easier to use in dedicated emulators
as opposed to mednafen, so I would strongly advise against removing
other emulators just because there's a "kitchen-sink" emulator that
already does it, though in this case I understand that you were
approaching it from the viewpoint that pcsxr was broken, which
obviously tends to change things.

-- 
Bryan

OpenBSD 5.9-beta (GENERIC.MP) #1541: Fri Jan  8 15:55:40 MST 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF,SENSOR
real mem  = 3219472384 (3070MB)
avail mem = 3145240576 (2999MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/01/10, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 
0xe0010 (68 entries)
bios0: vendor LENOVO version "79ETE6WW (2.26 )" date 04/01/2010
bios0: LENOVO 2623D9U
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF,SENSOR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
bus 0
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0x9
 0xc - 0xd3fff
 0xdc000 - 0xbfff
 0xfec0 - 0xfed3
 0xfed41000 - 0x
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "92P1139" serial   659 type LION oem "Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 
0xe/0x1!
cpu0: Enhanced SpeedStep 1996 MHz: speeds: 2000, 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility X1300 M52-64" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 1 int 16

ports/net/adsuck and how best to migrate around new CVS commit

[Bryan Linton]

On 2015-10-28 05:52:26, Theo de Raadt  wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   dera...@cvs.openbsd.org 2015/10/28 05:52:26
> 
> Modified files:
>   lib/libc/asr   : asr.c 
>   share/man/man5 : resolv.conf.5 
> 
> Log message:
> Remove support for [addr]:port syntax from the "nameserver" line.
> This extension never made it to other systems.  (pledge is also happy
> with this.  The idea of DNS @ any port collides with pledge encouraring
> differentiation between DNS and non-DNS sockets)
> ok phessler jung sthen kettenis
> 

Hello ports@,

I have a question on how to best migrate my installation of
ports/net/adsuck around this new change.

I currently run adsuck as a local process on a machine that also
runs unbound as a caching nameserver.  I have unbound running on
127.0.0.1:53 and adsuck running on 127.0.0.1:54 and find it convenient
to swap the hashmark between the following two lines in /etc/resolv.conf
when I want to quickly switch adsuck off for whatever reason:

#nameserver 127.0.0.1
nameserver [127.0.0.1]:54

Since obviously adsuck and unbound cannot both run on the same port,
what options do I have to move forward?

I was thinking that I could switch them and run unbound on port 54,
but since adsuck uses a copy of /etc/resolv.conf I would have no way
to point it to port 54 so that option is out.

I would have adsuck run on 127.0.0.1:53 and unbound on 127.0.0.2:53
but I tried that in the past and remember that I hit some kind of
problem (it could very well have been user-error) and wasn't able to
get it to work.

How are other people running both adsuck and unbound on the same 
machine?  Would any of you mind sharing how your systems are setup?

Any pointers would be greatly appreciated.

Thank you.

-- 
Bryan

Re: dhclient.conf does not appear to support resolv.conf formatting for nameservers on non-standard port

[Bryan Linton]

On 2015-07-09 22:01:01, Theo de Raadt dera...@cvs.openbsd.org wrote:
  On Thu, 09 Jul 2015 18:18:37 -0700, Edgar Pettijohn  
  ed...@pettijohn-web.com wrote:
  
   # chflags schg /etc/resolv.conf
  
   Just keep in mind you have to go to single user mode to undo the above.
  
  That's an interesting workaround I hadn't considered. The problem is that  
  this setting must be deployed via an Ansible playbook, so single user mode  
  is out.
 
 The 4.4BSD chflags model of security on inodes is unmaintained, and the
 utilitization of this is not realized OpenBSD.
 
 To be honest, I doubt any of us see much benefit in it, relative to other
 features of the system.  When you are holed, a few file changes + a reboot
 can undo it, voila, noone would ever notice.
 
 I don't think it is more than a gimmick.
 
 If you use it, you really are on your own.  To my knowledge, noone in
 the development group has seriously trialed/used it in years.


FWIW, one case where I find chflags useful is in the following scenario:
Some programs (mostly ones in the ports/games hierarchy) are not completely
stable when coupled with in-game, third-party add-ons, and tend to crash
occasionally.

On my old, circa 2005 systems, writing out a ~1.5 GB core file probabaly 
takes about 30-120 seconds to complete (I never actually timed it, but it 
certainly takes long enough to notice), by which time upon rejoining the 
game most people have already left.  By doing:

% rm game.core
% touch game.core
% chflags uchg game.core

It prevents the game from being able to write a core file, and allows me
to restart it and rejoin the game quickly.

Is it OpenBSD's fault these games crash from time to time?  No, it's
either the main developers of the game, or the third-party add-on
writers who are probably doing something with memory management that
OpenBSD's malloc rightly rejects.

Is this an extremely marginal usage case where I may be the only one
using it like this?  Yes, and possibly (in that order).

Should I be sending these backtraces upstream instead of silently tolerating
them?  Probably, but they happen infrequently enough now that it's really
not that difficult to just re-launch and re-join the game when it does happen.

I don't use chflags for anything security related, and I could probably
find another way to prevent programs from dumping core if I spent the time
to look, but this works for me so I use it.  From searching around at this
very moment, it looks like tweaking ulimit -c might also accomplish the 
same goal.

Someone could probably insert a quote here about features being used for 
purposes the original developers never even considered when they were first
implemented.

When you say that the chflags model is unmaintained I hear, this may
possibly be removed at some point in the future and if it breaks anything,
you get to keep all the pieces.  While I find it useful for my particular 
usage case, I won't complain if it's removed since I trust that the OpenBSD
developers remove code for good reason (being broken, buggy, or having 
other potentially negative effects).

That being said, I do find it useful in my (esoteric) case, though as I
said, these games have actually become a lot more stable over the years
so they actually don't crash all that often anymore.

-- 
Bryan

Re: dhclient.conf does not appear to support resolv.conf formatting for nameservers on non-standard port

[Bryan Linton]

My apologies, I meant to send this as a reply to misc@ but
obviously made a mistake.

-- 
Bryan

Re: UPDATE: windowmaker 0.95.6 (take 3!)

[Bryan Linton]

On 2015-03-11 18:48:58, Toby Slight tobysli...@gmail.com wrote:

 [...]

 Hi there,
 
 I wasn't sure whether to start a new thread or just reply to this relevant
 one. Apologies if it's bad form to bump such an old thread. Are mailing
 lists the same as forums in that regard?
 
 Anyway, I was just looking into updating the WindowMaker port, and thought
 I better search the archive beforehand, in case anyone else was doing
 anything with it, and I'm glad I did!
 
 However, nothing seems to have come from the work Timo did over a year ago,
 and WindowMaker has actually been updated to 0.95.6 since. Does anyone know
 why this update never made it into the tree?
 
 Anyway, I tried using the 0.95.5 update as a template for a  0.95.6 port
 but couldn't get it to build - it failed at the configure stage with the
 script not being able to find libXmu for some reason (despite the
 /usr/X11R6/lib and include paths being correct, and Timo's updated 0.95.5
 compiling and running just fine - I'm actually using it right now!).
 
 It's probably a really minor thing, but I'm too much of a noob to be able
 to quickly get the bottom of it, and before I invested any more time, I
 thought I had better check whether or not Timo or anyone else has since
 done any work on this port? Don't want to step on any toes
 

I was a user of WindowMaker back when this was submitted (I
haven't used it in years, though I stopped because I moved and
didn't have space for my desktop.  I'm not sure if I'll start
using it again or not, since I've become very accustomed to CWM on
my laptop now).

The problem it had was that 0.95.2 introduced a lot of regressions
and bugs that made it unusable.

See this thread for details: http://marc.info/?t=13302723911r=1w=3

Particularly these: 
http://marc.info/?l=openbsd-portsm=133569328101710w=2
http://marc.info/?l=openbsd-portsm=133194866716250w=2
http://marc.info/?l=openbsd-portsm=133151145814675w=2

Note in particular the last one, where I detail a reliable way to
get keyboard shortcuts to spawn multiple windows of the
application they're linked to.  Do it once and two windows spawn
per keypress.  Do it again and three spawn.  I stopped after I
could get five windows to spawn with a single keypress.

Since I don't use WindowMaker anymore (and may not again, since I
like CWM so much more) I can't test this, but please at least
verify that the new bugs in 0.95.2 that I detailed in the above
post have been fixed in 0.95.6.

If these bugs have been fixed, and no new ones have been
introduced, then I will leave it up to other WindowMaker users to
decide if this update is stable enough to go in.

-- 
Bryan

Re: UPDATE: x11/xfe 1.37 = 1.40

[Bryan Linton]

On 2015-01-16 20:17:28, Brian Callahan bcal...@devio.us wrote:
 
 On 01/12/15 00:45, Brian Callahan wrote:
  Hi ports --
 
  Here's an update to Xfe. This is a major version update.
  Partial changelog can be found on the homepage: http://roland65.free.fr/xfe/
 
  [...] 
 
  Working well on amd64.
 
  OK?
 
 
 Ping. All I got was the one user report.
 

I've been running with this for a few days now on i386 -current.  I
haven't seen any regressions.

Seems OK to me.

-- 
Bryan

Re: UPDATE: redshift 1.9.1 - 1.10

[Bryan Linton]

On 2015-01-09 21:34:02, Scarlett scarl...@xavin.net wrote:
 Needs testing on non-amd64 and of redshift-gtk by someone with a
 gnomish setup.
 
 Are the makefile changes ok?
 

I can't comment on the Makefile changes, but it seems to working
fine so far on i386.  I don't use Gnome, so I can't comment on the
-gtk portion of it either, but the base program is doing what I
expect it to do.

-- 
Bryan

Re: inputmethods/uim needs update to work with GTK-3 (was Re: recommended input methods?)

[Bryan Linton]

On 2015-01-08 08:32:09, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
  I'm hoping that this will be a simple thing to update if the
  person doing so knows the ports-tree well, but if not and people
  are too busy with other projects, I'll probably try to see what I
  can do in a couple months when I have some more free time.
 
 I can give it a try -- just don't hold your breath to soon.
 

There's no hurry, and I appreciate your willingness to give this a
look.

Thank you!

-- 
Bryan

Re: inputmethods/uim needs update to work with GTK-3 (was Re: recommended input methods?)

[Bryan Linton]

Ping?

I know that asking others to do work for them instead of doing
it themselves is frowned upon in OpenBSD culture, but even though
I might be able to hack something together if I persevered at it
long enough, I unfortunately won't have the free time to do so for
a while so I hope that one final ping after the holidays won't be
too far out of line.  

I would contact the maintainer directly and inquire privately, but
the current maintainer is listed as the ports@ mailing list.

In short, the version of inputmethods/uim currently in the tree is
over six years old, and needs a (strongly advised against)
environment variable set to work with GTK+3 applications, since
it's so old that it doesn't support GTK+3 except via the old XIM
module.

I'm hoping that this will be a simple thing to update if the
person doing so knows the ports-tree well, but if not and people
are too busy with other projects, I'll probably try to see what I
can do in a couple months when I have some more free time.

-- 
Bryan

On 2014-12-17 15:28:03, Bryan Linton b...@shoshoni.info wrote:
 [Moving to ports@ from misc@]
 
 On 2014-12-11 19:12:50, Bryan Linton b...@shoshoni.info wrote:
  
  [...]
  
  Note that some applications refuse to accept Japanese input unless
  they're run with the correct locale settings *AND* an overridden
  input module, so I have
  
  bind C-g env GTK_IM_MODULE=xim LC_CTYPE=ja_JP.UTF-8 gwaei
  
  in my .cwmrc so that a Japanese dictionary program of all things
  will accept Japanese input.
  
  [...]
  
 
 I believe I have tracked down the source of this bug.  Apparently
 the version of UIM currently in the ports tree (1.5.3) simply does
 not support GTK-3 applications as evidenced by a lack of a UIM
 module in /usr/local/lib/gtk-3.0/3.0.0/immodules wheras one is
 present in the GTK-2 directory /usr/local/lib/gtk-2.0/2.10.0/immodules
 
 Indeed, GTK-2 applications work fine when launched *without*
 needing any of the overridden environment variables whereas the
 GTK-3 applications need to have both their locale and input-module
 overridden to work correctly.
 
 According to UIM's website, GTK-3 support was first added in
 1.7.0-alpha, and the current version of UIM is 1.8.6, so it would
 seem that version 1.5.3 being released on 2008/09/07 is a bit out
 of date.
 
 I tried to see if I could build a new version of UIM by just
 bumping the version and adding a few tweaks here and there (such
 as adding gtk3 to the build-depends, adding a --with-gtk3 to the
 configure flags, and updating AUTOCONF_VERSION) but it would seem
 that the errors I was given were simply beyond my ability to
 easily fix.
 
 I don't suppose some kind soul would be willing to look into the
 possibility of churning out an update to UIM in the near future?
 
 It would certainly benefit people using GTK-3 applications, since
 UIM is used for more than just Japanese input.  It allows not only
 Chinese/Japanese/Korean input, but also provides an easy way to
 input IPA symbols (a must for an linguist) as well as a way to use
 dead-keys to input the variety of diacritics used in the various
 European languages (though I know there are other ways to
 accomplish this).
 
 I would certainly be very appreciative of any efforts towards this,
 and would of course be willing to test any updates since it
 appears that that is all I can do with my current skill level.
 
 As GTK3 applications become more and more popular over GTK2
 applications, I imagine that this will become a more pressing
 issue, though the fact that I appear to be the first one to have
 noticed it probably shows how many people this is really affecting
 at the moment...
 
 Regardless, I appreciate the effort the various OpenBSD developers
 have put into bringing a coherent GNOME desktop to OpenBSD.  Even
 though I use CWM as my window manager, I have no doubt that this
 cohesiveness is what has allowed me to simply pkg_add uim and
 related components and have everything Just Work (TM) for all
 these years, so I thank all the people involved.
 

inputmethods/uim needs update to work with GTK-3 (was Re: recommended input methods?)

[Bryan Linton]

[Moving to ports@ from misc@]

On 2014-12-11 19:12:50, Bryan Linton b...@shoshoni.info wrote:
 
 [...]
 
 Note that some applications refuse to accept Japanese input unless
 they're run with the correct locale settings *AND* an overridden
 input module, so I have
 
 bind C-g env GTK_IM_MODULE=xim LC_CTYPE=ja_JP.UTF-8 gwaei
 
 in my .cwmrc so that a Japanese dictionary program of all things
 will accept Japanese input.
 
 As I said before, unfortunately xombrero needs the same hack
 #bind C-x env GTK_IM_MODULE=xim LC_CTYPE=ja_JP.UTF-8 xombrero
 but this makes the fonts very ugly on most pages and in the
 general UI.  I'm still hoping to find some way to get it to
 support Japanese input without needing to force the locale to
 change, since it seems like Firefox, xterms, and most any non-GTK
 programs just Do the Right Thing (TM).
 
 [...]
 
 GTK apps used to Just Work (TM), but it seems like after new
 versions have been released over the last few years, more and more
 hacks have been needed to keep things working. 
 

I believe I have tracked down the source of this bug.  Apparently
the version of UIM currently in the ports tree (1.5.3) simply does
not support GTK-3 applications as evidenced by a lack of a UIM
module in /usr/local/lib/gtk-3.0/3.0.0/immodules wheras one is
present in the GTK-2 directory /usr/local/lib/gtk-2.0/2.10.0/immodules

Indeed, GTK-2 applications work fine when launched *without*
needing any of the overridden environment variables whereas the
GTK-3 applications need to have both their locale and input-module
overridden to work correctly.

According to UIM's website, GTK-3 support was first added in
1.7.0-alpha, and the current version of UIM is 1.8.6, so it would
seem that version 1.5.3 being released on 2008/09/07 is a bit out
of date.

I tried to see if I could build a new version of UIM by just
bumping the version and adding a few tweaks here and there (such
as adding gtk3 to the build-depends, adding a --with-gtk3 to the
configure flags, and updating AUTOCONF_VERSION) but it would seem
that the errors I was given were simply beyond my ability to
easily fix.

I don't suppose some kind soul would be willing to look into the
possibility of churning out an update to UIM in the near future?

It would certainly benefit people using GTK-3 applications, since
UIM is used for more than just Japanese input.  It allows not only
Chinese/Japanese/Korean input, but also provides an easy way to
input IPA symbols (a must for an linguist) as well as a way to use
dead-keys to input the variety of diacritics used in the various
European languages (though I know there are other ways to
accomplish this).

I would certainly be very appreciative of any efforts towards this,
and would of course be willing to test any updates since it
appears that that is all I can do with my current skill level.

As GTK3 applications become more and more popular over GTK2
applications, I imagine that this will become a more pressing
issue, though the fact that I appear to be the first one to have
noticed it probably shows how many people this is really affecting
at the moment...

Regardless, I appreciate the effort the various OpenBSD developers
have put into bringing a coherent GNOME desktop to OpenBSD.  Even
though I use CWM as my window manager, I have no doubt that this
cohesiveness is what has allowed me to simply pkg_add uim and
related components and have everything Just Work (TM) for all
these years, so I thank all the people involved.

-- 
Bryan

Re: [update] bogofilter 1.2.4

[Bryan Linton]

On 2014-10-19 22:07:15, Landry Breuil lan...@rhaalovely.net wrote:
 On Tue, Sep 30, 2014 at 10:52:27PM +0200, Landry Breuil wrote:
  Hi,
  
  here's an update to bogofilter 1.2.4 - the version we have in-tree is
  nearly 7 years old, and even if the motto if it ain't broken dont fix
  it is strong among some, there's been at least two CVEs since then:
  http://bogofilter.sourceforge.net/security/bogofilter-SA-2010-01
  http://bogofilter.sourceforge.net/security/bogofilter-SA-2012-01
  And lots of crash (and other errors..) fixes are listed on
  http://bogofilter.sourceforge.net/NEWS 
  
  if you use it, please test this update. All flavors build and tests pass
  on amd64 and macppc. I'm tempted to remove the qdbm flavor since qdbm
  itself looks *very* dead upstream and advertises tokyocabinet instead..
  but oh well.
 
 Anyone actually using this tested it ? I already have an okay, so unless
 someone sees a regression soon, i'll commit this.
 
 Landry
 
 
I've built the -sqlite3 flavor, bf_compacted my old database, and
it seems to be working fine, though I've only run about ~50 emails
through it so far.

If there are any regressions, they're not obvious ones, and from
skimming the changelog, it doesn't look like there were any drastic
changes made.

Seems to be OK for me.

-- 
Bryan

Re: [UPDATE] mpd-0.19

[Bryan Linton]

On 2014-10-13 14:14:04, David Coppa dco...@gmail.com wrote:
 
 Major update to mpd-0.19.
 
 Please test with your setup.
 Works for me(TM).
 

Seems to work OK with everything so far, though I've only spent
about five minutes playing around pushing various knobs.  

Had to update ports/audio/sonata to get it work right with the new
version, but it seems like seeking in large files is much faster,
and I haven't noticed any regressions.

-- 
Bryan

Re: NEW: net/quassel (needs testing..)

[Bryan Linton]

On 2014-08-22 21:10:04, Chuck Burns brea...@gmail.com wrote:
 Quassel is my favorite GUI IRC client.  It's a distributed IRC client.
 Think screen+irssi with a GUI. This is also my very first attempt at an
 OpenBSD port of anything, so don't hurt me. :)
 
 I eventually intend to make it into a multi part package, but not really
 sure yet how best to proceed.
 
 Because there are three different apps here. some people might only need 1
 or 2.. or want all three (rare)
 
 Here's how it works:
 There's the core which is the daemon
 There's the client which is .. well.. the client.
 
 Then, there's also a monolithic app which does away with the distributed
 nature of the app, and makes it a simple standalone IRC client.
 
 So.. One box might have the core, several boxes might have the client..
 
 Or, someone might just install the monolithic client.  The tarball can
 build all of them or some of them. I haven't yet figured out my best course
 of action on that..
 
 In the meantime, please test this port and give me a thrashing if I screwed
 up (which is likely)
 
 Thanks,
 Chuck Burns

Seems to build and run fine for me, though I did not perform
extended testing.

Three comments.  First, the licence file doesn't say GPL2+, it
says the following:

This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation;
either version 2 of the License, or (at your option)
version 3.

So it's *either* GPL2 or GPL3.  GPL4 (if/when it comes out) would
not be an option like it would for the licences that say any
later version as is usually the case, which is how the template
at https://gnu.org/licenses/gpl-howto.html is written.

The second comment is that the binaries are not being stripped.
The stripped versions in the following directory were created
manually by myself, after it had finished building.

% ls -lah
total 494376
drwxr-xr-x   2 root  wheel   512B Aug 23 14:50 .
drwxr-xr-x  11 root  wheel   512B Aug 23 14:41 ..
-rwxr-xr-x   1 root  wheel   108M Aug 23 13:02 quassel
-rwxr-xr-x   1 root  wheel   6.5M Aug 23 14:45 quassel.stripped
-rwxr-xr-x   1 root  wheel  85.9M Aug 23 13:03 quasselclient
-rwxr-xr-x   1 root  wheel   5.1M Aug 23 14:50 quasselclient.stripped
-rwxr-xr-x   1 root  wheel  32.8M Aug 23 13:03 quasselcore
-rwxr-xr-x   1 root  wheel   3.3M Aug 23 14:50 quasselcore.stripped

So the total install size would decrease from about 226 MB to about
15 MB if the binaries were stripped.  This is probably something
worth doing.

Third, make port-lib-depends-check says that WANTLIB should
should have the following added to it:
WANTLIB += QtScript QtSql QtXmlPatterns c m phonon pthread z

Other than that, it looks okay to me, but a more experienced
porter would probably be able to provide better feedback.

-- 
Bryan

Re: GTK1 is better than GTK2

[Bryan Linton]

On 2014-08-03 16:24:08, Christian Weisgerber na...@mips.inka.de wrote:
 Why is GTK1 better than GTK2?
 
 Because I can run a GTK1 application, such as xmms, on my sparc64
 (with X11 forwarding to a remote display, although that shouldn't
 matter).  When I try the same with a GTK2 application like netsurf
 or gpicview it crashes pretty quickly.
 
 I built netsurf with debugging symbols and the crash is deep in
 cairo  pango-cairo.  I haven't examined gpicview.
 
 Any other apps I should try?
 

I wonder if this might be the exact same thing I reported in this
email: http://marc.info/?l=openbsd-portsm=140295195921432w=2

Briefly, I see crashes in pango/cairo in editors/leafpad and
japanese/gwaei (both GTK2 applications) which seem to be extremely
frequent when they are displaying Japanese text, and somewhat
uncommon when they display only the English Latin alphabet.

FWIW, I also noticed that xombrero (also a GTK2/GTK3 application)
has a tendency to crash when I go to Japanese pages, to the point
that I open Firefox when I know I need to go to a Japanese page,
but that's also because I haven't been able to figure out how to
get xombrero to accept input from a Japanese IME (inputmethods/uim
and inputmethods/anthy) without changing any LC_* variables to
Japanese, which has the side effect of changing its default fonts
to ones that aren't very pretty when they're used to render the
Latin alphabet.

A release or two ago and I could input Japanese into xombrero
with whatever defaults shipped with the OS, but after some locale
commits it stopped working.  I just assumed that it wasn't
supposed to work that way before, and the way things are now are
more technically correct WRT POSIX or something, even if I
personally would rather it not be.  :)

Since pango and cairo are both used to render text, I assume
there's something about non-English-Latin scripts that it
doesn't like.  I'm not sure how well it likes umlauts, Greek, or
Cyrillic text though.  Since I don't speak any of those languages,
I seldom find myself reading text written in them.

--
Bryan

Segfault in bcopy in multiple ports when processing Japanese, pango/cairo related?

[Bryan Linton]

Hello list,

[backtraces provided below]

I've been experiencing several crashes in japanese/gwaei (a
Japanese-English dictionary program) and editors/leafpad (a simple
text-editor) that both seem to involve Japanese text.  It's
extremely rare (I can't even recall if leafpad has ever crashed
when using English-only files) when using non-Japanese files, and
extremely common when opening files containing Japanese.

Since both programs have almost identical backtraces, and both
involve Japanese text, I assume they are related.  They also
both involve pango and cairo, which further leads me to suspect
there is something about Japanese text or fonts which is causing this.

Of note, I tried upgrading to a newer version of gwaei than was in
ports (3.2.0 - 3.6.2) and not only did the crashes remain, but
the newer version was horribly broken, and I strongly recommend it
not be updated.

The two major issues I found were that in 3.6.2, results were not
sorted, so instead of an exact match of a word being the first
returned result, it was often number 20-30 in a list of related
words.  Additionally, the kanji radical search method was
redesigned in a way that was extremely difficult to use, so I
strongly recommend that gwaei remain as it is, and not be updated.

Since leafpad (a simple text editor) also displays the same crash,
I assume that it is not in the programs themselves, and either in
cairo or pango (if bcopy itself were really broken, I doubt I'd be
the only one to see it).

Of note, if gwaei or leafpad are going to crash, they usually do
so within a minute of being started and used.  If they don't crash
within that time, they typically run for quite some time without
crashing, often long enough for me to do what I need to do without
any further issue, so it appears there's a certain level of
non-determinism in this behavior.

I have no /etc/malloc.conf, so am running with the defaults on

OpenBSD 5.5-current (GENERIC.MP) #182: Fri Jun 13 12:47:35 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

Crashdump w/ backtrace follows.  gwaei is given first, followed by
a backtrace of leafpad.  If any further information is needed,
please don't hesitate to ask.

Script started on Sun Jun 15 18:07:32 2014
shoshoni-m% gdb `which gwaei` gwaei-bcopy.core
(no debugging symbols found)
Core was generated by `gwaei'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.18.0...done.
Loaded symbols for /usr/lib/libpthread.so.18.0
Loaded symbols for /usr/local/bin/gwaei
Reading symbols from /usr/local/lib/libgtk-3.so.1200.0...done.
Loaded symbols for /usr/local/lib/libgtk-3.so.1200.0
Reading symbols from /usr/local/lib/libgdk-3.so.1200.0...done.
Loaded symbols for /usr/local/lib/libgdk-3.so.1200.0
Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3600.0...done.
Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3600.0
Reading symbols from /usr/local/lib/libpango-1.0.so.3600.0...done.
Loaded symbols for /usr/local/lib/libpango-1.0.so.3600.0
Reading symbols from /usr/local/lib/libgobject-2.0.so.4000.0...done.
Loaded symbols for /usr/local/lib/libgobject-2.0.so.4000.0
Reading symbols from /usr/local/lib/libglib-2.0.so.4000.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.4000.0
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/local/lib/libpcre.so.3.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.3.0
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/local/lib/libffi.so.1.0...done.
Loaded symbols for /usr/local/lib/libffi.so.1.0
Reading symbols from /usr/local/lib/libgmodule-2.0.so.4000.0...done.
Loaded symbols for /usr/local/lib/libgmodule-2.0.so.4000.0
Reading symbols from /usr/local/lib/libgthread-2.0.so.4000.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.4000.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/local/lib/libcairo.so.12.2...done.
Loaded symbols for /usr/local/lib/libcairo.so.12.2
Symbols already loaded for /usr/lib/libpthread.so.18.0
Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.4...done.
Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.4
Reading symbols from /usr/X11R6/lib/libpthread-stubs.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libpthread-stubs.so.2.0
Reading symbols from /usr/X11R6/lib/libfontconfig.so.9.1...done.
Loaded symbols for /usr/X11R6/lib/libfontconfig.so.9.1
Reading symbols from /usr/X11R6/lib/libfreetype.so.22.0...done.
Loaded symbols for /usr/X11R6/lib/libfreetype.so.22.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/lib/libexpat.so.11.0...done.
Loaded symbols for /usr/lib/libexpat.so.11.0
Reading symbols from /usr/local/lib/libpng.so.17.1...done.
Loaded 

Re: mpd-0.18.11 m4a support

[Bryan Linton]

On 2014-06-04 21:38:06, James Turner ja...@calminferno.net wrote:
 On Wed, Jun 04, 2014 at 08:54:34PM -0400, James Turner wrote:
 With the mpd 0.18.10 update m4a playback support went a way for me. In
 order to regain m4a playback support in mpd I had to enable ffmpeg
 support.
 
 With this a number of other formats come along with it. Can others
 confirm m4a files are no longer found or play with the current mpd and
 that the attached diff brings back said support?
 
 
 And to clarify a bit, in 0.18 the mp4ff plugin was removed which
 provided m4a support from audio/faad so it appears ffmpeg is the only
 option now for m4a support.
 

I can confirm MP4s were gone without this patch, and have returned
with this patch, but I used to (can't remember how long ago) be
able to play MP4s with video (obviously with only the audio being
played) in MPD, which this patch doesn't restore.

It's not a huge deal, but if anyone wants to track the issue down,
I would greatly appreciate it.  :)

I'd still wholeheartedly recommend this patch going in though;  I
haven't had any issues with it so far, and having any kind of MP4
support at all is far better than none.

-- 
Bryan

Re: mpd-0.18.10 + FIX (Was: mpd-0.18.10)

[Bryan Linton]

On 2014-05-05 10:43:00, Landry Breuil lan...@openbsd.org wrote:
 On Mon, May 05, 2014 at 10:28:58AM +0200, David Coppa wrote:
  On Wed, Apr 30, 2014 at 11:07 PM, Landry Breuil lan...@openbsd.org wrote:
  
   So after rereading the discussion in
   http://bugs.musicpd.org/view.php?id=3944 and reading the patch, i think
   this is the way to go. Anyway, after testing it here on my ppc, it seems
   to just work fine. Feedback from others ?
  
   Landry
  
  So, after some time now, were you be able to reproduce that nasty bug?
 
 As i said, after some days of casual heavy usage, it didnt reproduce.
 

Echoing this, after casual use since you posted the new update, I
haven't been able to reproduce the bug I was seeing.

-- 
Bryan

Re: mpd-0.18.10 (Was: [wip] audio/mpd 0.18.9)

[Bryan Linton]

On 2014-04-21 09:55:22, Bryan Linton b...@shoshoni.info wrote:
 On 2014-04-18 15:57:06, David Coppa dco...@gmail.com wrote:
 On Tue, 25 Mar 2014, Landry Breuil wrote:
 
 So, after playing flawlessly for 3 hours, it stopped again. Looked at
 the mpdstate file, time had a regular value, but mpd didnt save it yet.
 pkill -9 mpd to really force-stop it, at that point it saved the mpdstate
 with time: -2147483648
 restarted mpd.. mpc still says the currently played track is the one
 which was playing before getting stuck. Mpd will only play one track before
 getting stuck.
 Kill mpd, set time to 0 in mpdstate, restart mpd. works fine.
 
 Maybe this is better... Can you try it?
 
 
 Been running this for three days now.  There was one hiccup that I
 thought was similar to what had been happening previously, but I
 have not been able to duplicate it since restarting mpd.
 
 I'd like to run with it for a bit longer to make certain it's
 still pretty stable, but other than that one hiccup, it's been
 running without any issues so far.
 

...And I just had the same bug that was mentioned previously
surface again.

Whatever changed between 0.18.9 and 0.18.10, it is much less
buggy with 0.18.10 than it was with 0.18.9, but it still has a bug
that didn't exist in 0.17.6 (the current version in ports), so I
would recommend against this update going in for the time being
at least.

FWIW, this is on:

OpenBSD 5.5-current (GENERIC.MP) #43: Sat Apr 12 09:39:12 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem  = 2682613760 (2558MB)
avail mem = 2626314240 (2504MB)

-- 
Bryan

Re: mpd-0.18.10 (Was: [wip] audio/mpd 0.18.9)

[Bryan Linton]

On 2014-04-18 15:57:06, David Coppa dco...@gmail.com wrote:
 On Tue, 25 Mar 2014, Landry Breuil wrote:
 
  So, after playing flawlessly for 3 hours, it stopped again. Looked at
  the mpdstate file, time had a regular value, but mpd didnt save it yet.
  pkill -9 mpd to really force-stop it, at that point it saved the mpdstate
  with time: -2147483648
  restarted mpd.. mpc still says the currently played track is the one
  which was playing before getting stuck. Mpd will only play one track before
  getting stuck.
  Kill mpd, set time to 0 in mpdstate, restart mpd. works fine.
 
 Maybe this is better... Can you try it?
 

Been running this for three days now.  There was one hiccup that I
thought was similar to what had been happening previously, but I
have not been able to duplicate it since restarting mpd.

I'd like to run with it for a bit longer to make certain it's
still pretty stable, but other than that one hiccup, it's been
running without any issues so far.

-- 
Bryan

Re: [wip] audio/mpd 0.18.9

[Bryan Linton]

On 2014-03-23 22:48:28, Landry Breuil lan...@rhaalovely.net wrote:
 Hi ports@,
 
 he's a diff to update audio/mpd to the latest 0.18.9, some notes:
 
 - it adds a dependency on gcc 4.8 because code was rewritten
   c++11-style. There are discussions to reimport mpd 0.17 as
 audio/mpd017 for architectures not having gcc 4.8 (ie anything besides
 i386/amd64/macppc/sparc64)
 - for some reason here mpd inexplicably stops playing after ending a
   track, and 'mpc play' or telnetting to 6600 and issuing 'play' doesnt
 resume it, it still seems to think it's playing. I need to kill it and
 restart it for another track to properly play. Anyone experiencing this ?
 Tried with/without random/consume modes.
 
 Please test this..
 

I think I'm seeing the same bug here:

OpenBSD 5.5-current (GENERIC.MP) #5: Tue Mar 18 16:19:15 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

It works fine for a while, but then MPD will play a song and then
stop, but if I seek to right before the end of the song, it will
continue on to play another song, but only one more before
stopping.

Sonata (the frontend I use) displays the old song's name and
length while playing the new song.  Seeking anywhere will
immediately seek to that spot in the previous song, whereupon if I
click to right before the end, it will go on to play the new song
again.

If the first song it gets stuck on is longer than the
second, clicking on a spot on the progress bar beyond the length
of the second song will cause the second song to repeat instead.
Only by clicking somewhere in the progress bar that is within the
limits of second song will it repeat the first.

I.e. First song is 20 seconds long, second in 40 seconds long.
When second song starts to play, clicking one-quarter of the way
will go back to the first song, clicking three-quarters of the way
will loop the second song.

It definitely seems like something weird is happening behind the
scenes, especially since I can play about 10 songs or so before it
starts exhibiting this bug.

-- 
Bryan

Re: geo/tangogps abort trap

[Bryan Linton]

On 2012-10-09 14:48:14, Kirill Bychkov ya...@linklevel.net wrote:
 
 Nope, it's still crashing
 

Tangogps started crashing for me when (IIRC) the following commit to
rthreads was made.

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/librthread/rthread_sync.c.diff?r1=1.33;r2=1.34;f=h

I hacked the following patch to restore tangogps to a working
state.  I should state that I have no idea how this affects the
system as a whole beyond the fact that nothing broke for me.

Since this is changing undefined behavior, it may be safe but it
may also crash your system, format your drives, and sing off-key
humppa songs to your pet cat.

I mention this patch only to illustrate how the problem started
and expect to be sternly corrected by someone who knows better if
this patch is going to do terrible things (which I fully expect
that it may).  

I would *strongly* encourage you not to test this on a production
system and to make sure that you have backups of whatever system
you do try this on.   Better to be safe than sorry.

ISTR that this change was made deliberately to flush out programs
that were sloppy in their usage of threads, but this was long ago
and I may be mistaken in that regard.

-- 
Bryan

Index: rthread_sync.c
===
RCS file: /cvs/src/lib/librthread/rthread_sync.c,v
retrieving revision 1.36
diff -u -p -u -r1.36 rthread_sync.c
--- rthread_sync.c  14 Apr 2012 12:07:49 -  1.36
+++ rthread_sync.c  10 Jun 2012 22:01:16 -
@@ -215,7 +215,8 @@ pthread_mutex_unlock(pthread_mutex_t *mu
mutex-type == PTHREAD_MUTEX_NORMAL)
return (0);
else
-   abort();
+   return (0);
+   /*  abort(); */
}
}
 

Re: NEW: archivers/libpar2

[Bryan Linton]

On 2012-07-02 18:48:51, Bryan Linton b...@shoshoni.info wrote:
 
 New version attached.
 

Ping.  

I've had this in my tree for about two years now.  It would be
nice if it could get committed along with NZBget.

-- 
Bryan

Re: NEW: news/nzbget

[Bryan Linton]

On 2012-07-02 18:50:47, Bryan Linton b...@shoshoni.info wrote:
 
 New version, MAINTAINER does not need to be explicitly set to
 ports@.
 

Ping.

I've had this in my tree for a while too.  I haven't objectively
measured, but NZBget seems to be much faster than news/hellanzb.

NZBget is also actively developed.  The latest release was in
April 2012.  Hellanzb's latest release was in 2007 and appears to
have spam on the frontpage of its wiki as I type this.

In fact, I initially ported this because hellanzb stopped working
after a python update (which has since been fixed in the hellanzb
port).

-- 
Bryan

Re: NEW: archivers/libpar2

[Bryan Linton]

On 2012-07-02 15:23:35, Simon Kuhnle si...@blarzwurst.de wrote:
On Mon, Jul 02, 2012 at 02:28:53PM +0200, Simon Kuhnle wrote:
On Sun, Jul 01, 2012 at 01:12:14PM -0700, Bryan Linton wrote:
 
 Tested on i386 and sparc64.  It fails to work properly with nzbget
 on sparc64 and has been marked BROKEN on that platform.
 
 I remember you mentioned that in your last mail you sent to me.
 Can you be more specific about that? And how to reproduce it?
 
 The thing is: par2cmdline (which already is in ports)
 could/should have the same problem then, too.
 
 Seems like it really has the same problem.
 
 $ par2 r foo.par2 * (with the exact same files):
 amd64: All files are correct, repair is not required.
 sparc64: Main packet not found.
 

IIRC, the error I received from libpar2 was the same or similar to
the above on sparc64.  I do remember that NZBget would download
the files fine, attempt to run a par check, spit out an error
message similar to the above, and then continue on downloading the
next file in the queue.

I can't test on sparc64 ATM though.  Sorry I can't be of more help
on this point.


-- 
Bryan