Hi,
This is a port of (originally) https://github.com/Yubico/libfido2
- but temporarily using my forked repository at
https://github.com/djm-google/libfido2 that has a couple of extra
pieces: OpenBSD support and a small extra library that OpenSSH can now
use to talk to U2F tokens. I have PRs pending for both of these so
I hope that I can point the port back to the upstream repository soon.
This port depends on the libcbor port that I sent a moment ago, and
all my caveats about being rusty wrt porting stuff applies.
ok?
If you're interested in using the new U2F support in OpenSSH and
you're running -current, then after installing this port and applying
patrick@'s uhid patch (on tech@) you should be able to do stuff like:
$ # Tell OpenSSH to use this library to talk to U2F devices
$ export SSH_SK_PROVIDER=/usr/local/lib/libsk-libfido2.so
$ # Generate a key
$ ssh-keygen -t ecdsa-sk
$ cat ~/.ssh/id_ecdsa_sk.pub
From there you have a public key that you can use as normal on
(-current) sshd, i.e. copying it to ~/.ssh/authorized_keys, etc.
When you run ssh to log in, you must also ensure it get either the
SSH_SK_PROVIDER environment variable or the equivalent
SecurityKeyProvider config item, and you must tap your key to authorise
the signature.
I'd very much like to hear your feedback
-d
Thursday, October 31, 2019
[NEW] devel/libcbor
Hi,
It's been a while since I've written a port and I'm pretty rusty, but
here's a port for https://github.com/PJK/libcbor - an implementation of
the RFC7049 Concise Binary Object Representation format.
This is used by (among other things) FIDO2 tokens and is a prerequisite
for libfido2 and some parts that I need to enable U2F tokens in OpenSSH
(see my next message).
Ok?
It's been a while since I've written a port and I'm pretty rusty, but
here's a port for https://github.com/PJK/libcbor - an implementation of
the RFC7049 Concise Binary Object Representation format.
This is used by (among other things) FIDO2 tokens and is a prerequisite
for libfido2 and some parts that I need to enable U2F tokens in OpenSSH
(see my next message).
Ok?
Curses ICB and IRC client
Hi
Yesterday I released v3.0.0 of Swirc.
The new version supports the ICB protocol.
I attach a port I've created.
Swirc uses pledge() in combination with unveil().
It was pledged very early already in 1.1.
I focus on portability and security.
But I basically do all the testing myself... + development (so far)
--
Med vänlig hälsning
Markus Uhlin
Yesterday I released v3.0.0 of Swirc.
The new version supports the ICB protocol.
I attach a port I've created.
Swirc uses pledge() in combination with unveil().
It was pledged very early already in 1.1.
I focus on portability and security.
But I basically do all the testing myself... + development (so far)
--
Med vänlig hälsning
Markus Uhlin
Re: [update] log4cplus 2.0.4
On 2019/10/31 15:17, sven falempin wrote:
> build ok 6.6
Your mail client mangles inline diffs (word-wraps, and replaces tabs
with spaces). this means they can't be applied with patch and need to be
re-edited by hand. You might have better luck with an attachment rather
than inline (generally it's preferred to send inline via an MTA which
doesn't break things, second best would be a working attachment, but
"inline and broken" is the worst option!)..
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/log4cplus/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 26 Jul 2017 22:45:18 -0000 1.10
> +++ Makefile 31 Oct 2019 19:12:39 -0000
> @@ -2,7 +2,7 @@
> COMMENT= logging API for C++
> -DISTNAME = log4cplus-1.2.0
> +DISTNAME = log4cplus-2.0.4
> EXTRACT_SUFX= .tar.bz2
> REVISION = 0
The REVISION line should be removed when updating to a new version.
Update notes for 2.0 say "Implementation language is now C++11".
This means it no longer builds with base-gcc so please remove that from the
COMPILER line.
net/kea depends on this, have you checked that it at least still builds?
The SHARED_LIBS line also need bumping to 3.0 because the update isn't ABI compatible
with the old version.
> build ok 6.6
Your mail client mangles inline diffs (word-wraps, and replaces tabs
with spaces). this means they can't be applied with patch and need to be
re-edited by hand. You might have better luck with an attachment rather
than inline (generally it's preferred to send inline via an MTA which
doesn't break things, second best would be a working attachment, but
"inline and broken" is the worst option!)..
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/log4cplus/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 26 Jul 2017 22:45:18 -0000 1.10
> +++ Makefile 31 Oct 2019 19:12:39 -0000
> @@ -2,7 +2,7 @@
> COMMENT= logging API for C++
> -DISTNAME = log4cplus-1.2.0
> +DISTNAME = log4cplus-2.0.4
> EXTRACT_SUFX= .tar.bz2
> REVISION = 0
The REVISION line should be removed when updating to a new version.
Update notes for 2.0 say "Implementation language is now C++11".
This means it no longer builds with base-gcc so please remove that from the
COMPILER line.
net/kea depends on this, have you checked that it at least still builds?
The SHARED_LIBS line also need bumping to 3.0 because the update isn't ABI compatible
with the old version.
Re: [NEW] databases/p5-DBICx-Sugar
On Thu, Oct 17, 2019 at 07:35:49AM +0000, wen heping wrote:
> Hi, ports@:
>
> Here is a patch to create new port databases/p5-DBICx-Sugar, which is
> required by the update of www/p5-Dancer2-Plugin-DBIC, which is required
> by the update of www/p5-Dancer2.
>
> The patch include 3 new ports：
> databases/p5-DBICx-Sugar
> devel/p5-Test-API
> devel/p5-Test-Modern
> All build well and pass all tests on amd64-head system.
>
> Comments? OK?
> wen
OK afresh1@ to import all three of these with one minor fix.
The CPAN_AUTHOR line in DBICx-Sugar is usually placed up near the
DISTNAME or by the MODULE=cpan line. I prefer it by the DISTNAME
myself, so it would be nice if that moved before import.
l8rZ,
--
andrew - http://afresh1.com
($do || !$do) && undef($try) ; # Master of Perl, Yoda is. Hmmmm?
> Hi, ports@:
>
> Here is a patch to create new port databases/p5-DBICx-Sugar, which is
> required by the update of www/p5-Dancer2-Plugin-DBIC, which is required
> by the update of www/p5-Dancer2.
>
> The patch include 3 new ports：
> databases/p5-DBICx-Sugar
> devel/p5-Test-API
> devel/p5-Test-Modern
> All build well and pass all tests on amd64-head system.
>
> Comments? OK?
> wen
OK afresh1@ to import all three of these with one minor fix.
The CPAN_AUTHOR line in DBICx-Sugar is usually placed up near the
DISTNAME or by the MODULE=cpan line. I prefer it by the DISTNAME
myself, so it would be nice if that moved before import.
l8rZ,
--
andrew - http://afresh1.com
($do || !$do) && undef($try) ; # Master of Perl, Yoda is. Hmmmm?
Following current - pkg_add update forward depedencies don't match question
Hello
I just updated a system to current the other day.
OpenBSD 6.6 GENERIC.MP#411 amd64
The last time I updated was probably 2-3 months ago.
Anyway, when I went to updated packages (also following current/snapshots),
I got a number of "forward dependencies - don't match" notices and the
packages don't update.
For example:
gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies:
| Dependencies of php-apache-7.1.27p0 on gettext-* don't match
| Dependencies of gnupg-1.4.23p1 on gettext-* don't match
| Dependencies of glib2-2.58.3p8 on gettext-* don't match
| Dependencies of courier-imap-4.18.2p0 on gettext-* don't match
| Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match
| Dependencies of libgpg-error-1.36 on gettext-* don't match
| Dependencies of python-3.6.8p0 on gettext-* don't match
| Dependencies of samba-4.8.9 on gettext-* don't match
| Dependencies of gdbm-1.16 on gettext-* don't match
| Dependencies of popt-1.16p1 on gettext-* don't match
| Dependencies of aspell-0.60.6.1p8 on gettext-* don't match
| Dependencies of libpsl-0.20.2 on gettext-* don't match
| Dependencies of wget-1.20.2 on gettext-* don't match
| Dependencies of php-7.1.27 on gettext-* don't match
| Dependencies of libidn-1.35 on gettext-* don't match
| Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match
| Dependencies of python-2.7.16 on gettext-* don't match
| Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match
| Dependencies of fetchmail-6.3.26p2 on gettext-* don't match
| Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match
| Dependencies of p11-kit-0.23.15p0 on gettext-* don't match
When I check:
# pkg_info | grep gettext
gettext-0.19.8.1p3 GNU gettext runtime libraries and programs
And the mirror shows:
gettext-runtime-0.20.1p0.tgz
Or (another example), with similar notices about forward dependencies not
matching:
# pkg_info | grep php-7
php-7.1.27 server-side HTML-embedded scripting language
And the mirror shows:
php-7.1.32.tgz
I see that I can "force" the update with "pkg_add -u -D updatedepends".
It seems like this should be safe to do, but it's not something I have done
before.
While my system isn't "production" for a large multi-national, I do use it
as a file server and stuff, and it is working right now, and I don't want to
make it not work.
So, before I did this, I was wondering if there was anything I should
consider/do to address this issue, other than just "forcing" the update?
I guess, when at its core, I don't really completely understand what the
notice means, and how and why it happened.
Thanks
Ted
I just updated a system to current the other day.
OpenBSD 6.6 GENERIC.MP#411 amd64
The last time I updated was probably 2-3 months ago.
Anyway, when I went to updated packages (also following current/snapshots),
I got a number of "forward dependencies - don't match" notices and the
packages don't update.
For example:
gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies:
| Dependencies of php-apache-7.1.27p0 on gettext-* don't match
| Dependencies of gnupg-1.4.23p1 on gettext-* don't match
| Dependencies of glib2-2.58.3p8 on gettext-* don't match
| Dependencies of courier-imap-4.18.2p0 on gettext-* don't match
| Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match
| Dependencies of libgpg-error-1.36 on gettext-* don't match
| Dependencies of python-3.6.8p0 on gettext-* don't match
| Dependencies of samba-4.8.9 on gettext-* don't match
| Dependencies of gdbm-1.16 on gettext-* don't match
| Dependencies of popt-1.16p1 on gettext-* don't match
| Dependencies of aspell-0.60.6.1p8 on gettext-* don't match
| Dependencies of libpsl-0.20.2 on gettext-* don't match
| Dependencies of wget-1.20.2 on gettext-* don't match
| Dependencies of php-7.1.27 on gettext-* don't match
| Dependencies of libidn-1.35 on gettext-* don't match
| Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match
| Dependencies of python-2.7.16 on gettext-* don't match
| Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match
| Dependencies of fetchmail-6.3.26p2 on gettext-* don't match
| Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match
| Dependencies of p11-kit-0.23.15p0 on gettext-* don't match
When I check:
# pkg_info | grep gettext
gettext-0.19.8.1p3 GNU gettext runtime libraries and programs
And the mirror shows:
gettext-runtime-0.20.1p0.tgz
Or (another example), with similar notices about forward dependencies not
matching:
# pkg_info | grep php-7
php-7.1.27 server-side HTML-embedded scripting language
And the mirror shows:
php-7.1.32.tgz
I see that I can "force" the update with "pkg_add -u -D updatedepends".
It seems like this should be safe to do, but it's not something I have done
before.
While my system isn't "production" for a large multi-national, I do use it
as a file server and stuff, and it is working right now, and I don't want to
make it not work.
So, before I did this, I was wondering if there was anything I should
consider/do to address this issue, other than just "forcing" the update?
I guess, when at its core, I don't really completely understand what the
notice means, and how and why it happened.
Thanks
Ted
Re: New/Replacement: Kicad 5.1.4
On Wed, Oct 02, 2019 at 09:29:47PM +0100, Stuart Henderson wrote:
> On 2019/10/02 18:02, Stuart Henderson wrote:
> Build finished. It also needs LIB_DEPENDS = ${MODTK_LIB_DEPENDS} to have
> a LIB_DEPENDS path to the entries in WANTLIB... but something gets confused
> about Tcl/Tk versions if you have both 8.5 and 8.6 installed:
Added
>
> oce-0.18.3(cad/oce):
> Missing lib: tcl86.1 (/usr/local/lib/oce-0.18/libTKXSDRAW.so.0.0) (NOT REACHABLE)
> Extra: tcl85.1
>
> i.e. it depends on tcl86 and tk85 which is definitely wrong, looking in
> CMakeCache.txt:
>
> TCL_INCLUDE_PATH:PATH=/usr/local/include/tcl8.5
> TCL_LIBRARY:FILEPATH=/usr/local/lib/libtcl86.so.1.8
> TCL_TCLSH:FILEPATH=/usr/local/bin/tclsh8.5
> TK_INCLUDE_PATH:PATH=/usr/local/include/tk8.5
> TK_LIBRARY:FILEPATH=/usr/local/lib/libtk85.so.0.19
> TK_WISH:FILEPATH=/usr/local/bin/wish8.5
> FIND_PACKAGE_MESSAGE_DETAILS_TCL:INTERNAL=[/usr/local/lib/libtcl86.so.1.8][/usr/local/include/tcl8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_TCLTK:INTERNAL=[/usr/local/lib/libtcl86.so.1.8][/usr/local/include/tcl8.5][/usr/local/lib/libtk85.so.0.19][/usr/local/include/tk8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_TK:INTERNAL=[/usr/local/lib/libtk85.so.0.19][/usr/local/include/tk8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_Tclsh:INTERNAL=[/usr/local/bin/tclsh8.5][v8.5()]
>
> we can see that it also uses the 8.6 library but 8.5 headers, so doubly
> wrong :)
>
> I think this must be coming from cmake's FindTCL module, I'm not
> sure how to repair it at the moment.
I think I've found a simple solution in another port. Adding
MODTK_VERSION = 8.6 appears to make cmake happy, and everything points
to 8.6 in CMakeCache.txt.
I'll start a build tomorrow with the attached updated port and report
back.
Tracey
--
Tracey Emery
> On 2019/10/02 18:02, Stuart Henderson wrote:
> Build finished. It also needs LIB_DEPENDS = ${MODTK_LIB_DEPENDS} to have
> a LIB_DEPENDS path to the entries in WANTLIB... but something gets confused
> about Tcl/Tk versions if you have both 8.5 and 8.6 installed:
Added
>
> oce-0.18.3(cad/oce):
> Missing lib: tcl86.1 (/usr/local/lib/oce-0.18/libTKXSDRAW.so.0.0) (NOT REACHABLE)
> Extra: tcl85.1
>
> i.e. it depends on tcl86 and tk85 which is definitely wrong, looking in
> CMakeCache.txt:
>
> TCL_INCLUDE_PATH:PATH=/usr/local/include/tcl8.5
> TCL_LIBRARY:FILEPATH=/usr/local/lib/libtcl86.so.1.8
> TCL_TCLSH:FILEPATH=/usr/local/bin/tclsh8.5
> TK_INCLUDE_PATH:PATH=/usr/local/include/tk8.5
> TK_LIBRARY:FILEPATH=/usr/local/lib/libtk85.so.0.19
> TK_WISH:FILEPATH=/usr/local/bin/wish8.5
> FIND_PACKAGE_MESSAGE_DETAILS_TCL:INTERNAL=[/usr/local/lib/libtcl86.so.1.8][/usr/local/include/tcl8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_TCLTK:INTERNAL=[/usr/local/lib/libtcl86.so.1.8][/usr/local/include/tcl8.5][/usr/local/lib/libtk85.so.0.19][/usr/local/include/tk8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_TK:INTERNAL=[/usr/local/lib/libtk85.so.0.19][/usr/local/include/tk8.5][v()]
> FIND_PACKAGE_MESSAGE_DETAILS_Tclsh:INTERNAL=[/usr/local/bin/tclsh8.5][v8.5()]
>
> we can see that it also uses the 8.6 library but 8.5 headers, so doubly
> wrong :)
>
> I think this must be coming from cmake's FindTCL module, I'm not
> sure how to repair it at the moment.
I think I've found a simple solution in another port. Adding
MODTK_VERSION = 8.6 appears to make cmake happy, and everything points
to 8.6 in CMakeCache.txt.
I'll start a build tomorrow with the attached updated port and report
back.
Tracey
--
Tracey Emery
Re: [NEW] security/yubico/yubikey-manager
On 2019/10/31 21:09, Klemens Nanni wrote:
> I know the usual way for Python libs is to provide flavours, but since
> this port depends on the unflavoured security/pcsc-lite which depends on
> Python 3 itself, this port's py2 flavour will also install Python 3.
Additionally 1) it's really billed as just the tool rather than the python
module, and 2) the flavour setup was wrong for multi-version anyway, it would
have needed to install the ykman script under a different filename for one of
the versions, and use a py- prefix.
> Point being: Python 3's going to be there anyway, so let's drop the
> Python 2 flavour - it ought to be deprecated anyway.
Yes I agree. Diff below does that, fixes some whitespace, sorts RUN_DEPENDS,
moves ykpers to LIB_DEPENDS+WANTLIB (it's not just a build dep, it's also
dlopen'd at runtime) and adds a bit more to DESCR from upstream's page.
Untested, as kn@ says it also needs pyscard.
diff --git Makefile Makefile
index 9199104..d068663 100644
--- Makefile
+++ Makefile
@@ -1,29 +1,32 @@
# $OpenBSD: Makefile.template,v 1.85 2019/09/09 19:19:05 kmos Exp $
-COMMENT = library and command line tool for configuring a YubiKey
+COMMENT = library and CLI tool (ykman) for configuring a YubiKey
MODPY_EGG_VERSION = 3.1.0
DISTNAME = yubikey-manager-${MODPY_EGG_VERSION}
-YK_PROJECT = yubikey-manager
+YK_PROJECT = yubikey-manager
CATEGORIES = sysutils
-FLAVORS = python3
-FLAVOR ?=
+MODULES = lang/python
+MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
MODPY_SETUPTOOLS = Yes
-MODULES = lang/python
-BUILD_DEPENDS = devel/swig \
- security/yubico/yubikey-personalization
-RUN_DEPENDS = security/py-fido2${MODPY_FLAVOR} \
- security/py-openssl${MODPY_FLAVOR} \
- devel/py-click${MODPY_FLAVOR} \
- devel/pyusb${MODPY_FLAVOR} \
+WANTLIB += ykpers-1 # dlopen()'d
+
+BUILD_DEPENDS = devel/swig
+LIB_DEPENDS = security/yubico/yubikey-personalization
+RUN_DEPENDS = devel/py-click${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR} \
+ devel/pyusb${MODPY_FLAVOR} \
+ security/pcsc-lite \
security/py-cryptography${MODPY_FLAVOR} \
- security/pcsc-lite
+ security/py-fido2${MODPY_FLAVOR} \
+ security/py-openssl${MODPY_FLAVOR}
+# XXX pyscard
+
TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR}
.include <bsd.port.mk>
diff --git pkg/DESCR pkg/DESCR
index 851a710..892a044 100644
--- pkg/DESCR
+++ pkg/DESCR
@@ -1 +1,5 @@
-Python library and command line tool for configuring a YubiKey
+The YubiKey Manager can configure FIDO2, OTP and PIV functionality on
+a YubiKey. It works with any currently supported YubiKey. You can also
+use the tool to check the type and firmware of a YubiKey. In addition,
+you can use the extended settings to specify other features, such as to
+configure 3-second long touch.
> I know the usual way for Python libs is to provide flavours, but since
> this port depends on the unflavoured security/pcsc-lite which depends on
> Python 3 itself, this port's py2 flavour will also install Python 3.
Additionally 1) it's really billed as just the tool rather than the python
module, and 2) the flavour setup was wrong for multi-version anyway, it would
have needed to install the ykman script under a different filename for one of
the versions, and use a py- prefix.
> Point being: Python 3's going to be there anyway, so let's drop the
> Python 2 flavour - it ought to be deprecated anyway.
Yes I agree. Diff below does that, fixes some whitespace, sorts RUN_DEPENDS,
moves ykpers to LIB_DEPENDS+WANTLIB (it's not just a build dep, it's also
dlopen'd at runtime) and adds a bit more to DESCR from upstream's page.
Untested, as kn@ says it also needs pyscard.
diff --git Makefile Makefile
index 9199104..d068663 100644
--- Makefile
+++ Makefile
@@ -1,29 +1,32 @@
# $OpenBSD: Makefile.template,v 1.85 2019/09/09 19:19:05 kmos Exp $
-COMMENT = library and command line tool for configuring a YubiKey
+COMMENT = library and CLI tool (ykman) for configuring a YubiKey
MODPY_EGG_VERSION = 3.1.0
DISTNAME = yubikey-manager-${MODPY_EGG_VERSION}
-YK_PROJECT = yubikey-manager
+YK_PROJECT = yubikey-manager
CATEGORIES = sysutils
-FLAVORS = python3
-FLAVOR ?=
+MODULES = lang/python
+MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
MODPY_SETUPTOOLS = Yes
-MODULES = lang/python
-BUILD_DEPENDS = devel/swig \
- security/yubico/yubikey-personalization
-RUN_DEPENDS = security/py-fido2${MODPY_FLAVOR} \
- security/py-openssl${MODPY_FLAVOR} \
- devel/py-click${MODPY_FLAVOR} \
- devel/pyusb${MODPY_FLAVOR} \
+WANTLIB += ykpers-1 # dlopen()'d
+
+BUILD_DEPENDS = devel/swig
+LIB_DEPENDS = security/yubico/yubikey-personalization
+RUN_DEPENDS = devel/py-click${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR} \
+ devel/pyusb${MODPY_FLAVOR} \
+ security/pcsc-lite \
security/py-cryptography${MODPY_FLAVOR} \
- security/pcsc-lite
+ security/py-fido2${MODPY_FLAVOR} \
+ security/py-openssl${MODPY_FLAVOR}
+# XXX pyscard
+
TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR}
.include <bsd.port.mk>
diff --git pkg/DESCR pkg/DESCR
index 851a710..892a044 100644
--- pkg/DESCR
+++ pkg/DESCR
@@ -1 +1,5 @@
-Python library and command line tool for configuring a YubiKey
+The YubiKey Manager can configure FIDO2, OTP and PIV functionality on
+a YubiKey. It works with any currently supported YubiKey. You can also
+use the tool to check the type and firmware of a YubiKey. In addition,
+you can use the extended settings to specify other features, such as to
+configure 3-second long touch.
Re: [NEW] security/yubico/yubikey-manager
On Sun, Oct 27, 2019 at 04:26:51PM -0500, Lucas Raab wrote:
> Updated version attached with forgotten deps
I installed the python 3 flavour (after installing py3-fido2 from kmos's
latest tarball):
$ ykman
Traceback (most recent call last):
File "/usr/local/bin/ykman", line 6, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3241, in <module>
@_call_aside
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3225, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3254, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 583, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 900, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 786, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyscard' distribution was not found and is required by yubikey-manager
> Updated version attached with forgotten deps
I installed the python 3 flavour (after installing py3-fido2 from kmos's
latest tarball):
$ ykman
Traceback (most recent call last):
File "/usr/local/bin/ykman", line 6, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3241, in <module>
@_call_aside
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3225, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3254, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 583, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 900, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 786, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyscard' distribution was not found and is required by yubikey-manager
Re: gdb: Use Python 3
On 2019/10/31 18:18, Klemens Nanni wrote:
> On Tue, Oct 22, 2019 at 10:14:11PM +0200, Klemens Nanni wrote:
> > Another step in deprecating Python 2; our 7.12.1 requires an upstream
> > commit contained in at least 8.1.50 since gdb uses a private Python API.
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=23252
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=aeab512851bf6ed623d1c6c4305b6ce05e51a10c
> >
> > I've been running with this for a while in regular usage, but would be
> > happy to see wider testing.
> >
> > Feedback?
> Diff below now actually contains the patch, so I guess noone tried it yet.
>
> I want to get rid of Python 2 and GDB has been behaving well with this
> diff so far, so I'd like to commit this soon eventually.
Sounds like they are few enough people using python support in our gdb
that it doesn't really matter if it gets broken :) I think it makes sense
to commit this to increase the chance of it getting tested.
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/gdb/Makefile,v
> retrieving revision 1.62
> diff -u -p -r1.62 Makefile
> --- Makefile 17 Oct 2019 17:10:26 -0000 1.62
> +++ Makefile 22 Oct 2019 19:55:27 -0000
> @@ -4,7 +4,7 @@ COMMENT= GNU debugger
> CATEGORIES= devel
>
> DISTNAME= gdb-7.12.1
> -REVISION= 8
> +REVISION= 9
>
> HOMEPAGE= https://www.gnu.org/software/gdb/
>
> @@ -35,6 +35,8 @@ CONFIGURE_ARGS= --program-prefix=e \
> USE_GMAKE= Yes
>
> MODULES += lang/python
> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> +
> LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
> TEST_DEPENDS += devel/dejagnu
> MODPY_BUILDDEP = No
> Index: patches/patch-gdb_python_python_c
> ===================================================================
> RCS file: patches/patch-gdb_python_python_c
> diff -N patches/patch-gdb_python_python_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-gdb_python_python_c 22 Oct 2019 19:35:10 -0000
> @@ -0,0 +1,47 @@
> +$OpenBSD$
> +
> +"Fix build issue with Python 3.7"; git: aeab512851bf6ed623d1c6c4305b6ce05e51a10c
> +
> +Index: gdb/python/python.c
> +--- gdb/python/python.c.orig
> ++++ gdb/python/python.c
> +@@ -1622,7 +1622,18 @@ finalize_python (void *ignore)
> +
> + restore_active_ext_lang (previous_active);
> + }
> ++
> ++#ifdef IS_PY3K
> ++/* This is called via the PyImport_AppendInittab mechanism called
> ++ during initialization, to make the built-in _gdb module known to
> ++ Python. */
> ++PyMODINIT_FUNC
> ++init__gdb_module (void)
> ++{
> ++ return PyModule_Create (&python_GdbModuleDef);
> ++}
> +
> On Tue, Oct 22, 2019 at 10:14:11PM +0200, Klemens Nanni wrote:
> > Another step in deprecating Python 2; our 7.12.1 requires an upstream
> > commit contained in at least 8.1.50 since gdb uses a private Python API.
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=23252
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=aeab512851bf6ed623d1c6c4305b6ce05e51a10c
> >
> > I've been running with this for a while in regular usage, but would be
> > happy to see wider testing.
> >
> > Feedback?
> Diff below now actually contains the patch, so I guess noone tried it yet.
>
> I want to get rid of Python 2 and GDB has been behaving well with this
> diff so far, so I'd like to commit this soon eventually.
Sounds like they are few enough people using python support in our gdb
that it doesn't really matter if it gets broken :) I think it makes sense
to commit this to increase the chance of it getting tested.
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/gdb/Makefile,v
> retrieving revision 1.62
> diff -u -p -r1.62 Makefile
> --- Makefile 17 Oct 2019 17:10:26 -0000 1.62
> +++ Makefile 22 Oct 2019 19:55:27 -0000
> @@ -4,7 +4,7 @@ COMMENT= GNU debugger
> CATEGORIES= devel
>
> DISTNAME= gdb-7.12.1
> -REVISION= 8
> +REVISION= 9
>
> HOMEPAGE= https://www.gnu.org/software/gdb/
>
> @@ -35,6 +35,8 @@ CONFIGURE_ARGS= --program-prefix=e \
> USE_GMAKE= Yes
>
> MODULES += lang/python
> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> +
> LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
> TEST_DEPENDS += devel/dejagnu
> MODPY_BUILDDEP = No
> Index: patches/patch-gdb_python_python_c
> ===================================================================
> RCS file: patches/patch-gdb_python_python_c
> diff -N patches/patch-gdb_python_python_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-gdb_python_python_c 22 Oct 2019 19:35:10 -0000
> @@ -0,0 +1,47 @@
> +$OpenBSD$
> +
> +"Fix build issue with Python 3.7"; git: aeab512851bf6ed623d1c6c4305b6ce05e51a10c
> +
> +Index: gdb/python/python.c
> +--- gdb/python/python.c.orig
> ++++ gdb/python/python.c
> +@@ -1622,7 +1622,18 @@ finalize_python (void *ignore)
> +
> + restore_active_ext_lang (previous_active);
> + }
> ++
> ++#ifdef IS_PY3K
> ++/* This is called via the PyImport_AppendInittab mechanism called
> ++ during initialization, to make the built-in _gdb module known to
> ++ Python. */
> ++PyMODINIT_FUNC
> ++init__gdb_module (void)
> ++{
> ++ return PyModule_Create (&python_GdbModuleDef);
> ++}
> +
Re: [NEW] security/py-fido2
On Sun, Oct 27, 2019 at 04:37:42PM -0400, Kurt Mosiejczuk wrote:
> With these changes, OK kmos@
Looks good, a few things:
Not sure how this library fits into sysutils as secondary category,
devel would fit after security, though.
setup.py lists
61 extras_require={':python_version < "3.4"': ["enum34"], "pcsc": ["pyscard"]},
That's still unaccounted for.
DESCR could contain more from ${WRKSRC}/README.adoc though.
Besides BSD, this port ships code under APL 2.0 and MPL 2.0 as well, see
the readme file.
Perhaps the example files are worth shipping as well?
OK kn with the py-enum34 dependency fixed, the rest I'll leave to
whoever commits (and maintains) this port - they're mere impressions
after a quick look.
> With these changes, OK kmos@
Looks good, a few things:
Not sure how this library fits into sysutils as secondary category,
devel would fit after security, though.
setup.py lists
61 extras_require={':python_version < "3.4"': ["enum34"], "pcsc": ["pyscard"]},
That's still unaccounted for.
DESCR could contain more from ${WRKSRC}/README.adoc though.
Besides BSD, this port ships code under APL 2.0 and MPL 2.0 as well, see
the readme file.
Perhaps the example files are worth shipping as well?
OK kn with the py-enum34 dependency fixed, the rest I'll leave to
whoever commits (and maintains) this port - they're mere impressions
after a quick look.
Re: Build libngspice from cad/ngspice
Works for me. Tests pass for ngspice.
On Wed, Oct 30, 2019 at 01:15:05AM -0600, Anthony J. Bentley wrote:
> Hi,
>
> Divorcing this from the KiCad thread.
>
> I've attached a new revision of the cad/ngspice -> cad/ngspice/{,lib}ngspice
> port. This one fixes "make test" within ngspice. I didn't bother
> doing the same for libngspice, because the test suite assumes you're
> building a binary and not a library, and fixing that is not worth it.
>
> ok?
>
> --
> Anthony J. Bentley
--
Tracey Emery
On Wed, Oct 30, 2019 at 01:15:05AM -0600, Anthony J. Bentley wrote:
> Hi,
>
> Divorcing this from the KiCad thread.
>
> I've attached a new revision of the cad/ngspice -> cad/ngspice/{,lib}ngspice
> port. This one fixes "make test" within ngspice. I didn't bother
> doing the same for libngspice, because the test suite assumes you're
> building a binary and not a library, and fixing that is not worth it.
>
> ok?
>
> --
> Anthony J. Bentley
--
Tracey Emery
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 10:56:38AM -0700, Mike Larkin wrote:
> On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote:
> > Hi, All:
> >
> > I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> > and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> > doesn't in 6.6.
> >
> > What is the best way for me to go about debugging this issue? So far,
> > I have checked:
> > - dmesg for ACPI wake devices
> > - syslog for suspend messages
> >
> > Specifically, the suspend works; however, when I attempt to wake the
> > device, the laptop seems to respond and attempt to wake, but the
> > display never turns on, and I cannot SSH into the machine. Below are
> > the dmesg and relevant syslog entries.
> >
>
> About a year or so ago I posted a message to either misc@ or tech@ about
> how to diagnose suspend/resume failures, by bisecting the resume path and
> placing resets or spins at various places to see how far the resume gets
> before dying. I would recommend finding that post (I just looked and I
> couldn't find it though) and walking through those steps.
Possibly this one?
https://marc.info/?l=openbsd-bugs&m=152536221312302&w=2
>
> I doubt any of us still have machines that old to try debugging this
> ourselves, the machine is nearly 15 years old.
>
> -ml
>
> > dmesg
> > =====
> >
> > OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> > root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
[cut]
> On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote:
> > Hi, All:
> >
> > I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> > and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> > doesn't in 6.6.
> >
> > What is the best way for me to go about debugging this issue? So far,
> > I have checked:
> > - dmesg for ACPI wake devices
> > - syslog for suspend messages
> >
> > Specifically, the suspend works; however, when I attempt to wake the
> > device, the laptop seems to respond and attempt to wake, but the
> > display never turns on, and I cannot SSH into the machine. Below are
> > the dmesg and relevant syslog entries.
> >
>
> About a year or so ago I posted a message to either misc@ or tech@ about
> how to diagnose suspend/resume failures, by bisecting the resume path and
> placing resets or spins at various places to see how far the resume gets
> before dying. I would recommend finding that post (I just looked and I
> couldn't find it though) and walking through those steps.
Possibly this one?
https://marc.info/?l=openbsd-bugs&m=152536221312302&w=2
>
> I doubt any of us still have machines that old to try debugging this
> ourselves, the machine is nearly 15 years old.
>
> -ml
>
> > dmesg
> > =====
> >
> > OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> > root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
[cut]
Re: [NEW] security/yubico/yubikey-manager
I know the usual way for Python libs is to provide flavours, but since
this port depends on the unflavoured security/pcsc-lite which depends on
Python 3 itself, this port's py2 flavour will also install Python 3.
Point being: Python 3's going to be there anyway, so let's drop the
Python 2 flavour - it ought to be deprecated anyway.
this port depends on the unflavoured security/pcsc-lite which depends on
Python 3 itself, this port's py2 flavour will also install Python 3.
Point being: Python 3's going to be there anyway, so let's drop the
Python 2 flavour - it ought to be deprecated anyway.
Re: update net/dnscrypt-proxy 2.0.30
net/dnscrypt-proxy 2.0.31 was just released to fix two regressions on
October 31, 2019. The diff is pasted below.
https://github.com/DNSCrypt/dnscrypt-proxy/releases/tag/2.0.31
"This version fixes two regressions introduced in version 2.0.29: DoH
server couldn't be reached over IPv6 any more, and the proxy couldn't be
interrupted while servers were being benchmarked."
Steps to reproduce the latter regression in 2.0.30:
1. Make sure server_names is commented out in /etc/dnscrypt-proxy.toml
# server_names = ['scaleway-fr' ...]
2. enable logging to /var/log/messages
log_level = 2
use_syslog = true
3. start dnscrypt-proxy
# /etc/rc.d/dnscrypt-proxy restart
4. as /var/log/messages prints out pings to various servers:
Oct 31 12:34:55 dust2 dnscrypt-proxy[29789]: [cs-usil] OK (DNSCrypt) - rtt: 78ms
Oct 31 12:35:00 dust2 dnscrypt-proxy[29789]: [cs-nl2] OK (DNSCrypt) - rtt: 155ms
Attempt to restart dnscrypt-proxy
# /etc/rc.d/dnscrypt-proxy restart
5. it prints and gets stuck on: "dnscrypt-proxy" instead of
"dnscrypt-proxy(OK) dnscrypt-proxy(OK)"
With 2.0.31 it restarts reliably while pinging to various servers. I had
noticed this in 2.0.30 but did not investigate further. Sorry for not
noting it in my test report. I successfully tested on amd64.
Feedback and tests are welcome.
Nam Nguyen writes:
> Nam Nguyen writes:
>
>> The main addition in 2.0.29 is anonymized DNS. "Routes are indirect ways
>> to reach DNSCrypt servers. A route maps a server name ("server_name") to
>> one or more relays that will be used to connect to that server."
>>
>> /var/dnscrypt-proxy/relays.md is now added to the port and is
>> populated after an initial run of dnscrypt-proxy.
>>
>> In /etc/dnscrypt-proxy.toml, I have the following:
>>
>> server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare']
>>
>> routes = [
>> { server_name='google', via=['anon-kama', 'anon-scaleway'] },
>> { server_name='cloudflare', via=['anon-kama', 'anon-scaleway'] },
>> ]
>>
>> However, I am not sure how to actually confirm that the anonymous DNS
>> relays are used. If I enable query logging:
>>
>> [query_log]
>> file = '/var/dnscrypt-proxy/query.log'
>>
>> $ touch /var/dnscrypt-proxy/query.log
>> $ chown _dnscrypt-proxy /var/dnscrypt-proxy/query.log
>>
>> I see logged queries of the form:
>>
>> [2019-10-30 17:57:02] 127.0.0.1 openbsd.org A PASS 59ms cloudflare
>>
>> with no mention of the anonymous DNS relay used. It seems that logging
>> the relay used is not yet implemented. Overall, I tested 2.0.30 on amd64
>> and it works, unbreaking 2.0.29.
>
> Correction: logging with the relay used is actually implemented.
>
> After someone told me I could use tcpdump, I was able to investigate
> this further.
>
> /var/dnscrypt-proxy/query.log:
> [2019-10-30 18:57:03] 127.0.0.1 104.238.153.46.vultr.com A PASS 225ms scaleway-fr
> [2019-10-30 18:57:03] 127.0.0.1 104.238.153.46.vultr.com.my.domain A NXDOMAIN 180ms scaleway-fr
>
> /etc/dnscrypt-proxy.toml:
> server_names = ['scaleway-fr']
>
> routes = [
> { server_name='scaleway-fr', via=['anon-inconnu'] },
> ]
>
> scaleway-fr is in France. anon-inconnu, the relay, is in Seattle, WA.
>
> With routes turned off, I was using scaleway-fr.
> # tcpdump -i re0
> 18:43:36.615199 192.168.1.5.18818 > scaleway-fr.dnscrypt.info.443: udp 512
>
> With routes turned on, I was instead using anon-inconnu.
> # tcpdump -i re0
> 18:59:00.926864 192.168.1.5.10477 > 104.238.153.46.vultr.com.443: udp 540
> 18:59:01.096732 104.238.153.46.vultr.com.443 > 192.168.1.5.10477: udp 304 [tos 0x20]
>
> Finally, there is no DNS over HTTPS (DoH) relay yet
> (https://github.com/DNSCrypt/dnscrypt-proxy/issues/993). This explains
> the behavior in my original e-mail. Google and Cloudflare are DoH
> servers, and tcpdump revealed that queries were sent directly to them.
>
> # Use servers implementing the DNSCrypt protocol
> dnscrypt_servers = true
>
> # Use servers implementing the DNS-over-HTTPS protocol
> doh_servers = false
>
> Anonymized DNS does not work with DoH servers and works with DNSCrypt
> servers.
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/Makefile,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 Makefile
--- Makefile 15 Oct 2019 04:18:20 -0000 1.45
+++ Makefile 31 Oct 2019 19:50:28 -0000
@@ -4,7 +4,7 @@ COMMENT = flexible DNS proxy with suppor
GH_ACCOUNT = jedisct1
GH_PROJECT = dnscrypt-proxy
-GH_TAGNAME = 2.0.28
+GH_TAGNAME = 2.0.31
CATEGORIES = net
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/distinfo,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 distinfo
--- distinfo 15 Oct 2019 04:18:20 -0000 1.21
+++ distinfo 31 Oct 2019 19:50:28 -0000
@@ -1,2 +1,2 @@
-SHA256 (dnscrypt-proxy-2.0.28.tar.gz) = K6KDQ97RUjPGnCNTzOFZqyrU5+troBjK9JXh5dMz2G0=
-SIZE (dnscrypt-proxy-2.0.28.tar.gz) = 2620245
+SHA256 (dnscrypt-proxy-2.0.31.tar.gz) = tdF65WhW5Xl7WdhivMsDj/iRrAvxWVNOmpN7DwzDV3c=
+SIZE (dnscrypt-proxy-2.0.31.tar.gz) = 2640523
Index: patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
--- patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml 15 Oct 2019 04:18:20 -0000 1.6
+++ patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml 31 Oct 2019 19:50:28 -0000
@@ -12,7 +12,7 @@ Index: dnscrypt-proxy/example-dnscrypt-p
## Require servers (from static + remote sources) to satisfy specific properties
-@@ -525,7 +525,7 @@ cache_neg_max_ttl = 600
+@@ -537,7 +537,7 @@ cache_neg_max_ttl = 600
[sources.'public-resolvers']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md']
@@ -21,3 +21,12 @@ Index: dnscrypt-proxy/example-dnscrypt-p
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
prefix = ''
+@@ -545,7 +545,7 @@ cache_neg_max_ttl = 600
+
+ [sources.'relays']
+ urls = ['https://github.com/DNSCrypt/dnscrypt-resolvers/raw/master/v2/relays.md', 'https://download.dnscrypt.info/resolvers-list/v2/relays.md']
+- cache_file = 'relays.md'
++ cache_file = '${LOCALSTATEDIR}/dnscrypt-proxy/relays.md'
+ minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
+ refresh_delay = 72
+ prefix = ''
October 31, 2019. The diff is pasted below.
https://github.com/DNSCrypt/dnscrypt-proxy/releases/tag/2.0.31
"This version fixes two regressions introduced in version 2.0.29: DoH
server couldn't be reached over IPv6 any more, and the proxy couldn't be
interrupted while servers were being benchmarked."
Steps to reproduce the latter regression in 2.0.30:
1. Make sure server_names is commented out in /etc/dnscrypt-proxy.toml
# server_names = ['scaleway-fr' ...]
2. enable logging to /var/log/messages
log_level = 2
use_syslog = true
3. start dnscrypt-proxy
# /etc/rc.d/dnscrypt-proxy restart
4. as /var/log/messages prints out pings to various servers:
Oct 31 12:34:55 dust2 dnscrypt-proxy[29789]: [cs-usil] OK (DNSCrypt) - rtt: 78ms
Oct 31 12:35:00 dust2 dnscrypt-proxy[29789]: [cs-nl2] OK (DNSCrypt) - rtt: 155ms
Attempt to restart dnscrypt-proxy
# /etc/rc.d/dnscrypt-proxy restart
5. it prints and gets stuck on: "dnscrypt-proxy" instead of
"dnscrypt-proxy(OK) dnscrypt-proxy(OK)"
With 2.0.31 it restarts reliably while pinging to various servers. I had
noticed this in 2.0.30 but did not investigate further. Sorry for not
noting it in my test report. I successfully tested on amd64.
Feedback and tests are welcome.
Nam Nguyen writes:
> Nam Nguyen writes:
>
>> The main addition in 2.0.29 is anonymized DNS. "Routes are indirect ways
>> to reach DNSCrypt servers. A route maps a server name ("server_name") to
>> one or more relays that will be used to connect to that server."
>>
>> /var/dnscrypt-proxy/relays.md is now added to the port and is
>> populated after an initial run of dnscrypt-proxy.
>>
>> In /etc/dnscrypt-proxy.toml, I have the following:
>>
>> server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare']
>>
>> routes = [
>> { server_name='google', via=['anon-kama', 'anon-scaleway'] },
>> { server_name='cloudflare', via=['anon-kama', 'anon-scaleway'] },
>> ]
>>
>> However, I am not sure how to actually confirm that the anonymous DNS
>> relays are used. If I enable query logging:
>>
>> [query_log]
>> file = '/var/dnscrypt-proxy/query.log'
>>
>> $ touch /var/dnscrypt-proxy/query.log
>> $ chown _dnscrypt-proxy /var/dnscrypt-proxy/query.log
>>
>> I see logged queries of the form:
>>
>> [2019-10-30 17:57:02] 127.0.0.1 openbsd.org A PASS 59ms cloudflare
>>
>> with no mention of the anonymous DNS relay used. It seems that logging
>> the relay used is not yet implemented. Overall, I tested 2.0.30 on amd64
>> and it works, unbreaking 2.0.29.
>
> Correction: logging with the relay used is actually implemented.
>
> After someone told me I could use tcpdump, I was able to investigate
> this further.
>
> /var/dnscrypt-proxy/query.log:
> [2019-10-30 18:57:03] 127.0.0.1 104.238.153.46.vultr.com A PASS 225ms scaleway-fr
> [2019-10-30 18:57:03] 127.0.0.1 104.238.153.46.vultr.com.my.domain A NXDOMAIN 180ms scaleway-fr
>
> /etc/dnscrypt-proxy.toml:
> server_names = ['scaleway-fr']
>
> routes = [
> { server_name='scaleway-fr', via=['anon-inconnu'] },
> ]
>
> scaleway-fr is in France. anon-inconnu, the relay, is in Seattle, WA.
>
> With routes turned off, I was using scaleway-fr.
> # tcpdump -i re0
> 18:43:36.615199 192.168.1.5.18818 > scaleway-fr.dnscrypt.info.443: udp 512
>
> With routes turned on, I was instead using anon-inconnu.
> # tcpdump -i re0
> 18:59:00.926864 192.168.1.5.10477 > 104.238.153.46.vultr.com.443: udp 540
> 18:59:01.096732 104.238.153.46.vultr.com.443 > 192.168.1.5.10477: udp 304 [tos 0x20]
>
> Finally, there is no DNS over HTTPS (DoH) relay yet
> (https://github.com/DNSCrypt/dnscrypt-proxy/issues/993). This explains
> the behavior in my original e-mail. Google and Cloudflare are DoH
> servers, and tcpdump revealed that queries were sent directly to them.
>
> # Use servers implementing the DNSCrypt protocol
> dnscrypt_servers = true
>
> # Use servers implementing the DNS-over-HTTPS protocol
> doh_servers = false
>
> Anonymized DNS does not work with DoH servers and works with DNSCrypt
> servers.
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/Makefile,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 Makefile
--- Makefile 15 Oct 2019 04:18:20 -0000 1.45
+++ Makefile 31 Oct 2019 19:50:28 -0000
@@ -4,7 +4,7 @@ COMMENT = flexible DNS proxy with suppor
GH_ACCOUNT = jedisct1
GH_PROJECT = dnscrypt-proxy
-GH_TAGNAME = 2.0.28
+GH_TAGNAME = 2.0.31
CATEGORIES = net
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/distinfo,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 distinfo
--- distinfo 15 Oct 2019 04:18:20 -0000 1.21
+++ distinfo 31 Oct 2019 19:50:28 -0000
@@ -1,2 +1,2 @@
-SHA256 (dnscrypt-proxy-2.0.28.tar.gz) = K6KDQ97RUjPGnCNTzOFZqyrU5+troBjK9JXh5dMz2G0=
-SIZE (dnscrypt-proxy-2.0.28.tar.gz) = 2620245
+SHA256 (dnscrypt-proxy-2.0.31.tar.gz) = tdF65WhW5Xl7WdhivMsDj/iRrAvxWVNOmpN7DwzDV3c=
+SIZE (dnscrypt-proxy-2.0.31.tar.gz) = 2640523
Index: patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
===================================================================
RCS file: /cvs/ports/net/dnscrypt-proxy/patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
--- patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml 15 Oct 2019 04:18:20 -0000 1.6
+++ patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml 31 Oct 2019 19:50:28 -0000
@@ -12,7 +12,7 @@ Index: dnscrypt-proxy/example-dnscrypt-p
## Require servers (from static + remote sources) to satisfy specific properties
-@@ -525,7 +525,7 @@ cache_neg_max_ttl = 600
+@@ -537,7 +537,7 @@ cache_neg_max_ttl = 600
[sources.'public-resolvers']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md']
@@ -21,3 +21,12 @@ Index: dnscrypt-proxy/example-dnscrypt-p
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
prefix = ''
+@@ -545,7 +545,7 @@ cache_neg_max_ttl = 600
+
+ [sources.'relays']
+ urls = ['https://github.com/DNSCrypt/dnscrypt-resolvers/raw/master/v2/relays.md', 'https://download.dnscrypt.info/resolvers-list/v2/relays.md']
+- cache_file = 'relays.md'
++ cache_file = '${LOCALSTATEDIR}/dnscrypt-proxy/relays.md'
+ minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
+ refresh_delay = 72
+ prefix = ''
Re: Are KF5 and KDE4 packages supposed to coexists?
On Fri Oct 25, 2019 at 05:17:26PM +0100, Stuart Henderson wrote:
> On 2019/10/25 17:27, Rafael Sadowski wrote:
> > On Thu Oct 24, 2019 at 09:02:44AM +0200, Federico Giannici wrote:
> > > Hi!
> > >
> > > I'd like to know if KDE4 packages are supposed to coexists with KF5 packages
> > > (OpenBSD amd64 6.6).
> > >
> > > In particular, I'd like to use both gwenview (KF5) and Juk (KDE4), but it
> > > seems that baloo-4.14.3p7 conflicts with kf5-icons-baloo-5.54.0, and
> > > kf5-icons-baloo-5.54.0 conflicts with baloo-4.14.3p7 (see below).
> > >
> > > Is this a known limitation?
> > >
> > > Thanks.
> > >
> > >
> > >
> > > Can't install kf5-icons-baloo-5.54.0 because of conflicts (baloo-4.14.3p7)
> > > Can't install gwenview-18.12.0p1: can't resolve kf5-icons-baloo-5.54.0
> >
> > This is correct, not all KDE4 and KF5 packages can coexists. The biggest
> > challenge here is the fight between baloo-4 and kf5-baloo.
> >
> > I GAVE UP to send new/replacement KDE5 ports to ports@. It doesn't get
> > any attention on the list and it's an impossible mission to get an OK
> > for it!
> >
> > Feel free to take the port from:
> >
> > https://github.com/sizeofvoid/openbsd-kde-wip
> >
> > If you need more ports, don't be shy and just ask. I'd be glad to get
> > feedback on:
> >
> > https://github.com/sizeofvoid/openbsd-kde-wip/tree/master/x11/kde-applications/juk
> >
> > RS
> >
>
> What do you think about just killing all the kde4 ports. This attempt at
> coexistence and a seemingly never-ending trickle of separate ports to
> handle in a piecemeal changeover is a nightmare to review and can't be
> good for you either.
My first thought was: Hell yes please! Second: It doesn't solve my issues.
I'm alone on the OpenBSD KDE ports road. Sure there are some users out
there but not porters. That's okay with me, except it's difficult to
update KDE4 ports by an import which need an OK.
So that doesn't solve my problem. With x11/kde-applications I am
currently updating just top-level applications and not the KDE Desktop
system. I want to go the easy way fist, replacing (more or less) all
KDE4 applications with KDE5 so that the KDE4-Desktop can still exist.
If this path is over and I can't get any further, we can delete it.
>
> Give me a tarball with all the new things that can be unpacked in
> /usr/ports and a diff to disable the kde4 things (don't worry about
> cvs rm's, just unhook from category Makefiles) and I'll look at it in
> bulk. (I need it to be easy to test it though, I won't try to assemble
> a tree by merging things from a git repo etc :)
This is a great offer, thanks in advance.
>
> Compared with GNOME, even with more people working on it, the port
> maintainers don't even try to have versions coexisting, it is just too
> difficult, and there are fewer people working on kde. Maybe some of the
> kf5 things are worse than the kde4 things but we just don't have the
> resources to mix and match and try to keep everything working.
>
> On 2019/10/25 17:27, Rafael Sadowski wrote:
> > On Thu Oct 24, 2019 at 09:02:44AM +0200, Federico Giannici wrote:
> > > Hi!
> > >
> > > I'd like to know if KDE4 packages are supposed to coexists with KF5 packages
> > > (OpenBSD amd64 6.6).
> > >
> > > In particular, I'd like to use both gwenview (KF5) and Juk (KDE4), but it
> > > seems that baloo-4.14.3p7 conflicts with kf5-icons-baloo-5.54.0, and
> > > kf5-icons-baloo-5.54.0 conflicts with baloo-4.14.3p7 (see below).
> > >
> > > Is this a known limitation?
> > >
> > > Thanks.
> > >
> > >
> > >
> > > Can't install kf5-icons-baloo-5.54.0 because of conflicts (baloo-4.14.3p7)
> > > Can't install gwenview-18.12.0p1: can't resolve kf5-icons-baloo-5.54.0
> >
> > This is correct, not all KDE4 and KF5 packages can coexists. The biggest
> > challenge here is the fight between baloo-4 and kf5-baloo.
> >
> > I GAVE UP to send new/replacement KDE5 ports to ports@. It doesn't get
> > any attention on the list and it's an impossible mission to get an OK
> > for it!
> >
> > Feel free to take the port from:
> >
> > https://github.com/sizeofvoid/openbsd-kde-wip
> >
> > If you need more ports, don't be shy and just ask. I'd be glad to get
> > feedback on:
> >
> > https://github.com/sizeofvoid/openbsd-kde-wip/tree/master/x11/kde-applications/juk
> >
> > RS
> >
>
> What do you think about just killing all the kde4 ports. This attempt at
> coexistence and a seemingly never-ending trickle of separate ports to
> handle in a piecemeal changeover is a nightmare to review and can't be
> good for you either.
My first thought was: Hell yes please! Second: It doesn't solve my issues.
I'm alone on the OpenBSD KDE ports road. Sure there are some users out
there but not porters. That's okay with me, except it's difficult to
update KDE4 ports by an import which need an OK.
So that doesn't solve my problem. With x11/kde-applications I am
currently updating just top-level applications and not the KDE Desktop
system. I want to go the easy way fist, replacing (more or less) all
KDE4 applications with KDE5 so that the KDE4-Desktop can still exist.
If this path is over and I can't get any further, we can delete it.
>
> Give me a tarball with all the new things that can be unpacked in
> /usr/ports and a diff to disable the kde4 things (don't worry about
> cvs rm's, just unhook from category Makefiles) and I'll look at it in
> bulk. (I need it to be easy to test it though, I won't try to assemble
> a tree by merging things from a git repo etc :)
This is a great offer, thanks in advance.
>
> Compared with GNOME, even with more people working on it, the port
> maintainers don't even try to have versions coexisting, it is just too
> difficult, and there are fewer people working on kde. Maybe some of the
> kf5 things are worse than the kde4 things but we just don't have the
> resources to mix and match and try to keep everything working.
>
Re: Display flickers after upgrade to 6.6
I can confirm that switching to EXA made GNOME usable. This'll only work up to Northern Islands cards/IGPs though.
Guess I'll be holding off of a GPU upgrade for a while longer.
--
Patrick Harper
paianni@fastmail.com
On Thu, 31 Oct 2019, at 13:47, Patrick Harper wrote:
> I haven't tried those settings yet (in my case GNOME Shell and
> Xfdashboard cause the display to corrupt and seize up except the
> cursor) but ShadowPrimary is a glamor option that should be irrelevant
> if EXA is used.
>
> For years I've also observed text flickering in the console after drm
> is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman
> should be fine with 8 million pixels.
>
> --
> Patrick Harper
> paianni@fastmail.com
>
> On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> > On Sat, 19 Oct 2019 17:59:41 +0200
> > Federico Giannici <giannici@neomedia.it> wrote:
> >
> > > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > > Hi,
> > > >
> > > > I ran into the same issue this morning. Disabling the compositor
> > > > worked for me, but I noticed later that this is also documented in
> > > > the package readme:
> > > >
> > > > Screen compositor
> > > > =================
> > > > If you're using the modesetting X driver and experience window
> > > > flickering when
> > > > the compositor is enabled, you should force the window manager to
> > > > use the XPresent method for vblank:
> > > >
> > > > $xfwm4 --vblank=xpresent --replace &
> > >
> > > I tried that command but it screwed all my windows (no more window
> > > decorations and buttons, I cannot operate on windows)!
> > > Now I had to came back to KDE...
> > > :-(
> > >
> > > Regards
> > >
> > >
> > > > This is documented upstream at
> > > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > > >
> > > > Haven't tested that yet and left the compositor disabled, but I
> > > > guess this will fix your issues. If it does, that's probably a good
> > > > reminder to first look in the readme next time (me included). ;)
> > > >
> > > > Regards,
> > > > André
> > > >
> >
> > Hi, I thought I'd relate my experience: I also experienced this issue on
> > a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> > chipset and also running xfce. My workaround
> > (which was based on 'try stuff to see what works') involved turning off
> > compositing and
> > (via xorg.conf.d):
> >
> > ...
> > Option "AccelMethod" "EXA"
> > Option "ShadowPrimary" "on"
> > Option "SwapbuffersWait" "off"
> > Option "EnablePageFlip" "off"
> > ...
> >
> > This resolved issues with flickering, the mouse pointer vanishing and
> > re-appearing depending on which window is below the pointer (enabling
> > software mouse pointer for this was worse as garbage was rendered in a
> > rect surrounding the pointer), and also *some* issues with logging
> > in-out of an X session via xenodm.
> >
> > I still experience problems with the machine going to sleep and waking
> > up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> > at all, or the mouse pointer goes wonky.
> >
> > Beyond the aforementioned, this set-up seems to allow me to use the
> > machine as before, however, I am not an X11 expert nor a radeondrm
> > driver expert; your mileage may very.
> >
> > If I ever try Andre's hint in the future (thank-you), I might report on
> > success/failure.
> >
> > regards,
> >
> > Jeff
> >
> >
>
>
Guess I'll be holding off of a GPU upgrade for a while longer.
--
Patrick Harper
paianni@fastmail.com
On Thu, 31 Oct 2019, at 13:47, Patrick Harper wrote:
> I haven't tried those settings yet (in my case GNOME Shell and
> Xfdashboard cause the display to corrupt and seize up except the
> cursor) but ShadowPrimary is a glamor option that should be irrelevant
> if EXA is used.
>
> For years I've also observed text flickering in the console after drm
> is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman
> should be fine with 8 million pixels.
>
> --
> Patrick Harper
> paianni@fastmail.com
>
> On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> > On Sat, 19 Oct 2019 17:59:41 +0200
> > Federico Giannici <giannici@neomedia.it> wrote:
> >
> > > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > > Hi,
> > > >
> > > > I ran into the same issue this morning. Disabling the compositor
> > > > worked for me, but I noticed later that this is also documented in
> > > > the package readme:
> > > >
> > > > Screen compositor
> > > > =================
> > > > If you're using the modesetting X driver and experience window
> > > > flickering when
> > > > the compositor is enabled, you should force the window manager to
> > > > use the XPresent method for vblank:
> > > >
> > > > $xfwm4 --vblank=xpresent --replace &
> > >
> > > I tried that command but it screwed all my windows (no more window
> > > decorations and buttons, I cannot operate on windows)!
> > > Now I had to came back to KDE...
> > > :-(
> > >
> > > Regards
> > >
> > >
> > > > This is documented upstream at
> > > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > > >
> > > > Haven't tested that yet and left the compositor disabled, but I
> > > > guess this will fix your issues. If it does, that's probably a good
> > > > reminder to first look in the readme next time (me included). ;)
> > > >
> > > > Regards,
> > > > André
> > > >
> >
> > Hi, I thought I'd relate my experience: I also experienced this issue on
> > a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> > chipset and also running xfce. My workaround
> > (which was based on 'try stuff to see what works') involved turning off
> > compositing and
> > (via xorg.conf.d):
> >
> > ...
> > Option "AccelMethod" "EXA"
> > Option "ShadowPrimary" "on"
> > Option "SwapbuffersWait" "off"
> > Option "EnablePageFlip" "off"
> > ...
> >
> > This resolved issues with flickering, the mouse pointer vanishing and
> > re-appearing depending on which window is below the pointer (enabling
> > software mouse pointer for this was worse as garbage was rendered in a
> > rect surrounding the pointer), and also *some* issues with logging
> > in-out of an X session via xenodm.
> >
> > I still experience problems with the machine going to sleep and waking
> > up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> > at all, or the mouse pointer goes wonky.
> >
> > Beyond the aforementioned, this set-up seems to allow me to use the
> > machine as before, however, I am not an X11 expert nor a radeondrm
> > driver expert; your mileage may very.
> >
> > If I ever try Andre's hint in the future (thank-you), I might report on
> > success/failure.
> >
> > regards,
> >
> > Jeff
> >
> >
>
>
[update] log4cplus 2.0.4
build ok 6.6
_____________________________________
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/log4cplus/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile 26 Jul 2017 22:45:18 -0000 1.10
+++ Makefile 31 Oct 2019 19:12:39 -0000
@@ -2,7 +2,7 @@
COMMENT= logging API for C++
-DISTNAME = log4cplus-1.2.0
+DISTNAME = log4cplus-2.0.4
EXTRACT_SUFX= .tar.bz2
REVISION = 0
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/log4cplus/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 28 Jan 2016 12:29:54 -0000 1.4
+++ distinfo 31 Oct 2019 19:12:39 -0000
@@ -1,2 +1,2 @@
-SHA256 (log4cplus-1.2.0.tar.bz2) =
aAzHqGUjhOPLOH/qwXlNg8jNpqA4yk52HfpqEWh6Y7k=
-SIZE (log4cplus-1.2.0.tar.bz2) = 629119
+SHA256 (log4cplus-2.0.4.tar.bz2) =
DIp7TKv/BwMjhfDG0aB40qecabHEOwaZHKd0+4WIAlI=
+SIZE (log4cplus-2.0.4.tar.bz2) = 1157072
cvs server: Diffing pkg
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/log4cplus/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 28 Jan 2016 12:29:54 -0000 1.4
+++ pkg/PLIST 31 Oct 2019 19:12:39 -0000
@@ -22,11 +22,9 @@ include/log4cplus/helpers/connectorthrea
include/log4cplus/helpers/fileinfo.h
include/log4cplus/helpers/lockfile.h
include/log4cplus/helpers/loglog.h
-include/log4cplus/helpers/logloguser.h
include/log4cplus/helpers/pointer.h
include/log4cplus/helpers/property.h
include/log4cplus/helpers/queue.h
-include/log4cplus/helpers/sleep.h
include/log4cplus/helpers/snprintf.h
include/log4cplus/helpers/socket.h
include/log4cplus/helpers/socketbuffer.h
@@ -65,8 +63,6 @@ include/log4cplus/thread/
include/log4cplus/thread/impl/
include/log4cplus/thread/impl/syncprims-cxx11.h
include/log4cplus/thread/impl/syncprims-impl.h
-include/log4cplus/thread/impl/syncprims-pthreads.h
-include/log4cplus/thread/impl/syncprims-win32.h
include/log4cplus/thread/impl/threads-impl.h
include/log4cplus/thread/impl/tls.h
include/log4cplus/thread/syncprims-pub-impl.h
_____________________________________
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/log4cplus/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile 26 Jul 2017 22:45:18 -0000 1.10
+++ Makefile 31 Oct 2019 19:12:39 -0000
@@ -2,7 +2,7 @@
COMMENT= logging API for C++
-DISTNAME = log4cplus-1.2.0
+DISTNAME = log4cplus-2.0.4
EXTRACT_SUFX= .tar.bz2
REVISION = 0
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/log4cplus/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 28 Jan 2016 12:29:54 -0000 1.4
+++ distinfo 31 Oct 2019 19:12:39 -0000
@@ -1,2 +1,2 @@
-SHA256 (log4cplus-1.2.0.tar.bz2) =
aAzHqGUjhOPLOH/qwXlNg8jNpqA4yk52HfpqEWh6Y7k=
-SIZE (log4cplus-1.2.0.tar.bz2) = 629119
+SHA256 (log4cplus-2.0.4.tar.bz2) =
DIp7TKv/BwMjhfDG0aB40qecabHEOwaZHKd0+4WIAlI=
+SIZE (log4cplus-2.0.4.tar.bz2) = 1157072
cvs server: Diffing pkg
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/log4cplus/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 28 Jan 2016 12:29:54 -0000 1.4
+++ pkg/PLIST 31 Oct 2019 19:12:39 -0000
@@ -22,11 +22,9 @@ include/log4cplus/helpers/connectorthrea
include/log4cplus/helpers/fileinfo.h
include/log4cplus/helpers/lockfile.h
include/log4cplus/helpers/loglog.h
-include/log4cplus/helpers/logloguser.h
include/log4cplus/helpers/pointer.h
include/log4cplus/helpers/property.h
include/log4cplus/helpers/queue.h
-include/log4cplus/helpers/sleep.h
include/log4cplus/helpers/snprintf.h
include/log4cplus/helpers/socket.h
include/log4cplus/helpers/socketbuffer.h
@@ -65,8 +63,6 @@ include/log4cplus/thread/
include/log4cplus/thread/impl/
include/log4cplus/thread/impl/syncprims-cxx11.h
include/log4cplus/thread/impl/syncprims-impl.h
-include/log4cplus/thread/impl/syncprims-pthreads.h
-include/log4cplus/thread/impl/syncprims-win32.h
include/log4cplus/thread/impl/threads-impl.h
include/log4cplus/thread/impl/tls.h
include/log4cplus/thread/syncprims-pub-impl.h
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 06:08:12PM +0000, Jason McIntyre wrote:
> On Thu, Oct 31, 2019 at 11:33:14AM -0600, Theo de Raadt wrote:
> > Jason McIntyre <jmc@kerhand.co.uk> wrote:
> >
> > > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > > minor inconsistency
> > > >
> > > > diff --git a/tcpdump.8 b/tcpdump.8
> > > > index ce16951..8c2cf33 100644
> > > > --- a/tcpdump.8
> > > > +++ b/tcpdump.8
> > > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > > .Ar window
> > > > is the number of bytes of receive buffer space available
> > > > at the other end of this connection.
> > > > -.Ar urg
> > > > +.Ar urgent
> > > > indicates there is urgent data in the packet.
> > > > .Ar options
> > > > are TCP options enclosed in angle brackets e.g.,
> > > >
> > >
> > > hi.
> > >
> > > have you established that it's the documentation that is wrong? i.e.
> > > that "urgent" is printed, and not actually "urg"?
> >
> > The situation is a bit more subtle than that. Just above, the manual
> > page leads with this header.
> >
> > The general format of a TCP protocol line is:
> >
> > src > dst: flags src-os data-seqno ack window urgent options
> >
> > It is saying there's a section of the line regarding the _window_, then a
> > section regarding _urgent_, then a section regarding _options_. In the
> > next paragraph it vaguely describes each of these without getting into
> > the specifics of the actual printed format (for instance, _window_ is
> > actually printed as " win %u".
> >
> > The .Ar above are the "section names" of the line. I think Tim's diff is
> > right.
> >
> >
>
> ok, i see your point (after a bit of head scratching). i'll commit the
> diff then.
>
> jmc
>
i should have added that the macros in this page are poorly used, and
that caused my confusion. it's another issue though.
jmc
> On Thu, Oct 31, 2019 at 11:33:14AM -0600, Theo de Raadt wrote:
> > Jason McIntyre <jmc@kerhand.co.uk> wrote:
> >
> > > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > > minor inconsistency
> > > >
> > > > diff --git a/tcpdump.8 b/tcpdump.8
> > > > index ce16951..8c2cf33 100644
> > > > --- a/tcpdump.8
> > > > +++ b/tcpdump.8
> > > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > > .Ar window
> > > > is the number of bytes of receive buffer space available
> > > > at the other end of this connection.
> > > > -.Ar urg
> > > > +.Ar urgent
> > > > indicates there is urgent data in the packet.
> > > > .Ar options
> > > > are TCP options enclosed in angle brackets e.g.,
> > > >
> > >
> > > hi.
> > >
> > > have you established that it's the documentation that is wrong? i.e.
> > > that "urgent" is printed, and not actually "urg"?
> >
> > The situation is a bit more subtle than that. Just above, the manual
> > page leads with this header.
> >
> > The general format of a TCP protocol line is:
> >
> > src > dst: flags src-os data-seqno ack window urgent options
> >
> > It is saying there's a section of the line regarding the _window_, then a
> > section regarding _urgent_, then a section regarding _options_. In the
> > next paragraph it vaguely describes each of these without getting into
> > the specifics of the actual printed format (for instance, _window_ is
> > actually printed as " win %u".
> >
> > The .Ar above are the "section names" of the line. I think Tim's diff is
> > right.
> >
> >
>
> ok, i see your point (after a bit of head scratching). i'll commit the
> diff then.
>
> jmc
>
i should have added that the macros in this page are poorly used, and
that caused my confusion. it's another issue though.
jmc
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> minor inconsistency
>
> diff --git a/tcpdump.8 b/tcpdump.8
> index ce16951..8c2cf33 100644
> --- a/tcpdump.8
> +++ b/tcpdump.8
> @@ -1257,7 +1257,7 @@ end of this connection.
> .Ar window
> is the number of bytes of receive buffer space available
> at the other end of this connection.
> -.Ar urg
> +.Ar urgent
> indicates there is urgent data in the packet.
> .Ar options
> are TCP options enclosed in angle brackets e.g.,
>
fixed, thanks.
jmc
> minor inconsistency
>
> diff --git a/tcpdump.8 b/tcpdump.8
> index ce16951..8c2cf33 100644
> --- a/tcpdump.8
> +++ b/tcpdump.8
> @@ -1257,7 +1257,7 @@ end of this connection.
> .Ar window
> is the number of bytes of receive buffer space available
> at the other end of this connection.
> -.Ar urg
> +.Ar urgent
> indicates there is urgent data in the packet.
> .Ar options
> are TCP options enclosed in angle brackets e.g.,
>
fixed, thanks.
jmc
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 11:33:14AM -0600, Theo de Raadt wrote:
> Jason McIntyre <jmc@kerhand.co.uk> wrote:
>
> > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > minor inconsistency
> > >
> > > diff --git a/tcpdump.8 b/tcpdump.8
> > > index ce16951..8c2cf33 100644
> > > --- a/tcpdump.8
> > > +++ b/tcpdump.8
> > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > .Ar window
> > > is the number of bytes of receive buffer space available
> > > at the other end of this connection.
> > > -.Ar urg
> > > +.Ar urgent
> > > indicates there is urgent data in the packet.
> > > .Ar options
> > > are TCP options enclosed in angle brackets e.g.,
> > >
> >
> > hi.
> >
> > have you established that it's the documentation that is wrong? i.e.
> > that "urgent" is printed, and not actually "urg"?
>
> The situation is a bit more subtle than that. Just above, the manual
> page leads with this header.
>
> The general format of a TCP protocol line is:
>
> src > dst: flags src-os data-seqno ack window urgent options
>
> It is saying there's a section of the line regarding the _window_, then a
> section regarding _urgent_, then a section regarding _options_. In the
> next paragraph it vaguely describes each of these without getting into
> the specifics of the actual printed format (for instance, _window_ is
> actually printed as " win %u".
>
> The .Ar above are the "section names" of the line. I think Tim's diff is
> right.
>
>
ok, i see your point (after a bit of head scratching). i'll commit the
diff then.
jmc
> Jason McIntyre <jmc@kerhand.co.uk> wrote:
>
> > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > minor inconsistency
> > >
> > > diff --git a/tcpdump.8 b/tcpdump.8
> > > index ce16951..8c2cf33 100644
> > > --- a/tcpdump.8
> > > +++ b/tcpdump.8
> > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > .Ar window
> > > is the number of bytes of receive buffer space available
> > > at the other end of this connection.
> > > -.Ar urg
> > > +.Ar urgent
> > > indicates there is urgent data in the packet.
> > > .Ar options
> > > are TCP options enclosed in angle brackets e.g.,
> > >
> >
> > hi.
> >
> > have you established that it's the documentation that is wrong? i.e.
> > that "urgent" is printed, and not actually "urg"?
>
> The situation is a bit more subtle than that. Just above, the manual
> page leads with this header.
>
> The general format of a TCP protocol line is:
>
> src > dst: flags src-os data-seqno ack window urgent options
>
> It is saying there's a section of the line regarding the _window_, then a
> section regarding _urgent_, then a section regarding _options_. In the
> next paragraph it vaguely describes each of these without getting into
> the specifics of the actual printed format (for instance, _window_ is
> actually printed as " win %u".
>
> The .Ar above are the "section names" of the line. I think Tim's diff is
> right.
>
>
ok, i see your point (after a bit of head scratching). i'll commit the
diff then.
jmc
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote:
> Hi, All:
>
> I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> doesn't in 6.6.
>
> What is the best way for me to go about debugging this issue? So far,
> I have checked:
> - dmesg for ACPI wake devices
> - syslog for suspend messages
>
> Specifically, the suspend works; however, when I attempt to wake the
> device, the laptop seems to respond and attempt to wake, but the
> display never turns on, and I cannot SSH into the machine. Below are
> the dmesg and relevant syslog entries.
>
About a year or so ago I posted a message to either misc@ or tech@ about
how to diagnose suspend/resume failures, by bisecting the resume path and
placing resets or spins at various places to see how far the resume gets
before dying. I would recommend finding that post (I just looked and I
couldn't find it though) and walking through those steps.
I doubt any of us still have machines that old to try debugging this
ourselves, the machine is nearly 15 years old.
-ml
> dmesg
> =====
>
> OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 527790080 (503MB)
> avail mem = 502480896 (479MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf80e0 (44 entries)
> bios0: vendor Dell Inc. version "A09" date 09/28/2005
> bios0: Dell Inc. Inspiron 6000
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
> acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30 GHz, 06-0d-06
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe0000000, bus 0-255
> acpimcfg0: addr 0x0, bus 0-0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 3 (PCIE)
> acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
> acpitz0 at acpi0: critical temperature is 99 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> acpivideo0 at acpi0: VID_
> acpivideo1 at acpi0: VID_
> acpivideo2 at acpi0: VID2
> bios0: ROM list: 0xc0000/0xf800! 0xcf800/0x800
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
> inteldrm0: apic 1 int 16
> "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
> pci1 at ppb0 bus 3
> bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18, address 00:11:43:70:7f:12
> bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
> cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
> "Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
> sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
> sdhc0: SDHC 1.0, 33 MHz base clock
> sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
> bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17, address 00:0b:7d:15:3a:24
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
> pcmcia0 at cardslot0
> auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16, ICH6
> ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
> ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
> audio0 at auich0
> "Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
> pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <TOSHIBA MK3021GAS>
> wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0: <SAMSUNG, CDRW/DVD SN-324S, U303> removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb4 at uhci3: USB revision 1.0
> uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> isa0 at ichpcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pms0: ALPS Glidepoint, version 0x7321
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> umass0 at uhub0 port 7 configuration 1 interface 0 "SanDisk Ultra Fit" rev 2.10/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd0 at scsibus2 targ 1 lun 0: <SanDisk, Ultra Fit, 1.00> removable serial.07815583160829112091
> sd0: 14664MB, 512 bytes/sector, 30031872 sectors
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on wd0a (cc890b5cad21430f.a) swap on wd0b dump on wd0b
> inteldrm0: 1280x800, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> ugen0 at uhub0 port 5 "TCT Holding Ltd. TCT Modem" rev 2.00/0.00 addr 3
> ugen0: setting configuration index 0 failed
> ugen0 detached
>
> messages
> ========
>
> Oct 16 11:13:23 bilbo apmd: system suspending
> Oct 16 11:13:23 bilbo apmd: battery status: high. external power status: connected. estimated battery life 100%
> Oct 16 11:13:24 bilbo /bsd: uhub1 detached
> Oct 16 11:13:24 bilbo /bsd: uhub2 detached
> Oct 16 11:13:24 bilbo /bsd: uhub3 detached
> Oct 16 11:20:42 bilbo syslogd[3039]: start
>
> Hi, All:
>
> I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> doesn't in 6.6.
>
> What is the best way for me to go about debugging this issue? So far,
> I have checked:
> - dmesg for ACPI wake devices
> - syslog for suspend messages
>
> Specifically, the suspend works; however, when I attempt to wake the
> device, the laptop seems to respond and attempt to wake, but the
> display never turns on, and I cannot SSH into the machine. Below are
> the dmesg and relevant syslog entries.
>
About a year or so ago I posted a message to either misc@ or tech@ about
how to diagnose suspend/resume failures, by bisecting the resume path and
placing resets or spins at various places to see how far the resume gets
before dying. I would recommend finding that post (I just looked and I
couldn't find it though) and walking through those steps.
I doubt any of us still have machines that old to try debugging this
ourselves, the machine is nearly 15 years old.
-ml
> dmesg
> =====
>
> OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 527790080 (503MB)
> avail mem = 502480896 (479MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf80e0 (44 entries)
> bios0: vendor Dell Inc. version "A09" date 09/28/2005
> bios0: Dell Inc. Inspiron 6000
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
> acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30 GHz, 06-0d-06
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe0000000, bus 0-255
> acpimcfg0: addr 0x0, bus 0-0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 3 (PCIE)
> acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
> acpitz0 at acpi0: critical temperature is 99 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> acpivideo0 at acpi0: VID_
> acpivideo1 at acpi0: VID_
> acpivideo2 at acpi0: VID2
> bios0: ROM list: 0xc0000/0xf800! 0xcf800/0x800
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
> inteldrm0: apic 1 int 16
> "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
> pci1 at ppb0 bus 3
> bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18, address 00:11:43:70:7f:12
> bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
> cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
> "Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
> sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
> sdhc0: SDHC 1.0, 33 MHz base clock
> sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
> bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17, address 00:0b:7d:15:3a:24
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
> pcmcia0 at cardslot0
> auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16, ICH6
> ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
> ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
> audio0 at auich0
> "Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
> pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <TOSHIBA MK3021GAS>
> wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0: <SAMSUNG, CDRW/DVD SN-324S, U303> removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb4 at uhci3: USB revision 1.0
> uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> isa0 at ichpcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pms0: ALPS Glidepoint, version 0x7321
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> umass0 at uhub0 port 7 configuration 1 interface 0 "SanDisk Ultra Fit" rev 2.10/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd0 at scsibus2 targ 1 lun 0: <SanDisk, Ultra Fit, 1.00> removable serial.07815583160829112091
> sd0: 14664MB, 512 bytes/sector, 30031872 sectors
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on wd0a (cc890b5cad21430f.a) swap on wd0b dump on wd0b
> inteldrm0: 1280x800, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> ugen0 at uhub0 port 5 "TCT Holding Ltd. TCT Modem" rev 2.00/0.00 addr 3
> ugen0: setting configuration index 0 failed
> ugen0 detached
>
> messages
> ========
>
> Oct 16 11:13:23 bilbo apmd: system suspending
> Oct 16 11:13:23 bilbo apmd: battery status: high. external power status: connected. estimated battery life 100%
> Oct 16 11:13:24 bilbo /bsd: uhub1 detached
> Oct 16 11:13:24 bilbo /bsd: uhub2 detached
> Oct 16 11:13:24 bilbo /bsd: uhub3 detached
> Oct 16 11:20:42 bilbo syslogd[3039]: start
>
Suspend on Dell Inspiron 6000
Hi, All:
I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
doesn't in 6.6.
What is the best way for me to go about debugging this issue? So far,
I have checked:
- dmesg for ACPI wake devices
- syslog for suspend messages
Specifically, the suspend works; however, when I attempt to wake the
device, the laptop seems to respond and attempt to wake, but the
display never turns on, and I cannot SSH into the machine. Below are
the dmesg and relevant syslog entries.
dmesg
=====
OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 527790080 (503MB)
avail mem = 502480896 (479MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf80e0 (44 entries)
bios0: vendor Dell Inc. version "A09" date 09/28/2005
bios0: Dell Inc. Inspiron 6000
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30 GHz, 06-0d-06
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE)
acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
acpitz0 at acpi0: critical temperature is 99 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
bios0: ROM list: 0xc0000/0xf800! 0xcf800/0x800
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
inteldrm0: apic 1 int 16
"Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
pci1 at ppb0 bus 3
bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18, address 00:11:43:70:7f:12
bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
"Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
sdhc0: SDHC 1.0, 33 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17, address 00:0b:7d:15:3a:24
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16, ICH6
ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
audio0 at auich0
"Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <TOSHIBA MK3021GAS>
wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <SAMSUNG, CDRW/DVD SN-324S, U303> removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pms0: ALPS Glidepoint, version 0x7321
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
umass0 at uhub0 port 7 configuration 1 interface 0 "SanDisk Ultra Fit" rev 2.10/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd0 at scsibus2 targ 1 lun 0: <SanDisk, Ultra Fit, 1.00> removable serial.07815583160829112091
sd0: 14664MB, 512 bytes/sector, 30031872 sectors
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on wd0a (cc890b5cad21430f.a) swap on wd0b dump on wd0b
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ugen0 at uhub0 port 5 "TCT Holding Ltd. TCT Modem" rev 2.00/0.00 addr 3
ugen0: setting configuration index 0 failed
ugen0 detached
messages
========
Oct 16 11:13:23 bilbo apmd: system suspending
Oct 16 11:13:23 bilbo apmd: battery status: high. external power status: connected. estimated battery life 100%
Oct 16 11:13:24 bilbo /bsd: uhub1 detached
Oct 16 11:13:24 bilbo /bsd: uhub2 detached
Oct 16 11:13:24 bilbo /bsd: uhub3 detached
Oct 16 11:20:42 bilbo syslogd[3039]: start
I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
doesn't in 6.6.
What is the best way for me to go about debugging this issue? So far,
I have checked:
- dmesg for ACPI wake devices
- syslog for suspend messages
Specifically, the suspend works; however, when I attempt to wake the
device, the laptop seems to respond and attempt to wake, but the
display never turns on, and I cannot SSH into the machine. Below are
the dmesg and relevant syslog entries.
dmesg
=====
OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
root@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 527790080 (503MB)
avail mem = 502480896 (479MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf80e0 (44 entries)
bios0: vendor Dell Inc. version "A09" date 09/28/2005
bios0: Dell Inc. Inspiron 6000
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30 GHz, 06-0d-06
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE)
acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
acpitz0 at acpi0: critical temperature is 99 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
bios0: ROM list: 0xc0000/0xf800! 0xcf800/0x800
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
inteldrm0: apic 1 int 16
"Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
pci1 at ppb0 bus 3
bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18, address 00:11:43:70:7f:12
bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
"Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
sdhc0: SDHC 1.0, 33 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17, address 00:0b:7d:15:3a:24
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16, ICH6
ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
audio0 at auich0
"Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <TOSHIBA MK3021GAS>
wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <SAMSUNG, CDRW/DVD SN-324S, U303> removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pms0: ALPS Glidepoint, version 0x7321
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
umass0 at uhub0 port 7 configuration 1 interface 0 "SanDisk Ultra Fit" rev 2.10/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd0 at scsibus2 targ 1 lun 0: <SanDisk, Ultra Fit, 1.00> removable serial.07815583160829112091
sd0: 14664MB, 512 bytes/sector, 30031872 sectors
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on wd0a (cc890b5cad21430f.a) swap on wd0b dump on wd0b
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ugen0 at uhub0 port 5 "TCT Holding Ltd. TCT Modem" rev 2.00/0.00 addr 3
ugen0: setting configuration index 0 failed
ugen0 detached
messages
========
Oct 16 11:13:23 bilbo apmd: system suspending
Oct 16 11:13:23 bilbo apmd: battery status: high. external power status: connected. estimated battery life 100%
Oct 16 11:13:24 bilbo /bsd: uhub1 detached
Oct 16 11:13:24 bilbo /bsd: uhub2 detached
Oct 16 11:13:24 bilbo /bsd: uhub3 detached
Oct 16 11:20:42 bilbo syslogd[3039]: start
nss: Set BUILD_OPT only when DEBUG is unset
Had this diff laying here ever since requiring a debug build of NSS;
I think BUILD_OPT still turned into `-O2' when I passed `DEBUG=-O0'
and/or stripping symbols in the end; either way it made setting DEBUG
what one would expect.
This does not effect normal builds as DEBUG is unset, so no REVISION
bump.
OK?
Index: security/nss/Makefile
===================================================================
RCS file: /cvs/ports/security/nss/Makefile,v
retrieving revision 1.111
diff -u -p -r1.111 Makefile
--- security/nss/Makefile 23 Oct 2019 19:30:25 -0000 1.111
+++ security/nss/Makefile 23 Oct 2019 22:31:59 -0000
@@ -25,8 +25,7 @@ LIB_DEPENDS= databases/sqlite3 \
devel/nspr>=${NSPR_VERSION}
WANTLIB += c pthread z nspr4 plc4 plds4 sqlite3>=22
-MAKE_ENV= BUILD_OPT=1 \
- LOCALBASE="${LOCALBASE}" \
+MAKE_ENV= LOCALBASE="${LOCALBASE}" \
NSS_SEED_ONLY_DEV_URANDOM=1 \
NSS_ENABLE_ECC=1 \
NSS_ENABLE_TLS_1_3=1 \
@@ -36,6 +35,10 @@ MAKE_ENV= BUILD_OPT=1 \
XCFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
NSPR_INCLUDE_DIR="${LOCALBASE}/include/nspr" \
NSPR_LIB_DIR="${LOCALBASE}/lib"
+
+.if !defined(DEBUG)
+MAKE_ENV+= BUILD_OPT=1
+.endif
USE_GMAKE= Yes
I think BUILD_OPT still turned into `-O2' when I passed `DEBUG=-O0'
and/or stripping symbols in the end; either way it made setting DEBUG
what one would expect.
This does not effect normal builds as DEBUG is unset, so no REVISION
bump.
OK?
Index: security/nss/Makefile
===================================================================
RCS file: /cvs/ports/security/nss/Makefile,v
retrieving revision 1.111
diff -u -p -r1.111 Makefile
--- security/nss/Makefile 23 Oct 2019 19:30:25 -0000 1.111
+++ security/nss/Makefile 23 Oct 2019 22:31:59 -0000
@@ -25,8 +25,7 @@ LIB_DEPENDS= databases/sqlite3 \
devel/nspr>=${NSPR_VERSION}
WANTLIB += c pthread z nspr4 plc4 plds4 sqlite3>=22
-MAKE_ENV= BUILD_OPT=1 \
- LOCALBASE="${LOCALBASE}" \
+MAKE_ENV= LOCALBASE="${LOCALBASE}" \
NSS_SEED_ONLY_DEV_URANDOM=1 \
NSS_ENABLE_ECC=1 \
NSS_ENABLE_TLS_1_3=1 \
@@ -36,6 +35,10 @@ MAKE_ENV= BUILD_OPT=1 \
XCFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
NSPR_INCLUDE_DIR="${LOCALBASE}/include/nspr" \
NSPR_LIB_DIR="${LOCALBASE}/lib"
+
+.if !defined(DEBUG)
+MAKE_ENV+= BUILD_OPT=1
+.endif
USE_GMAKE= Yes
Re: minor tcpdump.8 inconsistency
Otto Moerbeek <otto@drijf.net> wrote:
> On Thu, Oct 31, 2019 at 05:23:12PM +0000, Jason McIntyre wrote:
>
> > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > minor inconsistency
> > >
> > > diff --git a/tcpdump.8 b/tcpdump.8
> > > index ce16951..8c2cf33 100644
> > > --- a/tcpdump.8
> > > +++ b/tcpdump.8
> > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > .Ar window
> > > is the number of bytes of receive buffer space available
> > > at the other end of this connection.
> > > -.Ar urg
> > > +.Ar urgent
> > > indicates there is urgent data in the packet.
> > > .Ar options
> > > are TCP options enclosed in angle brackets e.g.,
> > >
> >
> > hi.
> >
> > have you established that it's the documentation that is wrong? i.e.
> > that "urgent" is printed, and not actually "urg"?
> >
> > jmc
> >
>
> It is "urg". The correct diff is this, I think.
>
> -Otto
>
> Index: tcpdump.8
> ===================================================================
> RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v
> retrieving revision 1.107
> diff -u -p -r1.107 tcpdump.8
> --- tcpdump.8 25 Sep 2019 17:02:00 -0000 1.107
> +++ tcpdump.8 31 Oct 2019 17:28:59 -0000
> @@ -1219,7 +1219,7 @@ will be of much use to you.
> The general format of a TCP protocol line is:
> .Bd -ragged -offset indent
> .Ar src No > Ar dst :
> -.Ar flags src-os data-seqno ack window urgent options
> +.Ar flags src-os data-seqno ack window urg options
> .Ed
> .Pp
> .Ar src
I don't agree. Because then "window" needs to be replaced with "win"
as well, and through the entire next paragraph also, and some people
may not win understanding but lose it instead.
> On Thu, Oct 31, 2019 at 05:23:12PM +0000, Jason McIntyre wrote:
>
> > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > > minor inconsistency
> > >
> > > diff --git a/tcpdump.8 b/tcpdump.8
> > > index ce16951..8c2cf33 100644
> > > --- a/tcpdump.8
> > > +++ b/tcpdump.8
> > > @@ -1257,7 +1257,7 @@ end of this connection.
> > > .Ar window
> > > is the number of bytes of receive buffer space available
> > > at the other end of this connection.
> > > -.Ar urg
> > > +.Ar urgent
> > > indicates there is urgent data in the packet.
> > > .Ar options
> > > are TCP options enclosed in angle brackets e.g.,
> > >
> >
> > hi.
> >
> > have you established that it's the documentation that is wrong? i.e.
> > that "urgent" is printed, and not actually "urg"?
> >
> > jmc
> >
>
> It is "urg". The correct diff is this, I think.
>
> -Otto
>
> Index: tcpdump.8
> ===================================================================
> RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v
> retrieving revision 1.107
> diff -u -p -r1.107 tcpdump.8
> --- tcpdump.8 25 Sep 2019 17:02:00 -0000 1.107
> +++ tcpdump.8 31 Oct 2019 17:28:59 -0000
> @@ -1219,7 +1219,7 @@ will be of much use to you.
> The general format of a TCP protocol line is:
> .Bd -ragged -offset indent
> .Ar src No > Ar dst :
> -.Ar flags src-os data-seqno ack window urgent options
> +.Ar flags src-os data-seqno ack window urg options
> .Ed
> .Pp
> .Ar src
I don't agree. Because then "window" needs to be replaced with "win"
as well, and through the entire next paragraph also, and some people
may not win understanding but lose it instead.
Re: minor tcpdump.8 inconsistency
Jason McIntyre <jmc@kerhand.co.uk> wrote:
> On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > minor inconsistency
> >
> > diff --git a/tcpdump.8 b/tcpdump.8
> > index ce16951..8c2cf33 100644
> > --- a/tcpdump.8
> > +++ b/tcpdump.8
> > @@ -1257,7 +1257,7 @@ end of this connection.
> > .Ar window
> > is the number of bytes of receive buffer space available
> > at the other end of this connection.
> > -.Ar urg
> > +.Ar urgent
> > indicates there is urgent data in the packet.
> > .Ar options
> > are TCP options enclosed in angle brackets e.g.,
> >
>
> hi.
>
> have you established that it's the documentation that is wrong? i.e.
> that "urgent" is printed, and not actually "urg"?
The situation is a bit more subtle than that. Just above, the manual
page leads with this header.
The general format of a TCP protocol line is:
src > dst: flags src-os data-seqno ack window urgent options
It is saying there's a section of the line regarding the _window_, then a
section regarding _urgent_, then a section regarding _options_. In the
next paragraph it vaguely describes each of these without getting into
the specifics of the actual printed format (for instance, _window_ is
actually printed as " win %u".
The .Ar above are the "section names" of the line. I think Tim's diff is
right.
> On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > minor inconsistency
> >
> > diff --git a/tcpdump.8 b/tcpdump.8
> > index ce16951..8c2cf33 100644
> > --- a/tcpdump.8
> > +++ b/tcpdump.8
> > @@ -1257,7 +1257,7 @@ end of this connection.
> > .Ar window
> > is the number of bytes of receive buffer space available
> > at the other end of this connection.
> > -.Ar urg
> > +.Ar urgent
> > indicates there is urgent data in the packet.
> > .Ar options
> > are TCP options enclosed in angle brackets e.g.,
> >
>
> hi.
>
> have you established that it's the documentation that is wrong? i.e.
> that "urgent" is printed, and not actually "urg"?
The situation is a bit more subtle than that. Just above, the manual
page leads with this header.
The general format of a TCP protocol line is:
src > dst: flags src-os data-seqno ack window urgent options
It is saying there's a section of the line regarding the _window_, then a
section regarding _urgent_, then a section regarding _options_. In the
next paragraph it vaguely describes each of these without getting into
the specifics of the actual printed format (for instance, _window_ is
actually printed as " win %u".
The .Ar above are the "section names" of the line. I think Tim's diff is
right.
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 05:23:12PM +0000, Jason McIntyre wrote:
> On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > minor inconsistency
> >
> > diff --git a/tcpdump.8 b/tcpdump.8
> > index ce16951..8c2cf33 100644
> > --- a/tcpdump.8
> > +++ b/tcpdump.8
> > @@ -1257,7 +1257,7 @@ end of this connection.
> > .Ar window
> > is the number of bytes of receive buffer space available
> > at the other end of this connection.
> > -.Ar urg
> > +.Ar urgent
> > indicates there is urgent data in the packet.
> > .Ar options
> > are TCP options enclosed in angle brackets e.g.,
> >
>
> hi.
>
> have you established that it's the documentation that is wrong? i.e.
> that "urgent" is printed, and not actually "urg"?
>
> jmc
>
It is "urg". The correct diff is this, I think.
-Otto
Index: tcpdump.8
===================================================================
RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v
retrieving revision 1.107
diff -u -p -r1.107 tcpdump.8
--- tcpdump.8 25 Sep 2019 17:02:00 -0000 1.107
+++ tcpdump.8 31 Oct 2019 17:28:59 -0000
@@ -1219,7 +1219,7 @@ will be of much use to you.
The general format of a TCP protocol line is:
.Bd -ragged -offset indent
.Ar src No > Ar dst :
-.Ar flags src-os data-seqno ack window urgent options
+.Ar flags src-os data-seqno ack window urg options
.Ed
.Pp
.Ar src
> On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> > minor inconsistency
> >
> > diff --git a/tcpdump.8 b/tcpdump.8
> > index ce16951..8c2cf33 100644
> > --- a/tcpdump.8
> > +++ b/tcpdump.8
> > @@ -1257,7 +1257,7 @@ end of this connection.
> > .Ar window
> > is the number of bytes of receive buffer space available
> > at the other end of this connection.
> > -.Ar urg
> > +.Ar urgent
> > indicates there is urgent data in the packet.
> > .Ar options
> > are TCP options enclosed in angle brackets e.g.,
> >
>
> hi.
>
> have you established that it's the documentation that is wrong? i.e.
> that "urgent" is printed, and not actually "urg"?
>
> jmc
>
It is "urg". The correct diff is this, I think.
-Otto
Index: tcpdump.8
===================================================================
RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v
retrieving revision 1.107
diff -u -p -r1.107 tcpdump.8
--- tcpdump.8 25 Sep 2019 17:02:00 -0000 1.107
+++ tcpdump.8 31 Oct 2019 17:28:59 -0000
@@ -1219,7 +1219,7 @@ will be of much use to you.
The general format of a TCP protocol line is:
.Bd -ragged -offset indent
.Ar src No > Ar dst :
-.Ar flags src-os data-seqno ack window urgent options
+.Ar flags src-os data-seqno ack window urg options
.Ed
.Pp
.Ar src
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote:
> minor inconsistency
>
> diff --git a/tcpdump.8 b/tcpdump.8
> index ce16951..8c2cf33 100644
> --- a/tcpdump.8
> +++ b/tcpdump.8
> @@ -1257,7 +1257,7 @@ end of this connection.
> .Ar window
> is the number of bytes of receive buffer space available
> at the other end of this connection.
> -.Ar urg
> +.Ar urgent
> indicates there is urgent data in the packet.
> .Ar options
> are TCP options enclosed in angle brackets e.g.,
>
hi.
have you established that it's the documentation that is wrong? i.e.
that "urgent" is printed, and not actually "urg"?
jmc
> minor inconsistency
>
> diff --git a/tcpdump.8 b/tcpdump.8
> index ce16951..8c2cf33 100644
> --- a/tcpdump.8
> +++ b/tcpdump.8
> @@ -1257,7 +1257,7 @@ end of this connection.
> .Ar window
> is the number of bytes of receive buffer space available
> at the other end of this connection.
> -.Ar urg
> +.Ar urgent
> indicates there is urgent data in the packet.
> .Ar options
> are TCP options enclosed in angle brackets e.g.,
>
hi.
have you established that it's the documentation that is wrong? i.e.
that "urgent" is printed, and not actually "urg"?
jmc
Re: gdb: Use Python 3
On Tue, Oct 22, 2019 at 10:14:11PM +0200, Klemens Nanni wrote:
> Another step in deprecating Python 2; our 7.12.1 requires an upstream
> commit contained in at least 8.1.50 since gdb uses a private Python API.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=23252
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=aeab512851bf6ed623d1c6c4305b6ce05e51a10c
>
> I've been running with this for a while in regular usage, but would be
> happy to see wider testing.
>
> Feedback?
Diff below now actually contains the patch, so I guess noone tried it yet.
I want to get rid of Python 2 and GDB has been behaving well with this
diff so far, so I'd like to commit this soon eventually.
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/gdb/Makefile,v
retrieving revision 1.62
diff -u -p -r1.62 Makefile
--- Makefile 17 Oct 2019 17:10:26 -0000 1.62
+++ Makefile 22 Oct 2019 19:55:27 -0000
@@ -4,7 +4,7 @@ COMMENT= GNU debugger
CATEGORIES= devel
DISTNAME= gdb-7.12.1
-REVISION= 8
+REVISION= 9
HOMEPAGE= https://www.gnu.org/software/gdb/
@@ -35,6 +35,8 @@ CONFIGURE_ARGS= --program-prefix=e \
USE_GMAKE= Yes
MODULES += lang/python
+MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
+
LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
TEST_DEPENDS += devel/dejagnu
MODPY_BUILDDEP = No
Index: patches/patch-gdb_python_python_c
===================================================================
RCS file: patches/patch-gdb_python_python_c
diff -N patches/patch-gdb_python_python_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-gdb_python_python_c 22 Oct 2019 19:35:10 -0000
@@ -0,0 +1,47 @@
+$OpenBSD$
+
+"Fix build issue with Python 3.7"; git: aeab512851bf6ed623d1c6c4305b6ce05e51a10c
+
+Index: gdb/python/python.c
+--- gdb/python/python.c.orig
++++ gdb/python/python.c
+@@ -1622,7 +1622,18 @@ finalize_python (void *ignore)
+
+ restore_active_ext_lang (previous_active);
+ }
++
++#ifdef IS_PY3K
++/* This is called via the PyImport_AppendInittab mechanism called
++ during initialization, to make the built-in _gdb module known to
++ Python. */
++PyMODINIT_FUNC
++init__gdb_module (void)
++{
++ return PyModule_Create (&python_GdbModuleDef);
++}
+
> Another step in deprecating Python 2; our 7.12.1 requires an upstream
> commit contained in at least 8.1.50 since gdb uses a private Python API.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=23252
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=aeab512851bf6ed623d1c6c4305b6ce05e51a10c
>
> I've been running with this for a while in regular usage, but would be
> happy to see wider testing.
>
> Feedback?
Diff below now actually contains the patch, so I guess noone tried it yet.
I want to get rid of Python 2 and GDB has been behaving well with this
diff so far, so I'd like to commit this soon eventually.
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/gdb/Makefile,v
retrieving revision 1.62
diff -u -p -r1.62 Makefile
--- Makefile 17 Oct 2019 17:10:26 -0000 1.62
+++ Makefile 22 Oct 2019 19:55:27 -0000
@@ -4,7 +4,7 @@ COMMENT= GNU debugger
CATEGORIES= devel
DISTNAME= gdb-7.12.1
-REVISION= 8
+REVISION= 9
HOMEPAGE= https://www.gnu.org/software/gdb/
@@ -35,6 +35,8 @@ CONFIGURE_ARGS= --program-prefix=e \
USE_GMAKE= Yes
MODULES += lang/python
+MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
+
LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
TEST_DEPENDS += devel/dejagnu
MODPY_BUILDDEP = No
Index: patches/patch-gdb_python_python_c
===================================================================
RCS file: patches/patch-gdb_python_python_c
diff -N patches/patch-gdb_python_python_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-gdb_python_python_c 22 Oct 2019 19:35:10 -0000
@@ -0,0 +1,47 @@
+$OpenBSD$
+
+"Fix build issue with Python 3.7"; git: aeab512851bf6ed623d1c6c4305b6ce05e51a10c
+
+Index: gdb/python/python.c
+--- gdb/python/python.c.orig
++++ gdb/python/python.c
+@@ -1622,7 +1622,18 @@ finalize_python (void *ignore)
+
+ restore_active_ext_lang (previous_active);
+ }
++
++#ifdef IS_PY3K
++/* This is called via the PyImport_AppendInittab mechanism called
++ during initialization, to make the built-in _gdb module known to
++ Python. */
++PyMODINIT_FUNC
++init__gdb_module (void)
++{
++ return PyModule_Create (&python_GdbModuleDef);
++}
+
Re: [UPDATE] mail/imapsync-1.945
On Wed, Oct 30, 2019 at 06:03:21PM +0000, Stuart Henderson wrote:
> On 2019/10/21 13:53, Henry Jensen wrote:
> > Gretings,
> >
> > attached diff updates imapsync from 1.727 to 1.945.
> > Three new dependencies (RUN_DEPENDS) were added:
> >
> > sysutils/p5-Sys-MemInfo
> > textproc/p5-Regexp-Common
> > devel/p5-File-Tail
> >
> > tested on -current amd64
> >
> > If OK, someone is needed to push it to CVS.
>
> Here it is with RUN_DEPENDS sorted and the duplicate entry removed.
> I've only build tested it - is it ok with you pea@?
>
>
Yes looks good for me.
Ok pea@
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/mail/imapsync/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 17 Oct 2019 20:15:55 -0000 1.19
> +++ Makefile 30 Oct 2019 18:02:11 -0000
> @@ -2,7 +2,7 @@
>
> GH_ACCOUNT= imapsync
> GH_PROJECT= imapsync
> -GH_TAGNAME= imapsync-1.727
> +GH_TAGNAME= imapsync-1.945
> DISTNAME= ${GH_TAGNAME}
>
> COMMENT= IMAP synchronization tool
> @@ -15,20 +15,22 @@ MAINTAINER= Pierre-Emmanuel Andre <pea@o
> PERMIT_PACKAGE= Yes
>
> RUN_DEPENDS= converters/p5-DateManip \
> - security/p5-IO-Socket-SSL \
> - security/p5-Digest-HMAC \
> - mail/p5-Mail-IMAPClient \
> - net/p5-IO-Socket-INET6 \
> - security/p5-IO-Socket-SSL \
> - devel/p5-IO-Tee \
> converters/p5-Unicode-String \
> - www/p5-URI \
> - security/p5-Authen-NTLM \
> + devel/p5-Data-Uniqid \
> devel/p5-File-Copy-Recursive \
> + devel/p5-File-Tail \
> + devel/p5-IO-Tee \
> devel/p5-Parse-RecDescent \
> + devel/p5-Readonly \
> devel/p5-Test-Pod \
> - devel/p5-Data-Uniqid \
> - devel/p5-Readonly
> + mail/p5-Mail-IMAPClient \
> + net/p5-IO-Socket-INET6 \
> + security/p5-Authen-NTLM \
> + security/p5-Digest-HMAC \
> + security/p5-IO-Socket-SSL \
> + sysutils/p5-Sys-MemInfo \
> + textproc/p5-Regexp-Common \
> + www/p5-URI
>
> NO_BUILD= Yes
> NO_TEST= Yes
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/mail/imapsync/distinfo,v
> retrieving revision 1.13
> diff -u -p -r1.13 distinfo
> --- distinfo 10 May 2017 12:47:56 -0000 1.13
> +++ distinfo 30 Oct 2019 18:02:11 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (imapsync-1.727.tar.gz) = UChyfUdqWBM1EF/yTqZ3MRr6XOb4EvCSbLI3djV5FGg=
> -SIZE (imapsync-1.727.tar.gz) = 1056838
> +SHA256 (imapsync-1.945.tar.gz) = U2OGojF4knVbJ1M02LH0zsowJG3XnAc7ySJ8EX36cak=
> +SIZE (imapsync-1.945.tar.gz) = 1708572
>
> On 2019/10/21 13:53, Henry Jensen wrote:
> > Gretings,
> >
> > attached diff updates imapsync from 1.727 to 1.945.
> > Three new dependencies (RUN_DEPENDS) were added:
> >
> > sysutils/p5-Sys-MemInfo
> > textproc/p5-Regexp-Common
> > devel/p5-File-Tail
> >
> > tested on -current amd64
> >
> > If OK, someone is needed to push it to CVS.
>
> Here it is with RUN_DEPENDS sorted and the duplicate entry removed.
> I've only build tested it - is it ok with you pea@?
>
>
Yes looks good for me.
Ok pea@
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/mail/imapsync/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 17 Oct 2019 20:15:55 -0000 1.19
> +++ Makefile 30 Oct 2019 18:02:11 -0000
> @@ -2,7 +2,7 @@
>
> GH_ACCOUNT= imapsync
> GH_PROJECT= imapsync
> -GH_TAGNAME= imapsync-1.727
> +GH_TAGNAME= imapsync-1.945
> DISTNAME= ${GH_TAGNAME}
>
> COMMENT= IMAP synchronization tool
> @@ -15,20 +15,22 @@ MAINTAINER= Pierre-Emmanuel Andre <pea@o
> PERMIT_PACKAGE= Yes
>
> RUN_DEPENDS= converters/p5-DateManip \
> - security/p5-IO-Socket-SSL \
> - security/p5-Digest-HMAC \
> - mail/p5-Mail-IMAPClient \
> - net/p5-IO-Socket-INET6 \
> - security/p5-IO-Socket-SSL \
> - devel/p5-IO-Tee \
> converters/p5-Unicode-String \
> - www/p5-URI \
> - security/p5-Authen-NTLM \
> + devel/p5-Data-Uniqid \
> devel/p5-File-Copy-Recursive \
> + devel/p5-File-Tail \
> + devel/p5-IO-Tee \
> devel/p5-Parse-RecDescent \
> + devel/p5-Readonly \
> devel/p5-Test-Pod \
> - devel/p5-Data-Uniqid \
> - devel/p5-Readonly
> + mail/p5-Mail-IMAPClient \
> + net/p5-IO-Socket-INET6 \
> + security/p5-Authen-NTLM \
> + security/p5-Digest-HMAC \
> + security/p5-IO-Socket-SSL \
> + sysutils/p5-Sys-MemInfo \
> + textproc/p5-Regexp-Common \
> + www/p5-URI
>
> NO_BUILD= Yes
> NO_TEST= Yes
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/mail/imapsync/distinfo,v
> retrieving revision 1.13
> diff -u -p -r1.13 distinfo
> --- distinfo 10 May 2017 12:47:56 -0000 1.13
> +++ distinfo 30 Oct 2019 18:02:11 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (imapsync-1.727.tar.gz) = UChyfUdqWBM1EF/yTqZ3MRr6XOb4EvCSbLI3djV5FGg=
> -SIZE (imapsync-1.727.tar.gz) = 1056838
> +SHA256 (imapsync-1.945.tar.gz) = U2OGojF4knVbJ1M02LH0zsowJG3XnAc7ySJ8EX36cak=
> +SIZE (imapsync-1.945.tar.gz) = 1708572
>
[ports-gcc] Unbreak devel/kdevelop
Hi!
> http://build-failures.rhaalovely.net/sparc64/2019-10-11/devel/kdevelop.log
> http://build-failures.rhaalovely.net/powerpc/2019-10-11/devel/kdevelop.log
(Logs from the previous version, but the issue remains)
The real issue is here:
--8<--
CMake Warning at plugins/welcomepage/CMakeLists.txt:33 (message):
Applying workaround for
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
-->8--
Upstream brought a fix for gcc-5 [0], that breaks the build on base-gcc
archs, where ports-gcc-8.3 is used to build the port.
Removing the fix allows to build KDevelop on macppc [1] -- with
Rafael's Qt-5.9.8 diff -- and on amd64 with the vanilla Qt-5.9.7. The
runtime is (very slow but) fine as well.
REVISION bump seems superfluous: this version never built on base-gcc
archs and brings no change on base-clang ones. Should i remove it?
Comments/feedback are welcome,
Charlène.
[0] https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
[1] https://bin.charlenew.xyz/kdevelop.log.gz
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/kdevelop/Makefile,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 Makefile
--- Makefile 25 Oct 2019 20:13:53 -0000 1.31
+++ Makefile 31 Oct 2019 15:00:13 -0000
@@ -6,6 +6,7 @@ USE_WXNEEDED = Yes
COMMENT = IDE for C, C++, Python, QML/JavaScript and PHP
VERSION = 5.4.3
+REVISION = 0
DISTNAME = kdevelop-${VERSION}
HOMEPAGE = https://www.kdevelop.org/
Index: patches/patch-plugins_welcomepage_CMakeLists_txt
===================================================================
RCS file: patches/patch-plugins_welcomepage_CMakeLists_txt
diff -N patches/patch-plugins_welcomepage_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-plugins_welcomepage_CMakeLists_txt 31 Oct 2019 15:00:13 -0000
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Drop useless fix used for gcc-5, because it breaks the build with
+ports-gcc>=8.3.0.
+
+Index: plugins/welcomepage/CMakeLists.txt
+--- plugins/welcomepage/CMakeLists.txt.orig
++++ plugins/welcomepage/CMakeLists.txt
+@@ -28,8 +28,3 @@ target_link_libraries(kdevwelcomepage
+ Qt5::QuickWidgets
+ KF5::Declarative
+ )
+-# see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
+-if (UNIX AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+- message(WARNING "Applying workaround for https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899")
+- target_link_libraries(kdevwelcomepage gcc_s gcc)
+-endif()
> http://build-failures.rhaalovely.net/sparc64/2019-10-11/devel/kdevelop.log
> http://build-failures.rhaalovely.net/powerpc/2019-10-11/devel/kdevelop.log
(Logs from the previous version, but the issue remains)
The real issue is here:
--8<--
CMake Warning at plugins/welcomepage/CMakeLists.txt:33 (message):
Applying workaround for
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
-->8--
Upstream brought a fix for gcc-5 [0], that breaks the build on base-gcc
archs, where ports-gcc-8.3 is used to build the port.
Removing the fix allows to build KDevelop on macppc [1] -- with
Rafael's Qt-5.9.8 diff -- and on amd64 with the vanilla Qt-5.9.7. The
runtime is (very slow but) fine as well.
REVISION bump seems superfluous: this version never built on base-gcc
archs and brings no change on base-clang ones. Should i remove it?
Comments/feedback are welcome,
Charlène.
[0] https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
[1] https://bin.charlenew.xyz/kdevelop.log.gz
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/kdevelop/Makefile,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 Makefile
--- Makefile 25 Oct 2019 20:13:53 -0000 1.31
+++ Makefile 31 Oct 2019 15:00:13 -0000
@@ -6,6 +6,7 @@ USE_WXNEEDED = Yes
COMMENT = IDE for C, C++, Python, QML/JavaScript and PHP
VERSION = 5.4.3
+REVISION = 0
DISTNAME = kdevelop-${VERSION}
HOMEPAGE = https://www.kdevelop.org/
Index: patches/patch-plugins_welcomepage_CMakeLists_txt
===================================================================
RCS file: patches/patch-plugins_welcomepage_CMakeLists_txt
diff -N patches/patch-plugins_welcomepage_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-plugins_welcomepage_CMakeLists_txt 31 Oct 2019 15:00:13 -0000
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Drop useless fix used for gcc-5, because it breaks the build with
+ports-gcc>=8.3.0.
+
+Index: plugins/welcomepage/CMakeLists.txt
+--- plugins/welcomepage/CMakeLists.txt.orig
++++ plugins/welcomepage/CMakeLists.txt
+@@ -28,8 +28,3 @@ target_link_libraries(kdevwelcomepage
+ Qt5::QuickWidgets
+ KF5::Declarative
+ )
+-# see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
+-if (UNIX AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+- message(WARNING "Applying workaround for https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899")
+- target_link_libraries(kdevwelcomepage gcc_s gcc)
+-endif()
[UPDATE] devel/openmpi 4.0.1 -> 4.0.2
Hello,
The attached diff updates devel/openmpi to the current stable release 4.0.2.
Changelog can be found here:
https://raw.githubusercontent.com/open-mpi/ompi/v4.0.x/NEWS
Tested on amd64 and arm64.
Most noteably this update fixes problems reported by David Raymond off-list.
-m
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 Makefile
--- Makefile 28 Jun 2019 11:05:11 -0000 1.28
+++ Makefile 30 Oct 2019 21:44:23 -0000
@@ -2,9 +2,9 @@
COMMENT = open source MPI-3.1 implementation
-V = 4.0.1
+V = 4.0.2
DISTNAME = openmpi-$V
-REVISION = 0
+#REVISION = 0
SHARED_LIBS += mca_common_dstore 0.0 # 1.0
SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/openmpi/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- distinfo 27 Jun 2019 13:52:00 -0000 1.4
+++ distinfo 30 Oct 2019 21:44:23 -0000
@@ -1,2 +1,2 @@
-SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
-SIZE (openmpi-4.0.1.tar.gz) = 17513706
+SHA256 (openmpi-4.0.2.tar.gz) = ZigFhw6GoUceWXObDDTG+QBODHoi2waFYtU4jsRCGQQ=
+SIZE (openmpi-4.0.2.tar.gz) = 17373487
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 PLIST
--- pkg/PLIST 27 Jun 2019 13:52:00 -0000 1.5
+++ pkg/PLIST 30 Oct 2019 21:44:23 -0000
@@ -143,15 +143,6 @@ lib/openmpi/mca_compress_gzip.so
lib/openmpi/mca_crs_none.a
lib/openmpi/mca_crs_none.la
lib/openmpi/mca_crs_none.so
-lib/openmpi/mca_dfs_app.a
-lib/openmpi/mca_dfs_app.la
-lib/openmpi/mca_dfs_app.so
-lib/openmpi/mca_dfs_orted.a
-lib/openmpi/mca_dfs_orted.la
-lib/openmpi/mca_dfs_orted.so
-lib/openmpi/mca_dfs_test.a
-lib/openmpi/mca_dfs_test.la
-lib/openmpi/mca_dfs_test.so
lib/openmpi/mca_errmgr_default_app.a
lib/openmpi/mca_errmgr_default_app.la
lib/openmpi/mca_errmgr_default_app.so
@@ -221,9 +212,6 @@ lib/openmpi/mca_iof_tool.so
lib/openmpi/mca_mpool_hugepage.a
lib/openmpi/mca_mpool_hugepage.la
lib/openmpi/mca_mpool_hugepage.so
-lib/openmpi/mca_notifier_syslog.a
-lib/openmpi/mca_notifier_syslog.la
-lib/openmpi/mca_notifier_syslog.so
lib/openmpi/mca_odls_default.a
lib/openmpi/mca_odls_default.la
lib/openmpi/mca_odls_default.so
@@ -288,6 +276,9 @@ lib/openmpi/mca_reachable_weighted.so
lib/openmpi/mca_regx_fwd.a
lib/openmpi/mca_regx_fwd.la
lib/openmpi/mca_regx_fwd.so
+lib/openmpi/mca_regx_naive.a
+lib/openmpi/mca_regx_naive.la
+lib/openmpi/mca_regx_naive.so
lib/openmpi/mca_regx_reverse.a
lib/openmpi/mca_regx_reverse.la
lib/openmpi/mca_regx_reverse.so
@@ -315,9 +306,6 @@ lib/openmpi/mca_rml_oob.so
lib/openmpi/mca_routed_binomial.a
lib/openmpi/mca_routed_binomial.la
lib/openmpi/mca_routed_binomial.so
-lib/openmpi/mca_routed_debruijn.a
-lib/openmpi/mca_routed_debruijn.la
-lib/openmpi/mca_routed_debruijn.so
lib/openmpi/mca_routed_direct.a
lib/openmpi/mca_routed_direct.la
lib/openmpi/mca_routed_direct.so
The attached diff updates devel/openmpi to the current stable release 4.0.2.
Changelog can be found here:
https://raw.githubusercontent.com/open-mpi/ompi/v4.0.x/NEWS
Tested on amd64 and arm64.
Most noteably this update fixes problems reported by David Raymond off-list.
-m
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 Makefile
--- Makefile 28 Jun 2019 11:05:11 -0000 1.28
+++ Makefile 30 Oct 2019 21:44:23 -0000
@@ -2,9 +2,9 @@
COMMENT = open source MPI-3.1 implementation
-V = 4.0.1
+V = 4.0.2
DISTNAME = openmpi-$V
-REVISION = 0
+#REVISION = 0
SHARED_LIBS += mca_common_dstore 0.0 # 1.0
SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/openmpi/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- distinfo 27 Jun 2019 13:52:00 -0000 1.4
+++ distinfo 30 Oct 2019 21:44:23 -0000
@@ -1,2 +1,2 @@
-SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
-SIZE (openmpi-4.0.1.tar.gz) = 17513706
+SHA256 (openmpi-4.0.2.tar.gz) = ZigFhw6GoUceWXObDDTG+QBODHoi2waFYtU4jsRCGQQ=
+SIZE (openmpi-4.0.2.tar.gz) = 17373487
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 PLIST
--- pkg/PLIST 27 Jun 2019 13:52:00 -0000 1.5
+++ pkg/PLIST 30 Oct 2019 21:44:23 -0000
@@ -143,15 +143,6 @@ lib/openmpi/mca_compress_gzip.so
lib/openmpi/mca_crs_none.a
lib/openmpi/mca_crs_none.la
lib/openmpi/mca_crs_none.so
-lib/openmpi/mca_dfs_app.a
-lib/openmpi/mca_dfs_app.la
-lib/openmpi/mca_dfs_app.so
-lib/openmpi/mca_dfs_orted.a
-lib/openmpi/mca_dfs_orted.la
-lib/openmpi/mca_dfs_orted.so
-lib/openmpi/mca_dfs_test.a
-lib/openmpi/mca_dfs_test.la
-lib/openmpi/mca_dfs_test.so
lib/openmpi/mca_errmgr_default_app.a
lib/openmpi/mca_errmgr_default_app.la
lib/openmpi/mca_errmgr_default_app.so
@@ -221,9 +212,6 @@ lib/openmpi/mca_iof_tool.so
lib/openmpi/mca_mpool_hugepage.a
lib/openmpi/mca_mpool_hugepage.la
lib/openmpi/mca_mpool_hugepage.so
-lib/openmpi/mca_notifier_syslog.a
-lib/openmpi/mca_notifier_syslog.la
-lib/openmpi/mca_notifier_syslog.so
lib/openmpi/mca_odls_default.a
lib/openmpi/mca_odls_default.la
lib/openmpi/mca_odls_default.so
@@ -288,6 +276,9 @@ lib/openmpi/mca_reachable_weighted.so
lib/openmpi/mca_regx_fwd.a
lib/openmpi/mca_regx_fwd.la
lib/openmpi/mca_regx_fwd.so
+lib/openmpi/mca_regx_naive.a
+lib/openmpi/mca_regx_naive.la
+lib/openmpi/mca_regx_naive.so
lib/openmpi/mca_regx_reverse.a
lib/openmpi/mca_regx_reverse.la
lib/openmpi/mca_regx_reverse.so
@@ -315,9 +306,6 @@ lib/openmpi/mca_rml_oob.so
lib/openmpi/mca_routed_binomial.a
lib/openmpi/mca_routed_binomial.la
lib/openmpi/mca_routed_binomial.so
-lib/openmpi/mca_routed_debruijn.a
-lib/openmpi/mca_routed_debruijn.la
-lib/openmpi/mca_routed_debruijn.so
lib/openmpi/mca_routed_direct.a
lib/openmpi/mca_routed_direct.la
lib/openmpi/mca_routed_direct.so
Re: Display flickers after upgrade to 6.6
I haven't tried those settings yet (in my case GNOME Shell and Xfdashboard cause the display to corrupt and seize up except the cursor) but ShadowPrimary is a glamor option that should be irrelevant if EXA is used.
For years I've also observed text flickering in the console after drm is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman should be fine with 8 million pixels.
--
Patrick Harper
paianni@fastmail.com
On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> On Sat, 19 Oct 2019 17:59:41 +0200
> Federico Giannici <giannici@neomedia.it> wrote:
>
> > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > Hi,
> > >
> > > I ran into the same issue this morning. Disabling the compositor
> > > worked for me, but I noticed later that this is also documented in
> > > the package readme:
> > >
> > > Screen compositor
> > > =================
> > > If you're using the modesetting X driver and experience window
> > > flickering when
> > > the compositor is enabled, you should force the window manager to
> > > use the XPresent method for vblank:
> > >
> > > $xfwm4 --vblank=xpresent --replace &
> >
> > I tried that command but it screwed all my windows (no more window
> > decorations and buttons, I cannot operate on windows)!
> > Now I had to came back to KDE...
> > :-(
> >
> > Regards
> >
> >
> > > This is documented upstream at
> > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > >
> > > Haven't tested that yet and left the compositor disabled, but I
> > > guess this will fix your issues. If it does, that's probably a good
> > > reminder to first look in the readme next time (me included). ;)
> > >
> > > Regards,
> > > André
> > >
>
> Hi, I thought I'd relate my experience: I also experienced this issue on
> a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> chipset and also running xfce. My workaround
> (which was based on 'try stuff to see what works') involved turning off
> compositing and
> (via xorg.conf.d):
>
> ...
> Option "AccelMethod" "EXA"
> Option "ShadowPrimary" "on"
> Option "SwapbuffersWait" "off"
> Option "EnablePageFlip" "off"
> ...
>
> This resolved issues with flickering, the mouse pointer vanishing and
> re-appearing depending on which window is below the pointer (enabling
> software mouse pointer for this was worse as garbage was rendered in a
> rect surrounding the pointer), and also *some* issues with logging
> in-out of an X session via xenodm.
>
> I still experience problems with the machine going to sleep and waking
> up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> at all, or the mouse pointer goes wonky.
>
> Beyond the aforementioned, this set-up seems to allow me to use the
> machine as before, however, I am not an X11 expert nor a radeondrm
> driver expert; your mileage may very.
>
> If I ever try Andre's hint in the future (thank-you), I might report on
> success/failure.
>
> regards,
>
> Jeff
>
>
For years I've also observed text flickering in the console after drm is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman should be fine with 8 million pixels.
--
Patrick Harper
paianni@fastmail.com
On Wed, 30 Oct 2019, at 13:12, Jeff wrote:
> On Sat, 19 Oct 2019 17:59:41 +0200
> Federico Giannici <giannici@neomedia.it> wrote:
>
> > On 2019-10-19 16:17, Andre Stoebe wrote:
> > > Hi,
> > >
> > > I ran into the same issue this morning. Disabling the compositor
> > > worked for me, but I noticed later that this is also documented in
> > > the package readme:
> > >
> > > Screen compositor
> > > =================
> > > If you're using the modesetting X driver and experience window
> > > flickering when
> > > the compositor is enabled, you should force the window manager to
> > > use the XPresent method for vblank:
> > >
> > > $xfwm4 --vblank=xpresent --replace &
> >
> > I tried that command but it screwed all my windows (no more window
> > decorations and buttons, I cannot operate on windows)!
> > Now I had to came back to KDE...
> > :-(
> >
> > Regards
> >
> >
> > > This is documented upstream at
> > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> > >
> > > Haven't tested that yet and left the compositor disabled, but I
> > > guess this will fix your issues. If it does, that's probably a good
> > > reminder to first look in the readme next time (me included). ;)
> > >
> > > Regards,
> > > André
> > >
>
> Hi, I thought I'd relate my experience: I also experienced this issue on
> a machine recently upgraded to OpenBSD 6.6 which uses the aruba
> chipset and also running xfce. My workaround
> (which was based on 'try stuff to see what works') involved turning off
> compositing and
> (via xorg.conf.d):
>
> ...
> Option "AccelMethod" "EXA"
> Option "ShadowPrimary" "on"
> Option "SwapbuffersWait" "off"
> Option "EnablePageFlip" "off"
> ...
>
> This resolved issues with flickering, the mouse pointer vanishing and
> re-appearing depending on which window is below the pointer (enabling
> software mouse pointer for this was worse as garbage was rendered in a
> rect surrounding the pointer), and also *some* issues with logging
> in-out of an X session via xenodm.
>
> I still experience problems with the machine going to sleep and waking
> up, as sometimes, upon wake-up, the graphics go wonky, or don't update
> at all, or the mouse pointer goes wonky.
>
> Beyond the aforementioned, this set-up seems to allow me to use the
> machine as before, however, I am not an X11 expert nor a radeondrm
> driver expert; your mileage may very.
>
> If I ever try Andre's hint in the future (thank-you), I might report on
> success/failure.
>
> regards,
>
> Jeff
>
>
Weekly Digest (with correction): Million pound fine for company after employee suffers amputation
| HSE's Weekly Digest e-bulletin: 31 October 2019 |
|
Health and Safety Executive - 5N1 Redgrave Court, Merton Road, Bootle, Merseyside L20 7HS
Subscribe to:
Posts (Atom)