OpenBSD Mail Box: June 2019

Sunday, June 30, 2019

Re: Evernote Alternative?

Just a little addendum to your final post:

I use OpenBSD as my desktop environment (also MAC OS and Linux) and I
was looking for years for an outline application which I can use on
every OS.

Finally I switched from open to (paid) closed source *sigh* but now most
of my problems were solved.

I use notecasepro, an I think I'm the only user who uses it on OpenBSD,
because I have to ask for a version running on an actual OpenBSD release.

And no, this is not an advertisement, but my personal result after
evaluating a lot of similar software which I can use on Linux, FreeBSD,
MacOS but not on OpenBSD.

Regards
Andre

Am 29.06.19 um 22:56 schrieb Chris Humphries:
> Final post.

textproc/p5-PDF-Table : Update to 0.11.0

Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/p5-PDF-Table/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile 21 Feb 2019 18:56:05 -0000 1.13
+++ Makefile 1 Jul 2019 06:14:01 -0000
@@ -2,12 +2,12 @@

COMMENT = create PDF tables with perl

-DISTNAME = PDF-Table-0.10.1
+DISTNAME = PDF-Table-0.11.0

CATEGORIES = textproc

# Perl
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes

MODULES = cpan
PKG_ARCH = *
Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/p5-PDF-Table/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo 21 Feb 2019 18:56:05 -0000 1.7
+++ distinfo 1 Jul 2019 06:14:01 -0000
@@ -1,2 +1,2 @@
-SHA256 (PDF-Table-0.10.1.tar.gz) = +y02nQl5funPeYEf+FBhu6jlbGHmXBOspnS1MhBaJxM=
-SIZE (PDF-Table-0.10.1.tar.gz) = 28459
+SHA256 (PDF-Table-0.11.0.tar.gz) = kUtcRnHaQArOFa7DIkSgvRWW4is05LNBp/KLJey0vZg=
+SIZE (PDF-Table-0.11.0.tar.gz) = 29930
Hi, ports@:

Here is a patch to update textproc/p5-PDF-Table to 0.11.0.
It build well and passed all tests on my amd64 head system.
No other ports depends on it.

Comments? OK ?

Regards,
wen

Re: Future of X.org?

On Mon, 1 Jul 2019, Juan Francisco Cantero Hurtado wrote:

> Xorg is the most insecure software in base.

Why? Because it has bugs? Or because, in oppossite to wayland,
it can listen to outside connections if configured so (by default
it does not)?

> If you only care about the remote apps, with wayland you can still run
> the apps within wayland. "ssh -X" will work fine.

I never do ssh -X. Nonsense in a LAN.

If X11 is so bad for you, then sure also nfs. Should it also be deletet?

> it is not a big lost for obvious reasons.

It is not a big lost *for you*.

Rodrigo.

Re: Future of X.org?

Roderick writes:
>
>
> On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
>
> > You can run (local or remote) X11 applications inside of a Wayland
> > compositor.
>
> The following contradicts your above assertion:
>
> https://wayland.freedesktop.org/faq.html#heading_toc_j_8

Wayland. The software product brought to you by the people with a FAQ containing this answer:

To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing.

followed by this question:

Why wasn't D-Bus used instead of the Wayland IPC mechanism?

and then finally this answer:

The alternative is to write a Wayland specific GL binding API, say, WaylandGL.

I don't think I'll be relying on software from such confused individuals any time soon.

Matthew

textproc/p5-PDF-API2: Update to 2.034

Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/p5-PDF-API2/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile 3 Jun 2019 16:06:57 -0000 1.23
+++ Makefile 1 Jul 2019 03:25:33 -0000
@@ -5,7 +5,7 @@ COMMENT = create PDF documents with perl
MODULES = cpan
PKG_ARCH = *

-DISTNAME = PDF-API2-2.033
+DISTNAME = PDF-API2-2.034
CATEGORIES = textproc

MAINTAINER = Stuart Henderson <sthen@openbsd.org>
Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/p5-PDF-API2/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo 23 Aug 2017 13:38:25 -0000 1.12
+++ distinfo 1 Jul 2019 03:25:33 -0000
@@ -1,2 +1,2 @@
-SHA256 (PDF-API2-2.033.tar.gz) = nAhm7BowU/c6+spfXNvmklkDtM5gb0v0rDF3MaadJ6A=
-SIZE (PDF-API2-2.033.tar.gz) = 3533753
+SHA256 (PDF-API2-2.034.tar.gz) = iqmIGPtuS+vW+QluIimJ3N1f1MX6KtHH8BSQU/xo8cw=
+SIZE (PDF-API2-2.034.tar.gz) = 3510253
Hi,

Here is a patch to update textproc/p5-PDF-API2 to 2.034. It build well and passed
all test on my amd64 system.

Two ports depends on it, textproc/p5-PDF-API2-Simple and textproc/p5-PDF-Table.
Both build well and passed all tests.

Comments? OK?

Regards,
wen

NEW: py-query

Here is www/py-query a new port. pyquery is a jquery like facility for
Python.

This is one of the missing TEST_DEPENDS for www/py-webtest, along with
WSGIProxy2 (Which I sent out earlier as a potential replacement for
www/py-wsgiproxy).

--Kurt

Update: www/py-beautifulsoup4 4.6.3 -> 4.7.1

Here is an update for www/py-beautifulsoup4 to the latest, 4.7.1.

It requires the new www/py-soupsieve port I sent out earlier tonight.
It converts over to using MODPY_PI so discards the MASTER_SITES line.
I also convert it to using standard MODPY-PYTEST rather than the
custom do-test target.

Of its TEST_DEPENDS consumers (which seems to be all its RUN_DEPENDS
consumers except x11/nagstamon), all the ports that have working
tests have all tests pass. The following ports tests didn't work:
audio/beets(tries to pull down responses over the net, I'm running
PORTS_PRIVSEP), net/py-siphon(missing dedepencies), www/buku (missing
dependencies), math/py-pandas(broken with pytest which complains about
calling fixtures directly), and security/wapiti (No tests to run).

I filled in missing dependencies for www/py-webtest to run its tests and
they all pass. Also passing on amd64 are net/toot, textproc/py-ofxparse,
and security/theharvester(the one test it has passes).

Originally I just set out to figure out why bs4's tests wouldn't run
directly via "make test". I had to run "make fake" first. If this update
isn't wanted at this point, I do have a separate diff for 4.6.3 that
irons out the weirdness with testing.

cc maintainer

--Kurt

Index: Makefile
===================================================================
RCS file: /cvs/ports/www/py-beautifulsoup4/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile 28 Apr 2019 20:51:58 -0000 1.10
+++ Makefile 30 Jun 2019 02:30:47 -0000
@@ -2,32 +2,30 @@

COMMENT = HTML/XML parser that supports invalid markup

-MODPY_EGG_VERSION = 4.6.3
+MODPY_EGG_VERSION = 4.7.1
DISTNAME = beautifulsoup4-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 0

CATEGORIES = www

-HOMEPAGE = http://www.crummy.com/software/BeautifulSoup/
+HOMEPAGE = https://www.crummy.com/software/BeautifulSoup/
MAINTAINER = frantisek holop <minusf@obiit.org>

# MIT
-PERMIT_PACKAGE_CDROM = Yes
-
-MASTER_SITES = ${HOMEPAGE}bs4/download/4.6/
+PERMIT_PACKAGE = Yes

MODULES = lang/python

-TEST_DEPENDS = devel/py-html5lib${MODPY_FLAVOR} \
- textproc/py-lxml${MODPY_FLAVOR}
-
FLAVORS = python3
FLAVOR ?=

MODPY_SETUPTOOLS = Yes
+MODPY_PI = Yes
+MODPY_PYTEST = Yes
+MODPY_PYTEST_ARGS = lib/bs4

-do-test: fake
- cd ${WRKINST}${MODPY_SITEPKG} && ${MODPY_BIN} -m unittest discover -s bs4
+RUN_DEPENDS = www/py-soupsieve${MODPY_FLAVOR}
+TEST_DEPENDS = devel/py-html5lib${MODPY_FLAVOR} \
+ textproc/py-lxml${MODPY_FLAVOR}

.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/py-beautifulsoup4/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo 1 Jan 2019 09:02:17 -0000 1.7
+++ distinfo 30 Jun 2019 02:30:47 -0000
@@ -1,2 +1,2 @@
-SHA256 (beautifulsoup4-4.6.3.tar.gz) = kPjmESHWrlg2LOO+2M2ZfvsAyRTq4P89Njwy+amCLRA=
-SIZE (beautifulsoup4-4.6.3.tar.gz) = 167469
+SHA256 (beautifulsoup4-4.7.1.tar.gz) = lFBll5+4Up3S8327WPALZhvby+v5VPk7Mv31Jj7zU0g=
+SIZE (beautifulsoup4-4.7.1.tar.gz) = 167065

New: www/py-soupsieve

This is www/py-soupsieve. From the description:

"Soup Sieve is a CSS selector library designed to be used with Beautiful
Soup 4. It aims to provide selecting, matching, and filtering using
modern CSS selectors."

It is needed for www/py-beautifulsoup4 4.7.0+ as the CSS Selector
implementation in bs4 was replaced with a dependency on soupsieve.

All of its regression test pass for both python2 and python3 on
amd64 and sparc64. Well, all of its tests pass with the updated
py-beauitfulsoup4. 13 tests fail on the existing 4.6.3 version of bs4
(for both amd64 and sparc64).

I'm cc'ing the py-beautifulsoup4 maintainer since this precedes the
py-beautifulsoup4 update I'm testing.

--Kurt

Update: deve/py-freezegun 0.3.9 -> 0.3.12

This updates py-freezegun to 0.3.12. Our current version isn't compatible
with Python 3.7.x so anything python3 that uses py-freezegun for tests is
currently broken.

I tested all consumers of py-freezegun. The only change that isn't 100%
positive is the python 2 flavor of py-cached-property fails one test
now:

======================================================================
FAIL: test_threads_ttl_expiry (tests.test_cached_property.TestCachedPropertyWithTTL)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/ports/pobj/py-cached-property-1.5.1/cached-property-1.5.1/tests/test_cached_property.py", line 207, in test_threads_ttl_expiry
self.assert_cached(check, 2 * num_threads)
File "/home/ports/pobj/py-cached-property-1.5.1/cached-property-1.5.1/tests/test_cached_property.py", line 69, in assert_cached
self.assertEqual(check.add_cached, expected)
AssertionError: 6 != 10

All others are the smae or better. Especially the python3 flavors, since
none of them worked before this update.

py-test-benchmark tests don't run before or after this update. I'm looking
into why that is the case.

cc maintainer

--Kurt

Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/py-freezegun/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile 15 May 2019 12:04:36 -0000 1.4
+++ Makefile 28 Jun 2019 06:25:59 -0000
@@ -2,22 +2,22 @@

COMMENT = let your Python tests travel through time

-MODPY_EGG_VERSION = 0.3.9
+MODPY_EGG_VERSION = 0.3.12
DISTNAME = freezegun-${MODPY_EGG_VERSION}
PKGNAME = py-freezegun-${MODPY_EGG_VERSION}
-REVISION = 0

CATEGORIES = devel

MAINTAINER = Joerg Jung <jung@openbsd.org>

# Apache 2.0
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes

MODULES = lang/python

MODPY_PI = Yes
MODPY_SETUPTOOLS = Yes
+MODPY_PYTEST = Yes

RUN_DEPENDS = devel/py-dateutil${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR}
@@ -28,8 +28,9 @@ TEST_DEPENDS = devel/py-nose${MODPY_FLA
FLAVORS = python3
FLAVOR ?=

-do-test:
- cd ${WRKSRC} && \
- ${LOCALBASE}/bin/nosetests${MODPY_BIN_SUFFIX} tests/*.py
+.if !${FLAVOR:Mpython3}
+post-extract:
+ rm ${WRKSRC}/freezegun/_async.py
+.endif

.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/py-freezegun/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo 27 May 2017 19:26:52 -0000 1.2
+++ distinfo 28 Jun 2019 06:25:59 -0000
@@ -1,2 +1,2 @@
-SHA256 (freezegun-0.3.9.tar.gz) = eDzMzX9glov+Sa2eEUwY6itjgx+qr2HB8fcd394cDu4=
-SIZE (freezegun-0.3.9.tar.gz) = 18118
+SHA256 (freezegun-0.3.12.tar.gz) = Kk2cjNPASiAeIMMTyvi2M48c+kzaQ/RqlMxKn9E+pec=
+SIZE (freezegun-0.3.12.tar.gz) = 24346
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/py-freezegun/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 26 May 2017 19:26:15 -0000 1.1.1.1
+++ pkg/PLIST 28 Jun 2019 06:25:59 -0000
@@ -9,5 +9,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/freezegun/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/freezegun/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/freezegun/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/freezegun/${MODPY_PYCACHE}_async.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/freezegun/${MODPY_PYCACHE}api.${MODPY_PYC_MAGIC_TAG}pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/freezegun/_async.py
lib/python${MODPY_VERSION}/site-packages/freezegun/api.py

Re: NEW: Tacacs+ port - shrubbery.net version

Hi sthen,

> Slightly tweaked version attached, this one's ok with me:
>
> - https homepage
> - PERMIT_*_CDROM is not used for new ports
> - whitespace nit in Makefile
> - tweak comment in patch
> - place @extraunexec above the @sample line, that way pkg_delete -c doesn't
> complain about a missing dir. (pkg_delete without -c will complain about
> not being able to remove the dir, that is no problem).
> - regen plist to include pkg-readme
> - adjust pkg-readme to set uid/gid on the files
> - change group ownership of log dir to wheel, easier for admins

thanks for the review, gonna commit this one.

Re: Future of X.org?

I make a mistake by writting this mail, but:

On Sun, Jun 30, 2019 at 09:09:08PM +0000, Roderick wrote:
>
> On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
>
> > Nope, you misunderstood the text.
>
> No. It is *you* that do not understand what X11 is and want it death.
> A very destructive attitude.
>

No, it's your attitude is destructive.

> > "This doesn't mean that remote rendering won't be possible with Wayland,
> > it just means that you will have to put a remote rendering server on top
> > of Wayland. One such server could be the X.org server".
>
> You quote the text and are unable to get the conclusion: having
> wayland, if you need X11, then you must implement an X11 server.
>
> Is it not clear from the text that for upgrading wayland to X11,
> you must implement X11, and the autor avoided it for keeping it simple?
>
> Is it not clear that wayland is *never* a substitute of X11?
>
> You confuse X11 with a graphical display, such the old ones of
> Amiga or MacOS. It was always possible to have it in unix. But
> that was never the purpose of X11. The graphic display is only
> a byproduct of X11.
>
> I remember in the 1990s that it was possible to run a comercial
> X11 in Macs: They had their graphical display, but that was neither X11
> nor a substituite of it. But you are trying to convince us that
> wayland is a substitute of X11, that X11 must die.
>
> And Xorg / xenocara is not bloat: it runs on meager X11 terminals.
> The bloat will come with wayland.
>
> And X11 imposes an standard. Programs done as X11 clients may run in
> any OS display in other. Wayland will bring chaos.
>
> Rodrigo
>

You are a liar, the Xenocara is a bloat. X11 is a bloat and its implementation
called X.org is a greater bloat. Mesa is a bloat, it's a shit fat C++ library.

X Window System is just a shit windowing system while Wayland is a simple,
fast and secure display server protocol.
(Well, almost simple, this XML dependance is overkill.)

You people protecting X make me doubt that OpenBSD aims security, I am
agree with Linus Torvalds who called us monkeys.

Re: Future of X.org?

On Sun, Jun 30, 2019 at 09:09:08PM +0000, Roderick wrote:
>
> On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
>
> > Nope, you misunderstood the text.
>
> No. It is *you* that do not understand what X11 is and want it death.
> A very destructive attitude.

You're the only one with a destructive attitude here. I'm trying to help
you because usually people doesn't understand how wayland works.

X11 and Wayland are both protocols. Xorg is just a server and will die
because nobody contributes to it. As usual, a lot of people complains
but nobody expend their time working on those projects.

The X11 protocol will live for decades. Xorg will die.

Xorg is the most insecure software in base. Running your X11 apps inside
of Wayland will be more secure than running the same apps inside of a
full installation of Xorg.

>
> > "This doesn't mean that remote rendering won't be possible with Wayland,
> > it just means that you will have to put a remote rendering server on top
> > of Wayland. One such server could be the X.org server".
>
> You quote the text and are unable to get the conclusion: having
> wayland, if you need X11, then you must implement an X11 server.

The X11 server for wayland has been available for years.

>
> Is it not clear from the text that for upgrading wayland to X11,
> you must implement X11, and the autor avoided it for keeping it simple?

The author wanted a secure and low latency alternative to X11 for local
use, not remote. He didn't want a reimplementation of X11. There is not
a "upgrading" thing.

Anything using GTK, EFL or QT will work transparently on wayland. And
you still have compatibility with X11 available.

>
> Is it not clear that wayland is *never* a substitute of X11?
>
> You confuse X11 with a graphical display, such the old ones of
> Amiga or MacOS. It was always possible to have it in unix. But
> that was never the purpose of X11. The graphic display is only
> a byproduct of X11.
>
> I remember in the 1990s that it was possible to run a comercial
> X11 in Macs: They had their graphical display, but that was neither X11
> nor a substituite of it. But you are trying to convince us that
> wayland is a substitute of X11, that X11 must die.

Again. Nope. Wayland is a substitute for the layer bellow of the
local graphical apps. The most common use of X11 nowadays.

If you only care about the remote apps, with wayland you can still run
the apps within wayland. "ssh -X" will work fine.

The only missing part here is the client-server architecture to send
unencrypted traffic over the network. Which for a OS like OpenBSD, it's
not a big lost for obvious reasons.

I'm not trying to convince you. I only replied because you said: "I also
have no much idea of what is wayland". And now you're ranting and
complaining how destructive I am. I'm not the problem here.

>
> And Xorg / xenocara is not bloat: it runs on meager X11 terminals.
> The bloat will come with wayland.

Right. The Xorg project code is quite small.

>
> And X11 imposes an standard. Programs done as X11 clients may run in
> any OS display in other. Wayland will bring chaos.

X11 brought insecurity.

Have a nice day and for the next time, try not to be an ass with people
who is trying to help you.

--
Juan Francisco Cantero Hurtado http://juanfra.info

Re: Future of X.org?

On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:

> Nope, you misunderstood the text.

No. It is *you* that do not understand what X11 is and want it death.
A very destructive attitude.

> "This doesn't mean that remote rendering won't be possible with Wayland,
> it just means that you will have to put a remote rendering server on top
> of Wayland. One such server could be the X.org server".

You quote the text and are unable to get the conclusion: having
wayland, if you need X11, then you must implement an X11 server.

Is it not clear from the text that for upgrading wayland to X11,
you must implement X11, and the autor avoided it for keeping it simple?

Is it not clear that wayland is *never* a substitute of X11?

You confuse X11 with a graphical display, such the old ones of
Amiga or MacOS. It was always possible to have it in unix. But
that was never the purpose of X11. The graphic display is only
a byproduct of X11.

I remember in the 1990s that it was possible to run a comercial
X11 in Macs: They had their graphical display, but that was neither X11
nor a substituite of it. But you are trying to convince us that
wayland is a substitute of X11, that X11 must die.

And Xorg / xenocara is not bloat: it runs on meager X11 terminals.
The bloat will come with wayland.

And X11 imposes an standard. Programs done as X11 clients may run in
any OS display in other. Wayland will bring chaos.

Rodrigo

6.5 pkg_add "Fatal error: Can't write session into tmp directory"

I have 6.5/i386 installed on a PC Engines alix board (hostname 'sodium'),
acting as a home firewall and router. I'd like to install some packages
the firewall it to make system adminstration easier. So... I downloaded
the appropriate 6./i386 packages from a nearby OpenBSD mirror, ssh-ed them
to /tmp on the firewall, and then (logged into the firewall as root) tried
to pkg_add them. Alas, pkg_add failed with an error message about being
unable to write into a temp directory:

sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz
Fatal error: Can't write session into tmp directory
at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025.
sodium#

I've checked that the firewall has adequate free memory & swap space,
that all the obviously-relevant filesystems are mounted read-write and
have free inodes and disk space, and that 'touch foo' can create a new
file in each of /tmp, /var/tmp, and /usr/tmp.

Is there something obvious I'm overlooked here? A Fine Man Page I should
be rereading before I start hacking debug prints into the pkg_add (perl)
source code?

Further information (cut-and-pasted from ssh session on the firewall):

sodium# uname -a
OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#1 i386
sodium# df -hi
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/wd0a 378M 47.7M 311M 13% 1771 47379 4% /
mfs:54350 62.9M 2.0M 57.7M 3% 8 8182 0% /tmp
/dev/wd0e 677M 15.1M 628M 2% 352 87710 0% /var
/dev/wd0f 1.5G 698M 734M 49% 16248 191622 8% /usr
mfs:42325 62.9M 2.0K 59.7M 0% 1 8189 0% /usr/tmp
/dev/wd0g 516M 138M 352M 28% 8980 58602 13% /usr/X11R6
/dev/wd0h 1.7G 218K 1.6G 0% 110 233744 0% /usr/local
/dev/wd0j 5.1G 2.0K 4.8G 0% 1 701565 0% /usr/obj
/dev/wd0i 1.3G 2.0K 1.3G 0% 1 181885 0% /usr/src
sodium# cat /etc/fstab
5fd63b50b0c6cb1d.a / ffs rw,softdep,noatime 1 1
5fd63b50b0c6cb1d.d /tmp mfs rw,async,nodev,nosuid,-s=64m 0 0
5fd63b50b0c6cb1d.e /var ffs rw,softdep,noatime,nodev,nosuid 1 2
5fd63b50b0c6cb1d.f /usr ffs rw,softdep,noatime,nodev 1 2
5fd63b50b0c6cb1d.d /usr/tmp mfs rw,async,nodev,nosuid,-s=64m 0 0
5fd63b50b0c6cb1d.g /usr/X11R6 ffs rw,softdep,noatime,nodev 1 2
5fd63b50b0c6cb1d.h /usr/local ffs rw,softdep,noatime,wxallowed,nodev 1 2
5fd63b50b0c6cb1d.j /usr/obj ffs rw,softdep,noatime,nodev,nosuid 1 2
5fd63b50b0c6cb1d.i /usr/src ffs rw,softdep,noatime,nodev,nosuid 1 2
sodium# top|head
load averages: 0.08, 0.02, 0.01 sodium.bkis-orchard.net 13:12:00
52 processes: 1 running, 50 idle, 1 on processor up 14 days, 5:21
CPU: 0.1% user, 0.0% nice, 0.3% sys, 0.0% spin, 0.3% intr, 99.3% idle
Memory: Real: 35M/110M act/tot Free: 127M Cache: 46M Swap: 0K/548M

PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
59735 root 10 0 0K 19M sleep bored 44:53 0.44% softnet
65312 root -22 0 0K 19M sleep - 339.9H 0.00% idle0
57981 root 10 0 0K 19M sleep bored 7:56 0.00% sensors
39371 _unbound 2 0 12M 10M sleep kqread 1:33 0.00% unbound
sodium# cd /tmp
sodium# ls -l
total 4144
drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .ICE-unix
drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .X11-unix
-rw-r--r-- 1 root wheel 1499861 Jun 30 12:31 lynx-2.8.9rel1.tgz
drwxr-xr-x 2 root wheel 512 Jun 16 07:51 sndio
-rw-r--r-- 1 root wheel 564428 Jun 30 12:31 tcsh-6.20.00p1-static.tgz
drwxrwxrwt 2 root wheel 512 Jun 30 12:33 vi.recover
sodium#
sodium# pkg_info
sodium#
sodium# which pkg_add
/usr/sbin/pkg_add
sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz
Fatal error: Can't write session into tmp directory
at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025.
sodium# env
_=/usr/bin/env
LOGNAME=root
PWD=/tmp
HOME=/root
OLDPWD=/tmp
SSH_TTY=/dev/ttyp0
TOP=-S -i -s1
MAIL=/var/mail/root
SSH_CLIENT=192.168.105.0 4099 22
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
TERM=xterm
SHELL=/bin/ksh
SSH_CONNECTION=192.168.105.0 4099 192.168.105.62 22
USER=root
sodium# cd /tmp
sodium# touch foo
sodium# ls -l foo
-rw-r--r-- 1 root wheel 0 Jun 30 13:07 foo
sodium# /bin/rm foo
sodium#
sodium# cd /var/tmp
sodium# touch foo
sodium# ls -l foo
-rw-r--r-- 1 root wheel 0 Jun 30 13:08 foo
sodium# /bin/rm foo
sodium#
sodium# cd /usr/tmp
sodium# touch foo
sodium# ls -l foo
-rw-r--r-- 1 root wheel 0 Jun 30 13:13 foo
sodium# /bin/rm foo
sodium#

Thanks in advance for any assistance,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn@astro.indiana-zebra.edu>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
currently on the west coast of Canada
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"

Re: man bgpd.conf + question

Thank you for your answer Claudio

Le samedi 29 juin 2019 à 19:56:41 UTC+2, Claudio Jeker <cjeker@diehard.n-r-g.com> a écrit :

On Fri, Jun 28, 2019 at 10:52:01PM +0000, Mik J wrote:
> Hello,
> I have a syntax error with announce none
> group "spam-bgp" {
>     remote-as           $spamASN
>     multihop 64
>     announce none
>
> I was told recently that everything is filtered by default from 6.4 and read on Internet that announce none is deprecated
> However man bgpd.conf (Openbsd 6.5) still has this command in section "NEIGHBORS AND GROUPS"announce (IPv4|IPv6) (none|unicast|vpn)
>
> Do you know what is correct ?

There is a difference between:
    announce none
and
    announce IPv4 none
or
    announce IPv6 none

The frist one no longer exists. The 2nd one still works and disables the
multiprotocol capability for the define AFI (IPv4 or IPv6).
By default the session enables the unicast AFI for the IP family that the
session uses. (e.g. announce IPv6 unicast for IPv6 sessions) and the other
AFI is disabled.

--
:wq Claudio

sparc64 bulk build report

Re: Future of X.org?

On Sun, Jun 30, 2019 at 06:55:42PM +0000, Roderick wrote:
>
>
> On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
>
> > You can run (local or remote) X11 applications inside of a Wayland
> > compositor.
>
> The following contradicts your above assertion:
>
> https://wayland.freedesktop.org/faq.html#heading_toc_j_8

Nope, you misunderstood the text.

"This doesn't mean that remote rendering won't be possible with Wayland,
it just means that you will have to put a remote rendering server on top
of Wayland. One such server could be the X.org server".

So, you will need a nested X11 server. Like you need on Windows or
MacOS. That's all.

You will see a desktop (compositor) running on top of Wayland, a browser
(just an example) window using also Wayland and your X11 applications
running like native applications.

--
Juan Francisco Cantero Hurtado http://juanfra.info

Re: Future of X.org?

On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:

> You can run (local or remote) X11 applications inside of a Wayland
> compositor.

The following contradicts your above assertion:

https://wayland.freedesktop.org/faq.html#heading_toc_j_8

Rod.

NEW: multimedia/gerbera [WIP]

Here's a working port for gerbera, but I never really used it since my
use case for it disappeared soon after getting the port done.

The server starts, full offline documentation is available, one (small?)
nit with inotify support remains unsolved, otherwise the port is in good
shape.

You'll find comments in the Makefile, active upstream work towards C++17
and an almost ready rc.d script where proper daemon user integration
shouuld be worked out.

So in case anyone is interested in this, feel free to pick it up,
improve things and perhaps import it. I'll gladly review things and
would be even happier so see someone maintain it, but I personally put
any more effort into it for above mentioned reasons.

Information for inst:gerbera-1.3.1

Comment:
UPnP Media Server

Description:
gerbera is a UPnP media server which allows you to stream your digital media
through your home network and consume it on a variety of UPnP compatible
devices.

Features include:

* Browse and playback your media via your network on all kinds of devices.
* Metadata extraction from MP3, OGG, AAC, M4A, FLAC, JPG (and many more!) files.
* Media thumbnail support
* Web UI with a tree view of the database and the file system, allowing to
add/remove/edit/browse your media
* Highly flexible media format transcoding via plugins / scripts
* Automatic directory rescans (timed, inotify)
* User defined server layout based on extracted metadata
* On the fly video thumbnail generation with libffmpegthumbnailer
* Support for external URLs (create links to internet content and serve them via
UPnP to your renderer)

Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>

WWW: https://github.com/gerbera/gerbera

Re: Future of X.org?

On Sun, Jun 30, 2019 at 03:59:55PM +0000, Roderick wrote:
>
>
> On Fri, 28 Jun 2019, gwes wrote:
>
> > I regularly run programs on one machine connected to a display
> > on another machine. AFAIK, the current state of Wayland makes
> > that difficult. I confess to not following it closely.
>
> I also do it, and I also have no much idea of what is wayland.
>
> But I have the impression that some people want to substitute X11
> with something that is not a replacement for it, that has other
> functionality. They confuse X11 with a mere graphical surface.

You can run (local or remote) X11 applications inside of a Wayland
compositor.

--
Juan Francisco Cantero Hurtado http://juanfra.info

Re: [maintainer update] www/p5-Mojo 8.18

Hi,

On Sun, 30 Jun 2019 20:11:01 +0300
Manolis Tzanidakis wrote:

> Hello,
> this diff updates www/p5-Mojo to 8.18. All tests pass.

Thanks!

I've found no issues while testing direct consumers as well.

We should move to PERMIT_PACKAGE though.

OK cwen@ (i'll commit and make the PERMIT_PACKAGE change
with another OK).

> Changes: https://metacpan.org/release/SRI/Mojolicious-8.18
>

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/www/p5-Mojo/Makefile,v
> retrieving revision 1.34
> diff -u -p -u -r1.34 Makefile
> --- Makefile 30 Apr 2019 02:11:35 -0000 1.34
> +++ Makefile 30 Jun 2019 17:06:43 -0000
> @@ -4,7 +4,7 @@ COMMENT = next generation web framework
>
> MODULES = cpan
> PKG_ARCH = *
> -DISTNAME = Mojolicious-8.15
> +DISTNAME = Mojolicious-8.18
> CATEGORIES = www
>
> MAINTAINER = Manolis Tzanidakis <mtzanidakis@gmail.com>
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/www/p5-Mojo/distinfo,v
> retrieving revision 1.26
> diff -u -p -u -r1.26 distinfo
> --- distinfo 30 Apr 2019 02:11:35 -0000 1.26
> +++ distinfo 30 Jun 2019 17:06:43 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (Mojolicious-8.15.tar.gz) =
> yFArI+TyE1RIYfIECjTf6nLj0QkzVcJMcPEtZdB37Ns= -SIZE
> (Mojolicious-8.15.tar.gz) = 755156 +SHA256 (Mojolicious-8.18.tar.gz)
> = /naCG/ir5sZKar4uMnIQ9WSgycsMX03DLC26DUO3AG4= +SIZE
> (Mojolicious-8.18.tar.gz) = 761103
>

Re: llvm-7.0.1 fallout: lang/crystal

On Sun, Jun 30, 2019 at 06:18:38PM +0200, Jeremie Courreges-Anglas wrote:
>
> Hi Wesley,
>
> On Wed, Feb 13 2019, Wesley Moxam <wesley.moxam@gmail.com> wrote:
> >> On Feb 13, 2019, at 7:47 AM, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
> >>
> >>> On Thu, Feb 07 2019, Stuart Henderson <stu@spacehopper.org> wrote:
> >>>> On 2019/02/07 18:02, Jeremie Courreges-Anglas wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm not sure you were notified so here's a heads-up: lang/crystal
> >>>> doesn't build any more after the update to clang 7 in both base and
> >>>> ports.
> >>>
> >>> Not handled upstream yet.
> >>> https://github.com/crystal-lang/crystal/issues/6754
> >>
> >> Wesley, I see that you have commented on this issue. Do you mind if
> >> we mark lang/crystal as temporarily BROKEN?
> >
> > That's fine with me. It may be a while before the issue is fixed
>
> Any news regarding lang/crystal? The issue is still open and "@bcardiff
> removed this from the 0.28.0 milestone on Mar 27".
>
> If upstream doesn't plan to support newer llvm releases and no
> alternative fix is found, then the port should be removed.

I don't know much about it, but can't it be built with ports gcc?

--
Antoine

L2TP/IPSec PSK with Android -- INVALID_ID_INFORMATION

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js v4.5.1
Comment: https://openpgpjs.org

xjMEXLy3oxYJKwYBBAHaRw8BAQdA1u+3PBDg+JyMo01717GQuPnJCv7coei7
Wa/mZ7ehSj/NJSJsZXZhQGVjZW50cnVtLmh1IiA8bGV2YUBlY2VudHJ1bS5o
dT7CdwQQFgoAHwUCXLy3owYLCQcIAwIEFQgKAgMWAgECGQECGwMCHgEACgkQ
DEGOClIQCPwAQwEA6t0v62AryOh8TC7zQ1UsKX11XnTCe/VdltU2oPo8GpkB
AMMJ9i4sNsD+n2mFEARyCjeDCgT8aDgYpVdOZMbmwWkEzjgEXLy3oxIKKwYB
BAGXVQEFAQEHQEAbn78Ua1uhxrBz+4GqkHFZ7S+DSqU6YLDGruK/PLUDAwEI
B8JhBBgWCAAJBQJcvLejAhsMAAoJEAxBjgpSEAj8moABALrjTKLxEnoTBfxb
HiYXWaZxlubOPO2zpz/f9ZBRqGz4AP4/a0fJisj8dDrGf/7JnVonh+KF7L98
v0SH1CTPXK6gDA==
=r0Cq
-----END PGP PUBLIC KEY BLOCK-----
Hi all!

I know (saw) this has come up numerous times, and someone has been successful, others weren't. I thought I'd try this out myself, and not surprisingly it wasn't successful :)
I've been using these howtos [1] -- I know these can be outdated and/or simply wrong, I just wanted to get the general idea on how to tackle this.
I've made it through a couple of hurdles but now I'm stuck and thought I'd ask some questions here.

So this is my configuration:
OpenBSD 6.5-stable

/etc/ipsec.conf:
ike passive esp transport \
proto udp \
from any to any port l2tp \
main auth "hmac-sha2" enc "aes-256" group modp1024 \
quick auth "hmac-sha2" enc "aes-256" \
psk "thisismykey"

(I found that some howtos specified the group attribute for the line `quick` as well, but that didn't work for me, then it seemed this whole thing just wouldn't match my connection)

I'm starting isakmpd(8) as
/sbin/isakmpd -d -v -K

Then doing an:
/sbin/ipsecctl -vf /etc/ipsec.conf
=====================8<=====================
C set [Phase 1]:Default=peer-default force
C set [peer-default]:Phase=1 force
C set [peer-default]:Authentication=thisismykey force
C set [peer-default]:Configuration=phase1-peer-default force
C set [phase1-peer-default]:EXCHANGE_TYPE=ID_PROT force
C add [phase1-peer-default]:Transforms=phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:HASH_ALGORITHM=SHA2_256 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:KEY_LENGTH=256,256:256 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:Life=LIFE_MAIN_MODE force
C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Phase=2 force
C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:ISAKMP-peer=peer-default force
C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Configuration=phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force
C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Local-ID=from-0.0.0.0/0=17 force
C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Remote-ID=to-0.0.0.0/0=17:1701 force
C set [phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:EXCHANGE_TYPE=QUICK_MODE force
C set [phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Suites=phase2-suite-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force
C set [phase2-suite-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Protocols=phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force
C set [phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:PROTOCOL_ID=IPSEC_ESP force
C set [phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Transforms=phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:TRANSFORM_ID=AES force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:KEY_LENGTH=256,256:256 force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:ENCAPSULATION_MODE=TRANSPORT force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:GROUP_DESCRIPTION=MODP_3072 force
C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:Life=LIFE_QUICK_MODE force
C set [from-0.0.0.0/0=17]:ID-type=IPV4_ADDR_SUBNET force
C set [from-0.0.0.0/0=17]:Network=0.0.0.0 force
C set [from-0.0.0.0/0=17]:Netmask=0.0.0.0 force
C set [to-0.0.0.0/0=17:1701]:ID-type=IPV4_ADDR_SUBNET force
C set [to-0.0.0.0/0=17:1701]:Network=0.0.0.0 force
C set [to-0.0.0.0/0=17:1701]:Netmask=0.0.0.0 force
C set [from-0.0.0.0/0=17]:Protocol=17 force
C set [to-0.0.0.0/0=17:1701]:Protocol=17 force
C set [to-0.0.0.0/0=17:1701]:Port=1701 force
C add [Phase 2]:Passive-Connections=from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701
C set [Phase 1]:Default=peer-default force
C set [peer-default]:Phase=1 force
C set [peer-default]:Authentication=thisismykey force
C set [peer-default]:Configuration=phase1-peer-default force
C set [phase1-peer-default]:EXCHANGE_TYPE=ID_PROT force
C add [phase1-peer-default]:Transforms=phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:HASH_ALGORITHM=SHA2_256 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:KEY_LENGTH=256,256:256 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force
C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:Life=LIFE_MAIN_MODE force
C set [from-::/0=17-to-::/0=17:1701]:Phase=2 force
C set [from-::/0=17-to-::/0=17:1701]:ISAKMP-peer=peer-default force
C set [from-::/0=17-to-::/0=17:1701]:Configuration=phase2-from-::/0=17-to-::/0=17:1701 force
C set [from-::/0=17-to-::/0=17:1701]:Local-ID=from-::/0=17 force
C set [from-::/0=17-to-::/0=17:1701]:Remote-ID=to-::/0=17:1701 force
C set [phase2-from-::/0=17-to-::/0=17:1701]:EXCHANGE_TYPE=QUICK_MODE force
C set [phase2-from-::/0=17-to-::/0=17:1701]:Suites=phase2-suite-from-::/0=17-to-::/0=17:1701 force
C set [phase2-suite-from-::/0=17-to-::/0=17:1701]:Protocols=phase2-protocol-from-::/0=17-to-::/0=17:1701 force
C set [phase2-protocol-from-::/0=17-to-::/0=17:1701]:PROTOCOL_ID=IPSEC_ESP force
C set [phase2-protocol-from-::/0=17-to-::/0=17:1701]:Transforms=phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:TRANSFORM_ID=AES force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:KEY_LENGTH=256,256:256 force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:ENCAPSULATION_MODE=TRANSPORT force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:GROUP_DESCRIPTION=MODP_3072 force
C set [phase2-transform-from-::/0=17-to-::/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:Life=LIFE_QUICK_MODE force
C set [from-::/0=17]:ID-type=IPV6_ADDR_SUBNET force
C set [from-::/0=17]:Network=:: force
C set [from-::/0=17]:Netmask=:: force
C set [to-::/0=17:1701]:ID-type=IPV6_ADDR_SUBNET force
C set [to-::/0=17:1701]:Network=:: force
C set [to-::/0=17:1701]:Netmask=:: force
C set [from-::/0=17]:Protocol=17 force
C set [to-::/0=17:1701]:Protocol=17 force
C set [to-::/0=17:1701]:Port=1701 force
C add [Phase 2]:Passive-Connections=from-::/0=17-to-::/0=17:1701
=====================8<=====================

/etc/npppd/npppd.conf:
=====================8<=====================
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}

tunnel L2TP protocol l2tp {
listen on 0.0.0.0
listen on ::
}

ipcp IPCP {
pool-address 192.168.100.2-192.168.100.254
dns-servers 8.8.8.8
}

# use pppx(4) interface. use an interface per a ppp session.
interface pppx0 address 192.168.100.1 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0
=====================8<=====================

So now when I connect from my Android 9 phone, set up as an L2TP/IPsec PSK connection, specifying the Server address as my internal LAN IP on the OpenBSD router (no NAT, just direct connection on the local network), setting the IPSec preshared key to the real key, and entering my username and password I've set for npppd(8), I'm getting this output from isakmpd(8):
=====================8<=====================
190048.505560 Default attribute_unacceptable: HASH_ALGORITHM: got SHA2_384, expected SHA2_256
190048.505768 Default attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1024, expected MODP_3072
190048.505943 Default attribute_unacceptable: HASH_ALGORITHM: got SHA2_384, expected SHA2_256
190048.530050 Default isakmpd: phase 1 done (as responder): initiator id 192.168.5.17, responder id 192.168.0.1, src: 192.168.0.1 dst: 192.168.5.17
190049.556596 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190049.556699 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190052.571991 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190052.572093 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190055.594500 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190055.594593 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190058.615783 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190058.615909 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190101.642382 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190101.642478 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190104.674817 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190104.674885 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190107.702932 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190107.703001 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190110.728935 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190110.729004 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190113.760991 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190113.761061 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
190116.770799 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.5.17, responder id 192.168.0.1
190116.770869 Default dropped message from 192.168.5.17 port 500 due to notification type INVALID_ID_INFORMATION
=====================8<=====================

Now I'm stuck here. I don't really know why it wouldn't accept these "IDs", I thought I've covered all my bases with "from any/to any" in ipsec.conf(5).
As for the attribute_unacceptable lines, I've tried to change the 'auth' attributes to "hmac-sha2-384", and I actually got the same messages.. I also tried to set the 'group' option for the 'main' and 'quick' lines to modp3072, no luck there either.

What also doesn't help is that every time my phone does an unsuccessful connection, I must restart it, because "something gets stuck there", and every subsequent connection attempt just doesn't do anything -- no packets are coming in from the phone anymore... Anyway.

I hope someone has had success with this and could point me in some kind of direction I'm not seeing.

Thanks in advance,
Dani

[1]:
http://bluepilltech.blogspot.com/2017/02/openbsd-l2tp-over-ipsec-android-601-ios.html
http://blog.fuckingwith.it/2016/04/openbsd-l2tpipsec-vpn-for-android.html
http://openbsd-archive.7691.n7.nabble.com/L2TP-IPSec-via-npppd-won-t-work-with-Android-5-x-td290194.html

--
Lévai, Dániel

[maintainer update] www/p5-Mojo 8.18

Hello,
this diff updates www/p5-Mojo to 8.18. All tests pass.

Changes: https://metacpan.org/release/SRI/Mojolicious-8.18

Index: Makefile
===================================================================
RCS file: /cvs/ports/www/p5-Mojo/Makefile,v
retrieving revision 1.34
diff -u -p -u -r1.34 Makefile
--- Makefile 30 Apr 2019 02:11:35 -0000 1.34
+++ Makefile 30 Jun 2019 17:06:43 -0000
@@ -4,7 +4,7 @@ COMMENT = next generation web framework

MODULES = cpan
PKG_ARCH = *
-DISTNAME = Mojolicious-8.15
+DISTNAME = Mojolicious-8.18
CATEGORIES = www

MAINTAINER = Manolis Tzanidakis <mtzanidakis@gmail.com>
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/p5-Mojo/distinfo,v
retrieving revision 1.26
diff -u -p -u -r1.26 distinfo
--- distinfo 30 Apr 2019 02:11:35 -0000 1.26
+++ distinfo 30 Jun 2019 17:06:43 -0000
@@ -1,2 +1,2 @@
-SHA256 (Mojolicious-8.15.tar.gz) = yFArI+TyE1RIYfIECjTf6nLj0QkzVcJMcPEtZdB37Ns=
-SIZE (Mojolicious-8.15.tar.gz) = 755156
+SHA256 (Mojolicious-8.18.tar.gz) = /naCG/ir5sZKar4uMnIQ9WSgycsMX03DLC26DUO3AG4=
+SIZE (Mojolicious-8.18.tar.gz) = 761103

Re: cd command, chdir syscall, shell behavour

Hi Edgar,

Edgar Pettijohn wrote on Sat, Jun 29, 2019 at 07:48:35PM -0500:
> Ingo Schwarze wrote:

>> If you want to search for a manual page, use man(1).
>> If you want to search for packages, use pkglocate(1).

> I don't think this would be needed on openbsd as the default
> install has everything you need for a basic system and it's easy
> to add additional packages. However, as I learned when I set up
> a Debian box for my son to play Minecraft it didn't. So it was
> kinda nice when I typed ifconfig it informed me what package to
> install

That argument doesn't really apply even to Debian.
Just like i said

If you want to search for packages, use pkglocate(1).

for OpenBSD, you would say

$ apt-cache search ifconfig

on Debian. Different systems have different tools, but the concept
that each tool should focus on its own job still applies.

Besides, ip(8) was probably already installed and likely good enough
for your job.

> and I eventually got everything working no thanks to the
> piss poor manual pages provided.

And that even though in the Linux world, few systems insist that
everything should have a manual page as much as Debian does...

Yours,
Ingo

Re: llvm-7.0.1 fallout: lang/crystal

Hi Wesley,

On Wed, Feb 13 2019, Wesley Moxam <wesley.moxam@gmail.com> wrote:
>> On Feb 13, 2019, at 7:47 AM, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
>>
>>> On Thu, Feb 07 2019, Stuart Henderson <stu@spacehopper.org> wrote:
>>>> On 2019/02/07 18:02, Jeremie Courreges-Anglas wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm not sure you were notified so here's a heads-up: lang/crystal
>>>> doesn't build any more after the update to clang 7 in both base and
>>>> ports.
>>>
>>> Not handled upstream yet.
>>> https://github.com/crystal-lang/crystal/issues/6754
>>
>> Wesley, I see that you have commented on this issue. Do you mind if
>> we mark lang/crystal as temporarily BROKEN?
>
> That's fine with me. It may be a while before the issue is fixed

Any news regarding lang/crystal? The issue is still open and "@bcardiff
removed this from the 0.28.0 milestone on Mar 27".

If upstream doesn't plan to support newer llvm releases and no
alternative fix is found, then the port should be removed.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: cd command, chdir syscall, shell behavour

Hi Ian,

ropers wrote on Sun, Jun 30, 2019 at 02:18:56PM +0200:

> In bash, `help` is a shell builtin and does do something, though IMO,
> the something that it does isn't initially as helpful as OpenBSD's
> help(1), especially to newbies. [1]

Yes. When a user types "help", it is unlikely they are confused
only about shell builtins (or even about the shell at large), but
it sounds more like they need getting started with the OS as a
whole.

> However, what it does do, i.e.
> * print a list of bash builtins in response to `help`, or
> * print bash builtin-specific help in response to `help [builtin]`
> could well be helpful later and relates to what we discussed earlier.
> Is man(1) plus info(1) plus bash's help some kind of triple
> book-keeping or wheel-reinvention?

More like quadruple because there is also the usage message.

But yes, that having a one- or two-line usage message on the one
hand and a complete and concise manual page on the other hand, and
no third copy of the same, is the current official OpenBSD position
because the information isn't really that hard to find in the manual
page, and a third copy would cause additional maintenance effort
and risk getting outdated.

All the same, developers occasionally discuss whether exceptions
of having -h or --help options for a few unusually complicated
programs might make sense (for example right now on tech@), but so
far, it was usually rejected.

> Perhaps, but in terms of convenience, bash's `help` and `help [builtin]`
> are stiff competition to [...] `man -k Ic,Nm=[term]` and `man -O
> tag=[term]`.

Except that features like `help` and `help [builtin]` work differently
for each and every program, so you can't really get used to them,
neither to how to call them nor to which usually incomplete selection
of information they might throw at you, whereas semantic tags work
in a general and uniform way, and not only for .Ic, which is just
one of many examples.

> footnote:
> [1] This also means that if an OpenBSD sysadmin tries to be "helpful
> to newbies" by installing the bash they're maybe used to, they will by
> default clobber access to OpenBSD's excellent help(1), and it would
> take extra care to re-enable that and to then figure out a nice way to
> still provide access to bash's builtin help too... aaargh! Maybe bash
> on OpenBSD isn't the best choice really.

Indeed, in particular not as a login shell.

On the other hand, if a user explicitly types "bash", they get what
they ask for, and there is nothing wrong with that.

Yours,
Ingo

Re: Future of X.org?

On Fri, 28 Jun 2019, gwes wrote:

> I regularly run programs on one machine connected to a display
> on another machine. AFAIK, the current state of Wayland makes
> that difficult. I confess to not following it closely.

I also do it, and I also have no much idea of what is wayland.

But I have the impression that some people want to substitute X11
with something that is not a replacement for it, that has other
functionality. They confuse X11 with a mere graphical surface.

Rodrigo

Re: [NEW] textproc/py-recommonmark

On Sun, Jun 30, 2019 at 12:34:13PM +0200, Jeremie Courreges-Anglas wrote:

> Duh, indeed.

> >> Also, setting MODPY_EGG_VERSION is useless or I'm missing something?

> > It's not necessary if using the GH_* tags, but if there is intention to
> > move it to PyPI in the future, it makes sense.

> The package started as a MODPY_PI port, but I indeed decided to go for
> the github repo to get more tests to run. It's not perfect yet, as I'm
> not sure I understand the cause for the "KeyError: 'refdoc'" tracebacks.

Ah. I assumed that was what it was, but even the github tarball seems to
leave out some files. I was getting errors about an index.md that seems
to be in the current master branch but not in the 0.5.0 GH tarball. So
I was unsure.

> Updated tarball attached, diff below. Thanks for your help.

This new version, OK kmos@

You're welcome on the help :)

--Kurt

> --8<--
> diff -pruN py-recommonmark.old/Makefile py-recommonmark/Makefile
> --- py-recommonmark.old/Makefile Sat Jun 29 07:24:49 2019
> +++ py-recommonmark/Makefile Sun Jun 30 12:21:24 2019
> @@ -2,10 +2,13 @@
>
> COMMENT = markdown parser for docutils
>
> -MODPY_EGG_VERSION = 0.5.0
> +MODPY_EGG_VERSION = 0.5.0
> +# Using github autogenerated tarball because pypi tarballs don't ship
> +# files needed by tests.
> GH_ACCOUNT = readthedocs
> GH_PROJECT = recommonmark
> GH_TAGNAME = ${MODPY_EGG_VERSION}
> +PKGNAME = py-recommonmark-${MODPY_EGG_VERSION}
>
> CATEGORIES = textproc devel
>
> @@ -20,7 +23,6 @@ MODPY_SETUPTOOLS = Yes
> RUN_DEPENDS = textproc/py-commonmark${MODPY_FLAVOR} \
> textproc/py-docutils${MODPY_FLAVOR} \
> textproc/py-sphinx${MODPY_FLAVOR}
> -TEST_DEPENDS = ${RUN_DEPENDS}
>
> FLAVORS = python3
> FLAVOR ?=
> -->8--
>
>

>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: dedicated user for sysutils/monit

On Fri, Jun 28, 2019 at 02:49:26PM +0200, Joel Carnat wrote:
> BTW, following stu@'s "(...) I think it really needs more support (...)"
> remark, I searched for things that would break if Monit would not run as
> root. I found that the "network ping test" requires root access to run.
> I don't use it myself so I didn't notice it when running as _monit.
> Documentation says: "Monit must also run as the root user in order to be
> able to perform the ping test (because the ping test must use raw
> sockets which usually only the super user is allowed to)."

For the reason that you mentioned above, I don't think it is a good
idea to make monit run as a non-root user by default. As you noticed,
monit doesn't appear to be designed to be run as a non-root user.

Best regards,
Caspar Schutijser

Re: NEW: Tacacs+ port - shrubbery.net version

On 2019/05/23 20:09, Jan Vlach wrote:
> Hi Gleydson, Stuart, ports,
>
> I'm running tac_plus with 200+ boxes with IOS, IOS-XE and IOS-XR.
>
> please see attached tgz for updated port.
>
> - I've taken Gleydson's latest work from openbsd-wip (I don't see the
> unexec and/or doc/shared implemented in PLIST) *
> - provided simplified tac_plus.conf.sample of stuff I have tested -
> logging in as full admins with level 15 and limited show users that I
> use for scripting/metrics. I can't really vouch for the functionality of
> dialup users etc. The full-blown config file example is still in the
> manpage
> - fixed typo in manpage for accounting to syslog - using `accounting
> syslog;` (including semicolon) does not work, but parser does not
> complain. If I remove the semicolon, accounting info gets logged to
> syslog as daemon.info (this was nasty :) )
> - fixed paths for tac.acct, tac.log and tac.who - all of them go to
> /var/log/tac_plus directory that's owned by _tacacs:_tacacs
> - ^ This fixes the case where you don't want to log into accounting file
> and want syslog accounting only (disabling accounting file directive
> leads to tacacs complaining of permission denied with with default path
> of /var/log/tac.acct) Changing the default path to
> /var/log/tac_plus/tac.acct and removing `accounting file = ...'
> directive properly disables logging to this file. Go figure :)
> - Updated paths in manpage (tac_plus.conf.5.in) as one is automatically
> substituted from configure variables, while the other is hardcoded.
> - Added README file to remind administrator to rotate his/her files.
>
> * I've tried to add the @extraunexec rm -rf /var/log/tac_plus/*, but I'm
> not sure it works:
>
> On package deletion pkg_delete complains that directory is not empty:
> [20:07][root@samsara:/var/log]# pkg_delete tacacs+
> tacacs+-4.0.4.28v0: ok
> Read shared items: ok
> --- -tacacs+-4.0.4.28v0 -------------------
> You should also remove /etc/tac_plus.conf (which was modified)
> You should also run rm -f /var/log/tac_plus/*
> Error deleting directory /var/log/tac_plus: Directory not empty
> You should also run /usr/sbin/userdel _tacacs
> You should also run /usr/sbin/groupdel _tacacs
>
> I'm sorry, I've wrestled, but I don't understand how the doc/examples directories work -
> what needs to be done in pkg configure phase and what is done in PLIST?
>
> Cluestick please?
>
> I've tested the accounting part with py-tacacs_plus on -current, don't have a real
> network box around at this time. (Gonna dogfood this tomorrow or next
> week)
>
> Could you please have a look if this is okay?
>
> jvl
>
> On Thu, May 23, 2019 at 11:34:23AM -0300, Gleydson Soares wrote:
> > > Can you use the standard locations for doc/examples please rather
> > > than /usr/local/share/tacacs?
> >
> > Yep.
> >
> > > Needs @extraunexec rm -f /var/log/tac_plus/* for pkg_delete -c.
> >
> > Done.
> > Thanks for the feedback, i'm pushing it to openbsd-wip.
> >
> > PS.: I'm running it and works just fine It has a dozen of Cisco Nexus switches already connected.
> > privdrop (_tacacs) fine.
> >
> > I will add some changes to example files provided by Jan Vlach, for pointing out how to use tac_plus on the fly on OpenBSD.(like features available with and without privdrop / etc).
> >
> > Also should be nice sent patches upstream. Jan Vlach, what do you think about?
> >
> > Cheers,
> >

Slightly tweaked version attached, this one's ok with me:

- https homepage
- PERMIT_*_CDROM is not used for new ports
- whitespace nit in Makefile
- tweak comment in patch
- place @extraunexec above the @sample line, that way pkg_delete -c doesn't
complain about a missing dir. (pkg_delete without -c will complain about
not being able to remove the dir, that is no problem).
- regen plist to include pkg-readme
- adjust pkg-readme to set uid/gid on the files
- change group ownership of log dir to wheel, easier for admins

Re: cd command, chdir syscall, shell behavour

Oops, I just mistakenly attributed Ingo's earlier reply to Edgar.
Apologies to both, and thanks very much for the help.

Ian

On 30/06/2019, ropers <ropers@gmail.com> wrote:
> On 30/06/2019, Edgar Pettijohn <edgar@pettijohn-web.com> wrote:
>>>> Then you need to say (...snip; see earlier email...)
>
> Thank you. That contained several useful hints I hadn't even figured
> out I could look for there, although this too seems obvious in
> retrospect. Maybe I'm not thinking about these things carefully enough
> in advance. :)
>
>>> This is perfectly fine, exactly as it should be:
>>>
>>> schwarze@isnote $ man bash
>>> man: No entry for bash in the manual.
>>> schwarze@isnote $ pkglocate bin/bash | head -n1
>>> bash-5.0.7p0:shells/bash:/usr/local/bin/bash
>>>
>>> > To end on a positive: Can I add how much I appreciate that OpenBSD
>>> > hard-links help(1) to man(1),
>>>
>>> Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ...
>>>
>>> > and that man will default to `man help` when called as help?
>>>
>>> and aaron@ added the help(1) manual page on Oct 18, 1999
>>> for OpenBSD 2.6.
>>>
>>> > This elegant way of having OpenBSD respond to `help` is really
>>> > n00b-friendly.
>>>
>>> And yet, even among those tiny innovations that are somehow neat,
>>> not all get picked up elsewhere:
>>>
>>> https://man.openbsd.org/FreeBSD-12.0/help
>>> https://man.openbsd.org/NetBSD-8.0/help
>>> https://man.openbsd.org/Linux-5.01/help
>
> In bash, `help` is a shell builtin and does do something, though IMO,
> the something that it does isn't initially as helpful as OpenBSD's
> help(1), especially to newbies. [1]
>
> However, what it does do, i.e.
> * print a list of bash builtins in response to `help`, or
> * print bash builtin-specific help in response to `help [builtin]`
> could well be helpful later and relates to what we discussed earlier.
> Is man(1) plus info(1) plus bash's help some kind of triple
> book-keeping or wheel-reinvention? Perhaps, but in terms of
> convenience, bash's `help` and `help [builtin]` are stiff competition
> to Edgar's earlier hints of `man -k Ic,Nm=[term]` and `man -O
> tag=[term]`.
> Don't get me wrong; I'm VERY grateful for the hints, and I don't think
> I have or know of an ideal solution. All the same, I think this is
> still an area where considerable possibility for user confusion yet
> abounds.
>
> Ian
>
> footnote:
> [1] This also means that if an OpenBSD sysadmin tries to be "helpful
> to newbies" by installing the bash they're maybe used to, they will by
> default clobber access to OpenBSD's excellent help(1), and it would
> take extra care to re-enable that and to then figure out a nice way to
> still provide access to bash's builtin help too... aaargh! Maybe bash
> on OpenBSD isn't the best choice really.
>

Re: suricata, librsvg : set CARGO_HOME for upcoming lang/rust-1.36

On Sun, Jun 30, 2019 at 02:02:47PM +0200, Antoine Jacoutot wrote:
>
> Why not setting PORTHOME=${WRKDIST} by default for cargo ports?

Setting CARGO_HOME is enough for this purpose and should affect only
cargo. At opposite setting PORTHOME could have unwanted side-effects,
and we will not catch write attempt in HOME any more for such ports.

It is why I prefer using CARGO_HOME in environment when possible.

Thanks.
--
Sebastien Marie

Re: cd command, chdir syscall, shell behavour

On 30/06/2019, Edgar Pettijohn <edgar@pettijohn-web.com> wrote:
>>> Then you need to say (...snip; see earlier email...)

Thank you. That contained several useful hints I hadn't even figured
out I could look for there, although this too seems obvious in
retrospect. Maybe I'm not thinking about these things carefully enough
in advance. :)

>> This is perfectly fine, exactly as it should be:
>>
>> schwarze@isnote $ man bash
>> man: No entry for bash in the manual.
>> schwarze@isnote $ pkglocate bin/bash | head -n1
>> bash-5.0.7p0:shells/bash:/usr/local/bin/bash
>>
>> > To end on a positive: Can I add how much I appreciate that OpenBSD
>> > hard-links help(1) to man(1),
>>
>> Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ...
>>
>> > and that man will default to `man help` when called as help?
>>
>> and aaron@ added the help(1) manual page on Oct 18, 1999
>> for OpenBSD 2.6.
>>
>> > This elegant way of having OpenBSD respond to `help` is really
>> > n00b-friendly.
>>
>> And yet, even among those tiny innovations that are somehow neat,
>> not all get picked up elsewhere:
>>
>> https://man.openbsd.org/FreeBSD-12.0/help
>> https://man.openbsd.org/NetBSD-8.0/help
>> https://man.openbsd.org/Linux-5.01/help

In bash, `help` is a shell builtin and does do something, though IMO,
the something that it does isn't initially as helpful as OpenBSD's
help(1), especially to newbies. [1]

However, what it does do, i.e.
* print a list of bash builtins in response to `help`, or
* print bash builtin-specific help in response to `help [builtin]`
could well be helpful later and relates to what we discussed earlier.
Is man(1) plus info(1) plus bash's help some kind of triple
book-keeping or wheel-reinvention? Perhaps, but in terms of
convenience, bash's `help` and `help [builtin]` are stiff competition
to Edgar's earlier hints of `man -k Ic,Nm=[term]` and `man -O
tag=[term]`.
Don't get me wrong; I'm VERY grateful for the hints, and I don't think
I have or know of an ideal solution. All the same, I think this is
still an area where considerable possibility for user confusion yet
abounds.

Ian

footnote:
[1] This also means that if an OpenBSD sysadmin tries to be "helpful
to newbies" by installing the bash they're maybe used to, they will by
default clobber access to OpenBSD's excellent help(1), and it would
take extra care to re-enable that and to then figure out a nice way to
still provide access to bash's builtin help too... aaargh! Maybe bash
on OpenBSD isn't the best choice really.

Re: suricata, librsvg : set CARGO_HOME for upcoming lang/rust-1.36

On Sun, Jun 30, 2019 at 12:41:02PM +0200, Sebastien Marie wrote:
> Hi,
>
> I am working on updating lang/rust to 1.36.0
>
> The release ships a new version of cargo which will want to write a file
> in $HOME (a lock file to manage concurrent access on package cache).
>
> To avoid an error while acquiring package cache lock, CARGO_HOME should
> be defined to a directory writable by the build. The default value of
> CARGO_HOME is "$HOME/.cargo", so alternatively PORTHOME in the port
> could be set too.
>
> As i think it is less invasive to set CARGO_HOME, I followed this way.
>
> The following diff takes care of:
> - security/suricata : configure look for CARGO_HOME env var
> - x11/gnome/librsvg : set CARGO_HOME via MAKE_ENV
>
> Some others ports not using devel/cargo sets PORTHOME (hey firefox o/)
> so the problem doesn't occurs. And ports using devel/cargo modules
> already defines CARGO_HOME by default.
>
> One possible leftover is devel/meson where lang/rust is a TEST_DEPS. But
> it seems it is directly using rustc compiler and not cargo. So I assume
> it is fine.
>
> No package bump as it is a build setting that don't affect anything with
> rust-1.35 we have in port.
>
> Comments or OK ?
> --
> Sebastien Marie

Why not setting PORTHOME=${WRKDIST} by default for cargo ports?

>
> Index: security/suricata/Makefile
> ===================================================================
> RCS file: /cvs/ports/security/suricata/Makefile,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile
> --- security/suricata/Makefile 3 May 2019 06:22:34 -0000 1.20
> +++ security/suricata/Makefile 30 Jun 2019 10:05:52 -0000
> @@ -49,7 +49,8 @@ CONFIGURE_STYLE = autoconf
> AUTOCONF_VERSION = 2.69
>
> CONFIGURE_ENV = ac_cv_path_HAVE_PDFLATEX= \
> - ac_cv_path_HAVE_GIT_CMD=
> + ac_cv_path_HAVE_GIT_CMD= \
> + CARGO_HOME=${WRKBUILD}/cargo-home
>
> CONFIGURE_ARGS = --disable-gccmarch-native \
> --enable-ipfw
> Index: x11/gnome/librsvg/Makefile
> ===================================================================
> RCS file: /cvs/ports/x11/gnome/librsvg/Makefile,v
> retrieving revision 1.148
> diff -u -p -r1.148 Makefile
> --- x11/gnome/librsvg/Makefile 13 May 2019 22:47:45 -0000 1.148
> +++ x11/gnome/librsvg/Makefile 30 Jun 2019 07:25:33 -0000
> @@ -19,7 +19,8 @@ SHARED_LIBS += rsvg-2 39.
> GNOME_VERSION= ${STABLE_VERSION}
> BUILD_DEPENDS= lang/rust
> PKG_ARGS= -Dold=0 -Dstable=1
> -MAKE_ENV+= CARGO_BUILD_JOBS=${MAKE_JOBS}
> +MAKE_ENV+= CARGO_BUILD_JOBS=${MAKE_JOBS} \
> + CARGO_HOME=${WRKBUILD}/cargo-home
> .else
> ### old
> REVISION= 3
>

--
Antoine

Re: [NEW] textproc/py-recommonmark

On 2019/06/29 22:31, Daniel Jakots wrote:
> On Sat, 29 Jun 2019 21:41:50 -0400, Kurt Mosiejczuk <kurt@cranky.work>
> wrote:
>
> > Also, do you wish to have the package named recommonmark-0.5.0 or
> > py-recommonmark-0.5.0? Right now it is the former since there isn't a
> > PKGNAME line.
>
> Since Jérémie chose to have a flavor, it needs to be py- prefixed.
>
>
> Also, setting MODPY_EGG_VERSION is useless or I'm missing something?

It avoids unneeded churn in PLISTs for simple version updates

Re: infrastructure patch: improve test handling

On Sat, Jun 29 2019, Marc Espie <espie@nerim.net> wrote:
> Documentation AND infra patch.
>
> - add test to the list of things that can be rebuilt/cleaned

This part needs a fix for PORTS_PRIVSEP=Yes, please see below.

> - recognize PORTS_PRIVSEP as a special case for automated testing,
> specifically, set TEST_IS_INTERACTIVE=network for testsuites that require
> network access.

Not reviewed / tested yet.

>
>
> Index: bsd.port.mk.5
> ===================================================================
> RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v
> retrieving revision 1.511
> diff -u -p -r1.511 bsd.port.mk.5
> --- bsd.port.mk.5 31 May 2019 21:27:48 -0000 1.511
> +++ bsd.port.mk.5 29 Jun 2019 12:39:47 -0000
> @@ -169,7 +169,7 @@ Clean ports contents.
> By default, it will clean the work directory.
> It can be invoked as
> make clean='[depends build bulk work fake flavors dist install sub package
> -packages plist]'.
> +packages plist test]'.
> .Bl -tag -width packages
> .It Va work
> Clean work directory.
> @@ -195,6 +195,8 @@ Uninstall package.
> Remove all copies of package file.
> .It Va plist
> Remove registered packing lists of all subpackages.
> +.It Va test
> +Clean test cookie.
> .It Va sub
> With
> .Va install
> @@ -702,8 +704,11 @@ see
> .It Cm reprepare
> Force running the
> .Ar prepare
> -target
> -again.
> +target again.
> +.It Cm retest
> +Force running the
> +.Ar test
> +target again.
> .It Cm show
> Invoked as make show=name, show the contents of ${name}.
> Invoked as make show="name1 name2 ...",
> @@ -3015,9 +3020,18 @@ Empty by default.
> .It Ev TEST_IS_INTERACTIVE
> Set to
> .Sq Yes
> -if port needs human interaction to run its tests, or set to
> +if port needs human interaction to run its tests, set to
> .Sq X11
> -if the tests need an active X11 display to work.
> +if the tests need an active X11 display to work,
> +set to
> +.Sq network
> +if the tests need access network
> +(setting
> +.Ev PORTS_PRIVSEP
> +disables network access for the
> +.Sq _pbuild
> +user, so these tests become, in effect,
> +interactive).
> .It Ev TEST_LOG
> Command used to log the results of regression tests to TEST_LOGFILE.
> Read-only.
>
>
>
>
>
> Index: bsd.port.mk
> ===================================================================
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1471
> diff -u -p -r1.1471 bsd.port.mk
> --- bsd.port.mk 16 Jun 2019 14:27:42 -0000 1.1471
> +++ bsd.port.mk 29 Jun 2019 12:39:53 -0000
> @@ -253,7 +253,7 @@ _clean += -f
> .endif
>
> _okay_words = depends work fake -f flavors dist install sub packages package \
> - bulk force plist build all
> + bulk force plist build all test
> .for _w in ${_clean}
> . if !${_okay_words:M${_w}}
> ERRORS += "Fatal: unknown clean command: ${_w}\n(not in ${_okay_words})"
> @@ -928,8 +928,13 @@ TEST_LOGFILE ?= ${WRKDIR}/test.log
> TEST_LOG = | ${_PBUILD} tee ${TEST_LOGFILE}
> IS_INTERACTIVE ?= No
> TEST_IS_INTERACTIVE ?= No
> +.if ${TEST_IS_INTERACTIVE:L} == "network" && ${PORTS_PRIVSEP:L} != "yes"
> +_TEST_IS_INTERACTIVE = No
> +.else
> +_TEST_IS_INTERACTIVE = ${TEST_IS_INTERACTIVE}
> +.endif
>
> -.if ${TEST_IS_INTERACTIVE:L} == "x11"
> +.if ${_TEST_IS_INTERACTIVE:L} == "x11"
> TEST_ENV += DISPLAY=${DISPLAY} XAUTHORITY=${XAUTHORITY}
> XAUTHORITY ?= ${HOME}/.Xauthority
> .endif
> @@ -1422,9 +1427,9 @@ MISSING_FILES += ${_F}
> ################################################################
> TRY_BROKEN ?= No
> _IGNORE_TEST ?=
> -.if ${TEST_IS_INTERACTIVE:L} != "no" && defined(BATCH)
> +.if ${_TEST_IS_INTERACTIVE:L} != "no" && defined(BATCH)
> _IGNORE_TEST += "has interactive tests"
> -.elif ${TEST_IS_INTERACTIVE:L} == "no" && defined(INTERACTIVE)
> +.elif ${_TEST_IS_INTERACTIVE:L} == "no" && defined(INTERACTIVE)
> _IGNORE_TEST += "does not have interactive tests"
> .endif
>
> @@ -2826,7 +2831,7 @@ ${_TEST_COOKIE}: ${_BUILD_COOKIE}
> .if ${NO_TEST:L} == "no"
> @${ECHO_MSG} "===> Regression tests for ${FULLPKGNAME}${_MASTER}"
> # When interactive tests need X11
> -. if ${TEST_IS_INTERACTIVE:L} == "x11"
> +. if ${_TEST_IS_INTERACTIVE:L} == "x11"
> . if !defined(DISPLAY) || !exists(${XAUTHORITY})
> @echo 1>&2 "The regression tests require a running instance of X."
> @echo 1>&2 "You will also need to set the environment variable DISPLAY"
> @@ -3151,6 +3156,9 @@ _internal-clean:
> . endfor
> . endif
> .endif
> +.if ${_clean:Mtest}
> + rm -f ${_TEST_COOKIE}

Should be

> + ${_PBUILD} rm -f ${_TEST_COOKIE}

else I get an error with make clean=test:

russell /usr/ports/x11/ratpoison$ make clean=test
===> Cleaning for ratpoison-1.4.9
rm -f /usr/ports/pobj/ratpoison-1.4.9/build-amd64/.test_done
rm: /usr/ports/pobj/ratpoison-1.4.9/build-amd64/.test_done: Permission denied
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3160 '_internal-clean')
*** Error 1 in /usr/ports/x11/ratpoison (/usr/ports/infrastructure/mk/bsd.port.mk:2486 'clean')

ok for this part of your diff (with ${_PBUILD} added). I think it's
a worthwhile addition. Thanks!

> +.endif
>
> print-build-depends:
> .if !empty(_BUILD_DEP)
> @@ -3473,6 +3481,10 @@ rebuild:
> @${_PBUILD} rm -f ${_BUILD_COOKIE}
> @${_MAKE} build
>
> +retest:
> + @${_PBUILD} rm -f ${_TEST_COOKIE}
> + @${_MAKE} test
> +
> regen:
> @${_PBUILD} rm -f ${_GEN_COOKIE}
> @${_MAKE} gen
> @@ -3549,7 +3561,7 @@ _all_phony = ${_recursive_depends_target
> post-distpatch post-extract post-install \
> post-patch post-test pre-build pre-configure pre-extract pre-fake \
> pre-install pre-patch pre-test prepare \
> - print-build-depends print-run-depends rebuild regen reprepare \
> + print-build-depends print-run-depends rebuild regen reprepare retest \
> test-depends test-depends-list run-depends-list \
> show-required-by subpackage uninstall _print-metadata \
> run-depends-args lib-depends-args all-lib-depends-args wantlib-args \
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE