Re: Fix japanese/less
On Wed, Mar 23, 2016 at 10:36:03AM +0900, YASUOKA Masahiko wrote: > On Tue, 22 Mar 2016 20:42:40 +1300 > Peter Kane wrote: > >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. > > > >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? > > On my environment they are half-height but the characters are correct. I > don't have a fix for this. > > Also you can use "uim-fep" instead of setting XMODIFIERS for xterm. > > --yasuoka Great, thanks for all the help. Peter
Re: [patch] archivers/libarchive ioctl woes
On Tue, Mar 22, 2016 at 10:30:51PM +0100, Matthias Kilian wrote:
> Hi,
>
> On Tue, Mar 22, 2016 at 04:20:34PM -0400, Bryan Steele wrote:
> > It seems libarchive/bsdtar is picking up headers from e2fsprogs if
> > installed, specifically, headers related to Linux file ioctls.
> >
> > ./ext2_fs.h:#define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
> >
> > Here's a patch so that it stops trying random ioctls that
> > fortunately all fail with our kernel.
> >
> > .. might be worth checking other ports.
>
> Well, no objections against your libarchive diff, but wouldn't it
> be better to patch the offending header in e2fsprogs and shield
> those #define's with #ifndef __OpenBSD__?
>
> If noone beats me, I'll give it a try in a day or two.
>
> Ciao,
> Kili
>
> ps: i mean something like this (completely untested for now):
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/e2fsprogs/Makefile,v
> retrieving revision 1.36
> diff -u -p -r1.36 Makefile
> --- Makefile 15 Dec 2015 10:52:02 - 1.36
> +++ Makefile 22 Mar 2016 21:29:19 -
> @@ -3,7 +3,7 @@
> COMMENT= utilities to manipulate ext2 filesystems
>
> DISTNAME=e2fsprogs-1.42.12
> -REVISION=1
> +REVISION=2
> CATEGORIES= sysutils devel
> SHARED_LIBS= blkid 0.0 \
> com_err 21.0 \
> Index: patches/patch-lib_ext2fs_ext2_fs_h
> ===
> RCS file: patches/patch-lib_ext2fs_ext2_fs_h
> diff -N patches/patch-lib_ext2fs_ext2_fs_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_ext2fs_ext2_fs_h22 Mar 2016 21:29:19 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +--- lib/ext2fs/ext2_fs.h.origSat Aug 2 22:26:22 2014
> lib/ext2fs/ext2_fs.h Tue Mar 22 22:26:56 2016
> +@@ -344,6 +344,7 @@ struct ext4_new_group_input {
> + #define _IOT_ext2_new_group_input _IOT (_IOTS(__u32), 5, _IOTS(__u16), 2,
> 0, 0)
> + #endif
> +
> ++#ifndef __OpenBSD__
> + #define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
> + #define EXT2_IOC_SETFLAGS _IOW('f', 2, long)
> + #define EXT2_IOC_GETVERSION _IOR('v', 1, long)
> +@@ -354,6 +355,7 @@ struct ext4_new_group_input {
> + #define EXT2_IOC_GROUP_ADD _IOW('f', 8,struct ext2_new_group_input)
> + #define EXT4_IOC_GROUP_ADD _IOW('f', 8,struct ext4_new_group_input)
> + #define EXT4_IOC_RESIZE_FS _IOW('f', 16, __u64)
> ++#endif
> +
> + /*
> + * Structure of an inode on the disk
This works too, whichever is preferred. Or both. :-)
ok brynet@ if it helps.
Re: Fix japanese/less
On Tue, 22 Mar 2016 20:42:40 +1300 Peter Kane wrote: 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. 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? On my environment they are half-height but the characters are correct. I don't have a fix for this. Also you can use "uim-fep" instead of setting XMODIFIERS for xterm. --yasuoka
Re: [patch] archivers/libarchive ioctl woes
Hi,
On Tue, Mar 22, 2016 at 04:20:34PM -0400, Bryan Steele wrote:
> It seems libarchive/bsdtar is picking up headers from e2fsprogs if
> installed, specifically, headers related to Linux file ioctls.
>
> ./ext2_fs.h:#define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
>
> Here's a patch so that it stops trying random ioctls that
> fortunately all fail with our kernel.
>
> .. might be worth checking other ports.
Well, no objections against your libarchive diff, but wouldn't it
be better to patch the offending header in e2fsprogs and shield
those #define's with #ifndef __OpenBSD__?
If noone beats me, I'll give it a try in a day or two.
Ciao,
Kili
ps: i mean something like this (completely untested for now):
Index: Makefile
===
RCS file: /cvs/ports/sysutils/e2fsprogs/Makefile,v
retrieving revision 1.36
diff -u -p -r1.36 Makefile
--- Makefile15 Dec 2015 10:52:02 - 1.36
+++ Makefile22 Mar 2016 21:29:19 -
@@ -3,7 +3,7 @@
COMMENT= utilities to manipulate ext2 filesystems
DISTNAME= e2fsprogs-1.42.12
-REVISION= 1
+REVISION= 2
CATEGORIES=sysutils devel
SHARED_LIBS= blkid 0.0 \
com_err 21.0 \
Index: patches/patch-lib_ext2fs_ext2_fs_h
===
RCS file: patches/patch-lib_ext2fs_ext2_fs_h
diff -N patches/patch-lib_ext2fs_ext2_fs_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_ext2fs_ext2_fs_h 22 Mar 2016 21:29:19 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+--- lib/ext2fs/ext2_fs.h.orig Sat Aug 2 22:26:22 2014
lib/ext2fs/ext2_fs.h Tue Mar 22 22:26:56 2016
+@@ -344,6 +344,7 @@ struct ext4_new_group_input {
+ #define _IOT_ext2_new_group_input _IOT (_IOTS(__u32), 5, _IOTS(__u16), 2, 0,
0)
+ #endif
+
++#ifndef __OpenBSD__
+ #define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
+ #define EXT2_IOC_SETFLAGS _IOW('f', 2, long)
+ #define EXT2_IOC_GETVERSION _IOR('v', 1, long)
+@@ -354,6 +355,7 @@ struct ext4_new_group_input {
+ #define EXT2_IOC_GROUP_ADD_IOW('f', 8,struct ext2_new_group_input)
+ #define EXT4_IOC_GROUP_ADD_IOW('f', 8,struct ext4_new_group_input)
+ #define EXT4_IOC_RESIZE_FS_IOW('f', 16, __u64)
++#endif
+
+ /*
+ * Structure of an inode on the disk
update audio/py-mpd2
Hi,
Here's an update for py-mpd2. I tried it quickly with audio/sonata, it
seems to work. Then I noticed they added a test suite so I added the
test target which is OK on amd64 and i386.
Cheers,
Daniel
Index: Makefile
===
RCS file: /cvs/ports/audio/py-mpd2/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile10 Jan 2016 15:55:50 - 1.9
+++ Makefile22 Mar 2016 20:47:17 -
@@ -2,7 +2,7 @@
COMMENT = Python client interface for MPD
-MODPY_EGG_VERSION =0.5.4
+MODPY_EGG_VERSION =0.5.5
DISTNAME = python-mpd2-${MODPY_EGG_VERSION}
PKGNAME = py-mpd2-${MODPY_EGG_VERSION}
@@ -20,7 +20,9 @@ MODPY_SETUPTOOLS =Yes
FLAVORS = python3
FLAVOR ?=
-# too many missing dependencies
-NO_TEST = Yes
+TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR}
+
+do-test:
+ cd ${WRKSRC} && ${LOCALBASE}/bin/python${MODPY_VERSION} mpd_test.py
.include
Index: distinfo
===
RCS file: /cvs/ports/audio/py-mpd2/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo10 Jan 2016 15:55:50 - 1.3
+++ distinfo22 Mar 2016 20:47:17 -
@@ -1,2 +1,2 @@
-SHA256 (python-mpd2-0.5.4.tar.gz) =
HMj0BGUqBps+8sEd6aiJOGO+KR3Er1x5LuqwqwboDsE=
-SIZE (python-mpd2-0.5.4.tar.gz) = 33324
+SHA256 (python-mpd2-0.5.5.tar.gz) =
MQ5zjE985bWxA5TsPxgsUkDdPsVexZo3WSTIAE+7XlE=
+SIZE (python-mpd2-0.5.5.tar.gz) = 37359
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/py-mpd2/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 16 Dec 2013 16:29:03 - 1.2
+++ pkg/PLIST 22 Mar 2016 20:47:17 -
@@ -1,7 +1,9 @@
@comment $OpenBSD: PLIST,v 1.2 2013/12/16 16:29:03 ajacoutot Exp $
!%%python3%%
lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}mpd.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}mpd_test.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/mpd.py
+lib/python${MODPY_VERSION}/site-packages/mpd_test.py
lib/python${MODPY_VERSION}/site-packages/python_mpd2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/python_mpd2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/python_mpd2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
UPDATE: net/nmap 7.11
Hi
Here the update for the new 7.11 release.
Kind regards.
Index: Makefile
===
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.119
diff -u -p -r1.119 Makefile
--- Makefile20 Mar 2016 16:12:25 - 1.119
+++ Makefile22 Mar 2016 20:34:20 -
@@ -3,7 +3,7 @@
COMMENT-main= scan ports and fingerprint stack of network hosts
COMMENT-zenmap=graphical frontend for nmap
-MODPY_EGG_VERSION= 7.10
+MODPY_EGG_VERSION= 7.11
DISTNAME= nmap-${MODPY_EGG_VERSION}
PKGNAME-main= ${DISTNAME}
PKGNAME-zenmap=nmap-zenmap-${MODPY_EGG_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/net/nmap/distinfo,v
retrieving revision 1.32
diff -u -p -r1.32 distinfo
--- distinfo18 Mar 2016 21:13:38 - 1.32
+++ distinfo22 Mar 2016 20:34:20 -
@@ -1,2 +1,2 @@
-SHA256 (nmap-7.10.tgz) = aOxAGi2neGSsClmNtqgq0mpxVt8fXVdtr756odcgeD0=
-SIZE (nmap-7.10.tgz) = 11086463
+SHA256 (nmap-7.11.tgz) = 38lds6juTFZlDbqloaHpibKWPej66iUxwh5v1uC8zCo=
+SIZE (nmap-7.11.tgz) = 11094209
[patch] archivers/libarchive ioctl woes
It seems libarchive/bsdtar is picking up headers from e2fsprogs if
installed, specifically, headers related to Linux file ioctls.
./ext2_fs.h:#define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
Here's a patch so that it stops trying random ioctls that
fortunately all fail with our kernel.
.. might be worth checking other ports.
Index: Makefile
===
RCS file: /cvs/ports/archivers/libarchive/Makefile,v
retrieving revision 1.28
diff -u -p -u -r1.28 Makefile
--- archivers/libarchive/Makefile 11 Mar 2016 19:59:11 - 1.28
+++ archivers/libarchive/Makefile 22 Mar 2016 20:12:23 -
@@ -3,7 +3,7 @@
COMMENT= multi-format archive and compression library
DISTNAME= libarchive-3.1.2
-REVISION= 0
+REVISION= 1
SHARED_LIBS= archive 8.2 # 14.2
CATEGORIES=archivers
HOMEPAGE= http://www.libarchive.org/
@@ -27,7 +27,9 @@ CONFIGURE_ARGS+=--without-lzmadec # old
CONFIGURE_ARGS+=--without-nettle # prefer OpenSSL
CONFIGURE_ARGS+=--without-xml2 # expat suffices
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib"
+ LDFLAGS="-L${LOCALBASE}/lib" \
+ ac_cv_header_ext2fs_ext2_fs_h=no \
+ ac_cv_have_decl_EXT2_IOC_GETFLAGS=no
MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/build/autoconf
# Regression tests known to fail due to locale issues
Re: UPDATE: editors/le
Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Remove PFRAG bits in the faq
On Tue, 22 Mar 2016 20:50:26 +0100, Jeremie Courreges-Anglas wrote: > > -Constructs of the form %%flavor%% will trigger the > > inclusion of -PFRAG.flavor. > > That part is still accurate. Yes, I didn't understand PFRAG things that well, thanks for pointing them out :)
pcre CVE-2016-3191 (was: Re: Vulnerable packages in ports 20/03/2016)
Sevan Janiyan writes:
> net/quagga - CVE-2016-2342
An update has been committed today, but I doubt that OpenBSD users would
be affected.
> devel/pcre - CVE-2016-3191
Blindly copy/pasted from upstream's repo.
Index: Makefile
===
RCS file: /cvs/ports/devel/pcre/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile11 Mar 2016 20:28:24 - 1.61
+++ Makefile22 Mar 2016 19:45:47 -
@@ -3,6 +3,7 @@
COMMENT= perl-compatible regular expression library
DISTNAME= pcre-8.38
+REVISION= 0
SHARED_LIBS += pcre 3.0 # 0.1
SHARED_LIBS += pcre16 0.0 # 0.0
Index: patches/patch-pcre_compile_c
===
RCS file: patches/patch-pcre_compile_c
diff -N patches/patch-pcre_compile_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pcre_compile_c22 Mar 2016 19:45:47 -
@@ -0,0 +1,59 @@
+$OpenBSD$
+
+CVE-2016-3191
+
+ Upstream commit: http://vcs.pcre.org/pcre?view=revision&revision=1631
+
+--- pcre_compile.c.origTue Mar 22 20:27:48 2016
pcre_compile.c Tue Mar 22 20:39:59 2016
+@@ -6,7 +6,7 @@
+ and semantics are as close as possible to those of the Perl 5 language.
+
+Written by Philip Hazel
+- Copyright (c) 1997-2014 University of Cambridge
++ Copyright (c) 1997-2016 University of Cambridge
+
+ -
+ Redistribution and use in source and binary forms, with or without
+@@ -560,6 +560,7 @@ static const char error_texts[] =
+ /* 85 */
+ "parentheses are too deeply nested (stack check)\0"
+ "digits missing in \\x{} or \\o{}\0"
++ "regular expression is too complicated\0"
+ ;
+
+ /* Table to identify digits and hex digits. This is used when compiling
+@@ -4591,7 +4592,8 @@ for (;; ptr++)
+ if (code > cd->start_workspace + cd->workspace_size -
+ WORK_SIZE_SAFETY_MARGIN) /* Check for overrun */
+ {
+- *errorcodeptr = ERR52;
++ *errorcodeptr = (code >= cd->start_workspace + cd->workspace_size)?
++ ERR52 : ERR87;
+ goto FAILED;
+ }
+
+@@ -6604,8 +6606,21 @@ for (;; ptr++)
+ cd->had_accept = TRUE;
+ for (oc = cd->open_caps; oc != NULL; oc = oc->next)
+ {
+- *code++ = OP_CLOSE;
+- PUT2INC(code, 0, oc->number);
++ if (lengthptr != NULL)
++{
++#ifdef COMPILE_PCRE8
++*lengthptr += 1 + IMM2_SIZE;
++#elif defined COMPILE_PCRE16
++*lengthptr += 2 + IMM2_SIZE;
++#elif defined COMPILE_PCRE32
++*lengthptr += 4 + IMM2_SIZE;
++#endif
++}
++ else
++{
++*code++ = OP_CLOSE;
++PUT2INC(code, 0, oc->number);
++}
+ }
+ setverb = *code++ =
+ (cd->assert_depth > 0)? OP_ASSERT_ACCEPT : OP_ACCEPT;
Index: patches/patch-pcre_internal_h
===
RCS file: patches/patch-pcre_internal_h
diff -N patches/patch-pcre_internal_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pcre_internal_h 22 Mar 2016 19:45:47 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+CVE-2016-3191
+
+ Upstream commit: http://vcs.pcre.org/pcre?view=revision&revision=1631
+
+--- pcre_internal.h.orig Tue Mar 22 20:28:40 2016
pcre_internal.hTue Mar 22 20:30:29 2016
+@@ -7,7 +7,7 @@
+ and semantics are as close as possible to those of the Perl 5 language.
+
+Written by Philip Hazel
+- Copyright (c) 1997-2014 University of Cambridge
++ Copyright (c) 1997-2016 University of Cambridge
+
+ -
+ Redistribution and use in source and binary forms, with or without
+@@ -2289,7 +2289,7 @@ enum { ERR0, ERR1, ERR2, ERR3, ERR4, ERR5, ERR6,
+ERR50, ERR51, ERR52, ERR53, ERR54, ERR55, ERR56, ERR57, ERR58, ERR59,
+ERR60, ERR61, ERR62, ERR63, ERR64, ERR65, ERR66, ERR67, ERR68, ERR69,
+ERR70, ERR71, ERR72, ERR73, ERR74, ERR75, ERR76, ERR77, ERR78, ERR79,
+- ERR80, ERR81, ERR82, ERR83, ERR84, ERR85, ERR86, ERRCOUNT };
++ ERR80, ERR81, ERR82, ERR83, ERR84, ERR85, ERR86, ERR87, ERRCOUNT };
+
+ /* JIT compiling modes. The function list is indexed by them. */
+
Index: patches/patch-pcreposix_c
===
RCS file: patches/patch-pcreposix_c
diff -N patches/patch-pcreposix_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pcreposix_c 22 Mar 2016 19:45:47 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+CVE-2016-3191
+
+ Upstream commit: http://vcs.pcre.org/pcre?view=revision&revision=1631
+
+--- pcr
Re: Remove PFRAG bits in the faq
Daniel Jakots writes: > Hi, Bijour, > While looking for something else, I saw that PFRAG bits wasn't removed > from the guide/faq yet. > > Cheers, > Daniel > > Index: differences.html > === > RCS file: /cvs/www/faq/ports/differences.html,v > retrieving revision 1.18 > diff -u -p -r1.18 differences.html > --- differences.html 22 Mar 2016 10:56:56 - 1.18 > +++ differences.html 22 Mar 2016 19:35:01 - > @@ -417,10 +417,6 @@ make sense for that port (e.g., FLAV > The WRKDIR is tweaked so that distinct flavors can be built > concurrently without colliding. > > -Constructs of the form %%flavor%% will trigger the inclusion of > -PFRAG.flavor. That part is still accurate. > The %%SHARED%% construct triggers the inclusion > -of PFRAG.shared. > - > bsd.port.subdir.mk understands the extension > SUBDIR=directory,opt1,opt2 to say `build port in directory > with FLAVOR=opt1 opt2.' > Index: guide.html > === > RCS file: /cvs/www/faq/ports/guide.html,v > retrieving revision 1.49 > diff -u -p -r1.49 guide.html > --- guide.html22 Mar 2016 11:01:15 - 1.49 > +++ guide.html22 Mar 2016 19:35:22 - > @@ -531,22 +531,6 @@ Anything not installed can be added to a > Note that PLIST annotations are documented in the > http://man.openbsd.org/?sektion=1&query=pkg_create"; > >pkg_create(1) manual. > - > -Ports that install shared libraries may have another file called > -PFRAG.shared. > - > -PLIST describes the files being independent of whether the > architecture > -supports shared libraries or not. > - > -PFRAG.shared describes only the files being additionally installed > on > -those architectures that support shared libraries. > - > -PFRAG.noshared describes only the files being additionally > installed on > -architectures that do not support shared libraries. > - > -If a port will only work on an architecture supporting shared > -libraries, for example if it relies on loading modules at runtime with > -dlopen(), set SHARED_ONLY=yes. > > > It is possible some directories do not need to be in the PLIST > Index: testing.html > === > RCS file: /cvs/www/faq/ports/testing.html,v > retrieving revision 1.27 > diff -u -p -r1.27 testing.html > --- testing.html 22 Mar 2016 10:56:56 - 1.27 > +++ testing.html 22 Mar 2016 19:35:34 - > @@ -207,8 +207,7 @@ $ for ms in $(make show=MASTER_SITES) > >package > > - Package creation can break if pkg/PLIST* and/or > - pkg/PFRAG* are wrong. Same here. > + Package creation can break if pkg/PLIST* is wrong. > > >install > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Remove PFRAG bits in the faq
Hi, While looking for something else, I saw that PFRAG bits wasn't removed from the guide/faq yet. Cheers, Daniel Index: differences.html === RCS file: /cvs/www/faq/ports/differences.html,v retrieving revision 1.18 diff -u -p -r1.18 differences.html --- differences.html22 Mar 2016 10:56:56 - 1.18 +++ differences.html22 Mar 2016 19:35:01 - @@ -417,10 +417,6 @@ make sense for that port (e.g., FLAV The WRKDIR is tweaked so that distinct flavors can be built concurrently without colliding. -Constructs of the form %%flavor%% will trigger the inclusion of -PFRAG.flavor. The %%SHARED%% construct triggers the inclusion -of PFRAG.shared. - bsd.port.subdir.mk understands the extension SUBDIR=directory,opt1,opt2 to say `build port in directory with FLAVOR=opt1 opt2.' Index: guide.html === RCS file: /cvs/www/faq/ports/guide.html,v retrieving revision 1.49 diff -u -p -r1.49 guide.html --- guide.html 22 Mar 2016 11:01:15 - 1.49 +++ guide.html 22 Mar 2016 19:35:22 - @@ -531,22 +531,6 @@ Anything not installed can be added to a Note that PLIST annotations are documented in the http://man.openbsd.org/?sektion=1&query=pkg_create"; >pkg_create(1) manual. - -Ports that install shared libraries may have another file called -PFRAG.shared. - -PLIST describes the files being independent of whether the architecture -supports shared libraries or not. - -PFRAG.shared describes only the files being additionally installed on -those architectures that support shared libraries. - -PFRAG.noshared describes only the files being additionally installed on -architectures that do not support shared libraries. - -If a port will only work on an architecture supporting shared -libraries, for example if it relies on loading modules at runtime with -dlopen(), set SHARED_ONLY=yes. It is possible some directories do not need to be in the PLIST Index: testing.html === RCS file: /cvs/www/faq/ports/testing.html,v retrieving revision 1.27 diff -u -p -r1.27 testing.html --- testing.html22 Mar 2016 10:56:56 - 1.27 +++ testing.html22 Mar 2016 19:35:34 - @@ -207,8 +207,7 @@ $ for ms in $(make show=MASTER_SITES) package - Package creation can break if pkg/PLIST* and/or - pkg/PFRAG* are wrong. + Package creation can break if pkg/PLIST* is wrong. install
Re: [New port] SLOCCount 2.26
On Mon, Mar 21, 2016 at 10:38:12PM +, Stuart Henderson wrote:
> [...]
> - DESCR is a bit long
> - manpages shouldn't be compressed
> - textproc probably is better, then it will be in the same category as
> cloc. devel as a secondary category makes sense though.
> [...]
Done.
> [...]
> - optional but you could avoid patching the makefile like this
>
> MAKE_FLAGS= PREFIX=${PREFIX} \
> MAN_DIR=${PREFIX}/man \
> DOC_DIR=${PREFIX}/share/doc/sloccount
> [...]
The makefile of SLOCcount is really stubborn. Without patching and with
these options, it tries to install into /usr/local/bin during fake, so
I've left the patch (slightly tweaked so it doesn't compress the
manpage) in.
> [...]
> (also tar.gz is a bit easier than .tbz to review for those of us who
> have their mail client to pass mimetypes like application/x-tar,
> x-tar-gz, etc to vim ;)
> [...]
Whoops, my finger memory was faster than my brain there :)
--
Gregor
textproc-sloccount.tgz
Description: Binary data
Re: Update man pages after NO_SHARED cleanup
Christian Weisgerber writes:
> The scaffolding to support architectures without shared libraries
> has been removed from the ports infrastructure. This updates the
> ports tree man pages accordingly.
>
> bsd.port.arch.mk.5
> bsd.port.mk.5
> port-modules.5
> ruby-module.5
>
> Gone are or will be shortly:
> * the variables CONFIGURE_SHARED, NO_SHARED_LIBS, NO_SHARED_ARCHS,
> and SHARED_ONLY;
> * the PROPERTIES value "no_shared";
> * the PFRAG.shared* and PFRAG.no-shared* files.
>
> (While there, also drop mention of the long gone PROPERTIES value
> "elf".)
>
> OK?
Reads fine, ok with me.
[...]
> @@ -1433,9 +1430,6 @@ is set to "Yes".
> If
> .Ev CONFIGURE_STYLE
> is set to "gnu" or "simple",
> -.Ev CONFIGURE_SHARED
> -is appended to
> -.Ev CONFIGURE_ARGS ,
> .Li CPPFLAGS="-I${LOCALBASE}/include"
> and
> .Li LDFLAGS="-L${LOCALBASE}/lib"
> @@ -1744,9 +1738,8 @@ set by a port:
> .Ev EXTRACT_SUFX ,
> .Ev ONLY_FOR_ARCHS ,
> .Ev PORTHOME ,
This comma could be removed.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [update] textproc/multimarkdown
Stuart Henderson writes:
> On 2016/03/19 15:38, Michael McConville wrote:
>> > +ALL_TARGET = deprecated
>> > +
>> > +# golf MAKE_FLAGS down to 80chars.. :-|
>> > +_i = -include
>> > +_incs = ${_i} src/GLibFacade.h ${_i} src/version.h ${_i}
>> > src/parser.h
>> > +MAKE_FLAGS = CFLAGS="${CFLAGS} ${_incs}"
>>
>> Why golf? Can't you just use backslashes as necessary? I would get rid
>> of _i and _incs.
>>
>
> I think this approach is dangerous, better to keep those bits which are
> normally part of upstream's Makefile in their Makefile and change the
> way that you pass in CFLAGS. (e.g. maybe pass in COPTFLAGS instead and
> change their Makefile to do COPTFLAGS?=-O3 and "CFLAGS?=${COPTFLAGS} ...
> -include ...")
>
> But then again, we have cmake, why not just use that? It's upstream's
> preferred build infrastructure, whereas for the make-based one they say
> "I don't recommend this approach, but it should work in a pinch"..
Agree, this was sleazy and poorly considered. I'm sorry. Anytime I
find myself golfing I should stop.
Attached is new attempt that uses cmake instead. Works for me on i386.
N.B.: I set NO_TEST to Yes now because the tests are buried in a git
submodule; furthermore, the repo on which the submodule is based has
no tags and thus no releases, making it impossible for me to reach out
for it as a distfile (unless I'm missing something). I'm going to try
to convince the upstream to start tagging that repo, but if I fail
then I'll self-host a tarball for tests on the next update.
Thanks as always for the feedback.
Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
Index: Makefile
===
RCS file: /cvs/ports/textproc/multimarkdown/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile 5 Apr 2015 13:31:15 - 1.2
+++ Makefile 22 Mar 2016 18:48:31 -
@@ -1,13 +1,13 @@
# $OpenBSD: Makefile,v 1.2 2015/04/05 13:31:15 sthen Exp $
-V = 4.7.1
+V = 5.1.0
COMMENT = marked-up plain text to formatted document converter
DISTNAME = ${GH_PROJECT}-${V}
PKGNAME = multimarkdown-${V}
CATEGORIES = textproc
GH_ACCOUNT = fletcher
-GH_PROJECT = MultiMarkdown-4
+GH_PROJECT = MultiMarkdown-5
GH_TAGNAME = ${V}
HOMEPAGE = http://fletcherpenney.net/multimarkdown/
@@ -20,15 +20,19 @@ WANTLIB += c
BUILD_DEPENDS = devel/greg
-USE_GMAKE = Yes
-ALL_TARGET = ALL
-MAKE_FLAGS = CFLAGS="${CFLAGS} -include GLibFacade.h -DHAVE_ARC4RANDOM" \
- GREG=${LOCALBASE}/bin/greg
+MODULES = devel/cmake
+
+CFLAGS += -DHAVE_SRAND_DETERMINISTIC
+
+CONFIGURE_ARGS += -DGREG=${LOCALBASE}/bin/greg
# Test files aren't included in distfile.
NO_TEST = Yes
+pre-configure:
+ touch ${WRKBUILD}/README.html
+
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/multimarkdown ${PREFIX}/bin/
+ ${INSTALL_PROGRAM} ${WRKBUILD}/multimarkdown ${PREFIX}/bin/
.include
Index: distinfo
===
RCS file: /cvs/ports/textproc/multimarkdown/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 24 Mar 2015 19:16:13 - 1.1.1.1
+++ distinfo 22 Mar 2016 18:48:31 -
@@ -1,2 +1,2 @@
-SHA256 (MultiMarkdown-4-4.7.1.tar.gz) = gy5dzm+hv/TWfmSsLMJPCSCujZEoDlPqh5I3odQ/SGU=
-SIZE (MultiMarkdown-4-4.7.1.tar.gz) = 120896
+SHA256 (MultiMarkdown-5-5.1.0.tar.gz) = ZdT8mzDrZq9vYLN8HzJBlf3xqSb/umBoLd9+/MH4eGg=
+SIZE (MultiMarkdown-5-5.1.0.tar.gz) = 135170
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt 22 Mar 2016 18:48:31 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Use installed greg
+--- CMakeLists.txt.orig Mon Feb 22 20:05:02 2016
CMakeLists.txt Tue Mar 22 12:45:41 2016
+@@ -149,7 +149,7 @@ endif ()
+ # Need to build parser.c via greg
+ add_custom_command (
+ OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/parser.c
+- COMMAND ${PROJECT_SOURCE_DIR}/submodules/greg/greg -o ${CMAKE_CURRENT_BINARY_DIR}/parser.c ${PROJECT_SOURCE_DIR}/src/parser.leg
++ COMMAND ${GREG} -o ${CMAKE_CURRENT_BINARY_DIR}/parser.c ${PROJECT_SOURCE_DIR}/src/parser.leg
+ )
+
+ # src_files are the primary files, and will be included in doxygen documentation
Index: patches/patch-Makefile
===
RCS file: patches/patch-Makefile
diff -N patches/patch-Makefile
--- patches/patch-Makefile 24 Mar 2015 19:16:13 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,37 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.1.1.1 2015/03/24 19:16:13 okan Exp $
-
-Make it possible to pass GREG=/usr/local/bin/greg in on the
-command line and avoid git submodules.
-
Makefile.orig Mon Mar 23 18:21:56 2015
-+++ Makefile Mon Mar 23 18:32:22 2015
-@@ -32,18 +32,25 @@ ifeq ($(MAKECMDGOALS),static)
- LDFLAGS += -static -static-libgc
Fix wkhtmltopdf runtime dependency
Apparently wkhtmltopdf has a runtime dependency on icu4c. Attached
patch adds it to the port. It would be great if this patch could
also be added to 5.9-stable.
Thanks.
Frank
Index: Makefile
===
RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile13 Jan 2016 22:31:38 - 1.6
+++ Makefile21 Mar 2016 19:07:41 -
@@ -8,7 +8,7 @@ COMMENT = convert HTML to PDF using Web
GH_ACCOUNT = wkhtmltopdf
GH_PROJECT = wkhtmltopdf
GH_TAGNAME = 0.12.2.4
-REVISION = 2
+REVISION = 3
QT_COMMIT =7e48a1fac7e0f9aefccd01e9871f987da3a62fda
MASTER_SITES0 = https://github.com/wkhtmltopdf/qt/archive/
DISTFILES =${DISTNAME}.tar.gz \
@@ -25,11 +25,13 @@ MAINTAINER =Frank Groeneveld
Re: Vulnerable packages in ports 20/03/2016
On 2016-03-22, Sevan / Venture37 wrote: >> Presumably they use the shared library? > > Correct. Then they don't need a revision bump. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: pledge(2) urlview
On 2016-03-19, Jeremie Courreges-Anglas wrote: > It would be sad if addition of pledge(2) to ports resulted tons of > #ifdef __OpenBSD__. From the patches in the ports tree I can only spot > archivers/xz and devel/cscope following that pattern. Well, pledge(2) *is* specific to OpenBSD. That's why I wrapped it in __OpenBSD__ when I added it to xz. -- Christian "naddy" Weisgerber na...@mips.inka.de
[NEW] textproc/lua-lustache
Hi ports@, Here is a new port, I use it locally when developing on a Lua codebase and it's also a dependency for an upcoming port. >From DESCR : lustache is an implementation of the mustache template system in Lua. Mustache is a logic-less template syntax. It can be used for HTML, config files, source code - anything. It works by expanding tags in a template using values provided in a hash or object. We call it "logic-less" because there are no if statements, else clauses, or for loops. Instead there are only tags. Some tags are replaced with a value, some nothing, and others a series of values. lua-lustache.tar.gz Description: application/tar-gz
[NEW] snakeyaml - n00b's first attempt at a Maven/Java port
All, Attached to this email is a port of snakeyaml, a YAML parser for Java. The thing that makes this challenging is that the upstream build for this doesn't use ANT, it uses Maven. As many of you may know, the way Maven works is that you fetch the upstream source, and then as it builds, it is accessing the internet and pulling down the additional dependency jarfiles it needs to successfully build the final packages. Unfortunately, we have our build system locked down (and rightly so) so that during the build phase, the network is inaccessible. My "solution" (some might say hack) to this is that I run the full build and test locally, and then grab the contents of my ~/.m2/repository directory (where maven caches those files so that they aren't re-fetched each time) and put it in a tarball in a separate gitHub repository that is solely dedicated to the port in question and is synchronized to the version (and version dependencies) of the upstream project. The port then fetches the maven dependencies as a separate DISTFILES0 source and then leverages a feature of maven to run in "offline" mode using a local directory as the source of the dependencies. I've tried to do this as cleanly as my little n00b brain can manage but I would really appreciate some hardcore feedback on this suggested port. If I can get it clean enough to where folks on the list are willing to commit it for me, I'd like to wade into the ports infrastructure and documentation and see if I can suggest a patch that would allow this to happen more easily so that we could have access to the large number of Maven-built open source packages out there (most of the JDBC drivers, some of the required infrastructure for a full build of OpenJDK, etc.) I have tested this port locally to simulate the formal build process by first running a 'make fetch', then ifconfig down-ing my network and running the rest of the build and install process with no network connectivity. It "works on my machine" (TM) in this mode. I'll be doing further testing on my i386, single core sparc64 and multicore sparc64 boxes to ensure that this works everywhere that we have Java support as well; however, I wanted to get feedback now before I dive into that part. Please, be as direct as you possibly can on this so that I can leverage the collective knowledge of the group to perhaps solve this problem in a more systematic way. Thanks in advance, by the way, for all of your suggestions and thank you for the help you've given me to get this far. Thanks, Bryan snakeyaml.tgz Description: GNU Zip compressed data
Re: Where do we want PKG_ARCH in Makefile?
We are going to have to be careful with these perl WANTLIBs, now that
SHARED_ONLY isn't used they are easy to miss, and worse some people
may try to remove them because they say "extra", which will mess things
up for future perl updates.
This might be a useful addition to portcheck.
On 2016/03/21 19:09, Nigel Taylor wrote:
> On 03/20/16 10:33, Stuart Henderson wrote:
> > Watch out for p5-libintl, it currently does not have SHARED_ONLY=Yes
> > and should do. Not touching it myself now to avoid getting in your way.
> >
> >
>
> These also are wrong, and have been for some time.
>
> $ pwd
> /usr/ports/packages/amd64/no-arch
> $ pkg_info -Sq p5-* | grep ",[A-z]"
> p5-Digest-MD4-1.9p1,c.84.2
> p5-Digest-Skein-0.05p3,c.84.2
> p5-Socket-GetAddrInfo-0.22p0,c.84.2
> p5-Wx-0.9928,@p5-Alien-wxWidgets-0.67p0,@p5-ExtUtils-XSpp-0.18,@wxWidgets-media-2.8.12p7,m.9.0,pthread.20.1,stdc++.57.0,wx_base.3.0,wx_base_net.3.0,wx_base_xml.3.0,wx_gtk2_adv.3.0,wx_gtk2_aui.3.0,wx_gtk2_core.3.0,wx_gtk2_html.3.0,wx_gtk2_media.3.0,wx_gtk2_richtext.3.0,wx_gtk2_stc.3.0,wx_gtk2_xrc.3.0
Fixed.
> All these are wrong also .
>
> $ pkg_info -Sq *.tgz | grep ",[A-z]"
> glm-0.9.7.1,@gcc-libs-4.9.3p3,estdc++.17.0
> gnustep-make-2.6.7p1,@gcc-libs-4.9.3p3,@gtar-1.28p1,estdc++.17.0
> gtk3mm-documentation-3.18.0,@gcc-libs-4.9.3p3,estdc++.17.0
> kde-shared-data-4.14.3p1,@gcc-libs-4.9.3p3,@gtk-update-icon-cache-3.18.9,estdc++.17.0
> ruby-ri_docs-1.8.7.374p0,@libiconv-1.14p3,iconv.6.0
> tmake-1.10p3,@qt3-mt-3.8p9,lib/qt3/qt-mt.33.0
> unoconv-0.7p1,@gcc-libs-4.9.3p3,@libreoffice-5.1.1.3p0v0,@python-3.4.4,estdc++.17.0
I haven't looked at these yet.
> $ portcheck
> www/p5-HTML-Base
>
> portcheck fails to find this one... It could find problem by analysing
> the PLIST
> I do have a fixed version of p5-HTML-Base. Replace ${P5ARCH} by
> ${P5SITE} in the do-install:, recreate pkg/PLIST, and bump.
This one is odd, why is it using P5ARCH in the first place?
Just a mistake or is there a particular reason?
Re: [mail/sendmail] SMTP session reuse bugfix
Jeremie Courreges-Anglas writes:
> Claus Assmann writes:
>
>> FYI (I haven't seen this in ports yet):
[...]
>> If sendmail tried to reuse an SMTP session which had already been
>> closed by the server, then the connection cache could have invalid
>> information about the session. One possible consequence was that
>> STARTTLS was not used even if offered.
>> The problem can be fixed by either:
>> - applying the patch (for 8.15.2) available at
>> ftp://ftp.sendmail.org/pub/sendmail/8.15.2.mci.p0
>> ftp://ftp.sendmail.org/pub/sendmail/8.15.2.mci.p0.sig
>
> The diff below applies your patch to the current tarball. Build-tested
> only as my setup doesn't involve STARTTLS... Tests welcome.
[...]
>> - or disabling the connection cache:
>> define(`confMCI_CACHE_SIZE', `0')
>>
>> The problem can be mitigated by setting at least one of these options:
>> - using a very short timeout:
>> define(`confMCI_CACHE_TIMEOUT', `5s')
>> - sorting the queue by hosts:
>> define(`confQUEUE_SORT_ORDER', `Host')
>
> We could patch the m4 bits, but people tend not to regen their .cf often
> so that would not help much in the end.
>
>> Note: This issue is fixed in sendmail snapshot 8.16.0.16 (or newer)
>> for those who would like to test upcoming releases.
ping
Same diff inline, for convenience.
Index: Makefile
===
RCS file: /cvs/ports/mail/sendmail/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile7 Mar 2016 14:19:46 - 1.14
+++ Makefile9 Mar 2016 21:52:59 -
@@ -7,9 +7,11 @@ V= 8.15.2
DISTNAME = sendmail.${V}
PKGNAME-main = sendmail-${V}
PKGNAME-libmilter =libmilter-${V}
-REVISION-main =0
+REVISION-main =1
FULLPKGNAME-libmilter =libmilter-${V}
FULLPKGPATH-libmilter =mail/sendmail,-libmilter
+
+PATCHFILES = 8.15.2.mci.p0
SHARED_LIBS = milter 4.0
Index: distinfo
===
RCS file: /cvs/ports/mail/sendmail/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo19 Jul 2015 02:25:35 - 1.3
+++ distinfo9 Mar 2016 22:19:18 -
@@ -1,2 +1,4 @@
+SHA256 (8.15.2.mci.p0) = nqS15nJXc76HXnORZGpbj2ssLfuSRqbjR2OvR/tN5uA=
SHA256 (sendmail.8.15.2.tar.gz) = JPlLX9dnBfFYl6eJMqXyQ5oysaL9w1dpuxpfXZtNtDk=
+SIZE (8.15.2.mci.p0) = 6712
SIZE (sendmail.8.15.2.tar.gz) = 2207417
Index: pkg/PLIST-libmilter
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Vulnerable packages in ports 20/03/2016
> On 21 Mar 2016, at 16:36, Christian Weisgerber wrote: > > Presumably they use the shared library? Correct. Sevan
Re: [WIP] Grub 2.02-beta3
On Tue, Mar 22, 2016 at 06:46:25AM -0400, Josh Grosse wrote:
> Hi, Jiri. I haven't built your port, yet, just ran it through
> portcheck(1). It found a missing gettext dependency, and if you
> add gettext to your modules, you won't need a lib dependency on xz.
>
Something like this?
--- /tmp/Makefile.orig Tue Mar 22 12:04:00 2016
+++ MakefileTue Mar 22 12:02:19 2016
@ -13,8 +13,10 @@ PERMIT_PACKAGE_CDROM=Yes
MASTER_SITES= http://alpha.gnu.org/gnu/grub/
-MODULES+= lang/python
-MODULES += gcc4
+WANTLIB+= c util
+
+MODULES+= lang/python devel/gettext
+MODULES+= gcc4
MODGCC4_LANGS = c
MODGCC4_ARCHS = *
@ -24,7 +26,6 @@ AUTOMAKE_VERSION= 1.15
BUILD_DEPENDS+=${MODGNU_AUTOCONF_DEPENDS} \
${MODGNU_AUTOMAKE_DEPENDS} \
devel/bison
-LIB_DEPENDS+= archivers/xz
CONFIGURE_STYLE=automake
CONFIGURE_ARGS+=--sysconfdir=${SYSCONFDIR} \
j.
[WIP] Grub 2.02-beta3
Hi, this is real WIP of Grub 2.02-beta3. I've tried my best but it needs for sure more testing - I'd tried to adapt README and configuration file for disabling partition to Grub 2 syntax but I'm not personally user of such features. My original goal was to replace pxelinux with Grub2 but I still have issues to "pxechain" OpenBSD pxeboot from Grub2 downloaded via PXE. Tests, comments are welcomed. j. grub2.tar.gz Description: application/tar-gz
Re: Fix japanese/less
On 2016-03-22 20:42:40, Peter Kane wrote: > On Mon, Mar 21, 2016 at 05:52:53PM +0900, Bryan Linton wrote: > > 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 > > > > 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 with the tweak I mentioned above, you'll find UIM worth switching to. While the historian in me loves to preserve old software, and the "OpenBSD-ness" in me values a diverse range of software, sometimes I do indeed remind myself that sometimes we deprecate things for a reason. It seems like UIM is becoming the more or less "standard" IME for the most part, since it can interface with just about any language and backend AFAIK. It's probably worth switching to in the long run since I don't know how well maintained any of the other IMEs will be in the future. -- Bryan
Re: remove mail/metamail?
On 2016/03/20 13:54, Michael McConville wrote: > Stuart Henderson wrote: > > As mentioned elsewhere but wanted to get it on ports@ as well, a few > > other programs have a soft dependency on metamail, mostly newsreaders > > (tin, slrn and emacs gnus can optionally uae it). And it may be used > > in some local scripts for encoding MIME messages, there aren't many > > options for simple command-line tools to do this.. > > My main concern is how vulnerable metamail likely is. It had a > far-from-stellar record when it was popular: > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=metamail > > Because it isn't packaged with Debian or being widely used anymore, I > doubt it's getting many eyeballs. And development stopped in 1994. I > wouldn't be surprised if the latest versions of afl and Coverity could > find some scary stuff. > I see that other BSDs have metamail and a separate package for mmencode. What do you think about about doing that and removing the main metamail port, mmencode will skip the scariest code and is probably the part that is hardest to replace (e.g. mpack/munpack don't do some of the encodings that mmencode supports).
Re: Fix japanese/less
On Mon, Mar 21, 2016 at 05:52:53PM +0900, Bryan Linton wrote: > 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 > 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. 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. Now that the startup is running better I haven't seen any anthy-related root processes hanging around in top. Peter
