Re: postfix stable35->3.5.22, stable->3.7.8

2023-12-29 Thread Why 42? The lists account.


On Fri, Dec 22, 2023 at 10:24:03PM +, Stuart Henderson wrote:
> On 2023/12/22 22:20, Stuart Henderson wrote:
> > On 2023/12/19 16:52, Stuart Henderson wrote:
> > > Here are updates to postfix stable and stable35 versions, the latter
> > > from tb@. I've tested both.
> > 
> > New ones with smtpd_forbid_bare_newline :
> 
> oops, updated on a machine that didn't have the 3.5 openssl
> patch, here are the right ones:
> ...

Hi Stuart,

That's very cool - I'd love to be able to build a new Postfix with that
fix.

Currently I'm running 7.3 (+ postfix-3.7.5p8-sasl2). Should this diff
apply to 7.3?

FYI, I've not used ports much before, well, not in the last 10 years or
so. I was able to download the port tar archive:
> ftp https://cdn.openbsd.org/pub/OpenBSD/$(uname -r)/{ports.tar.gz,SHA256.sig}

And, after some faffing around, I was able to do "make fetch" and "make
extract". However, when I use patch to try to apply the diffs from your
email, I noticed two errors. The first one is a "patch reversed" error:
> dna-ng:postfix 29.12 17:26:00 % patch -i 
> ~robb/obsd_ports_postfix_build_mods_smtp_smuggling_20231222.patch ; echo $?
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: stable/Makefile
> |===
> |RCS file: /cvs/ports/mail/postfix/stable/Makefile,v
> |retrieving revision 1.251
> |diff -u -p -r1.251 Makefile
> |--- stable/Makefile  26 Oct 2023 20:17:58 -  1.251
> |+++ stable/Makefile  22 Dec 2023 22:22:09 -
> --
> Patching file stable/Makefile using Plan A...
> Reversed (or previously applied) patch detected!  Assume -R? [y] 
> Hunk #1 succeeded at 2 with fuzz 1 (offset 1 line).
> Can't backup stable/Makefile, output is in /home/robb/tmp/patchoS8gjDYOvpd: 
> Permission denied
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> ...
(Not sure how best to answer that question) ...

Then, after several apparently successful patch operations, the patch
command ends with:
> ...
> |Index: stable35/patches/patch-src_tls_tls_misc_c
> |===
> |RCS file: stable35/patches/patch-src_tls_tls_misc_c
> |diff -N stable35/patches/patch-src_tls_tls_misc_c
> |--- /dev/null1 Jan 1970 00:00:00 -
> |+++ stable35/patches/patch-src_tls_tls_misc_c22 Dec 2023 22:22:09 
> -
> --
> (Creating file stable35/patches/patch-src_tls_tls_misc_c...)
> patch:  can't find stable35/patches/patch-src_tls_tls_misc_c
> 2

At this point the stable35/patches sub-directory contains:
> dna-ng:postfix 29.12 17:47:40 % l stable35/patches/
> -rw-r--r--  1 root  wheel   566 Nov  1  2022 patch-src_util_sys_defs_h
> -rw-r--r--  1 root  wheel   424 Nov  1  2022 patch-src_tls_tls_server_c
> -rw-r--r--  1 root  wheel   415 Nov  1  2022 patch-src_tls_tls_certkey_c
> -rw-r--r--  1 root  wheel   674 Nov  1  2022 patch-makedefs
> -rw-r--r--  1 root  wheel  6248 Nov  1  2022 patch-conf_master_cf
> -rw-r--r--  1 root  wheel   611 Nov  1  2022 patch-conf_main_cf
> drwxr-xr-x  2 root  wheel   512 Mar 25  2023 CVS

It seems more likely I'm doing something wrong than there is an issue
with your patch ... but just FYI.

Ironically, I'm only interested in building 3.7.9 + sasl2. If I carry on
regardless :-) ... then I run into some issue(s) around ports and
permissions e.g. "make prepare" starts, runs and then fails with:
> ...
> ===>  Building package for metaauto-1.0p4
> Create /home/robb/ports/PACKAGE_REPOSITORY/amd64/no-arch/metaauto-1.0p4.tgz
> Creating package metaauto-1.0p4
> pkg_create: mkdir /usr/ports/plist: Permission denied

After a further (long) period of experimentation, I tried switching from
using sudo to doas in mk.conf ... but now even the fetch command fails
:-/

Cheers,
Robb.



XFCE thunar dumps core when toggling "show hidden"

2023-12-28 Thread Why 42? The lists account.


Hi All,

(This discussion/issue moved from misc).

Thunar crashes when I try to toggle "show hidden" e.g. via "Ctrl+h":
zsh: segmentation fault (core dumped)  thunar

I'm running a recent snapshot:
mjoelnir:empty_directory 28.12 10:30:37 % uname -a
OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1535 amd64

With XFCE 4.18 e.g.
thunar-4.18.8   Xfce4 file manager
thunar-archive-0.5.2 Thunar archive plugin
thunar-media-tags-0.4.0 Thunar media tags plugin
xfce-4.18.1 Xfce desktop meta-package (base installation)

Below is a gdb stacktrace with various debug packages installed:
debug-glib2-2.78.3  debug info for glib2
debug-gtk+3-3.24.39 debug info for gtk+3
debug-thunar-4.18.8 debug info for thunar

Cheers,
Robb.


(gdb) bt
#0  g_node_traverse_pre_order (node=, flags=G_TRAVERSE_ALL, 
func=0xb39a046db40 , 
data=0xb3c1e775d20) at ../glib-2.78.3/glib/gnode.c:543
#1  0x0b3bff3c2577 in g_node_traverse_pre_order (node=, 
flags=G_TRAVERSE_ALL, func=0xb39a046db40 
, data=0xb3c1e775d20) at 
../glib-2.78.3/glib/gnode.c:544
#2  0x0b3bff3c2577 in g_node_traverse_pre_order (node=, 
flags=G_TRAVERSE_ALL, func=0xb39a046db40 
, data=0xb3c1e775d20) at 
../glib-2.78.3/glib/gnode.c:544
#3  0x0b39a0471046 in thunar_tree_view_set_show_hidden (view=0xb3c2ec9edc0, 
show_hidden=) at thunar-tree-view.c:1990
#4  thunar_tree_view_set_property (object=0xb3c2ec9edc0, prop_id=, value=, pspec=) at thunar-tree-view.c:509
#5  0x0b3c5df7982a in object_set_property (object=0xb3c2ec9edc0, 
pspec=0xb3c2ec70560, value=0x7c245b20a620, nqueue=0xb3c2aaeb250, 
user_specified=) at ../glib-2.78.3/gobject/gobject.c:1811
#6  0x0b3c5df795a8 in g_object_setv (object=0xb3c2ec9edc0, n_properties=1, 
names=0x7c245b20a5e0, values=0x7c245b20a620) at 
../glib-2.78.3/gobject/gobject.c:2722
#7  0x0b3c5df7a94b in g_object_set_property (object=0xdfdfdfdfdfdfdfdf, 
property_name=0xb39a03dea3b "show-hidden", value=0x0) at 
../glib-2.78.3/gobject/gobject.c:3022
#8  0x0b3c5df69f19 in on_source_notify (source=, 
pspec=, context=) at 
../glib-2.78.3/gobject/gbinding.c:556
#9  0x0b3c5df7142b in g_closure_invoke (closure=0xb3c1e76f570, 
return_value=, n_param_values=, 
param_values=0x7c245b20a7e0, invocation_hint=) at 
../glib-2.78.3/gobject/gclosure.c:832
#10 0x0b3c5df8df4c in signal_emit_unlocked_R (node=0x7c245b20a830, 
detail=2100, instance=0xb3c47855690, emission_return=0x0, 
instance_and_params=0x7c245b20a7e0) at ../glib-2.78.3/gobject/gsignal.c:3980
#11 0x0b3c5df8bbab in signal_emit_valist_unlocked (instance=0xb3c47855690, 
signal_id=, detail=2100, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3612
#12 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c47855690, 
signal_id=1, detail=2100, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#13 g_signal_emit (instance=0xb3c47855690, signal_id=1, detail=2100) at 
../glib-2.78.3/gobject/gsignal.c:3675
#14 0x0b3c5df7da53 in g_object_dispatch_properties_changed 
(object=0xb3c47855690, n_pspecs=1, pspecs=0x7c245b20aaf8) at 
../glib-2.78.3/gobject/gobject.c:1427
#15 0x0b3c5df77e1c in g_object_notify_by_spec_internal 
(object=0xb3c47855690, pspec=0xb3c2ec77790) at 
../glib-2.78.3/gobject/gobject.c:1551
#16 0x0b39a047fc07 in thunar_window_action_show_hidden 
(window=0xb3c0f47e260) at thunar-window.c:4727
#17 0x0b3c5df7142b in g_closure_invoke (closure=0xb3c99ee9d40, 
return_value=, n_param_values=, 
param_values=0x7c245b20acc0, invocation_hint=) at 
../glib-2.78.3/gobject/gclosure.c:832
#18 0x0b3c5df8df4c in signal_emit_unlocked_R (node=0x7c245b20ad00, 
detail=0, instance=0xb3c99ef7180, emission_return=0x0, 
instance_and_params=0x7c245b20acc0) at ../glib-2.78.3/gobject/gsignal.c:3980
#19 0x0b3c5df8bbab in signal_emit_valist_unlocked (instance=0xb3c99ef7180, 
signal_id=, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3612
#20 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c99ef7180, 
signal_id=487, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#21 g_signal_emit (instance=0xb3c99ef7180, signal_id=487, detail=0) at 
../glib-2.78.3/gobject/gsignal.c:3675
#22 0x0b3c42762fc6 in gtk_check_menu_item_toggled 
(check_menu_item=0xb3c99ef7180) at ../gtk+-3.24.39/gtk/gtkcheckmenuitem.c:473
#23 gtk_check_menu_item_activate (menu_item=0xdfdfdfdfdfdfdfdf) at 
../gtk+-3.24.39/gtk/gtkcheckmenuitem.c:640
#24 0x0b3c5df716fc in _g_closure_invoke_va (closure=0xb3bab6b6420, 
return_value=, instance=, args=0x7c245b20b250, 
n_params=, param_types=) at 
../glib-2.78.3/gobject/gclosure.c:895
#25 0x0b3c5df8bedf in signal_emit_valist_unlocked (instance=0xb3c99ef7180, 
signal_id=175, detail=, var_args=0x7c245b20b250) at 
../glib-2.78.3/gobject/gsignal.c:3516
#26 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c99ef7180, 
signal_id=175, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#27 g_signal_emit (instance=0xb3c99ef7180, signal_id=175, detail=0) at 
../glib-2.78.3/gobject/gsignal.c:3675
#28 

Re: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.

2023-07-21 Thread Alexis de BRUYN [Mailing Lists]

On 20/07/2023 11:58, Stuart Henderson wrote:

Did pkg_add -u complete successfully or did you have any errors or warnings?

No, no errors/warnings.

I have done a sysclean -a after, and deleted some libs.

You might get more information from trying to run a Qt-based program 
with LD_DEBUG set in the environment, but there will be a lot of output, 
probably needs running under script rather than relying on scrollback.


$ LD_DEBUG=1 flameshot
[...]
examining: '/usr/local/lib/qt5/libQt5XcbQpa.so.1.2'
loading: libz.so.5.0 required by /usr/local/lib/qt5/libQt5XcbQpa.so.1.2
dlopen: failed to open libz.so.5.0

$ ll /usr/local/lib/qt5/libQt5XcbQpa.so*
-rw-r--r--  1 root  bin  3043000 May 21 19:56 
/usr/local/lib/qt5/libQt5XcbQpa.so.0.1
-rw-r--r--  1 root  bin  3036224 Jul 17 17:30 
/usr/local/lib/qt5/libQt5XcbQpa.so.1.0
-rw-r--r--  1 root  bin  1709088 Mar  7  2020 
/usr/local/lib/qt5/libQt5XcbQpa.so.1.2


$ doas rm -f /usr/local/lib/qt5/libQt5XcbQpa.so.1.2
doas (ale...@ws-alexis.lan.mrs.de-bruyn.fr) password:

All Qt-based programs are running fine now.

Thanks Stuart and Rafael for your help.




--
   Sent from a phone, apologies for poor formatting.


On 20 July 2023 04:00:25 "Alexis de BRUYN [Mailing Lists]" 
 wrote:



On 19/07/2023 22:20, Rafael Sadowski wrote:
On Wed Jul 19, 2023 at 06:17:08PM +0200, Alexis de BRUYN [Mailing 
Lists] wrote:

Hi Everybody,

Following -current, I have just sysupgraded / pkg_add -u (after ~40 
days),

and I cannot launch qt applications anymore :

$ nextcloud
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" 
even though

it was found.
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, 
offscreen, vnc,
wayland-egl, wayland, wayland-xcomposite-egl, 
wayland-xcomposite-glx, xcb.



Could you run qtdiag-qt5 and send the output?

$ QT_DEBUG_PLUGINS=1 qtdiag-qt5
QFactoryLoader::QFactoryLoader() checking directory path
"/usr/local/lib/qt5/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at
"/usr/local/lib/qt5/plugins/platforms/libqeglfs.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqeglfs.so,
metadata=
{
     "IID":
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
     "MetaData": {
         "Keys": [
             "eglfs"
         ]
     },
     "archreq": 0,
     "className": "QEglFSIntegrationPlugin",
     "debug": false,
     "version": 331520
}


Got keys from plugin meta data ("eglfs")
QFactoryLoader::QFactoryLoader() looking at
"/usr/local/lib/qt5/plugins/platforms/libqminimal.so"
Found metadata in lib
/usr/local/lib/qt5/plugins/platforms/libqminimal.so, metadata=
{
     "IID":
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
     "MetaData": {
         "Keys": [
             "minimal"
         ]
     },
     "archreq": 0,
     "className": "QMinimalIntegrationPlugin",
     "debug": false,
     "version": 331520
}


Got keys from plugin meta data ("minimal")
QFactoryLoader::QFactoryLoader() looking at
"/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so"
Found metadata in lib
/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so, metadata=
{
     "IID":
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
     "MetaData": {
         "Keys": [
             "minimalegl"
         ]
     },
     "archreq": 0,
     "className": "QMinimalEglIntegrationPlugin",
     "debug": false,
     "version": 331520
}


Got keys from plugin meta data ("minimalegl")
QFactoryLoader::QFactoryLoader() looking at
"/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so"
Found metadata in lib
/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so, metadata=
{
     "IID":
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
     "MetaData": {
         "Keys": [
             "offscreen"
         ]
     },
     "archreq": 0,
     "className": "QOffscreenIntegrationPlugin",
     "debug": false,
     "version": 331520
}


Got keys from plugin meta data ("offscreen")
QFactoryLoader::QFactoryLoader() looking at
"/usr/local/lib/qt5/plugins/platforms/libqvnc.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqvnc.so,
metadata=
{
     "IID":
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
     "MetaData": {
         "Keys": [
      

Re: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.

2023-07-19 Thread Alexis de BRUYN [Mailing Lists]

On 19/07/2023 22:20, Rafael Sadowski wrote:

On Wed Jul 19, 2023 at 06:17:08PM +0200, Alexis de BRUYN [Mailing Lists] wrote:

Hi Everybody,

Following -current, I have just sysupgraded / pkg_add -u (after ~40 days),
and I cannot launch qt applications anymore :

$ nextcloud
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though
it was found.
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc,
wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.



Could you run qtdiag-qt5 and send the output?

$ QT_DEBUG_PLUGINS=1 qtdiag-qt5
QFactoryLoader::QFactoryLoader() checking directory path 
"/usr/local/lib/qt5/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqeglfs.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqeglfs.so, 
metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"eglfs"
]
},
"archreq": 0,
"className": "QEglFSIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("eglfs")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqminimal.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqminimal.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"minimal"
]
},
"archreq": 0,
"className": "QMinimalIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("minimal")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"minimalegl"
]
},
"archreq": 0,
"className": "QMinimalEglIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("minimalegl")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"offscreen"
]
},
"archreq": 0,
"className": "QOffscreenIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("offscreen")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqvnc.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqvnc.so, 
metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"vnc"
]
},
"archreq": 0,
"className": "QVncIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("vnc")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqwayland-egl.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqwayland-egl.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"wayland-egl"
]
},
"archreq": 0,
"className": "QWaylandEglPlatformIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("wayland-egl")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqwayland-generic.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqwayland-generic.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"wayland"
]

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.

2023-07-19 Thread Alexis de BRUYN [Mailing Lists]

Hi Everybody,

Following -current, I have just sysupgraded / pkg_add -u (after ~40 
days), and I cannot launch qt applications anymore :


$ nextcloud
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even 
though it was found.
This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.


Available platform plugins are: eglfs, minimal, minimalegl, offscreen, 
vnc, wayland-egl, wayland, wayland-xcomposite-egl, 
wayland-xcomposite-glx, xcb.


Abort trap

$ doas pkg_add -r qtbase-5.15.10
quirks-6.134 signed on 2023-07-18T21:18:51Z

$ QT_PLUGIN_PATH=/usr/local/lib/qt5/plugins/ nextcloud
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even 
though it was found.
This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.


Available platform plugins are: eglfs, minimal, minimalegl, offscreen, 
vnc, wayland-egl, wayland, wayland-xcomposite-egl, 
wayland-xcomposite-glx, xcb.


Abort trap

$ QT_DEBUG_PLUGINS=1 nextcloud
QFactoryLoader::QFactoryLoader() checking directory path 
"/usr/local/lib/qt5/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqeglfs.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqeglfs.so, 
metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"eglfs"
]
},
"archreq": 0,
"className": "QEglFSIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("eglfs")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqminimal.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqminimal.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"minimal"
]
},
"archreq": 0,
"className": "QMinimalIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("minimal")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqminimalegl.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"minimalegl"
]
},
"archreq": 0,
"className": "QMinimalEglIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("minimalegl")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqoffscreen.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"offscreen"
]
},
"archreq": 0,
"className": "QOffscreenIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("offscreen")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqvnc.so"
Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqvnc.so, 
metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"vnc"
]
},
"archreq": 0,
"className": "QVncIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("vnc")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqwayland-egl.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqwayland-egl.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"wayland-egl"
]
},
"archreq": 0,
"className": "QWaylandEglPlatformIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("wayland-egl")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqwayland-generic.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqwayland-generic.so, metadata=

{
"IID": 
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",

"MetaData": {
"Keys": [
"wayland"
]
},
"archreq": 0,
"className": "QWaylandIntegrationPlugin",
"debug": false,
"version": 331520
}


Got keys from plugin meta data ("wayland")
QFactoryLoader::QFactoryLoader() looking at 
"/usr/local/lib/qt5/plugins/platforms/libqwayland-xcomposite-egl.so"
Found metadata in lib 
/usr/local/lib/qt5/plugins/platforms/libqwayland-xcomposite-egl.so, 
metadata=

{
"IID": 

Something strange: SSL failed with mutt-2.1.3v3-gpgme-sasl

2021-10-20 Thread Why 42? The lists account.


Hi All,

I just sysupgraded my OpenBSD desktop and also updated mutt to
mutt-2.1.3v3-gpgme-sasl.

At start time the new mutt version failed to connect to the IMAP server
with an error:
> SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate
> verify failed

When I then deleted the file ~/.mutt/certs/server_certificates (set as
certificate_file in muttrc) and restarted mutt, it worked. I.e. mutt
prompted me if I wished to accept the servers certificate, I answered
with "a" (to accept) and my inbox messages were displayed.

If  I then quit mutt and restart, mutt again fails with the same SSL
error.

It won't connect again until that (new) certificate file is once again
deleted.

It seems that mutt is somehow unable to use the certificate file that it
itself created in the preceding session.

Nothing has changed on the server side. The content of the certificate
file is identical to that created by the previous version of mutt.

Thoughts?

Cheers,
Robb.


mjoelnir:certs 20.10 18:01:06 % pwd
/space/home/robb/.mutt/certs

mjoelnir:certs 20.10 18:01:08 % l  
total 80
-rw---  1 robb  robb  4842 Apr 10  2015 certificates_old
-rw---  1 robb  robb  7076 Jun  4  2015 ca_certificates.crt
-rw---  1 robb  robb  7101 Oct 11  2015 server_certificates_20211019_MOVED
-rw---  1 robb  robb  3577 Oct 19 22:41 server_certificates_fail
-rw---  1 robb  robb  3577 Oct 20 16:45 server_certificates

mjoelnir:certs 20.10 18:01:11 % sha256 server_certificates_fail 
server_certificates
SHA256 (server_certificates_fail) = 
4804cf6a5de7515916a69f0d078944d77a9194d33f91978a4da8a954bf4ebeca
SHA256 (server_certificates) =  
4804cf6a5de7515916a69f0d078944d77a9194d33f91978a4da8a954bf4ebeca



Re: CVS: cvs.openbsd.org: ports

2021-09-15 Thread lists
Tue, 14 Sep 2021 23:16:24 -0600 (MDT) Rafael Sadowski

> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   rsadow...@cvs.openbsd.org   2021/09/14 23:16:24
> 
> Modified files:
>   multimedia/mpv : Makefile 
> 
> Log message:
> Disable the sndio backend again
> 
> Too many errors have been reported with it.
> 
> Leave the backend in for anyone else that might want to look at the code and
> work on it.
> 
> From Brad
> 

Hello Rafael,

Objection to this removal, the errors are negligible usage trivial problems on
loops and playlist audo-advance only.  It actually works fine on streaming and
other media playback.  It is 2x more efficient on bandwidth and processor load
when using remote sndiod server on the network, it really makes a difference..

Please leave it enabled, since it is a configuration tunable.  This mpv player
is a port (third party application), not part of the operating system and does
not follow that rubber stamped "remove it all" for another year.  Programs are
not supposed to have their modules "unavailable" just because someone reported
they can not enjoy it completely, or rather fix their own configuration files.

--
Kind regards,
Anton Lazarov
MScEng EECSIT



Re: update mail/claws-mail

2021-08-20 Thread lists
Thu, 19 Aug 2021 19:24:24 +0200 Solene Rapenne 
> > Sun, 11 Jul 2021 08:56:40 +0200 Landry Breuil   
> > > Le Sat, Jul 10, 2021 at 10:37:05PM +0200, Solene a écrit :
> > > > This update the stable version of claws mail, a new 4.0 release has
> > > > been done now so I think we will need a new port for this one  
> > > 
> > > new port, why ? 4.0.0 is just the Gtk3 version, which will probably
> > > supersede the Gtk2 version.. maybe only a question of compatible plugins
> > > at some point.
> > > 
> > > great to see claws mail is still alive and kicking !
> > > 
> > > Landry
> > 
> > Hello ports@, Landry, Solene,
> > 
> > Indeed, claws-mail branch 4 already updated in port is just the Gtk3 version
> > while branch 3 is the Gtk2 version feature for feature in the last releases.
> > 
> > It therefore makes sense to see two improvements to the port in this regard:
> > 
> > Flavors for both gtk2 and gtk3 (branches/ports mutually exclusive) your call
> > Debug symbols for (both of the packages) for this port (flavors) needed also
> > 
> > It frequently crashes in the latest snapshots and latest packages with Gtk3.
> > 
> > Please provide multi-port / branch / flavor as you see fit for Gtk2 & debug.
> 
> hello, when it crashes are you doing something special?  Can you
> reproduce the crash? I never had a crash since I updated.
> 
> The port has no maintainer.  Debug symbols can certainly be enabled,
> however I have no interest into maintaining the gtk2 version and
> make the port even more complicated than it is already.
> 
> If you want to add support for the gtk2, please provide a patch to
> split claws-mail in gtk2 and gtk3 versions, and you could also take
> maintainership, that would be very appreciated to have a maintainer
> for this port.

Hello Solene, ports@,

Yes, the crashes are fairly reproducible and trivial to trigger, mostly when
you use the email program moving mails between folders and is related to the
GUI toolkit switch precise in the pixbuf and gtk3 libraries.. as seen in the
backtrace I sent you in the previous email.  That one was for changing prefs
related to the themes, and the svg parts.. But it also crashes routinely too
when you normally use the program and is again Gtk3 related, see this trace:

Program received signal SIGSEGV, Segmentation fault.
strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:45
45  /usr/src/lib/libc/arch/amd64/string/strcmp.S: No such file or directory.
in /usr/src/lib/libc/arch/amd64/string/strcmp.S
Current language:  auto; currently asm
(gdb) bt
#0  strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:45
#1  0x0327f0227457 in g_str_equal () from 
/usr/local/lib/libglib-2.0.so.4201.6
#2  0x0327f022579c in g_hash_table_lookup () from 
/usr/local/lib/libglib-2.0.so.4201.6
#3  0x0325cbfe6878 in summary_has_opened_message () from 
/usr/local/bin/claws-mail
#4  0x0325cc085951 in gtk_cmctree_pre_recursive () from 
/usr/local/bin/claws-mail
#5  0x0325cc085ad8 in gtk_cmctree_pre_recursive () from 
/usr/local/bin/claws-mail
#6  0x0325cbfd6fb2 in summary_execute () from /usr/local/bin/claws-mail
#7  0x0325cbfdeb75 in summary_move_selected_to () from 
/usr/local/bin/claws-mail
#8  0x0325cbef1a17 in folderview_grab_focus () from 
/usr/local/bin/claws-mail
#9  0x03287148863c in _gtk_marshal_VOID__OBJECT_INT_INT_BOXED_UINT_UINT () 
from /usr/local/lib/libgtk-3.so.2201.0
#10 0x0328b6fd8e6e in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#11 0x0328b6ff1b89 in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#12 0x0328b6ff2a08 in g_signal_emit_valist () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#13 0x0328b6ff2f8a in g_signal_emit_by_name () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#14 0x032871453ac0 in gtk_drag_selection_received () from 
/usr/local/lib/libgtk-3.so.2201.0
#15 0x032871485cce in _gtk_marshal_VOID__BOXED_UINTv () from 
/usr/local/lib/libgtk-3.so.2201.0
#16 0x0328b6fd909f in _g_closure_invoke_va () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#17 0x0328b6ff23ea in g_signal_emit_valist () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#18 0x0328b6ff2f8a in g_signal_emit_by_name () from 
/usr/local/lib/libgobject-2.0.so.4200.13
#19 0x0328713451c6 in gtk_selection_convert () from 
/usr/local/lib/libgtk-3.so.2201.0
#20 0x032871454ab3 in gtk_drag_dest_drop () from 
/usr/local/lib/libgtk-3.so.2201.0
#21 0x032871454255 in _gtk_drag_dest_handle_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x0328712a4a69 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0328360e23db in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#24 0x03283611d684 in gdk_event_source_dispatch () from 
/usr/local/lib/libgdk-3.so.2201.1
#25 0x0327f023a9cf in g_main_context_dispatch () from 
/usr/local/lib/libglib-2.0.so.4201.6
#26 0x0327f023ad8a in g_main_context_iterate () 

Re: update mail/claws-mail

2021-08-19 Thread lists
Sun, 11 Jul 2021 08:56:40 +0200 Landry Breuil 
> Le Sat, Jul 10, 2021 at 10:37:05PM +0200, Solene a écrit :
> > This update the stable version of claws mail, a new 4.0 release has
> > been done now so I think we will need a new port for this one  
> 
> new port, why ? 4.0.0 is just the Gtk3 version, which will probably
> supersede the Gtk2 version.. maybe only a question of compatible plugins
> at some point.
> 
> great to see claws mail is still alive and kicking !
> 
> Landry
> 

Hello ports@, Landry, Solene,

Indeed, claws-mail branch 4 already updated in port is just the Gtk3 version
while branch 3 is the Gtk2 version feature for feature in the last releases.

It therefore makes sense to see two improvements to the port in this regard:

Flavors for both gtk2 and gtk3 (branches/ports mutually exclusive) your call
Debug symbols for (both of the packages) for this port (flavors) needed also

It frequently crashes in the latest snapshots and latest packages with Gtk3.

Program received signal SIGSEGV, Segmentation fault.
0x00e3251357aa in gdk_pixbuf_get_width () from 
/usr/local/lib/libgdk_pixbuf-2.0.so.3200.3
(gdb) bt
#0  0x00e3251357aa in gdk_pixbuf_get_width () from 
/usr/local/lib/libgdk_pixbuf-2.0.so.3200.3
#1  0x00e1169907ee in gtk_cmctree_node_get_type () from 
/usr/local/bin/claws-mail
#2  0x00e116997f59 in gtk_cmclist_set_column_justification () from 
/usr/local/bin/claws-mail
#3  0x00e1169a32d3 in gtk_cmclist_set_button_actions () from 
/usr/local/bin/claws-mail
#4  0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#5  0x00e31d527de0 in gtk_container_propagate_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#6  0x00e31d52859d in gtk_container_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#7  0x00e31d6c512e in gtk_scrolled_window_render () from 
/usr/local/lib/libgtk-3.so.2201.0
#8  0x00e31d5303a1 in gtk_css_custom_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#9  0x00e31d536adb in gtk_css_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#10 0x00e31d6c0f8f in gtk_scrolled_window_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#11 0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#12 0x00e31d527de0 in gtk_container_propagate_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#13 0x00e31d666229 in gtk_paned_render () from 
/usr/local/lib/libgtk-3.so.2201.0
#14 0x00e31d5303a1 in gtk_css_custom_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#15 0x00e31d536adb in gtk_css_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#16 0x00e31d663bbf in gtk_paned_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#17 0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#18 0x00e31d527de0 in gtk_container_propagate_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#19 0x00e31d52859d in gtk_container_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#20 0x00e31d4d0dda in gtk_box_draw_contents () from 
/usr/local/lib/libgtk-3.so.2201.0
#21 0x00e31d5303a1 in gtk_css_custom_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x00e31d536adb in gtk_css_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x00e31d4cfeaf in gtk_box_draw () from /usr/local/lib/libgtk-3.so.2201.0
#24 0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#25 0x00e31d527de0 in gtk_container_propagate_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#26 0x00e31d52859d in gtk_container_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#27 0x00e31d4d0dda in gtk_box_draw_contents () from 
/usr/local/lib/libgtk-3.so.2201.0
#28 0x00e31d5303a1 in gtk_css_custom_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#29 0x00e31d536adb in gtk_css_gadget_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#30 0x00e31d4cfeaf in gtk_box_draw () from /usr/local/lib/libgtk-3.so.2201.0
#31 0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#32 0x00e31d527de0 in gtk_container_propagate_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#33 0x00e31d52859d in gtk_container_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#34 0x00e31d7cc44d in gtk_window_draw () from 
/usr/local/lib/libgtk-3.so.2201.0
#35 0x00e31d7a6975 in gtk_widget_draw_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#36 0x00e31d7a7ee0 in gtk_widget_render () from 
/usr/local/lib/libgtk-3.so.2201.0
#37 0x00e31d626bc3 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#38 0x00e34fb7c3db in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#39 0x00e34fb93cea in _gdk_window_process_updates_recurse_helper () from 
/usr/local/lib/libgdk-3.so.2201.1
#40 0x00e34fb94323 in gdk_window_process_updates_internal () from 
/usr/local/lib/libgdk-3.so.2201.1
#41 0x00e34fb94597 in gdk_window_process_updates_with_mode () from 

Re: Remove security/keepassx

2020-02-22 Thread lists
Sat, 22 Feb 2020 07:41:21 +0100 Rafael Sadowski 
> What do you think about the idea of deleting keepassx and set a pkgpath
> in keepassxc?

Hi Rafael,

Thanks for keeping up on top of the work with QT5, and KDE in general.

I think we should keep keepassx a bit more due to some vulnerabilities
in keepassxc in the not so very distant past, and insufficient time to
advance keepassx related software, incl on other systems to keepassxc.

What do you think about keeping both for a while more & revisit later?

Kind regards,
Anton Lazarov
MScEng EECSIT

> Here is a quote from the keepassxc FAQ:
> 
> Q: Why KeePassXC instead of KeePassX?
> A: KeePassX is an amazing password manager, but hasn't seen much active
> development for quite a while. Many good pull requests were never merged
> and the original project is missing some features which users can expect
> from a modern password manager. Hence, we decided to fork KeePassX to
> continue its development and provide you with everything you love about
> KeePassX plus many new features and bugfixes.
> 
> -- https://keepassxc.org/docs/#faq-keepassx
> 
> 
> Everything keepassx can do, so can keepassxc and more. "File format
> compatibility with KeePass2, KeePassX, MacPass, KeeWeb and many others
> (KDBX 3.1 and 4.0)"
> 
> It feels so right!
> 
> RS
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/keepassxc/Makefile,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 Makefile
> --- Makefile  20 Jan 2020 06:28:12 -  1.27
> +++ Makefile  22 Feb 2020 06:33:57 -
> @@ -4,6 +4,7 @@ COMMENT = management tool for password a
>  
>  V =  2.5.3
>  DISTNAME =   keepassxc-${V}
> +REVISION =   0
>  
>  CATEGORIES = security
>  
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/keepassxc/pkg/PLIST,v
> retrieving revision 1.18
> diff -u -p -u -p -r1.18 PLIST
> --- pkg/PLIST 20 Jan 2020 06:28:12 -  1.18
> +++ pkg/PLIST 22 Feb 2020 06:33:57 -
> @@ -1,4 +1,5 @@
>  @comment $OpenBSD: PLIST,v 1.18 2020/01/20 06:28:12 rsadowski Exp $
> +@pkgpath security/keepassx
>  @bin bin/keepassxc
>  @bin bin/keepassxc-cli
>  %%browser%%
> 



Re: Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-22 Thread lists+ports
On Fri, Nov 22, 2019 at 11:16:15PM +, Stuart Henderson wrote:
> Oh, it looks like the lang/go port itself doesn't honour MAKE_ENV, but
> I don't see any xorps in the restic binary - does that work for you?

restic is now working.  Thanks!



Re: Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-22 Thread lists+ports
A little more info - it looks like the latest i386 package may have been
incorrectly built?  I might start playing around trying to build from
ports on the soekris, but it may take a while :)

https://github.com/golang/go/issues/35789

I don't really understand why I'm still seeing the "xorps" instruction
short of a) the port not being built with GO386=387 (based on that
conversation) or b) there being a bug somewhere in Go (or c) PEBKAC).



Re: Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-21 Thread lists+ports
I saw that the repos had updated this morning so gave it a try - I'm
seeing the exact same behavior I was before :(

new dmesg header:
OpenBSD 6.6-current (GENERIC) #391: Wed Nov 20 23:05:05 MST 2019

pkg_info for go:
go-1.13.3p0 Go programming language


On Wed, Nov 20, 2019 at 03:02:44PM +, Stuart Henderson wrote:
> In theory the next set of i386 snapshot packages should be built without
> SSE for go ports, so they should work on these machines. Check for a
> set including "go-1.13.3p0.tgz" or newer - will probably be on the mirrors
> late tomorrow or thereabouts.



Re: Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-18 Thread lists+ports
I think I may have found the problem:
https://github.com/golang/go/issues/20009#issuecomment-294437962

It looks like the ports machines building Go probably have SSE/SSE2, so
the resulting binary expects those to be present.

I'm not sure what can be done short of building Go on my Soekris…  I
can't fault anyone for using a more "modern" CPU when building the ports
tree for distribution.



Re: Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-15 Thread lists+ports
On Fri, Nov 15, 2019 at 01:16:55AM +, Stuart Henderson wrote:
> I think if you run "disassemble" from gdb (or pkg_add gdb and run "egdb"
> in case the old gdb in base doesn't understand the opcodes) you may find
> which instruction it's complaining about.
> 
> This runs OK on an i386 with more CPU features; most likely it wants
> SSE or similar which the Geode LX in your net5501 doesn't have. (Go has
> runtime cpuid checks for most of the SSE variants but I think not for
> the original SSE which it probably just assumes is available).
> One clue would be if the disassembly has instructions referencing
> registers X0..X15 which are just used for SSE.
> 
> > cpu0 at mainbus0: (uniprocessor)
> > cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> > 500 MHz, 05-0a-02
> > cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW

egdb seems to work a little better:

(gdb) run
Starting program: /usr/local/bin/go 

Program received signal SIGILL, Illegal instruction.
runtime.check () at /usr/local/go/src/runtime/runtime1.go:146
146 i, i1 float32
(gdb) bt
#0  runtime.check () at /usr/local/go/src/runtime/runtime1.go:146
#1  0x0809794e in runtime.rt0_go () at /usr/local/go/src/runtime/asm_387.s:238
#2  0x0896c360 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


It has been a *long* time since I've looked at assembly - I *think* this
is failing on xorps, which is an SSE instruction?

(gdb) disassemble
Dump of assembler code for function runtime.check:
   0x0807f9f0 <+0>: mov%gs:0xfffc,%ecx
   0x0807f9f7 <+7>: cmp0x8(%ecx),%esp
   0x0807f9fa <+10>:jbe0x807fd6b 
   0x0807fa00 <+16>:sub$0x2c,%esp
   0x0807fa03 <+19>:movl   $0x0,0x20(%esp)
=> 0x0807fa0b <+27>:xorps  %xmm0,%xmm0
   0x0807fa0e <+30>:movss  %xmm0,0x1c(%esp)
   0x0807fa14 <+36>:xorps  %xmm0,%xmm0
   0x0807fa17 <+39>:movsd  %xmm0,0x24(%esp)
   0x0807fa1d <+45>:movl   $0x0,0x18(%esp)
   0x0807fa25 <+53>:movl   $0x4b57ce31,(%esp)
   0x0807fa2c <+60>:movl   $0xb3a,0x4(%esp)
   0x0807fa34 <+68>:movl   $0x3b9aca00,0x8(%esp)
   0x0807fa3c <+76>:lea0x20(%esp),%eax
   0x0807fa40 <+80>:mov%eax,0xc(%esp)
   0x0807fa44 <+84>:call   0x80801b0 
   0x0807fa49 <+89>:cmpl   $0x3039,0x10(%esp)
   0x0807fa51 <+97>:jne0x807fd54 
   0x0807fa57 <+103>:   cmpl   $0xd431,0x20(%esp)
   0x0807fa5f <+111>:   jne0x807fd54 
   0x0807fa65 <+117>:   movl   $0x0,0x14(%esp)
   0x0807fa6d <+125>:   movl   $0x1,0x14(%esp)
   0x0807fa75 <+133>:   lea0x14(%esp),%eax
   0x0807fa79 <+137>:   mov%eax,(%esp)
   0x0807fa7c <+140>:   movl   $0x1,0x4(%esp)
   0x0807fa84 <+148>:   movl   $0x2,0x8(%esp)
   0x0807fa8c <+156>:   call   0x804a660 
   0x0807fa91 <+161>:   movzbl 0xc(%esp),%eax
   0x0807fa96 <+166>:   test   %al,%al
   0x0807fa98 <+168>:   je 0x807fd3e 
   0x0807fa9e <+174>:   cmpl   $0x2,0x14(%esp)
   0x0807faa3 <+179>:   jne0x807fd28 
   0x0807faa9 <+185>:   movl   $0x4,0x14(%esp)
   0x0807fab1 <+193>:   lea0x14(%esp),%eax
   0x0807fab5 <+197>:   mov%eax,(%esp)
   0x0807fab8 <+200>:   movl   $0x5,0x4(%esp)
   0x0807fac0 <+208>:   movl   $0x6,0x8(%esp)
   0x0807fac8 <+216>:   call   0x804a660 
   0x0807facd <+221>:   movzbl 0xc(%esp),%eax
   0x0807fad2 <+226>:   test   %al,%al
   0x0807fad4 <+228>:   jne0x807fd12 
   0x0807fada <+234>:   cmpl   $0x4,0x14(%esp)
   0x0807fadf <+239>:   jne0x807fcfc 
   0x0807fae5 <+245>:   movl   $0x,0x14(%esp)
   0x0807faed <+253>:   lea0x14(%esp),%eax
   0x0807faf1 <+257>:   mov%eax,(%esp)
   0x0807faf4 <+260>:   movl   $0x,0x4(%esp)
   0x0807fafc <+268>:   movl   $0xfffe,0x8(%esp)
   0x0807fb04 <+276>:   call   0x804a660 
   0x0807fb09 <+281>:   movzbl 0xc(%esp),%eax
   0x0807fb0e <+286>:   test   %al,%al
   0x0807fb10 <+288>:   je 0x807fce6 
   0x0807fb16 <+294>:   cmpl   $0xfffe,0x14(%esp)
   0x0807fb1b <+299>:   jne0x807fcd0 
   0x0807fb21 <+305>:   movl   $0x0,0x18(%esp)
   0x0807fb29 <+313>:   movl   $0x1010101,0x18(%esp)
   0x0807fb31 <+321>:   lea0x19(%esp),%eax
   0x0807fb35 <+325>:   mov%eax,(%esp)
   0x0807fb38 <+328>:   movb   $0xf0,0x4(%esp)
   0x0807fb3d <+333>:   call   0x804a880 
   0x0807fb42 <+338>:   cmpb   $0x1,0x18(%esp)
   0x0807fb47 <+343>:   jne0x807fcba 
   0x0807fb4d <+349>:   cmpb   $0xf1,0x19(%esp)
   0x0807fb52 <+354>:   jne0x807fcba 
   0x0807fb58 <+360>:   cmpb   $0x1,0x1a(%esp)
   0x0807fb5d <+365>:   jne0x807fcba 
   0x0807fb63 <+371>:   cmpb   $0x1,0x1b(%esp)
   0x0807fb68 <+376>:   jne0x807fcba 
   0x0807fb6e <+382>:   movl   $0x0,0x18(%esp)
   0x0807fb76 <+390>:   movl   $0x,0x18(%esp)
   0x0807fb7e <+398>:   lea0x19(%esp),%eax
   0x0807fb82 <+402>:   mov%eax,(%esp)
   0x0807fb85 <+405>:   movb   $0x1,0x4(%esp)
   0x0807fb8a <+410>:   call   0x804a890 
   0x0807fb8f <+415>:   cmpb   $0xff,0x18(%esp)
   

Illegal instruction (core dumped) with go/restic on Soekris i386

2019-11-14 Thread lists+ports
Hello all,

Trying to run go or restic on a soekris net5501 results in:

Illegal instruction (core dumped)

Has anyone else seen issues similar to this?  Go seems to work fine on
all my amd64 boxes, and this is unfortunately the only i386 I have
around to test on.

Here's some minimal debug output:

(gdb) run
Starting program: /usr/local/bin/go 

Program received signal SIGILL, Illegal instruction.
0x0807fa0b in runtime.check ()
Current language:  auto; currently minimal
(gdb) bt
#0  0x0807fa0b in runtime.check ()
#1  0x08927120 in ?? ()
#2  0xcf7c5728 in ?? ()
#3  0x08049598 in x_cgo_init ()
Previous frame inner to this frame (corrupt stack?)
(gdb) 

and my dmesg:

OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536363008 (511MB)
avail mem = 510914560 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:00:24:cb:55:34
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address 
00:00:24:cb:55:35
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address 
00:00:24:cb:55:36
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
00:00:24:cb:55:37
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 1: 
wd0: 1-sector PIO, LBA, 30560MB, 62586880 sectors
wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, 
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00 
addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (ee5bf60599620eb3.a) swap on wd0b dump on wd0b
syncing disks... done
OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536363008 (511MB)
avail mem = 510910464 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 

Re: w3m broken, Re: update boehm-gc 8.0.4 libatomic_ops 7.6.10

2019-06-10 Thread lists
Fri, 7 Jun 2019 23:13:51 +0200 Christian Weisgerber 
> li...@wrant.com:
> 
> > On amd64 latest snap, a recent w3m package installation segfaults on run:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x16d1b18988e7 in GC_mark_from () from /usr/local/lib/libgc.so.4.0
> > Current language:  auto; currently minimal  
> 
> Fallout from changes to ld.so.  Fixed in -current.
> 

Thanks, confirmed working again on latest snapshots.  Much appreciated.



w3m broken, Re: update boehm-gc 8.0.4 libatomic_ops 7.6.10

2019-06-07 Thread lists
Hi Nam,

On amd64 latest snap, a recent w3m package installation segfaults on run:

(gdb) r
Starting program: /usr/local/bin/w3m 

Program received signal SIGSEGV, Segmentation fault.
0x16d1b18988e7 in GC_mark_from () from /usr/local/lib/libgc.so.4.0
Current language:  auto; currently minimal
(gdb) bt
#0  0x16d1b18988e7 in GC_mark_from () from /usr/local/lib/libgc.so.4.0
#1  0x16d1b189847c in GC_mark_some () from /usr/local/lib/libgc.so.4.0
#2  0x16d1b188d67d in GC_stopped_mark () from /usr/local/lib/libgc.so.4.0
#3  0x16d1b188d520 in GC_try_to_collect_inner () from 
/usr/local/lib/libgc.so.4.0
#4  0x16d1b189ce6e in GC_init () from /usr/local/lib/libgc.so.4.0
#5  0x16cf2d1384ad in ?? () from /usr/local/bin/w3m
#6  0x16cf2d138148 in ?? () from /usr/local/bin/w3m
#7  0x in ?? ()
(gdb) q

Please, test this again after the latest ports changes (gettext related).

Kind regards,
Anton Lazarov

Tue, 7 May 2019 09:27:25 +0100 Stuart Henderson 
> On 2019/05/06 05:45, Nam Nguyen wrote:
> > This is an update for boehm-gc 8.0.4 (released March 2, 2019) and
> > libatomic_ops 7.6.10 (released March 1, 2019). I tested on amd64 with
> > w3m. I do not have access to aarch64 to test the patches.  
> 
> boehm-gc has many machine-dependent parts, it wants testing on more arches
> than just amd64+aarch64.
> 
> > Changelogs:
> > https://github.com/ivmai/bdwgc/commit/d3dede3ce4462cd82a15f161af797ca51654546a
> > https://github.com/ivmai/libatomic_ops/commit/7702826f7a8a0aa1b08293322adf49510f4438d1
> > 
> > - I am willing to become maintainer, although I do not understand the
> >   patches. I have familiarized myself with this port now.  
> 
> I would say that somebody maintaining boehm-gc should really understand
> the patches a bit..
> 
> > - HOMEPAGE uses https://
> > - Fixed patches to apply cleanly, with the biggest change being
> >   patch-include_private_gcconfig_h where we no longer need "- use
> >   __data_start instead of _fdata on OpenBSD/mips64", as it has already
> >   been applied upstream.
> > - --enable-static=yes is a new configure flag.
> >   How did I notice this new flag? First, I noticed some missing
> >   symbols. Next, am_libgc_la_OBJECTS is commented out in the generated
> >   Makefile, but the old behavior has the complement commented out.
> > --8<---cut here---start->8---
> > #am_libgc_la_OBJECTS = allchblk.lo alloc.lo \
> > #   blacklst.lo dbg_mlc.lo dyn_load.lo \
> > #   finalize.lo gc_dlopen.lo gcj_mlc.lo \
> > #   headers.lo mach_dep.lo malloc.lo \
> > #   mallocx.lo mark.lo mark_rts.lo misc.lo \
> > #   new_hblk.lo obj_map.lo os_dep.lo \
> > #   ptr_chck.lo reclaim.lo specific.lo \
> > #   typd_mlc.lo $(am__objects_1) \
> > #   $(am__objects_2) $(am__objects_3) \
> > #   $(am__objects_4) $(am__objects_5) \
> > #   $(am__objects_6) $(am__objects_7) \
> > #   $(am__objects_8)
> > am_libgc_la_OBJECTS = extra/gc.lo $(am__objects_9) \
> > $(am__objects_1) $(am__objects_2) \
> > $(am__objects_3) $(am__objects_4) \
> > $(am__objects_5) $(am__objects_6) \
> > $(am__objects_7) $(am__objects_8)
> > --8<---cut here---end--->8---
> > 
> > As the porting guide suggests under Handling Complex Situations > Know
> > the Software, "Read the configure script options." Lesson learned.
> > --8<---cut here---start->8---
> > $ ./configure --help
> > old version:
> >   --enable-shared[=PKGS]  build shared libraries [default=yes]
> >   --enable-static[=PKGS]  build static libraries [default=yes]
> > new version:
> >   --enable-static[=PKGS]  build static libraries [default=no]
> >   --enable-shared[=PKGS]  build shared libraries [default=yes]
> > --8<---cut here---end--->8---
> > 
> > SHARED_LIBS +=  gc  4.0 -> 5.0
> > SHARED_LIBS +=  gccpp   0.0 -> 0.1
> > SHARED_LIBS +=  cord2.3   
> > SHARED_LIBS +=  atomic_ops  2.0
> > SHARED_LIBS +=  atomic_ops_gpl  2.0
> > 
> > gccpp: new symbols
> > --8<---cut here---start->8---
> > --- /tmp/libgccpp.old   Mon May  6 02:22:14 2019
> > +++ /tmp/libgccpp.new   Mon May  6 02:21:53 2019
> > @@ -1,5 +1,8 @@
> > +T _Z18GC_throw_bad_allocv
> >  T _ZdaPv
> > +T _ZdaPvm
> >  T _ZdlPv
> > +T _ZdlPvm
> >  T _Znam
> >  T _Znwm
> >  T _fini
> > --8<---cut here---end--->8---
> > 
> > gc: Removal of GC_unix_sbrk_get_mem behind a conditional macro means
> > libgc 4.0 -> 5.0.
> > --8<---cut here---start->8---
> > --- /tmp/libgc.old  Mon May  6 02:18:37 2019
> > +++ /tmp/libgc.new  Mon May  6 02:18:27 2019
> > @@ -3,6 +3,8 @@
> >  T AO_pause
> >  T AO_store_full_emulation
> >  T GC_FirstDLOpenedLinkMap
> > +T GC_abort_on_oom
> > +T GC_acquire_mark_lock
> >  T GC_add_ext_descriptor
> > 

[update] emacs-26.2

2019-04-15 Thread lists
Hi Jérémie, ports@,

Please see Emacs 26.2 has been released on Apr 12th:

https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00503.html

The changelog features a doas method for tramp mode:

https://www.gnu.org/software/emacs/news/NEWS.26.2

I don't have a build environment here no attachment.

Kind regards,
Anton Lazarov



Re: [new] net/swirc

2018-09-30 Thread lists
Sun, 30 Sep 2018 23:20:53 +0200 Solene Rapenne 
> Here is a port of swirc, a simple C irc client using curses. It supports SSL,
> SASL auth mechanism, logging and is pledged.
> 

Hi ports@,

Interesting at first glance, Makefile from proposed swirc port contains:

HOMEPAGE =  https://www.nifty-networks.net/swirc/

On the homepage is listed this repository https://github.com/uhlin/swirc
with numerous links to changelogs, issue tracker, project home page etc.

The account, picture and name bring up the thread from the misc archive:

https://marc.info/?m=149532438309321

Not objecting the port suggested, just please use caution with the port.

Kind regards,
Anton Lazarov



Re: [update] emacs-26.1

2018-05-29 Thread lists
Tue, 29 May 2018 19:00:51 +0200 Jeremie Courreges-Anglas

> So emacs-26.1 has been released yesterday:
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00765.html
> 
> I doubt that this update addresses the bug encountered by Grégoire,
> Piotr and Manuel, but I don't think it will make it worse.
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29170
> 
> I have only built and tested this on amd64 so far, I'll handle armv7
> and sparc64 later.  People running different archs and/or one of the
> graphical flavors, your test reports are welcome!
> 

Hi Jérémie,

Could you please add it to the ports tree too so we can test the package?
Preferably, without removing the current 25 branch that has been working.
Alternatively, would be happy to wait, currently stuck on Apr 22nd snaps.

Kind regards,
Anton Lazarov

> 
> Index: Makefile
> ===
> RCS file: /d/cvs/ports/editors/emacs/Makefile,v
> retrieving revision 1.74
> diff -u -p -r1.74 Makefile
> --- Makefile  20 May 2018 08:27:18 -  1.74
> +++ Makefile  29 May 2018 11:52:17 -
> @@ -2,8 +2,7 @@
>  
>  COMMENT= GNU editor: extensible, customizable, self-documenting
>  
> -VERSION= 25.3
> -REVISION=1
> +VERSION= 26.1
>  DISTNAME=emacs-${VERSION}
>  
>  CATEGORIES=  editors
> @@ -15,7 +14,7 @@ MAINTAINER= Jeremie Courreges-Anglas   # GPLv3+
>  PERMIT_PACKAGE_CDROM=Yes
>  
> -WANTLIB= c m ncurses pthread gnutls xml2 z
> +WANTLIB= c m curses pthread gnutls xml2 z
>  
>  MASTER_SITES=${MASTER_SITE_GNU:=emacs/}
>  
> @@ -47,46 +46,47 @@ LIB_DEPENDS=  security/gnutls \
>  .if ${FLAVOR} == "no_x11"
>  CONFIGURE_ARGS+= --without-x \
>   --without-dbus \
> - --without-gconf \
>   --without-gsettings \
> - --without-jpeg
> + --without-jpeg \
> + --without-lcms2
>  .else
>  LIB_DEPENDS+=x11/dbus \
>   x11/gnome/librsvg \
> - devel/gconf2 \
>   graphics/jpeg \
>   graphics/png \
>   graphics/tiff \
>   graphics/giflib \
> - graphics/ImageMagick
> + graphics/ImageMagick \
> + graphics/lcms2
>  RUN_DEPENDS+=devel/desktop-file-utils \
>   devel/xdg-utils \
>   x11/gtk+3,-guic
>  . if ${FLAVOR} == "athena"
>  CONFIGURE_ARGS+= --with-x-toolkit=athena
>  LIB_DEPENDS+=x11/Xaw3d
> -WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xaw3d
> -WANTLIB += Xext Xft Xinerama Xmu Xpm Xrandr Xrender Xt cairo dbus-1
> -WANTLIB += fontconfig freetype gconf-2 gdk_pixbuf-2.0 gif gio-2.0
> -WANTLIB += glib-2.0 gobject-2.0 intl jpeg png rsvg-2 tiff X11-xcb Xfixes xcb
> +WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
> +WANTLIB += Xaw3d Xext Xfixes Xft Xinerama Xmu Xpm Xrandr Xrender
> +WANTLIB += Xt cairo dbus-1 fontconfig freetype gdk_pixbuf-2.0
> +WANTLIB += gif gio-2.0 glib-2.0 gobject-2.0 intl jpeg lcms2 png
> +WANTLIB += rsvg-2 tiff xcb
>  . elif ${FLAVOR} == "gtk2"
>  CONFIGURE_ARGS+= --with-x-toolkit=gtk2
>  LIB_DEPENDS+=x11/gtk+2
> -WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xcomposite
> -WANTLIB += Xcursor Xdamage Xext Xfixes Xft Xi Xinerama Xpm Xrandr
> -WANTLIB += Xrender atk-1.0 cairo dbus-1 fontconfig freetype gconf-2
> -WANTLIB += gdk-x11-2.0 gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0
> -WANTLIB += gtk-x11-2.0 intl jpeg pango-1.0 pangocairo-1.0 pangoft2-1.0
> -WANTLIB += png rsvg-2 tiff X11-xcb xcb
> +WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
> +WANTLIB += Xcomposite Xcursor Xdamage Xext Xfixes Xft Xi Xinerama
> +WANTLIB += Xpm Xrandr Xrender atk-1.0 cairo dbus-1 fontconfig
> +WANTLIB += freetype fribidi gdk-x11-2.0 gdk_pixbuf-2.0 gif gio-2.0
> +WANTLIB += glib-2.0 gobject-2.0 gtk-x11-2.0 intl jpeg lcms2 pango-1.0
> +WANTLIB += pangocairo-1.0 pangoft2-1.0 png rsvg-2 tiff xcb
>  . elif ${FLAVOR} == "gtk3"
>  CONFIGURE_ARGS+= --with-x-toolkit=gtk3
>  LIB_DEPENDS+=x11/gtk+3
>  WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
> -WANTLIB += Xfixes Xft Xinerama Xpm Xrandr Xrender atk-1.0 cairo
> -WANTLIB += cairo-gobject dbus-1 fontconfig freetype gconf-2 gdk-3
> -WANTLIB += gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0 gtk-3
> -WANTLIB += intl jpeg pango-1.0 pangocairo-1.0 png rsvg-2 tiff
> -WANTLIB += xcb
> +WANTLIB += Xext Xfixes Xft Xinerama Xpm Xrandr Xrender atk-1.0
> +WANTLIB += cairo cairo-gobject dbus-1 fontconfig freetype fribidi
> +WANTLIB += gdk-3 gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0
> +WANTLIB += gtk-3 intl jpeg lcms2 pango-1.0 

Re: initial pledge() wip for firefox

2018-05-03 Thread lists
Thu, 3 May 2018 06:45:22 +0200 Sebastien Marie 
> On Thu, May 03, 2018 at 12:27:05AM +0300, li...@wrant.com wrote:
> > > 
> > > So if i understand, in that case 37 is the fd for places.sqlite-wal
> > > opened earlier in the ktrace ?
> > >   

Hi Landry, Sebastien,

Yes, wiped that temp file, but generated a fresh one, different fd num:

 50653 firefox  CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7e1d58)
 50653 firefox  STRU  struct timespec { 44122.094371935 }
 50653 firefox  RET   clock_gettime 0
 50653 firefox  CALL  getpid()
 50653 firefox  RET   getpid 50653/0xc5dd
 50653 firefox  CALL  stat(0x7f7e1b30,0x7f7e18a0)
 50653 firefox  NAMI  "/home/user/.mozilla/firefox/test/places.sqlite"
 50653 firefox  STRU  struct stat { dev=1051, ino=181924, mode=-rw-r--r-- , 
nlink=1, uid=1000<"user">, gid=1000<"user">, rdev=742816, atime=1524794989<"Apr 
27 05:09:49 2018">.487312718, mtime=1525294393<"May  2 23:53:13 
2018">.783442474, ctime=1525294393<"May  2 23:53:13 2018">.783442474, 
size=5242880, blocks=10272, blksize=16384, flags=0x0, gen=0x0 }
 50653 firefox  RET   stat 0
 50653 firefox  CALL  
open(0xb1f8870275d,0x10202,0644)
 50653 firefox  NAMI  "/home/user/.mozilla/firefox/test/places.sqlite-wal"
 50653 firefox  RET   open 40/0x28
 50653 firefox  CALL  fstat(40,0x7f7e1780)
 50653 firefox  STRU  struct stat { dev=1051, ino=182010, mode=-rw-r- , 
nlink=1, uid=1000<"user">, gid=1000<"user">, rdev=0, atime=1525294428<"May  2 
23:53:48 2018">.294304583, mtime=1525294428<"May  2 23:53:48 2018">.294304583, 
ctime=1525294428<"May  2 23:53:48 2018">.294304583, size=0, blocks=0, 
blksize=16384, flags=0x0, gen=0x0 }
 50653 firefox  RET   fstat 0
 50653 firefox  CALL  fchmod(40,0644)
 50653 firefox  PLDG  fchmod, "fattr", errno 1 Operation not permitted
 50653 firefox  PSIG  SIGABRT SIG_DFL
 50653 firefox  NAMI  "firefox.core"
 50653 firefox  STRU  struct pollfd [2] { fd=16, events=0x3, 
revents=0<> } { fd=37, events=0x3, revents=0<> }
 50653 firefox  STRU  struct pollfd { fd=4, events=0x1, revents=0<> }

Same trace with the stat structs obviously the details are significant.
Please advise if you'd need further traces and how to obtain more info.

> I think I already seen this behaviour in fossil:
> - openbsd ports@ list: 
> https://marc.info/?l=openbsd-ports=152196264519554=2
> - fossil-scm list: 
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27158.html
> 
> The fchmod(2) code behave to libsqlite.
> 
> In the fossil case (but I assume similarity here), libsqlite sets the
> mode on "foo-journal" to be the same than "foo". This code path could be
> triggered when the initial run that create "foo" had difference umask
> setting than the current run that create "foo-journal".
> 
> Anton, what are the mode of (it was part of stripped stat information :-])
> - /home/user/.mozilla/firefox/test/places.sqlite
> - /home/user/.mozilla/firefox/test/places.sqlite-wal (once created)

Included above, indeed the places.sqlite-wal file has a different mode.

Does firefox use own routines for fattr operations, or the system ones?
And probably the same question for both (lib)sqlite and fossil applies.

> and what is your umask value in this shell ?

The umask is set in the .profile (ksh) as umask 027 (changed from 022).

Is it the right time to precise the pledge path to the profile dir only
and probably another code path would be the save files routines (ouch)?

I suggest web clients should not have access to paths outside $workdir.

Kind regards,
Anton Lazarov



Re: initial pledge() wip for firefox

2018-05-02 Thread lists
Wed, 2 May 2018 21:26:56 +0200 Landry Breuil 
> On Wed, May 02, 2018 at 05:56:53PM +0300, li...@wrant.com wrote:
> > Wed, 2 May 2018 07:15:45 +0200 Landry Breuil   
> > > On Wed, May 02, 2018 at 04:07:51AM +0300, li...@wrant.com wrote:  
> > > > 
> > > > Hi Landry,
> > > > 
> > > > With the snapshot Build date: 1525207106 - Tue May  1 20:38:26 UTC 2018
> > > > firefox-60.0beta16 from https://packages.rhaalovely.net/snapshots/amd64
> > > > it progresses a bit further and aborts with pledge "fattr", syscall 124
> > > > using promises: 'stdio rpath wpath cpath inet proc exec prot_exec flock
> > > > ps sendfd recvfd dns vminfo tty drm' results: Abort trap (core dumped). 
> > > >
> > > 
> > > main process needs fattr & unix to save files here; i added them in
> > > https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=pledge=11f3f89db4c5cf973205c7a7d332ac52c9d70911
> > > 
> > > For a useful report; reproduce with ktrace -di, and mention/quote the
> > > end of the trace (ie the syscall that triggers the abord should relate
> > > to the file it was trying to act upon)
> > >   
> > 
> > Hi Landry,
> > 
> > Succeeds on stat & open places.sqlite, stat places.sqlite-wal & at it
> > 
> > 68642 firefox  CALL  fchmod(37,0644)
> > 68642 firefox  PLDG  fchmod, "fattr", errno 1 Operation not permitted
> > 68642 firefox  PSIG  SIGABRT SIG_DFL
> > 68642 firefox  NAMI  "firefox.core"  
> 
> So if i understand, in that case 37 is the fd for places.sqlite-wal
> opened earlier in the ktrace ?
> 

Hi Landry,

Yes, wiped that temp file, but generated a fresh one, different fd num:

 50653 firefox  CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7e1d58)
 50653 firefox  STRU  struct timespec { 44122.094371935 }
 50653 firefox  RET   clock_gettime 0
 50653 firefox  CALL  getpid()
 50653 firefox  RET   getpid 50653/0xc5dd
 50653 firefox  CALL  stat(0x7f7e1b30,0x7f7e18a0)
 50653 firefox  NAMI  "/home/user/.mozilla/firefox/test/places.sqlite"
 50653 firefox  STRU  struct stat { ... }  
 50653 firefox  RET   stat 0
 50653 firefox  CALL  
open(0xb1f8870275d,0x10202,0644)
 50653 firefox  NAMI  "/home/user/.mozilla/firefox/test/places.sqlite-wal"
 50653 firefox  RET   open 40/0x28
 50653 firefox  CALL  fstat(40,0x7f7e1780)
 50653 firefox  STRU  struct stat { ... }
 50653 firefox  RET   fstat 0
 50653 firefox  CALL  fchmod(40,0644)
 50653 firefox  PLDG  fchmod, "fattr", errno 1 Operation not permitted
 50653 firefox  PSIG  SIGABRT SIG_DFL
 50653 firefox  NAMI  "firefox.core"
 50653 firefox  STRU  struct pollfd [2] { fd=16, events=0x3, 
revents=0<> } { fd=37, events=0x3, revents=0<> }
 50653 firefox  STRU  struct pollfd { fd=4, events=0x1, revents=0<> }

Collapsed the stats output, let me know if the details are significant.
Please advise if you'd need further traces and how to obtain more info.

Kind regards,
Anton Lazarov



Re: initial pledge() wip for firefox

2018-05-02 Thread lists
Wed, 2 May 2018 07:15:45 +0200 Landry Breuil 
> On Wed, May 02, 2018 at 04:07:51AM +0300, li...@wrant.com wrote:
> > 
> > Hi Landry,
> > 
> > With the snapshot Build date: 1525207106 - Tue May  1 20:38:26 UTC 2018
> > firefox-60.0beta16 from https://packages.rhaalovely.net/snapshots/amd64
> > it progresses a bit further and aborts with pledge "fattr", syscall 124
> > using promises: 'stdio rpath wpath cpath inet proc exec prot_exec flock
> > ps sendfd recvfd dns vminfo tty drm' results: Abort trap (core dumped).  
> 
> main process needs fattr & unix to save files here; i added them in
> https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=pledge=11f3f89db4c5cf973205c7a7d332ac52c9d70911
> 
> For a useful report; reproduce with ktrace -di, and mention/quote the
> end of the trace (ie the syscall that triggers the abord should relate
> to the file it was trying to act upon)
> 

Hi Landry,

Succeeds on stat & open places.sqlite, stat places.sqlite-wal & at it

68642 firefox  CALL  fchmod(37,0644)
68642 firefox  PLDG  fchmod, "fattr", errno 1 Operation not permitted
68642 firefox  PSIG  SIGABRT SIG_DFL
68642 firefox  NAMI  "firefox.core"

Patched locally as per your suggestion in the cgit diff the file here

in /usr/local/lib/firefox/browser/defaults/preferences/all-openbsd.js

-pref("security.sandbox.pledge.main","stdio rpath wpath cpath inet proc exec 
prot_exec flock ps sendfd recvfd dns vminfo tty drm");
+pref("security.sandbox.pledge.main","stdio rpath wpath cpath inet proc exec 
prot_exec flock ps sendfd recvfd dns vminfo tty drm unix fattr");

and continuing further testing, thank you very much for the feedback.

Kind regards,
Anton Lazarov



Re: initial pledge() wip for firefox

2018-05-01 Thread lists
Thu, 26 Apr 2018 22:29:40 +0200 Klemens Nanni 
> Your firefox-60.0beta15 with today's snapshot on my X230 gets killed
> almost immediately:
> 
>   699328  51384 firefox  CALL  shmget(0,0x47000,IPC_CREAT|SEM_R|SEM_A)
>   699329  51384 firefox  PLDG  shmget, "", errno 1 Operation not permitted
>   699330  51384 firefox  PSIG  SIGABRT SIG_DFL
> 
> So shmget(2) needs to be hoised.
> 

Hi Landry,

With the snapshot Build date: 1525207106 - Tue May  1 20:38:26 UTC 2018
firefox-60.0beta16 from https://packages.rhaalovely.net/snapshots/amd64
it progresses a bit further and aborts with pledge "fattr", syscall 124
using promises: 'stdio rpath wpath cpath inet proc exec prot_exec flock
ps sendfd recvfd dns vminfo tty drm' results: Abort trap (core dumped).

Kind regards,
Anton Lazarov



Re: [New] [WIP] pkgconf 1.4.2

2018-02-23 Thread lists
Fri, 23 Feb 2018 06:46:42 -0500 Adam Steen 
> Hi Stuart
> 
> Thank you that worked perfectly, now for some testing.
> 
> Please note
> 
> pkg-config -> https://www.freedesktop.org/wiki/Software/pkg-config/
> 
> is different from
> 
> pkgconf -> https://github.com/pkgconf/pkgconf
> 
> Cheers
> Adam
> 

Hi Adam,

Please note, in OpenBSD words beginning with pkg are used for package
tools and package related system utilities, e.g. pkg_add & pkglocate.

I would consider a utility using that word as prefix, and not related
to package tools and package utilities for OpenBSD a deterioration of
my user interface, if some "useful" package pulled in a dependency on
this tool you're proposing with a confusing name, that is not related
to the OpenBSD package tools and package management system utilities.

How about not naming a port pkgsomething here pkgconf, unless it does
relate to the OpenBSD pkg tools, maybe configures OpenBSD pkg system?

Instead of polluting any pkg-config with pkgconf, maybe rename both..

Kind regards,
Anton Lazarov



Re: removal www/newsbeuter

2018-02-11 Thread lists
Sun, 11 Feb 2018 19:46:19 +0100 Björn Ketelaars

> newsbeuter has been abandoned almost 6 months ago. There is however an
> active maintained fork available (https://newsboat.org), which is in
> ports: www/newsboat.
> 
> Any objections to sending www/newsbeuter to the attic?
> 

no, bin it



Re: ?Remove x11/fbpanel

2017-07-10 Thread lists
Mon, 10 Jul 2017 07:04:00 -0700 "Heppler, J. Scott"

> x11/fbpanel is an abandoned project with no updates since 2010.

Hi J. Scott,

Objection to remove this port, still works and useful in some scenarios.

Kind regards,
Anton Lazarov

> The panels plugins for networking/audio volume were linux specific.
> OpenBSD functionality for these features is available in x11/tint2
> which is actively maintained.  If anyone has concerns, I can point to
> tint2 configuratons with menu buttons, battery, networking,
> clock/calendar and audio volume systray icons.
> 
> 
> .
> 
> J. Scott Heppler
> 



Re: OpenBSD Package Manager

2017-05-29 Thread lists
Mon, 29 May 2017 14:16:26 -0400 "H. Ishikawa" 
> Hello, I'd like to ask some specific areas of the pkg_add tools.
> 
> 1. Why Perl instead of C?
> Perl is comparatively slow, and I think this limits who can contribute
> to the source code. How many developers in OpenBSD are actively doing
> any review of the pkg_add tools code? Would there be any interest in
> porting pkgsrc or pkgng from another BSD, or rewriting it in C?
> 
> 2. Why no package database file?
> Other package managers like apt-get can fetch a single file that has
> all the package versions/info in it. When I update my packages on
> OpenBSD Current, it is a very slow process. Each package must be
> individually checked for updates, rather than comparing a list of
> what I have to a single list of the newest versions. This makes
> doing updates very painful and I avoid doing it sometimes.
> 
> 3. Why so many connections?
> When I tried to investigate why the update was so slow, I saw that
> pkg_add was making one HTTPS connection per package! Tools like
> wget from Linux can reuse a single connection for many downloads.
> Could this be added to pkg_add in OpenBSD?
> 
> Thank you.

Hi hishi,

I disagree with your statements - pkg tools are easy, reliable & quick.

perlfaq - frequently asked questions about Perl
http://man.openbsd.org/perlfaq

OpenBSD::Intro - Introduction to the pkg tools internals
http://man.openbsd.org/OpenBSD::Intro

pkg_add - install or update software packages
http://man.openbsd.org/pkg_add

1) Implementer gets to choose the tool, Perl is fast enough, confirmed.
2) This is one reliable approach, what others choose is not a template.
3) Because, tools evolve, please feel free to provide your improvement.

From an independent user perspective, your arguments are kind of weak..

Kind regards,
Anton Lazarov



Re: Patch for fonts/terminus-font/Makefile

2016-09-05 Thread lists
Sun, 04 Sep 2016 22:29:21 -0700 Aioi Yuuko 
> I was actually considering that naming convention, with only one minor 
> caveat: it would break the current flavors. I see four possibilities:
> a) keep symquotes and center_tilde, then add in flavors named directly after 
> the remaining upstream patches
> b) custom names for everything
> c) all names directly after the upstream patches
> d) leave it alone and if anyone wants to really customize, let them edit the 
> makefile themselves
> 
> Discussing just a font for more than ten or so total messages feels like 
> bikeshedding to me, so if we don't get a conclusive answer soonish, I'll 
> probably just drop it (i.e. pick option d).
> On 4 Sep 2016 4:23 p.m., "Dmitrij D. Czarkoff"  wrote:
> >
> > Aioi Yuuko  wrote: 
> >  
> > >-FLAVORS = symquotes centered_tilde 
> > >+FLAVORS = symquotes centered_tilde type_dv cyrillic_i distinct_l script_g 
> > >high_k   
> >
> > This doesn't make sense to me.  There are 10 options and we have 7 
> > FLAVORs with custom (albeit somewhat descriptive) names.  I'd rather go 
> > for 
> >
> > FLAVORS = ao2 dv1 ge2 gq2 ij1 ka2 ll2 td1 hi2 br1 
> >
> > and refer to HOMEPAGE for details.  In the end, the font's defaults are 
> > rather sane, and those who want to customize their font can probably 
> > pick their preferences themselves.   

Hi Aioi,

Point b) was the original direction, I recommend not following this.  The
custom names are much longer than the actual upstream variants (flavors).
This would only make sense for a very limited number of flavours, like it
was originally with a).  I also recommend following Dmitrij's proposal to
match exactly upstream variants for our flavors, your option c).  Agreed?

P.S. I too think the original variants are not ideally named yet wrapping
them in long flavor 'convenience' names is indeed going too far.  Plus it
creates added ambiguity and points for mismatch if upstream make changes.

Kind regards,
Anton



Re: Patch for fonts/terminus-font/Makefile

2016-09-04 Thread lists
Sat, 3 Sep 2016 20:19:39 -0700 Aioi Yuuko 
> Hi,
> 
> Attached is a patch to fonts/terminus adds two new FLAVORs: 
> ``real_russian'' which makes cyrillic letters look more like those of a 
> typical print typeface, and ``distinct_l'' which enables exactly what 
> one would think. This still doesn't cover the full set of internal 
> patches, but I think that's a good thing, at least for now.
> 
> t. yuuko

Hi Aioi,

Please also provide separate ij1 (cyrillic_i) and k2 (high_k), as per
their original upstream character variants.  It is reasonable to have
dv1 (type_dv) independent, despite the fact it mimics type machines &
teletypes from Soviet era, it is less legible than dv2 (the default).
I would also recommend you provide ge2 (script_g) while you're there.

Kind regards,
Anton



Re: rm www/cherokee?

2016-09-03 Thread lists
Sat, 3 Sep 2016 10:14:19 +0100 Stuart Henderson 
> On 2016/09/03 02:38, Juan Francisco Cantero Hurtado wrote:
> > Upstream is dead and the maintainer has not updated the port for years.
> > OK?.  
> 
> Either it should be updated or removed. There are a couple of commits
> recently so it doesn't seem *totally* dead upstream, but it's not very
> active.

Hi ports@,

There is one possible use case as transition away from rewrite rules,
the approach cherokee uses allows beginners a hands on with rewrites.

Kind regards,
Anton

> If nobody is using it -> remove
> 
> If somebody is using it and willing to maintain -> keep
> 
> > Subpackages require something special in quirks?  
> 
> You just need to list all the subpackages.
> 



Re: wxneeded for lang/ruby

2016-08-21 Thread lists
Sun, 21 Aug 2016 22:02:24 +0200 Landry Breuil 
> That's just pure beauty. Wait. I meant horror :)

Will Ruby system application developers be left behind without latest
improvements in infrastructure under language libraries?  Fall behind
Python?  Reassign resources to modern development practices?  Really?



Re: Port removals

2016-08-08 Thread lists
Sun, 7 Aug 2016 21:01:00 -0400 James Turner 
> I would like to remove the following ports because they are either no
> longer maintained upstream or are no longer required by any other ports
> Any objections? oks?
> 
> editors/se
[...]

Hi James,

In case you stop maintaining the se (screen editor) port, please don't
remove it from ports tree & packages, thank you very much for porting.

OpenBSD ports listing web sites

editors/se - screen oriented version of the classic text editor ed
[http://ports.su/editors/se]
[http://openports.se/editors/se]

OpenBSD CVSweb for ports/editors/se: index, description

[http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/editors/se/]
[http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/editors/se/pkg/DESCR]

se (screen editor): homepage, history, screenshots
[http://se-editor.org/]
[http://se-editor.org/history.html]
[http://se-editor.org/screenshots.html]

Kind regards,
Anton



Re: epub reader

2016-07-08 Thread lists
Fri, 8 Jul 2016 10:47:54 -0400 Jiri B 
> On Fri, Jul 08, 2016 at 08:36:11AM -0600, Jack J. Woehr wrote:
> > Is there a tool to read epubs on OpenBSD? I looked in MARC archives
> > and don't find any info.  
> 
> mupdf
> calibre
> an extension in firefox...

This extension worked, tried it once for an epub-only version of an ebook:

Firefox add-on EPUBReader
[https://addons.mozilla.org/en-US/firefox/addon/epubreader/]

Thanks for the other suggestions (mupdf, ebook-tools), I'll try them out
too (knew calibre yet find it a bit too heavy for simply checking epubs).



Re: [UPDATE] games/yquake2 5.32 => 5.34

2016-06-27 Thread lists
Sun, 26 Jun 2016 22:31:55 +0200 Adam Wolk 

> > Same diff but with an additional change to
> > ports/infrastructure/db/user.list and using the same ID.

An underscore informs me it's a program Who brought the user, correct?

Is it any reasonable consideration to make the user names any package,
(here a port) brings up on the system match the _program (_port) name?

Is it also worth making packages (ports) users/groups start with a _p
so they end up together when listed alphabetically, e.g. _pdescent2 ?

NB: I am only considering the system maintenance factors, and don't
insist on anything changed, but please let me know what is the norm.

> Index: Makefile
> ===
> RCS file: /cvs/ports/games/yquake2/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile  16 Mar 2016 16:46:32 -  1.3
> +++ Makefile  26 Jun 2016 20:23:55 -
> @@ -4,12 +4,13 @@ ONLY_FOR_ARCHS= i386 amd64 sparc64
>  
>  COMMENT= Yamagi Quake II
>  N=   yquake2
> -V=   5.32
> +V=   5.34
>  PKGNAME= ${N}-${V}
>  DISTNAME=quake2-${V}
>  CATEGORIES=  games
>  
>  HOMEPAGE=http://www.yamagi.org/quake2/
> +MAINTAINER=  Adam Wolk 
>  MASTER_SITES=http://deponie.yamagi.org/quake2/
>  EXTRACT_SUFX=.tar.xz
>  
> @@ -25,11 +26,12 @@ LIB_DEPENDS=  audio/libvorbis \
>  MAKE_ENV+=   VERBOSE=1
>  USE_GMAKE=   Yes
>  
> +MAKE_FLAGS = config WITH_SYSTEMWIDE=yes WITH_SYSTEMDIR=${PREFIX}/share/${N}
> +
>  do-install:
> - ${INSTALL_SCRIPT} ${FILESDIR}/yquake2 ${PREFIX}/bin/
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}
>   ${INSTALL_PROGRAM} ${WRKBUILD}/release/{quake2,q2ded} \
> - ${PREFIX}/share/${N}/
> + ${PREFIX}/bin/
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}/baseq2
>   ${INSTALL_PROGRAM} ${WRKBUILD}/release/baseq2/game.so \
>   ${PREFIX}/share/${N}/baseq2/
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/yquake2/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo  17 Jan 2016 15:18:31 -  1.1.1.1
> +++ distinfo  26 Jun 2016 20:23:55 -
> @@ -1,2 +1,2 @@
> -SHA256 (quake2-5.32.tar.xz) = v8eAMlSp0iiIVU1a8lL//iEts9qwYxY3u5BFhhuOUIw=
> -SIZE (quake2-5.32.tar.xz) = 1692720
> +SHA256 (quake2-5.34.tar.xz) = gOEZPGM9vuh7n8uGQwafm9pEOqZVUcjzUYcBNsM9ONQ=
> +SIZE (quake2-5.34.tar.xz) = 1702984
> Index: files/yquake2
> ===
> RCS file: files/yquake2
> diff -N files/yquake2
> --- files/yquake2 17 Jan 2016 15:18:31 -  1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,3 +0,0 @@
> -#!/bin/sh
> -cd /usr/local/share/yquake2
> -exec /usr/local/share/yquake2/quake2 "$@"
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/games/yquake2/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 17 Jan 2016 15:18:31 -  1.1.1.1
> +++ pkg/PLIST 26 Jun 2016 20:23:55 -
> @@ -1,8 +1,17 @@
>  @comment $OpenBSD: PLIST,v 1.1.1.1 2016/01/17 15:18:31 bmercer Exp $
> -bin/yquake2
> +@newgroup _q2:779
> +@newuser _q2:779:_q2:daemon:Yamagi Quake II Server:/var/q2:/sbin/nologin
> +@bin bin/q2ded
> +@bin bin/quake2
>  share/doc/pkg-readmes/${FULLPKGNAME}
>  share/yquake2/
>  share/yquake2/baseq2/
>  share/yquake2/baseq2/game.so
> -@bin share/yquake2/q2ded
> -@bin share/yquake2/quake2
> +@mode 750
> +@owner _q2
> +@group _q2
> +@sample /var/q2/
> +@owner
> +@group
> +@mode
> +@rcscript ${RCDIR}/q2ded
> Index: pkg/q2ded.rc
> ===
> RCS file: pkg/q2ded.rc
> diff -N pkg/q2ded.rc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pkg/q2ded.rc  26 Jun 2016 20:23:55 -
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +#
> +# $OpenBSD: $
> +
> +daemon="${TRUEPREFIX}/bin/q2ded"
> +daemon_user="_q2"
> +
> +. /etc/rc.d/rc.subr
> +
> +pexp="${daemon}.*"
> +
> +rc_bg=YES
> +rc_reload=NO
> +
> +rc_cmd $1
> Index: user.list
> ===
> RCS file: /cvs/ports/infrastructure/db/user.list,v
> retrieving revision 1.275
> diff -u -p -r1.275 user.list
> --- user.list 2 Jun 2016 18:32:26 -   1.275
> +++ user.list 26 Jun 2016 20:24:13 -
> @@ -287,3 +287,4 @@ id  user  group   port options
>  776 _ioq3_ioq3   games/ioquake3
>  777 _svnserve_svnserve   devel/subversion
>  778 _gitdaemon   _gitdaemon  devel/git
> +779 _q2  _q2 games/yquake2
> 
> 



Re: [NEW] audio/svmidi

2016-06-27 Thread lists
> > > > > > Sorry deleted the original email before I noticed this.
> > > > > > 
> > > > > > svmidi needs fonts/terminus
> > > > > > --
> > > > > > Edgar Pettijohn
> > > > > 
> > > > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is 
> > > > > on base
> > > > > right?
> > > > 
> > > > Was this not 13 as seen here in file 
> > > > /usr/X11R6/share/X11/app-defaults/XTerm
> > > > 
> > > > 141:*VT100.utf8Fonts.font:  
> > > > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> > > > 
> > > > Try with this:
> > > > 
> > > > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*'
> > > > 
> > > > You could test around with xfontsel(1)
> > > > 
> > > > xfontsel - point and click selection of X11 font names
> > > > [http://man.openbsd.org/xfontsel]
> > > > 
> > > > $ xfontsel
> > > > 
> > > > NB: I may be completely wrong, please don't take it verbatim, verify.
> > > 
> > > Why not 14? I got it from xfontsel
> > 
> > It's up to you mostly, if you choose to follow that just for consistency
> > given the following statements are not completely off the chart or wrong.
> > 
> > While there may be very few reasons for the *-13-* I'll try to add some:
> > 
> > + XTerm 'probably' uses *-13-* by default on a fresh install
> > + 'maybe' some of the sizes cover more from the UTF-8 demo sample
> > 
> > http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
> > 
> > And then again, it's a matter of personal preferences, for my eyes, I
> > just stick to fonts that draw the letter with 1 pixel line width only.
> > 
> > Experiment a bit with various settings and pick the one you like best.
> 
> Ok I got it,
> 
> changed to '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*'
> 
> Attached updated archive.

While terminus itself is not bad, I think you improved upon the choice.
Thank you, hope I get to play with your program from the packages soon!

> Regards;
> 
> Henrique N. Lengler
> 



Re: [NEW] audio/svmidi

2016-06-27 Thread lists
Mon, 27 Jun 2016 18:50:01 -0300 "Henrique N. Lengler"

> On Tue, Jun 28, 2016 at 12:09:10AM +0300, li...@wrant.com wrote:
> > Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler"
> >   
> > > On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote:  
> > > > Sorry deleted the original email before I noticed this.
> > > > 
> > > > svmidi needs fonts/terminus
> > > > -- 
> > > > Edgar Pettijohn
> > > 
> > > Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on 
> > > base
> > > right?  
> > 
> > Was this not 13 as seen here in file /usr/X11R6/share/X11/app-defaults/XTerm
> > 
> > 141:*VT100.utf8Fonts.font:  
> > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> > 
> > Try with this:
> > 
> > '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*'
> > 
> > You could test around with xfontsel(1)
> > 
> > xfontsel - point and click selection of X11 font names
> > [http://man.openbsd.org/xfontsel]
> > 
> > $ xfontsel
> > 
> > NB: I may be completely wrong, please don't take it verbatim, verify.  
> 
> Why not 14? I got it from xfontsel

It's up to you mostly, if you choose to follow that just for consistency
given the following statements are not completely off the chart or wrong.

While there may be very few reasons for the *-13-* I'll try to add some:

+ XTerm 'probably' uses *-13-* by default on a fresh install
+ 'maybe' some of the sizes cover more from the UTF-8 demo sample

http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

And then again, it's a matter of personal preferences, for my eyes, I
just stick to fonts that draw the letter with 1 pixel line width only.

Experiment a bit with various settings and pick the one you like best.

> > > Attached updated archive.
> > > 
> > > Regards;
> > > 
> > > Henrique N. Lengler  
> >   
> 



Re: [NEW] audio/svmidi

2016-06-27 Thread lists
Mon, 27 Jun 2016 17:10:21 -0300 "Henrique N. Lengler"

> On Sun, Jun 26, 2016 at 09:45:23PM -0500, Edgar Pettijohn wrote:
> > Sorry deleted the original email before I noticed this.
> > 
> > svmidi needs fonts/terminus
> > -- 
> > Edgar Pettijohn  
> 
> Changed to '-misc-fixed-medium-*-*-*-14-*-*-*-*-*-*-*', this font is on base
> right?

Was this not 13 as seen here in file /usr/X11R6/share/X11/app-defaults/XTerm

141:*VT100.utf8Fonts.font:  
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

Try with this:

'-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-*'

You could test around with xfontsel(1)

xfontsel - point and click selection of X11 font names
[http://man.openbsd.org/xfontsel]

$ xfontsel

NB: I may be completely wrong, please don't take it verbatim, verify.

> Attached updated archive.
> 
> Regards;
> 
> Henrique N. Lengler



Re: [update] sysclean 1.8

2016-06-04 Thread lists
Sat, 4 Jun 2016 08:41:13 -0500 Amit Kulkarni 
> On Sat, Jun 4, 2016 at 8:00 AM, Sebastien Marie  wrote:
> 
> > Hi,
> >
> > Any OK for upgrading sysutils/sysclean ?
> >
> > Changes:
> >   - add a new mode (used by default): safe mode. it excludes any dynamic
> > libraries and all files under /etc directory. it is a more safe
> > default.
> >   - small documentation bug in usage.
> >
> >  
> Thank you for ignoring /etc by default. IMHO, before integrating in future
> with sysmerge, this should be the way to go.

'sysmerge is not sysclean, consecutive iterations on snapshot upgrades,
system merge, system clean, review, ports upgrade, ports clean, review.
Integrate with automatic upgrades, but not in sysmerge, after sysmerge.



Re: [new] devel/cargo

2016-05-25 Thread lists
Wed, 25 May 2016 12:25:34 +0100 skin...@britvault.co.uk (Craig Skinner)
> Here is an exposition of the 5 paragraphs:
> http://ar.to/2010/01/dissecting-the-unlicense

Craig, we should have less such material, for more bright ideas in
correct software to discuss on multiple standard compliant systems.



chrome extensions won't install - Apr 24 snap. pledge issue?

2016-04-25 Thread lists
After working around hardware acceleration issues (was running chrome as
another user, and /dev/drm0 needed to be chmod'd), I'm trying to install
extensions from the web store in chromium.  Whenever I click "add to
chrome" next to an extension, the button changes to "checking..." and
hangs.

Here's the CLI output (not sure if any of this is related.  Nothing
immediately pops up when I click add... the last line shows up after a
few seconds):

$ chrome
[86425:654932160:0425/150733:ERROR:process_posix.cc(195)] Not implemented 
reached in bool (anonymous namespac
[86425:2047154176:0425/150733:ERROR:linux_util.cc(122)] Not implemented reached 
in std::string base::GetLinux
[86425:445509376:0425/150733:ERROR:process_posix.cc(195)] Not implemented 
reached in bool (anonymous
namespace)::WaitForExitWithTimeoutImpl(base::ProcessHandle, int *, 
base::TimeDelta)
[86425:445509376:0425/150741:ERROR:network_interfaces_posix.cc(63)] Not 
implemented reached in bool
net::GetNetworkList(NetworkInterfaceList *, int)
[86425:1215920384:0425/150818:ERROR:process_posix.cc(195)] Not implemented 
reached in bool (anonymous
namespace)::WaitForExitWithTimeoutImpl(base::ProcessHandle, int *, 
base::TimeDelta)

This shows up in /var/log/messages:
Apr 25 15:01:01 host /bsd: chrome(2929): sysctl 2: 6 19 433940382 -788461926 
430637056 -255
Apr 25 15:01:01 host /bsd: chrome(2929): syscall 202 ""



Re: fonts/terminus-font: Add `centered_tilde' flavor

2016-04-24 Thread lists
Sun, 24 Apr 2016 16:26:17 +0200 LÉVAI Dániel 
> Stuart Henderson @ 2016-04-24T02:57:12 +0200:
> > On 2016/04/23 16:34, patrick keshishian wrote:  
> > > + symquotes- Build with symmetric single quotes.
> > > + centered_tilde   - Build with centered ASCII tilde.
> > > + symquotes-centered_tilde - Build with both modifications.  
> > 
> > I think this last line is a little confusing, it suggests there's
> > something unusual about this port - and if you're building it from
> > ports it won't work like that anyway - you would specify it like
> > `env FLAVOR="symquotes centered_tilde" make'.
> > 
> > Looking at the post-patch target, we don't actually need it at
> > all, see the diff below. I also included upstream's patch names in
> > DESCR in case somebody is looking for a variant by that name, and
> > tweaked the text above a little.
> > 
> > Although I am still in two minds about this strange spelling of
> > the word that most English-speakers in the world know as "centred".

To evade spelling debate mostly, the tilde is in the middle regarding
top/middle/bottom position, and not left/centre/right orientation :-)

Just an idea to exchange the centre and middle for less ambiguity and
quick address of screen placement position as top/mid/bot-L/C/R, maybe
counter intuitive at first, but here middle seems better suited to me.

> > OK with you Daniel? (and I guess, as maintainer, you get final
> > choice on spelling ;-)  
> 
> I'm okay with whatever makes this comfortable for users.

As a person of the Cyrillic script and more than 33 yrs PC usage, here
is a list of what's historically correct and widely accepted the norm:

ao1 - the default as is, ao2 is UNREADABLE
dv2 - more readable and similar to cursive handwriting
ge2 - same, although ge1 is not wrong, ge2 is much much better
gq2 - preferred for text only (manuals) and gq1 is better for coding
ij1 - ij1 is much more readable! should be the default
ka2 - similar to latin k, this is much more readable should be default
ll2 - preferred hugely, this is important for legibility
td1 - proposed default here http://terminus-font.sourceforge.net/
br1 - looks much more pronounced

> But I'm not a native speaker, and I don't want to step on anyone's toes,
> so please decide on the spelling :)

So, how about mid_tilde flavour being the name and the default as well?

It looks the tilde is in the middle vertically on the glass console too.

Regards,
Anton

> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/fonts/Makefile,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 Makefile
> > --- Makefile10 Mar 2016 07:22:46 -  1.31
> > +++ Makefile24 Apr 2016 00:48:51 -
> > @@ -56,6 +56,9 @@
> >   SUBDIR += spranq-ecofont-ttf
> >   SUBDIR += symbola-ttf
> >   SUBDIR += terminus-font
> > + SUBDIR += terminus-font,symquotes
> > + SUBDIR += terminus-font,symquotes,centered_tilde
> > + SUBDIR += terminus-font,centered_tilde
> >   SUBDIR += ubuntu-fonts
> >   SUBDIR += un-fonts
> >   SUBDIR += zh-arphicttf
> > Index: terminus-font/Makefile
> > ===
> > RCS file: /cvs/ports/fonts/terminus-font/Makefile,v
> > retrieving revision 1.10
> > diff -u -p -r1.10 Makefile
> > --- terminus-font/Makefile  13 Nov 2015 20:18:25 -  1.10
> > +++ terminus-font/Makefile  24 Apr 2016 00:48:51 -
> > @@ -3,6 +3,7 @@
> >  COMMENT =  fixed width fonts especially for long hacking sessions
> >  
> >  DISTNAME = terminus-font-4.40
> > +REVISION = 0
> >  CATEGORIES =   fonts x11
> >  
> >  HOMEPAGE = http://terminus-font.sourceforge.net/
> > @@ -24,13 +25,18 @@ FONTDIR =   ${PREFIX}/share/fonts/terminu
> >  
> >  USE_GMAKE =Yes
> >  
> > -FLAVORS =  symquotes
> > +FLAVORS =  symquotes centered_tilde
> >  FLAVOR ?=
> >  
> > +.if ${FLAVOR:Mcentered_tilde}
> > +FLAVOR_PATCHES += ${WRKSRC}/alt/td1.diff
> > +.endif
> > +
> >  .if ${FLAVOR:Msymquotes}
> > -post-patch:
> > -   ${PATCH} -d ${WRKSRC} < ${WRKSRC}/alt/gq2.diff
> > +FLAVOR_PATCHES += ${WRKSRC}/alt/gq2.diff
> >  .endif
> > +
> > +PATCH_LIST = patch-* ${FLAVOR_PATCHES}
> >  
> >  do-install:
> > ${GZIP_CMD} ${WRKSRC}/*.pcf
> > Index: terminus-font/pkg/DESCR
> > ===
> > RCS file: /cvs/ports/fonts/terminus-font/pkg/DESCR,v
> > retrieving revision 1.1.1.1
> > diff -u -p -r1.1.1.1 DESCR
> > --- terminus-font/pkg/DESCR 19 Jul 2011 09:16:08 -  1.1.1.1
> > +++ terminus-font/pkg/DESCR 24 Apr 2016 00:48:51 -
> > @@ -1,5 +1,6 @@
> >  The Terminus font is a complete set of fixed-size fonts designed
> > -especially for the usage in terms.
> > +especially for use in terminals.
> >  
> >  Flavors:
> > -   symquotes - Build with symmetric single quotes.
> > + 

Re: fonts/terminus-font: Add `centered_tilde' flavor

2016-04-24 Thread lists
Sat, 23 Apr 2016 17:13:37 -0400 Michael Reed 
> On 04/23/16 17:01, patrick keshishian wrote:
> > On 4/23/16, Michael Reed  wrote:  
> >> I prefer this variant of terminus, I wonder what others think.  
> >
> > Just reading the description of this patch on $HOMEPAGE, I
> > wonder (as the page suggests) if this should be default?  
> 
> I initially agreed with that because a centered tilde seems to be
> more common in other fonts, and I personally like it more,
> but after some thought I don't think so.
> 
> If a user does `pkg_add terminus', I'd think they would expect to

Should, unless it's common acceptance it must include some patches.

> get the vanilla, unpatched version of Terminus.  If upstream does
> indeed make that the default then so be it, but for now I think a
> separate flavor would be preferable for end-users.

Not very important to me anyway, yet I would prefer the default install
mimicked historically accepted readable text norms and not the "modern"
this and that fancy quotes and other eye poking variation of legibility.

> What do you think?

Seconded, flavours within reason.  It is known this font has too many.
I think you will make the default look good without need for checking.



Re: sysutils/sysclean 1.5

2016-04-22 Thread lists
Fri, 22 Apr 2016 06:50:34 +0200 Sebastien Marie 
> On Thu, Apr 21, 2016 at 08:50:14PM +0200, Joerg Jung wrote:
> > 
> > Do you plan to remove /usr/local from defaults ignore list?
> >   
> 
> It is something I considered but it would have some drawbacks too.
> 
> First, it isn't in initial scope of sysclean, which was started for
> cleaning base only.
> 
> From functionnality point of vue, it will clash a bit with pkg_check(8).
> 
> With the perl version, if the performance impact for integrate
> /usr/local in the cleanup is thiner, the filesystem walk will still have
> to enter in a big directory: on my host it is 20% more for walk time.
> 
> I have no specific opinion in favor or against it.

Thank you for the work on this utility, I consider it very useful here.

Well, sysmerge(8) has the -p option for package mode.  So, sysclean(8)
may too work on package dirs, if you would like to add this.  And also
pkg_check(8) could be mentioned in see also section.  I see a benefit
to both approaches, especially if a clear option is added to sysclean.



Re: Post pkg_delete messages, change message format?

2016-03-26 Thread lists
Fri, 25 Mar 2016 12:47:01 -0500 Chris Bennett

> After I delete packages, especially pkg_delete -X, I get a long list of
> instructions like:
> 
You should also run rm -rf /
>
> With this format, I have to copy/paste each rm -rf, groupdel, etc by hand.
> Could these messages be changed to something easier to use like:
> 
rm -rf /
> 
> This would make these commands very simple to run.

Mindlessly dead easy simple to run, even no need to paste, just pipe to
xargs and don't be tempted to cut, grep or tutorial forbade sed.
> 
> Chris Bennett

I 'ojbect' to your strip, it got diffed off.



Re: Post pkg_delete messages, change message format?

2016-03-26 Thread lists
Fri, 25 Mar 2016 20:27:08 -0700 Jeremy Evans 
> On Fri, Mar 25, 2016 at 10:47 AM, Chris Bennett <
> chrisbenn...@bennettconstruction.us> wrote:  
> 
> > With this format, I have to copy/paste each rm -rf, groupdel, etc by hand.
> > Could these messages be changed to something easier to use like:
> >
> >
> > --- -hplip-3.16.2 ---
> > You should also run
> > rm -rf /usr/local/share/hplip/data/firmware
> > rm -rf /usr/local/share/hplip/data/plugins
> > rm -rf /usr/local/share/hplip/fax/plugins
> > rm -rf /usr/local/share/hplip/prnt/plugins
> > rm -rf /usr/local/share/hplip/scan/plugins
> > rm -f /usr/local/share/hplip/plugin.spec
> >
> > This would make these commands very simple to run.
> >  
> 
> I agree.  The ruby ports already do this, and I think it would be a good
> idea for other packages to do so as well.

The way you present it, looks a lot more acceptable.  If only paste in
terminal can not break in the middle resulting in something similar to:

> > rm -rf /usr/local/share/hplip/data/firmware
> > rm -rf /usr/local/share/hplip/data/plugins
> > rm -rf /usr/local/share/hplip/fax/plugins
> > rm -rf /usr/local/share/hplip/prnt/plugins
> > rm -rf /usr^
: not found



Re: Post pkg_delete messages, change message format?

2016-03-26 Thread lists
Fri, 25 Mar 2016 14:54:12 -0500 Chris Bennett
<chrisbenn...@bennettconstruction.us>
> On Fri, Mar 25, 2016 at 09:32:19PM +0200, li...@wrant.com wrote:
> > Fri, 25 Mar 2016 12:47:01 -0500 Chris Bennett
> > <chrisbenn...@bennettconstruction.us>  
> > > After I delete packages, especially pkg_delete -X, I get a long list of
> > > instructions like:
> > >   
> > You should also run rm -rf /  
> > >  
> 
> There was a diff to prevent this. Not sure if it was committed.

There was no diff in your proposal, this is not about previous anything.

The blatant example is to point out obvious flaws in your suggestion.

Having this change would encourage copy-paste tempting practice, which
is neither safe nor practical.

Processing the output with simple tools like cut and xargs is at your
disposal, if you are so burdened for a couple of repetitions.

> > > With this format, I have to copy/paste each rm -rf, groupdel, etc by hand.
> > > Could these messages be changed to something easier to use like:
> > >   
> > rm -rf /  
> > > 
> > > This would make these commands very simple to run.  
> > 
> > Mindlessly dead easy simple to run, even no need to paste, just pipe to
> > xargs and don't be tempted to cut, grep or tutorial forbade sed.  
> > > 
> > > Chris Bennett  
> > 
> > I 'ojbect' to your strip, it got diffed off.  
> 
> Ever set PKG_PATH wrong?

No.

> Ever wanted to clean out all packages while running -current upgrading
> to a new snapshot before doing a fresh install on next snapshot?

$ man pkg_delete

 -X Delete everything, except the list of packages that follow.

An example to feed to your terminal (check it beforehand, please):

$ sudo pkg_delete -c -I -D baddepend -vv -m -X /var/db/pkg/*-firmware-[0-9]*

> I, personally, would find this change helpful.

Dangerously careless.  Let's see what others think too.

> This change would mean a lot of work, but not need to be done urgently
> at all.

Still no diff.

> This change may have very valid reasons not do it.

Here is why you could show more valid reasons to do it.

> It never hurts to ask reasonable questions. I did not search the mailing
> lists for a previous question about this. Asking this question at all
> may have been a waste of time since it has been addressed before. Which
> means I may have made a mistake in asking it "yet again".

Expand on a wrong idea does not make it right.  Anyway, it's about your
proposal here, and not previous posts.

> On the other hand, the openbsd web pages have just such a format for
> upgrades and following -current.

If you're pasting without reading, there are a lot of tutorial pages on
the internet as well for your fun (and profit).

No problem if you reply off list, maybe move this to misc@ interim?



Re: NEW: sysutils/sysclean

2016-02-29 Thread lists
Mon, 29 Feb 2016 09:57:37 +0100 Sebastien Marie 
> On Mon, Feb 29, 2016 at 09:44:11AM +0100, Antoine Jacoutot wrote:
> > 
> > Out of curiosity, any reason you did not want to "enhance" pkg_check?  

From a many machine host master user perspective, no reason not to have
one for ports, another for the base, Xenocara and other (db) candidates
as appropriate or using different languages and framework environments.

> > I think most of us have home-made clean scripts and it's be nice to
> > have a native tool.  

Well, if these stay home grown, are they too hairy to be shared or just
trade secret?  Nice initiative, long overdue (encouraging sense) & very
much in the hopes this gets worked up from ports to native.  Thank you,
for breaking out the home-world barrier with this proposed tool.



chrome segfault when run under ssh -X

2016-01-27 Thread lists
When running chrome via ssh -X (to utilize X11 security extensions),
chrome has started segfaulting.  I first noticed this after upgrading to
5.8 from 5.7, but never got around to googling for fixes, etc.  I'm now
on -current, and seeing the same issue.

$ ssh -X browser@localhost
$ chrome
Xlib:  extension "RANDR" missing on display "localhost:11.0".
Xlib:  extension "XInputExtension" missing on display "localhost:11.0".
Xlib:  extension "RANDR" missing on display "localhost:11.0".
Segmentation fault (core dumped)

When first noticed on 5.8, I tested in a Debian VM under Virtualbox, and
everything ran fine.

Maybe there isn't enough interest in this since it's an edge case, but
I've been fond of the idea of user separation and some degree of X11
protection that ssh provides.

Here's a trace from 5.8 when I compiled it with symbols:

Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.8"...(no debugging symbols 
found)

Core was generated by `chrome'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.19.0...done.
Loaded symbols for /usr/lib/libpthread.so.19.0
Loaded symbols for /usr/local/chrome/chrome
Reading symbols from /usr/local/lib/libestdc++.so.17.0...done.
Loaded symbols for /usr/local/lib/libestdc++.so.17.0
Reading symbols from /usr/local/lib/libexecinfo.so.2.0...done.
Loaded symbols for /usr/local/lib/libexecinfo.so.2.0
Reading symbols from /usr/local/lib/libgmodule-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgmodule-2.0.so.4200.1
Reading symbols from /usr/local/lib/libgobject-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.1
Reading symbols from /usr/local/lib/libglib-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.4200.1
Reading symbols from /usr/lib/libevent.so.4.1...done.
Loaded symbols for /usr/lib/libevent.so.4.1
Reading symbols from /usr/local/lib/libnss3.so.37.1...done.
Loaded symbols for /usr/local/lib/libnss3.so.37.1
Reading symbols from /usr/local/lib/libsmime3.so.37.1...done.
Loaded symbols for /usr/local/lib/libsmime3.so.37.1
Reading symbols from /usr/local/lib/libnspr4.so.23.1...done.
Loaded symbols for /usr/local/lib/libnspr4.so.23.1
Reading symbols from /usr/local/lib/libgconf-2.so.6.2...done.
Loaded symbols for /usr/local/lib/libgconf-2.so.6.2
Reading symbols from /usr/local/lib/libgio-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgio-2.0.so.4200.1
Reading symbols from /usr/local/lib/libxml2.so.15.1...done.
Loaded symbols for /usr/local/lib/libxml2.so.15.1
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.24.0...done.
Loaded symbols for /usr/X11R6/lib/libfreetype.so.24.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/libcairo.so.12.3...done.
Loaded symbols for /usr/local/lib/libcairo.so.12.3
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/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/local/lib/libpng.so.17.2...done.
Loaded symbols for /usr/local/lib/libpng.so.17.2
Reading symbols from /usr/local/lib/libjpeg.so.67.0...done.
Loaded symbols for /usr/local/lib/libjpeg.so.67.0
Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
Reading symbols from /usr/X11R6/lib/libXi.so.12.1...done.
Loaded symbols for /usr/X11R6/lib/libXi.so.12.1
Reading symbols from /usr/X11R6/lib/libXcursor.so.5.0...done.
Loaded symbols for /usr/X11R6/lib/libXcursor.so.5.0
Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
Reading symbols from /usr/X11R6/lib/libXrender.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXrender.so.6.0
Reading symbols from /usr/X11R6/lib/libXss.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXss.so.6.0
Reading symbols from /usr/local/lib/libatk-1.0.so.21609.1...done.
Loaded symbols for /usr/local/lib/libatk-1.0.so.21609.1
Reading symbols from /usr/X11R6/lib/libXcomposite.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libXcomposite.so.4.0
Reading symbols from /usr/lib/libsndio.so.6.0...done.
Loaded symbols for /usr/lib/libsndio.so.6.0
Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
Loaded symbols for 

Re: pledge in ports

2016-01-19 Thread lists
Tue, 19 Jan 2016 02:40:18 +1300 Carlin Bingham 
> None of these can be dropped later or made conditional on the
> configuration, as tor's config can be changed and reloaded while it's
> running and it needs them all to handle that.
> 
> Is a wide pledge like this still beneficial?

Shows obvious application design flaws.  So much for the application
goals.  And/or the actual use case.  Understand the mail further now?



Re: mail/claws-mail update

2015-11-02 Thread lists
On Thu, 17 Sep 2015 20:29:08 +0200 Daniel Jakots <vigdis+o...@chown.me>
wrote:
>
> Hi,
> 
> Thanks for your report.
> 
> I talked with people from upstream about the trace and they asked if you
> could try a newer version of libetpan.
> 
> jca@ kindly did the hard work for it so you can either take the patch
> there https://marc.info/?l=openbsd-ports=144251205430518=2 and
> build a new libetpan and then rebuild claws-mail or hope it goes in
> and wait for new packages.
> 
> According to the page https://github.com/dinhviethoa/libetpan/releases
> it talks about new gmail features and according to `dig mx` you use
> gmail so hopefully it solved your problem.
> 
> Cheers,
> Daniel
> 

Hi Daniel,

Thank you all for the follow up on this and taking port maintainership.

After libetpan update, the crashes continued (very similar traces) and
even the new version of claws-mail keeps crashing consistently.  Did
not want to lose track of progress on this thread, so replying here
with a back trace and some details related.

Reminder, the crashes happen with NNTP enabled when opening a mailing
list, or when updating the list of messages from the news server
(GMANE).  This can cause the program to crash when replying or
composing, as soon as in the background it gets into checking for new
news messages.  Also while running on its own, without any user
interaction.

I've not been able to find a specific method to trigger the crash on
purpose (while reading mailing lists browsing messages replying etc),
but the program can not be ran for more than a couple of minutes/hours
at most as it certainly does crash.

Please see if this can be brought upstream and followed up until to a
solution.  Can help further with back traces and suggesting you toggle
debug symbols for claws-mail (libetpan?) for a couple of builds in the
packages to help get to the actual cause of this reliability problem in
claws-mail.

Regards,
Anton Lazarov

OpenBSD GENERIC.MP#1554 amd64 running claws-mail-3.13.0 from packages

$ claws-mail -V
Claws Mail version 3.13.0
runtime GTK+ 2.24.28 / GLib 2.46.1
buildtime GTK+ 2.24.28 / GLib 2.46.1
Compiled-in features:
 Enchant
 GnuTLS
 IPv6
 iconv
 libetpan 1.6
 libSM

$ /usr/bin/gdb /usr/local/bin/claws-mail ~/claws-mail.core 
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.8"...(no debugging symbols 
found)

Core was generated by `claws-mail'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.20.0...done.
Loaded symbols for /usr/lib/libpthread.so.20.0
Loaded symbols for /usr/local/bin/claws-mail
Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.2400.0...done.
Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.2400.0
Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.2400.0...done.
Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.2400.0
Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3800.0
Reading symbols from /usr/local/lib/libpango-1.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libpango-1.0.so.3800.0
Reading symbols from /usr/local/lib/libgobject-2.0.so.4200.2...done.
Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.2
Reading symbols from /usr/local/lib/libglib-2.0.so.4200.2...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.4200.2
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.2...done.
Loaded symbols for /usr/local/lib/libffi.so.1.2
Reading symbols from /usr/local/lib/libgthread-2.0.so.4200.2...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.4200.2
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.3...done.
Loaded symbols for /usr/local/lib/libcairo.so.12.3
Symbols already loaded for /usr/lib/libpthread.so.20.0
Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.6...done.
Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.6
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/X11

Re: [astro/ansiweather] broken

2015-10-31 Thread lists
Hi Raf,

> I'm sure that the users of the port had already noticed it a while back
> but, as it stands, ansiweather is broken.

Yep, you can be pretty sure it's broken and about to be recurring as
it's not such an easily solvable problem below the surface, please read
through the next comments.  Like others I too spotted it on the day it
broke by chance, was not certain it is a port I'd use daily period.

Thanks for following this up, looks like an update is pending review:

http://marc.info/?l=openbsd-ports=144622297712023

> A fix is already in the git repository but requires each user to apply
> for an API key.

Asking each client to manually apply for an API key would actually
render the shell script OWM API presenter as pretty useless
complication and drive it away into reseller business category (wait is
it not the model already?), just consider how stupid it is to ask
visitors to subscribe before reading a piece of data dubbed open on the
Internet (that you already have floating around everywhere).  Now let's
not get into the discussion of page scrape compared to web service API
junk food talk, but you get the point.

> At the same time, the author is pondering applying for
> an app/project-wide API key.

While pondering, the API could change, then after a while start asking
monetary tokens, or simply rate limit because it can't take up any load
(at least not just for free without adds and touch ups of data
points at which point our discussion is a waste of time if not
already).

Temp fix now the key for app developers, until bait and switch clicks
through (ticking already).  Can't compete with the GOOGs at this libre
pace, right (well they are not free too in any meaning of the word)?
Oh wait, every mobile device has environmental sensors, and so do
wagons on the road, yet 'nobody' thought of portable weather stations
and NTPd like clients.  This taxable app approach makes me sick.  I
like the port goals though, presenting valuable weather data, except
the data serialisation method is junk and everything nasty about the
provider dependency decay designed into it.

> Also, IMVHO, 'astro' doesn't seem like a good fit for the port - i.e. in
> FreeBSD ports and NetBSD pkgsrc it is under 'misc'.

Worse choice would be a misc category to clog, no?  Thanks for actually
proposing category placement for this port, yet there are no candidates
for environmental readings to make it a category so why not astro?

Too much info than bargained for.. just scream in a private mail (been
having a thought about it for a while you see).  Thanks for pointing
out the problem zones, and let's see how this fares.  Predictions are
hard when you don't have a horse in the race.

Regards,
Ant



Possible fixes for xcolors color database

2015-09-18 Thread lists
Hi ports@

Some time ago this rgb.txt file (X color 'database') got updated:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/rgb/rgb.txt.diff?r1=1.2=1.3
http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/rgb/rgb.txt

I don't know if this is the actual file that gets installed
in /usr/X11R6/share/X11/rgb.txt please advise if this is not so.

I've found out experimentally that the xcolors port since does not
display all colors as expected and modified my copy of rgb.txt in $HOME
and am using it like this so far:

/usr/local/bin/xcolors -rgbfile ~/rgb.txt

Here is the port:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/x11/xcolors/

One possible approach is that either the xcolors port gets updated to
accommodate the new system wide rgb.txt, or alternatively it could
receive an own copy of a working rgb.txt (less preferred), similar to
other ports that have a local version (notably emacs).

I've not found any issues (so far in daily usage) with changing my
system wide rgb.txt, but prefer xcolors to work with the current
included in Xorg (or at least not break with multiple definitions of
the same colour).

Presumably the intended goal is to have xcolors display (almost) all X
color names for reference, as in quick install the port from package and
it just would work and continue to work with the updated color database
without any fiddling.

I actually found out about this by trying to understand why emacs was
having issues starting and was complaining about undefined colors some
time ago (forgotten about details already) and it may have had
something to do with terminal colors defined as names in .Xresources,
the point is that then xcolors did not help me with a nice set of
color names to use for a reference of all X colors predefined.

A relevant thread that fixed xcolors to use system color database:

http://marc.info/?l=openbsd-ports=121333283228282

Here is how I tweaked my system wide rgb.txt (probably this reverts the
above mentioned update as the silliest approach) but this allows xcolors
to work (for me) without specifying the color database on the command
line:

P.S. I don't have the skills and understanding to fix xcolors on my own
(yet).

Regards,
Anton

$ diff -u /usr/X11R6/share/X11/rgb.txt{.orig,}  
--- /usr/X11R6/share/X11/rgb.txt.orig   Mon Jan  5 11:53:22 2015
+++ /usr/X11R6/share/X11/rgb.txtFri Sep 18 00:44:18 2015
@@ -57,14 +57,14 @@
 119 136 153LightSlateGrey
 190 190 190gray
 190 190 190grey
-190 190 190x11 gray
-190 190 190X11Gray
-190 190 190x11 grey
-190 190 190X11Grey
-128 128 128web gray
-128 128 128WebGray
-128 128 128web grey
-128 128 128WebGrey
+!190 190 190   x11 gray
+!190 190 190   X11Gray
+!190 190 190   x11 grey
+!190 190 190   X11Grey
+!128 128 128   web gray
+!128 128 128   WebGray
+!128 128 128   web grey
+!128 128 128   WebGrey
 211 211 211light grey
 211 211 211LightGrey
 211 211 211light gray
@@ -113,7 +113,7 @@
  72 209 204MediumTurquoise
  64 224 208turquoise
   0 255 255cyan
-  0 255 255aqua
+!  0 255 255   aqua
 224 255 255light cyan
 224 255 255LightCyan
  95 158 160cadet blue
@@ -140,11 +140,11 @@
 124 252   0lawn green
 124 252   0LawnGreen
   0 255   0green
-  0 255   0lime
-  0 255   0x11 green
-  0 255   0X11Green
-  0 128   0web green
-  0 128   0WebGreen
+!  0 255   0   lime
+!  0 255   0   x11 green
+!  0 255   0   X11Green
+!  0 128   0   web green
+!  0 128   0   WebGreen
 127 255   0chartreuse
   0 250 154medium spring green
   0 250 154MediumSpringGreen
@@ -216,16 +216,16 @@
 219 112 147pale violet red
 219 112 147PaleVioletRed
 176  48  96maroon
-176  48  96x11 maroon
-176  48  96X11Maroon
-128   0   0web maroon
-128   0   0WebMaroon
+!176  48  96   x11 maroon
+!176  48  96   X11Maroon
+!128   0   0   web maroon
+!128   0   0   WebMaroon
 199  21 133medium violet red
 199  21 133MediumVioletRed
 208  32 144violet red
 208  32 144VioletRed
 255   0 255magenta
-255   0 255fuchsia
+!255   0 255   fuchsia
 238 130 238violet
 221 160 221plum
 218 112 214orchid
@@ -238,10 +238,10 @@
 138  43 226blue violet
 138  43 226BlueViolet
 160  32 240purple
-160  32 240x11 purple
-160  32 240X11Purple
-128   0 128web purple
-128   0 128WebPurple

Re: newsbeuter 2.7 dumps core

2015-09-17 Thread lists
Hi ports@, Kyle,

Ping?

This thread:

http://marc.info/?l=openbsd-ports=144166134505761

Anyone actually using the newsbeuter (RSS/Atom feed reader) for more
than a test spin?

Please let me know if I could help with testing an updated / bug fix
package.

Regards,
Anton

P.S. Attaching another back trace just in case:

$ /usr/bin/gdb /usr/local/bin/newsbeuter ~/newsbeuter.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.8"...
Core was generated by `newsbeuter'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.19.0...done.
Loaded symbols for /usr/lib/libpthread.so.19.0
Loaded symbols for /usr/local/bin/newsbeuter
Symbols already loaded for /usr/lib/libpthread.so.19.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/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/lib/libsqlite3.so.31.0...done.
Loaded symbols for /usr/lib/libsqlite3.so.31.0
Reading symbols from /usr/local/lib/libcurl.so.25.0...done.
Loaded symbols for /usr/local/lib/libcurl.so.25.0
Reading symbols from /usr/local/lib/libxml2.so.15.1...done.
Loaded symbols for /usr/local/lib/libxml2.so.15.1
Reading symbols from /usr/local/lib/libstfl.so.0.0...done.
Loaded symbols for /usr/local/lib/libstfl.so.0.0
Reading symbols from /usr/local/lib/libjson-c.so.0.0...done.
Loaded symbols for /usr/local/lib/libjson-c.so.0.0
Reading symbols from /usr/lib/libcrypto.so.36.0...done.
Loaded symbols for /usr/lib/libcrypto.so.36.0
Reading symbols from /usr/lib/libstdc++.so.57.0...done.
Loaded symbols for /usr/lib/libstdc++.so.57.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/lib/libc.so.83.0...done.
Loaded symbols for /usr/lib/libc.so.83.0
Reading symbols from /usr/lib/libncursesw.so.14.0...done.
Loaded symbols for /usr/lib/libncursesw.so.14.0
Reading symbols from /usr/local/lib/libidn.so.17.2...done.
Loaded symbols for /usr/local/lib/libidn.so.17.2
Reading symbols from /usr/lib/libssl.so.37.0...done.
Loaded symbols for /usr/lib/libssl.so.37.0
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/liblzma.so.2.1...done.
Loaded symbols for /usr/local/lib/liblzma.so.2.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  _fmt (format=0xc646993dc54 "a, %d %b %Y %T %z", t=0x0, pt=0xc668e946840 "", 
ptlim=0xc668e946c40 "f¦в$О_р\nf¦в$О_р\n8n\224\216f\f", warnp=0xc668e9467f4)
at /usr/src/lib/libc/time/strftime.c:158
158 t->tm_wday >= DAYSPERWEEK) ?
(gdb) bt
#0  _fmt (format=0xc646993dc54 "a, %d %b %Y %T %z", t=0x0, pt=0xc668e946840 "", 
ptlim=0xc668e946c40 "f¦в$О_р\nf¦в$О_р\n8n\224\216f\f", warnp=0xc668e9467f4)
at /usr/src/lib/libc/time/strftime.c:158
#1  0x0c66a3fa286d in *_libc_strftime (s=0xc668e946840 "", maxsize=1024, 
format=0xc646993dc53 "%a, %d %b %Y %T %z", t=0x0)
at /usr/src/lib/libc/time/strftime.c:130
#2  0x0c6469771532 in newsbeuter::rss_item::pubDate (this=Variable "this" 
is not available.
) at src/rss.cpp:116
#3  0x0c64697c46e1 in newsbeuter::itemview_formaction::prepare 
(this=0xc66c39d5200) at src/itemview_formaction.cpp:99
#4  0x0c646973e916 in newsbeuter::view::force_redraw (this=Variable "this" 
is not available.
) at src/view.cpp:811
#5  0x0c6469752a65 in newsbeuter::controller::reload_all 
(this=0x7f7be7a0, unattended=false) at src/controller.cpp:873
#6  0x0c6469770b5b in newsbeuter::downloadthread::run (this=0xc670ddfe7c0) 
at src/downloadthread.cpp:24
#7  0x0c6469818fef in newsbeuter::run_thread (p=0xc670ddfe7c0) at 
src/thread.cpp:45
#8  0x0c66d051a90e in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:145
#9  0x0c66a3f3d79b in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#10 0x in ?? ()
Current language:  auto; currently c
(gdb) bt full
#0  _fmt (format=0xc646993dc54 "a, %d %b %Y %T %z", t=0x0, pt=0xc668e946840 "", 
ptlim=0xc668e946c40 "f¦в$О_р\nf¦в$О_р\n8n\224\216f\f", warnp=0xc668e9467f4)
at /usr/src/lib/libc/time/strftime.c:158
len = Variable "len" is not available.
(gdb) info threads
  3 process 13684  0x0c66a3f445ba in nanosleep () at :2
  2 process 193  0x0c66a3f56b9a in poll () at :2
* 1 process 2066  _fmt (format=0xc646993dc54 "a, %d %b %Y %T %z", t=0x0, 
pt=0xc668e946840 "", ptlim=0xc668e946c40 "f¦в$О_р\nf¦в$О_р\n8n\224\216f\f", 

Re: mail/claws-mail update

2015-09-17 Thread lists
> Hi,
> 
> Thanks for your report.
> 
> I talked with people from upstream about the trace and they asked if you
> could try a newer version of libetpan.
> 
> jca@ kindly did the hard work for it so you can either take the patch
> there https://marc.info/?l=openbsd-ports=144251205430518=2 and
> build a new libetpan and then rebuild claws-mail or hope it goes in
> and wait for new packages.
> 
> According to the page https://github.com/dinhviethoa/libetpan/releases
> it talks about new gmail features and according to `dig mx` you use
> gmail so hopefully it solved your problem.
> 
> Cheers,
> Daniel

Hi Daniel,

Actually (for me) it crashes on NNTP (GMaNe) reading mailing lists and
indeed libetpan is in the backtrace in the crashes. Not sure if it's
the SSL/TLS handling or date format handling of a particular article
(or a new line) as it's not triggered by a special set of actions,
rather core-dumping (seemingly) sporadic on NNTP article browsing with
a certainty it does crash and can not be ran for more than a couple of
minutes / hours at a time.

I've put a side comment in the other thread too (spotted the libetpan
mention right away), just in case it is useful but it's not yet made the
mailing list (held for review probably, don't know what causes several
hours of delay on posts to the mailing lists).

I'll wait for a package and see how it fares. I've been dealing with
this claws-mail bug and many other (RSSyl) one way or another for a
long time, let's see if it's the only culprit.

Thanks for your follow up on this, much appreciated (as always).

P.S. Excuse me for the carbon copy directly but not always messages
even reach the mailing list (especially if new posts appear before mine
make it to the list). This is however not related to the claws-mail
bugs and I have an idea what's happening :)

Regards,
Anton



Re: mail/libetpan update (hint: claws-mail)

2015-09-17 Thread lists
> Major bump because I'm not sure whether a minor one is actually enough.
> No more autotools goo, no more docs since it comes straight out of the
> git repo.  Making releases is hard.  Extra time_t fixes because it
> seemed easy in comparison to building the docs...

Side comments only:

Hi Jérémie, Daniel,

Thank you for following up on the claws-mail dependency (libetpan),
seen in the backtrace:

http://marc.info/?l=openbsd-ports=144241041432328

Hope this fixes the long standing claws-mail bug, though there are some
older bug reports in claws-mail bugzilla related to NNTP.

Tough nut, hope libraries current versions are a good start, not sure
what am I talking about :) fingers crossed it's the date format
handling and not borked threads

Regards,
Anton



Re: mail/claws-mail update

2015-09-16 Thread lists
> Also fingers crossed this version fixes the crashes (segfaults)
> experienced frequently with Claws mail.
> 
> I'll say something with a backtrace if these continue on the new
> version once I get a hold of a package on the mirror.

Hi Daniel, Landry, Stuart,

Unfortunately the new version claws-mail program continues to crash
similarly to previous versions with segmentation fault (core dumped).

Here is the promised back trace:

$ /usr/bin/gdb /usr/local/bin/claws-mail ~/claws-mail.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.8"...(no debugging symbols 
found)

Core was generated by `claws-mail'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.19.0...done.
Loaded symbols for /usr/lib/libpthread.so.19.0
Loaded symbols for /usr/local/bin/claws-mail
Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.2400.0...done.
Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.2400.0
Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.2400.0...done.
Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.2400.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.4200.1...done.
Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.1
Reading symbols from /usr/local/lib/libglib-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.4200.1
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.1...done.
Loaded symbols for /usr/local/lib/libffi.so.1.1
Reading symbols from /usr/local/lib/libgmodule-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgmodule-2.0.so.4200.1
Reading symbols from /usr/local/lib/libgthread-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.4200.1
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.3...done.
Loaded symbols for /usr/local/lib/libcairo.so.12.3
Symbols already loaded for /usr/lib/libpthread.so.19.0
Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.6...done.
Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.6
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.24.0...done.
Loaded symbols for /usr/X11R6/lib/libfreetype.so.24.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.2...done.
Loaded symbols for /usr/local/lib/libpng.so.17.2
Reading symbols from /usr/X11R6/lib/libxcb-shm.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-shm.so.1.1
Reading symbols from /usr/X11R6/lib/libxcb.so.3.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb.so.3.1
Reading symbols from /usr/X11R6/lib/libxcb-render.so.1.0...done.
Loaded symbols for /usr/X11R6/lib/libxcb-render.so.1.0
Reading symbols from /usr/X11R6/lib/libXrender.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXrender.so.6.0
Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
Reading symbols from /usr/local/lib/libpangoft2-1.0.so.3600.0...done.
Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.3600.0
Reading symbols from /usr/local/lib/libharfbuzz.so.5.1...done.
Loaded symbols for /usr/local/lib/libharfbuzz.so.5.1
Reading symbols from /usr/local/lib/libgraphite2.so.1.0...done.
Loaded symbols for /usr/local/lib/libgraphite2.so.1.0
Reading symbols from /usr/local/lib/libgio-2.0.so.4200.1...done.
Loaded symbols for /usr/local/lib/libgio-2.0.so.4200.1
Reading symbols from /usr/X11R6/lib/libXinerama.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXinerama.so.6.0
Reading symbols from /usr/X11R6/lib/libXi.so.12.1...done.
Loaded symbols for 

Re: mail/claws-mail update

2015-09-13 Thread lists
On Sat, 12 Sep 2015 20:31:51 +0100
Stuart Henderson  wrote:

> On 2015/09/12 21:25, Landry Breuil wrote:
> > On Sat, Sep 12, 2015 at 02:51:53PM +0200, Daniel Jakots wrote:
> > > On Sat, 12 Sep 2015 13:34:17 +0100, Stuart Henderson
> > >  wrote:
> > > 
> > > > On 2015/09/12 10:00, Daniel Jakots wrote:
> > > > > A few days after this email, I made a new claws-mail package on my
> > > > > laptop without the patches that were containing the link of the bug
> > > > > id 2640 or 2642 (hard way ...). I don't really understand what the
> > > > > patches should do but I haven't encountered any problem.
> > > > 
> > > > So how about this with those extra patches (i.e. the ones that
> > > > upstream rejected) removed?
> > > 
> > > I guess it's fine. Thanks!
> > 
> > Just for the record, all those patches were added 3 years ago, see
> > http://marc.info/?t=13408376241=1=2 for history.
> 
> yes, I saw that, but since upstream found problems with the patches, the
> sensible thing is to remove them and if somebody wants them brought back,
> they can address the problems that were found :)

Hi Stuart, Landry, Daniel,

Thank you for the update, hoping for a package build soon now:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/mail/claws-mail/Makefile

Also fingers crossed this version fixes the crashes (segfaults)
experienced frequently with Claws mail.

I'll say something with a backtrace if these continue on the new
version once I get a hold of a package on the mirror.

Regards,
Anton



newsbeuter 2.7 dumps core

2015-09-07 Thread lists
Hi ports@

I've been running into core dump problems with the newsbeuter RSS
reader installed from package on a kept up to date via snapshots
OpenBSD amd64 system. I would prefer to continue using newsbeuter, but
at the rate this eats memory and fails, it's inconvenient and
unreliable as a news reader.

Usually the newsbeuter process runs OK for short periods but for longer
periods gains (probably leaks too but I can't figure it out) memory
eventually core dumping. I'll try to provide details here about the set
up, which is pretty much very standard.

There is probably a bug in the newsbeuter in ports, given the age of
the version we have is 2.7 released Aug 2013, and the fact there have
been 2 newer versions out so far, please advise how to proceed with
this further. I've mailed the port maintainer on July 4 and he replied
back he'll have a look at it in a week time frame, but there may be
some road block preventing the update of the port to the latest
newsbeuter 2.9 released Feb 19, 2015.

Import in ports
http://marc.info/?l=openbsd-ports=138188611024254

Version in ports
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/www/newsbeuter/Makefile

Version at homepage
http://newsbeuter.org/download.html

CVSweb of port
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/newsbeuter/

Version installed here:

$ newsbeuter -v
newsbeuter 2.7 - http://www.newsbeuter.org/ Copyright (C) 2006-2010 Andreas 
Krennmair
Compilation date/time: Jul 27 2015 03:34:50
System: OpenBSD 5.8 (amd64)
Compiler: g++ 4.2.1 20070719
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
libcurl: libcurl/7.43.0 LibreSSL/2.0.0 zlib/1.2.3 libidn/1.32 (compiled with 
7.43.0)
SQLite: 3.8.9 (compiled with 3.8.9)
libxml2: compiled with 2.9.2

RSS feeds polled:

$ grep -vE '(^#|^$)' ~/.newsbeuter/urls | wc -l
 107

Database cache size:

$ cd ~/.newsbeuter ; ls -sk cache.db
 58720 cache.db

Configuration tweaks:

$ grep -viE '(^#|^$|^color|^highlight)' ~/.newsbeuter/config
article-sort-order date-desc
auto-reload yes
reload-time 30
reload-threads 4
datetime-format "%y-%b-%d"
browser w3m
confirm-exit yes
goto-first-unread yes
swap-title-and-hints yes
max-items 500

Backtrace of coredump:

$ gdb `which newsbeuter` ~/newsbeuter.core  
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.8"...
Core was generated by `newsbeuter'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.19.0...done.
Loaded symbols for /usr/lib/libpthread.so.19.0
Loaded symbols for /usr/local/bin/newsbeuter
Symbols already loaded for /usr/lib/libpthread.so.19.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/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/lib/libsqlite3.so.30.1...done.
Loaded symbols for /usr/lib/libsqlite3.so.30.1
Reading symbols from /usr/local/lib/libcurl.so.24.9...done.
Loaded symbols for /usr/local/lib/libcurl.so.24.9
Reading symbols from /usr/local/lib/libxml2.so.15.1...done.
Loaded symbols for /usr/local/lib/libxml2.so.15.1
Reading symbols from /usr/local/lib/libstfl.so.0.0...done.
Loaded symbols for /usr/local/lib/libstfl.so.0.0
Reading symbols from /usr/local/lib/libjson-c.so.0.0...done.
Loaded symbols for /usr/local/lib/libjson-c.so.0.0
Reading symbols from /usr/lib/libcrypto.so.35.0...done.
Loaded symbols for /usr/lib/libcrypto.so.35.0
Reading symbols from /usr/lib/libstdc++.so.57.0...done.
Loaded symbols for /usr/lib/libstdc++.so.57.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/lib/libc.so.80.1...done.
Loaded symbols for /usr/lib/libc.so.80.1
Reading symbols from /usr/lib/libncursesw.so.14.0...done.
Loaded symbols for /usr/lib/libncursesw.so.14.0
Reading symbols from /usr/local/lib/libidn.so.17.2...done.
Loaded symbols for /usr/local/lib/libidn.so.17.2
Reading symbols from /usr/lib/libssl.so.35.0...done.
Loaded symbols for /usr/lib/libssl.so.35.0
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/liblzma.so.2.1...done.
Loaded symbols for /usr/local/lib/liblzma.so.2.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  _fmt (format=0xb7e1943dc34 "a, %d %b %Y %T %z", t=0x0, pt=0xb803beb1a30 "", 
ptlim=0xb803beb1e30 "�hK\207r\035�\205�hK\207r\035�\205( �;\200\v", 
warnp=0xb803beb19e4)
at /usr/src/lib/libc/time/strftime.c:157
157 pt = _add((t->tm_wday < 0 ||
(gdb) bt
#0  _fmt 

Re: Add devel/ruby-tame, wrapper for tame(2)

2015-07-22 Thread lists
Thank you for your time following up on this with the explanatory
and reassuring details.



Re: Add devel/ruby-tame, wrapper for tame(2)

2015-07-20 Thread lists
 Please refrain from such comments.

So, I'm definitely shutting up until you tell me to speak out. And
again. can you time frame how you would keep up the work done by
OpenBSD developers?



Re: Add devel/ruby-tame, wrapper for tame(2)

2015-07-20 Thread lists
Is this port going to keep up with the development of the underlying
structure it depends on? Please advise timescale.



net/pidgin coredumps after ssl patch

2014-09-30 Thread ks-lists
Hi. I've been using finch from ports (net/pidgin subpkg) for a
few months. Today I restarted it and it core dumps. The maintainer
suggested I email ports list for help.

I installed from 5.5 amd64 package. Nothing has changed lately.
A Pidgin developer told me building against OpenSSL instead of
NSS or GNUTLS was mostly unsupported. The error makes me think
that maybe this patch broke something:

http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/010_openssl.patch.sig

and it didn't manifest itself since latest upgrade restart.

Core was generated by `finch'.
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/finch
Reading symbols from /usr/local/lib/libgnt.so.6.2...done.
Loaded symbols for /usr/local/lib/libgnt.so.6.2
Reading symbols from /usr/lib/libncursesw.so.14.0...done.
Loaded symbols for /usr/lib/libncursesw.so.14.0
Reading symbols from /usr/lib/libpanelw.so.6.0...done.
Loaded symbols for /usr/lib/libpanelw.so.6.0
Reading symbols from /usr/local/lib/libpython2.7.so.0.0...done.
Loaded symbols for /usr/local/lib/libpython2.7.so.0.0
Reading symbols from /usr/local/lib/libpurple.so.6.2...done.
Loaded symbols for /usr/local/lib/libpurple.so.6.2
Reading symbols from /usr/local/lib/libdbus-glib-1.so.4.3...done.
Loaded symbols for /usr/local/lib/libdbus-glib-1.so.4.3
Reading symbols from /usr/local/lib/libgthread-2.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.3800.0
Reading symbols from /usr/local/lib/libxml2.so.15.1...done.
Loaded symbols for /usr/local/lib/libxml2.so.15.1
Reading symbols from /usr/local/lib/libidn.so.17.0...done.
Loaded symbols for /usr/local/lib/libidn.so.17.0
Reading symbols from /usr/local/lib/libdbus-1.so.11.0...done.
Loaded symbols for /usr/local/lib/libdbus-1.so.11.0
Reading symbols from /usr/local/lib/libgio-2.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libgio-2.0.so.3800.0
Reading symbols from /usr/local/lib/libgobject-2.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libgobject-2.0.so.3800.0
Reading symbols from /usr/local/lib/libgmodule-2.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libgmodule-2.0.so.3800.0
Reading symbols from /usr/local/lib/libffi.so.0.0...done.
Loaded symbols for /usr/local/lib/libffi.so.0.0
Reading symbols from /usr/local/lib/libglib-2.0.so.3800.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.3800.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/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.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/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/lib/libutil.so.12.0...done.
Loaded symbols for /usr/lib/libutil.so.12.0
Symbols already loaded for /usr/lib/libpthread.so.18.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/lib/libc.so.73.1...done.
Loaded symbols for /usr/lib/libc.so.73.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/local/lib/finch/gntgf.so...done.
Loaded symbols for /usr/local/lib/finch/gntgf.so
Reading symbols from /usr/X11R6/lib/libX11.so.16.0...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.0
Reading symbols from /usr/X11R6/lib/libxcb.so.3.0...done.
Loaded symbols for /usr/X11R6/lib/libxcb.so.3.0
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/libXau.so.10.0...done.
Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
Reading symbols from /usr/local/lib/finch/gnthistory.so...done.
Loaded symbols for /usr/local/lib/finch/gnthistory.so
Reading symbols from /usr/local/lib/finch/gntlastlog.so...done.
Loaded symbols for /usr/local/lib/finch/gntlastlog.so
Reading symbols from /usr/local/lib/finch/gnttinyurl.so...done.
Loaded symbols for /usr/local/lib/finch/gnttinyurl.so
Reading symbols from /usr/local/lib/finch/grouping.so...done.
Loaded symbols for /usr/local/lib/finch/grouping.so
Reading symbols from /usr/local/lib/finch/gntclipboard.so...done.
Loaded symbols for /usr/local/lib/finch/gntclipboard.so
Reading symbols from /usr/local/lib/purple-2/buddynote.so...done.
Loaded symbols for /usr/local/lib/purple-2/buddynote.so
Reading symbols from /usr/local/lib/purple-2/dbus-example.so...done.
Loaded symbols for /usr/local/lib/purple-2/dbus-example.so
Reading symbols from /usr/local/lib/purple-2/idle.so...done.
Loaded symbols for /usr/local/lib/purple-2/idle.so
Reading symbols from 

Re: new: owx

2011-09-18 Thread mitja-lists

On 09/18/11 21:47, jirib wrote:

On Sun, 18 Sep 2011 23:10:33 +0200
Mitja Muženičmi...@muzenic.net  wrote:



OWX (Open Wouxun) is an open-source program designed to program
Wouxun transceivers. It was developed on Wouxun KG-UV2D and
tested on KG-UVD1P (both identify as KG669V). Possibly other
Wouxuns are supported too, but
this is not guaranteed - use at your own risk and ALWAYS make
backups! This software is highly experimental. Using it can
result in rendering your radio unusable and your dog killed. You
have been warned. --

Tested on my Wouxun KG-817 HAM radio with a Prolific
USB-to-serial adapter with fancy wiring at the end so it hooks
up to the radio's speaker and mic jacks (as described in
/usr/local/share/doc/owx/README). Since the protocol and memory
layouts of the radio are reverse engineered, not every function
is supported.



I am glad that I am not the only one with a Wouxun radio :) It will
probably work even better on a KG-UV1 than on my KG-817, just make
sure to read the docs carefully. Let me know if it works for you.


Hi,

I'm just curious, what do you use these radios for in days of mobile
phones and sms? If it is not confidential :-)

jirib



http://en.wikipedia.org/wiki/Amateur_radio

Mitja



fyi port for graphics/png does not like MANPS=1

2009-05-05 Thread ppruett-lists



I happened to put in my /etc/mk.conf
MANPS=1

and was working a xeon processer with stable openbsd 4.5 by trying make 
package for /usr/ports


And lol, I got a install error, for the package graphics/png

install -c -o root -g bin -m 444 libpng.ps3 
/usr/ports/graphics/png/w-png-1.2.33/fake-amd64/usr/share/man/ps3/libpng.ps
install: 
/usr/ports/graphics/png/w-png-1.2.33/fake-amd64/usr/share/man/ps3/libpng.ps: 
No such file or directory

*** Error code 71


I went back and comment the MANPS in etc/mk.conf
and it was able to make the pakage..

JUST AN FYI to whom it may concern.