CVS: cvs.openbsd.org: ports

[Theo Buehler]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/03/16 22:51:28

Modified files:
databases/redis: Makefile distinfo 
databases/redis/patches: patch-src_Makefile 
Added files:
databases/redis/patches: patch-src_networking_c 

Log message:
Update to Redis 5.0.8. Fixes some security issues and plugs lots
of memory leaks. Add a patch for a time_t truncation issue on
architectures with 32 bit longs. The update results in one test
failure showing much more often on sparc64:

*** [err]: pending querybuf: check size of pending_querybuf after set a big 
value in tests/unit/pendingquerybuf.tcl
the used_memory of replica is much larger than master. Master:35666976 
Replica:69051032

Tests by Uwe Werler.

ok kn, "move forward" danj

Release notes:

https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES

[Update] converters/p5-Convert-UUlib : Update to 1.71

[wen heping]

Hi, ports@:

   Here is a patch for converters/p5-Convert-UUlib:
i) Update to 1.71
ii) Add a missing RUN_DEPENDS
iii) Remove a trailing whitespace in DESCR

   It build well and pass all tests on amd64-current system.
   No other ports depends on p5-Convert-UUlib.

Cheers !
wen
Index: Makefile
===
RCS file: /cvs/ports/converters/p5-Convert-UUlib/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile5 Feb 2020 07:36:01 -   1.22
+++ Makefile17 Mar 2020 02:10:09 -
@@ -2,7 +2,7 @@
 
 COMMENT=   interface to the uulib library
 
-DISTNAME = Convert-UUlib-1.5
+DISTNAME = Convert-UUlib-1.71
 EPOCH =1
 CATEGORIES=converters
 MODULES=   cpan
@@ -13,5 +13,7 @@ PERMIT_PACKAGE=   Yes
 WANTLIB += c perl
 
 BUILD_DEPENDS =devel/p5-Canary-Stability
+
+RUN_DEPENDS =  devel/p5-common-sense
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/converters/p5-Convert-UUlib/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo5 Feb 2020 07:36:01 -   1.9
+++ distinfo17 Mar 2020 02:10:09 -
@@ -1,2 +1,2 @@
-SHA256 (Convert-UUlib-1.5.tar.gz) = 
DNgbwhN3+tGR+JqkJ3M+/lt+dcoYiekxeUWtRIxjiOo=
-SIZE (Convert-UUlib-1.5.tar.gz) = 236213
+SHA256 (Convert-UUlib-1.71.tar.gz) = 
Gdsh2va88u7wAijv8NKxayjQM++SFP12dLboIt5yCwM=
+SIZE (Convert-UUlib-1.71.tar.gz) = 277227
Index: pkg/DESCR
===
RCS file: /cvs/ports/converters/p5-Convert-UUlib/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR   25 Nov 2002 03:12:28 -  1.1.1.1
+++ pkg/DESCR   17 Mar 2020 02:10:09 -
@@ -1 +1 @@
-Perl interface to the uulib library (a.k.a. uudeview/uuenview). 
+Perl interface to the uulib library (a.k.a. uudeview/uuenview).

CVS: cvs.openbsd.org: ports

[Aaron Bieber]

CVSROOT:/cvs
Module name:ports
Changes by: abie...@cvs.openbsd.org 2020/03/16 19:59:17

Modified files:
security/ogvt  : Makefile distinfo 

Log message:
Bump ogvt to 1.0.3

OK tb@

Re: Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"

[nik...@rpgresearch.com]

On Mon, 16 Mar 2020 04:12:41 +
Ian McWilliam  wrote:

> Did you pkg_add p5-CGI-Fast at some point?
> 
> What does your pkg_info | grep -i p5-CGI look like?
> 
> Ian McWilliam
> 
> From: owner-po...@openbsd.org  on behalf of
> nik...@rpgresearch.com  Sent: Monday, 16
> March 2020 12:35 PM To: ports@openbsd.org 
> Subject: Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"
> 
> I have been working on setting up Sympa on OpenBSD.
> 
> I have OpenSMTPd working with the Sympa daemon, but I'm getting stuck
> on the wwsympa set up with nginx (I hope to switch to OpenBSD's HTTPd
> after I get Nginx working).
> 
> I used the Nginx config provided by the port maintainer:
> 
> >server {
> >   server_name domain.com;
> >   listen on 0.0.0.0:80;
> >
> >   location /static-sympa {
> >   alias /var/www/sympa/;
> >   }
> >
> >
> >   location / {
> >   fastcgi_pass localhost:1026;
> >   fastcgi_split_path_info ^(/sympa)(.+)$;
> >   include fastcgi_params;
> >   fastcgi_param PATH_INFO $fastcgi_path_info;
> >   fastcgi_param
> >   SCRIPT_FILENAME /usr/local/libexec/sympa/wwsympa-wrapper.fcgi; }
> >}  
> 
> When I launch all the services, wwsympa crashes out with the following
> error in /var/log/messages.
> 
> >wwsympa[40272]: err main::#138 DIED: Can't locate CGI/Fast.pm in @INC
> >(you may need to install the CGI::Fast module) (@INC
> >contains: /usr/local/libdata/perl5/site_perl/amd64-openbsd 
> >/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd 
> >/usr/libdata/perl5)
> >at /usr/local/libexec/sympa/wwsympa.fcgi line 139  
> 
> I will now make this email unbearably long by sharing this dump:
> 
> >ls /usr/local/libdata/perl5/site_perl/  
> AppConfigEncode   MIME
> Role iso8859.pl   mhsingle.pl
> AppConfig.pm ErrorMLDBM
> SQL  libwww   mhthread.pl
> Archive  Error.pm MLDBM.pm
> Sort mhamain.pl   mhtime.pl
> BEval MRO
> StackTrace   mhdb.pl  mhtxtenrich.pl
> Bundle   Exporter Mail
> Sub  mhdysub.pl   mhtxthtml.pl
> CGI  Fh.pmMath
> Sympamhexternal.plmhtxtplain.pl
> CGI.pm   File MaxMind
> Sympa.pm mhfile.plmhtxttsv.pl
> CGI.pod  Font Method
> Term mhidxrc.pl   mhusage.pl
> ClassFreezeThaw.pmModule
> Test mhindex.pl   mhutil.pl
> CloneGeoIP2   MojoX
> Throwablemhinit.plnamespace
> Conf.pm  GeoIP2.pmMoo
> Throwable.pm mhlock.ploo.pm Convert
> HTML Moo.pm   Time
> mhmimetypes.pl   osinit.pl Crypt
> HTTP MooX Try
> mhmsgextbody.pl  qprint.pl DDP.pm
> IO   Mozilla  URI
> mhmsgfile.pl readmail.pl Data
> JSON MuninURI.pm
> mhnote.plspamassassin-run.pod Date
> LWP  Net  WWW
> mhnull.plstrictures DateTime
> LWP.pm   OpenBSD  XML
> mhopt.pl strictures.pm Devel
> List POD2 amd64-openbsd
> mhrcfile.pl Digest   Locale
> Package  base64.plmhrcvars.pl
> Dist Log  RPC
> ewhutil.pl   mhrmm.pl EmailMHonArc
> RRDp.pm  iso2022jp.pl mhscan.pl
> 
> Is this a dependency issue, or is there a step that I could be
> missing? I am not familiar with CGI in general.
> 
> 
> Thank you all!
> 

Thank you for responding so quickly:

>pkg_info | grep -i p5-CGI
 
>p5-CGI-4.43 handle Common Gateway Interface requests and
>responses

It does appear to be a listed dependency and is installed:

>cat /var/db/pkg/sympa-6.2.16p2/+REQUIRING  | grep p5-CGI-4.43
>p5-CGI-4.43

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/03/16 17:50:28

Modified files:
games/devilutionx: Makefile distinfo 
games/devilutionx/patches: patch-CMakeLists_txt 

Log message:
Update to devilutionx-1.0.1
Changelog: https://github.com/diasurgical/devilutionX/releases/tag/1.0.1

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/03/16 17:39:10

Modified files:
misc/feathernotes: Makefile distinfo 
misc/feathernotes/pkg: PLIST 

Log message:
Update to feathernotes-0.6.0
Changelog: https://github.com/tsujan/FeatherNotes/releases/tag/V0.6.0

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/03/16 17:22:17

Modified files:
editors/featherpad: Makefile distinfo 
editors/featherpad/pkg: PLIST 

Log message:
Update featherpad to 0.13.1
The important changelog bits are here:
https://github.com/tsujan/FeatherPad/releases/tag/V0.13.0

Re: Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"

[Ian McWilliam]

You'll actually need to add CGI::Fast as a package as it is missing.

pkg_add p5-CGI-Fast


Ian McWilliam

From: nik...@rpgresearch.com 
Sent: Monday, 16 March 2020 4:27 PM
To: Ian McWilliam 
Cc: ports@openbsd.org 
Subject: Re: Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"

On Mon, 16 Mar 2020 04:12:41 +
Ian McWilliam  wrote:

> Did you pkg_add p5-CGI-Fast at some point?
>
> What does your pkg_info | grep -i p5-CGI look like?
>
> Ian McWilliam
> 
> From: owner-po...@openbsd.org  on behalf of
> nik...@rpgresearch.com  Sent: Monday, 16
> March 2020 12:35 PM To: ports@openbsd.org 
> Subject: Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"
>
> I have been working on setting up Sympa on OpenBSD.
>
> I have OpenSMTPd working with the Sympa daemon, but I'm getting stuck
> on the wwsympa set up with nginx (I hope to switch to OpenBSD's HTTPd
> after I get Nginx working).
>
> I used the Nginx config provided by the port maintainer:
>
> >server {
> >   server_name domain.com;
> >   listen on 0.0.0.0:80;
> >
> >   location /static-sympa {
> >   alias /var/www/sympa/;
> >   }
> >
> >
> >   location / {
> >   fastcgi_pass localhost:1026;
> >   fastcgi_split_path_info ^(/sympa)(.+)$;
> >   include fastcgi_params;
> >   fastcgi_param PATH_INFO $fastcgi_path_info;
> >   fastcgi_param
> >   SCRIPT_FILENAME /usr/local/libexec/sympa/wwsympa-wrapper.fcgi; }
> >}
>
> When I launch all the services, wwsympa crashes out with the following
> error in /var/log/messages.
>
> >wwsympa[40272]: err main::#138 DIED: Can't locate CGI/Fast.pm in @INC
> >(you may need to install the CGI::Fast module) (@INC
> >contains: /usr/local/libdata/perl5/site_perl/amd64-openbsd 
> >/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd 
> >/usr/libdata/perl5)
> >at /usr/local/libexec/sympa/wwsympa.fcgi line 139
>
> I will now make this email unbearably long by sharing this dump:
>
> >ls /usr/local/libdata/perl5/site_perl/
> AppConfigEncode   MIME
> Role iso8859.pl   mhsingle.pl
> AppConfig.pm ErrorMLDBM
> SQL  libwww   mhthread.pl
> Archive  Error.pm MLDBM.pm
> Sort mhamain.pl   mhtime.pl
> BEval MRO
> StackTrace   mhdb.pl  mhtxtenrich.pl
> Bundle   Exporter Mail
> Sub  mhdysub.pl   mhtxthtml.pl
> CGI  Fh.pmMath
> Sympamhexternal.plmhtxtplain.pl
> CGI.pm   File MaxMind
> Sympa.pm mhfile.plmhtxttsv.pl
> CGI.pod  Font Method
> Term mhidxrc.pl   mhusage.pl
> ClassFreezeThaw.pmModule
> Test mhindex.pl   mhutil.pl
> CloneGeoIP2   MojoX
> Throwablemhinit.plnamespace
> Conf.pm  GeoIP2.pmMoo
> Throwable.pm mhlock.ploo.pm Convert
> HTML Moo.pm   Time
> mhmimetypes.pl   osinit.pl Crypt
> HTTP MooX Try
> mhmsgextbody.pl  qprint.pl DDP.pm
> IO   Mozilla  URI
> mhmsgfile.pl readmail.pl Data
> JSON MuninURI.pm
> mhnote.plspamassassin-run.pod Date
> LWP  Net  WWW
> mhnull.plstrictures DateTime
> LWP.pm   OpenBSD  XML
> mhopt.pl strictures.pm Devel
> List POD2 amd64-openbsd
> mhrcfile.pl Digest   Locale
> Package  base64.plmhrcvars.pl
> Dist Log  RPC
> ewhutil.pl   mhrmm.pl EmailMHonArc
> RRDp.pm  iso2022jp.pl mhscan.pl
>
> Is this a dependency issue, or is there a step that I could be
> missing? I am not familiar with CGI in general.
>
>
> Thank you all!
>

Thank you for responding so quickly:

>pkg_info | grep -i p5-CGI

>p5-CGI-4.43 handle Common Gateway Interface requests and
>responses

It does appear to be a listed dependency and is installed:

>cat /var/db/pkg/sympa-6.2.16p2/+REQUIRING  | grep p5-CGI-4.43
>p5-CGI-4.43

CVS: cvs.openbsd.org: ports

[Juan Francisco Cantero Hurtado]

CVSROOT:/cvs
Module name:ports
Changes by: juan...@cvs.openbsd.org 2020/03/16 16:00:59

Modified files:
devel/mercurial: Makefile distinfo 
devel/mercurial/pkg: PLIST-main 

Log message:
Update to mercurial 5.3.1.

Re: [new] devel/yarn an alternative to npm

[Aaron Bieber]

On Mon, 16 Mar 2020 at 17:44:31 -0300, Elias M. Mariani wrote:
> Hello Aaron,
> This is an old submission...
> Is there any reason to have this tool in the ports tree?

I would like to get it in as a more sane (not by much) alternative to npm.

I have a yet to be submitted version that fixes an issue people reported back.
I'll send it of tonight some time (along with a node update).

> I found this mail because I wanted to see if porting VS Code was
> possible and how much work would require.
> TL;DR: VS Code uses Yarn to install.

It might be worth checking in with bcallah@, I know he was also working on a
port of it. Not sure how far along he got though.

> Is this the case for lots of ports?
> I think that there are lots of interesting tools to have: Discord, VS
> Code, Atom, so on...
> Most of them depending on npm, yarn, Electron (now we have this one I think).
> But it seems a lot of work to produce packages with our ports workflow
> with those tools, you seem to have more insight on the subject.
> What do you think?

The only way to do it sanely is to vendor the 'node_modules' directories with
everything. Having a port per module (yarn, npm or otherwise) is completely
untenable.

> 
> Cheers.
> Elias mariani@
> 
> On Thu, Dec 12, 2019 at 2:15 PM Aaron Bieber  wrote:
> >
> > Hi!
> >
> > This is a port of yarn. It's an alternative to npm.
> >
> >   https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli
> >   (I will post an update to node when it lands.)
> >
> > Unfortunately it suffers from some of the same issues. :P
> >
> > DESCR:
> >  Fast: Yarn caches every package it has downloaded, so it never needs to
> >  download the same package again. It also does almost everything 
> > concurrently to
> >  maximize resource utilization. This means even faster installs.
> >
> >  Reliable: Using a detailed but concise lockfile format and a deterministic
> >  algorithm for install operations, Yarn is able to guarantee that any
> >  installation that works on one system will work exactly the same on another
> >  system.
> >
> >  Secure: Yarn uses checksums to verify the integrity of every installed 
> > package
> >  before its code is executed.
> >
> > OK? Cluestick? "Take yer JS and gtfo?!"?
> >
> > --
> > PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE

Re: [new] devel/yarn an alternative to npm

[Rafael Sadowski]

On Mon Mar 16, 2020 at 05:44:31PM -0300, Elias M. Mariani wrote:
> Hello Aaron,
> This is an old submission...
> Is there any reason to have this tool in the ports tree?
> I found this mail because I wanted to see if porting VS Code was
> possible and how much work would require.
> TL;DR: VS Code uses Yarn to install.
> Is this the case for lots of ports?
> I think that there are lots of interesting tools to have: Discord, VS
> Code, Atom, so on...

Looks like fun, good luck.

https://svnweb.freebsd.org/ports/head/editors/atom/Makefile?revision=526528=markup

> Most of them depending on npm, yarn, Electron (now we have this one I think).
> But it seems a lot of work to produce packages with our ports workflow
> with those tools, you seem to have more insight on the subject.
> What do you think?
> 
> Cheers.
> Elias mariani@
> 
> On Thu, Dec 12, 2019 at 2:15 PM Aaron Bieber  wrote:
> >
> > Hi!
> >
> > This is a port of yarn. It's an alternative to npm.
> >
> >   https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli
> >   (I will post an update to node when it lands.)
> >
> > Unfortunately it suffers from some of the same issues. :P
> >
> > DESCR:
> >  Fast: Yarn caches every package it has downloaded, so it never needs to
> >  download the same package again. It also does almost everything 
> > concurrently to
> >  maximize resource utilization. This means even faster installs.
> >
> >  Reliable: Using a detailed but concise lockfile format and a deterministic
> >  algorithm for install operations, Yarn is able to guarantee that any
> >  installation that works on one system will work exactly the same on another
> >  system.
> >
> >  Secure: Yarn uses checksums to verify the integrity of every installed 
> > package
> >  before its code is executed.
> >
> > OK? Cluestick? "Take yer JS and gtfo?!"?
> >
> > --
> > PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE
> 

Re: [new] devel/yarn an alternative to npm

[Elias M. Mariani]

Hello Aaron,
This is an old submission...
Is there any reason to have this tool in the ports tree?
I found this mail because I wanted to see if porting VS Code was
possible and how much work would require.
TL;DR: VS Code uses Yarn to install.
Is this the case for lots of ports?
I think that there are lots of interesting tools to have: Discord, VS
Code, Atom, so on...
Most of them depending on npm, yarn, Electron (now we have this one I think).
But it seems a lot of work to produce packages with our ports workflow
with those tools, you seem to have more insight on the subject.
What do you think?

Cheers.
Elias mariani@

On Thu, Dec 12, 2019 at 2:15 PM Aaron Bieber  wrote:
>
> Hi!
>
> This is a port of yarn. It's an alternative to npm.
>
>   https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli
>   (I will post an update to node when it lands.)
>
> Unfortunately it suffers from some of the same issues. :P
>
> DESCR:
>  Fast: Yarn caches every package it has downloaded, so it never needs to
>  download the same package again. It also does almost everything concurrently 
> to
>  maximize resource utilization. This means even faster installs.
>
>  Reliable: Using a detailed but concise lockfile format and a deterministic
>  algorithm for install operations, Yarn is able to guarantee that any
>  installation that works on one system will work exactly the same on another
>  system.
>
>  Secure: Yarn uses checksums to verify the integrity of every installed 
> package
>  before its code is executed.
>
> OK? Cluestick? "Take yer JS and gtfo?!"?
>
> --
> PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE

Re: I'd like to remove tortoisehg. Anyone using it?.

[Juan Francisco Cantero Hurtado]

On Sat, Mar 14, 2020 at 10:16:42PM -0400, George Koehler wrote:
> On Sat, 14 Mar 2020 21:32:36 +0100
> Juan Francisco Cantero Hurtado  wrote:
> 
> > Since a few mercurial releases ago, they're not releasing new versions.
> > Tortoise uses the internal API of mercurial, so I can't update mercurial
> > without updating also tortoisehg. We're stuck now on the version 5.0 and
> > the mercurial devs are going to release 5.4 the next month.
> 
> I use mercurial, but I have never installed tortoisehg on OpenBSD.
> ok gkoehler@ to remove devel/tortoisehg
> 
> We have tortoisehg 5.0.2.  HOMEPAGE [1] doesn't show versions after
> 5.0.2, but their repo has tags [2] of 5.1, 5.3, 5.3.1, and the
> download area [3] has tars of 5.3 and 5.3.1.  Almost no distro has
> these versions, but FreeBSD uses the tag of 5.1, and Fedora has 5.3.1.
> --George
> 
> [1] https://tortoisehg.bitbucket.io/
> [2] https://bitbucket.org/tortoisehg/thg/downloads/?tab=tags
> [3] https://bitbucket.org/tortoisehg/targz/downloads/

That's the problem. In the last year, the releases have been lagging,
sometimes for months, only published as a tag in bitbucket, not always
and not at time for mayor mercurial versions. On the other hand,
mercurial is a server exposed to the network using an unsupported python
version. Our actual mercurial version would be 1+ year old for 6.8 with
large changes in between (python2 to python3).

Tortoise is easy to maintain. We could add the port again in the future
if upstream starts to release new versions regularly. There is a dev who
is trying to move the project to heptapod and the tarballs/binaries to
the official mercurial server. They are just not there yet.

I will remove the port this night.

https://bitbucket.org/tortoisehg/thg/issues/5443/same-problem-as-always-mercurial-51-is-out

https://groups.google.com/forum/#!topic/thg-dev/wePAki2smKE


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

Re: [gcc-archs/sparc64] Fix net/arping build

[Kurt Mosiejczuk]

On Mon, Mar 16, 2020 at 08:48:50PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 16 2020, Kurt Mosiejczuk  wrote:
> > arping needs c99 mode. Adding this to CFLAGS fixes the build on sparc64
> > (and presumably other base-gcc architectures).

> > ok?

> I'd prefer -std=gnu99.  -std=gnuXX is the default for both clang and gcc.

> > (cc maintainer)

> done :)

Sure thing. I just need to remember to grep for gnu99 next time I am
looking for an example :)

--Kurt

CVS: cvs.openbsd.org: ports

[Juan Francisco Cantero Hurtado]

CVSROOT:/cvs
Module name:ports
Changes by: juan...@cvs.openbsd.org 2020/03/16 13:53:57

Modified files:
devel  : Makefile 
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 
Removed files:
devel/tortoisehg: Makefile distinfo 
devel/tortoisehg/files: config.py 
devel/tortoisehg/patches: patch-setup_py 
devel/tortoisehg/pkg: DESCR PLIST 

Log message:
Remove tortoisehg.

Tortoisehg uses the internal mercurial API. We must to maintain mercurial and
tortoisehg in sync. In the last year, the releases have been lagging, sometimes
for months, only published as a tag in bitbucket, not always and not at time
for mayor mercurial versions. On the other hand, mercurial is a server exposed
to the network using an unsupported python version. Our actual mercurial
version would be 1+ year old for 6.8 with large changes in between (python2 to
python3).

We could add the port again in the future if upstream starts to release new
versions regularly.

OK paco@ gkoehler@. No objection sthen@.

Re: llvm: -python: adjust RDEP

[Jeremie Courreges-Anglas]

On Mon, Mar 16 2020, Klemens Nanni  wrote:
> On Mon, Mar 16, 2020 at 02:57:16PM +0100, Jeremie Courreges-Anglas wrote:
>> On Sun, Mar 15 2020, Klemens Nanni  wrote:
>> > All subpackages ave a RDEP on python, so explicitness for -python is
>> > redundant.
>> 
>> -python ships a true python module, IMO it should have an rdep on python
>> like other python modules in the tree.  Same goes for -lldb.
> Note that i'm certainly not removing the RDEP, it is already registered
> through the module.  I don't want to specify it twice because it is a)
> redundant and b) brings other problems.

In my PoV RUN_DEPENDS-python is explicit and doesn't bring other
problems.  Which problems do you have in mind?

>> -main ships a bunch of python scripts, but right now those scripts
>> aren't properly MODPY_ADJ'd.  I think it makes more sense to discuss
>> removing the python rdep in this subpackage.  scan-view for example is
>> a python script, thankfully scan-build alone is enough.
>> 
>> > More importantly, this uncovers how the devel/gtest RDEP has been
>> > clobbered by it;
>> 
>> The deps of the -python subpackage make sense to me as-is, without an
>> explicit dependency on devel/gtest.
> gtest already is an explicit RDEP for every subpackage through global
> RUN_DEPENDS, but that is another story of its own as you elaborated.

I don't understand this.  The -python and -lldb subpackage have explicit
rdeps that aren't affected by the global RUN_DEPENDS, only -main
inherits the global RUN_DEPENDS.

>> Not ok with this diff, but I'm happy with moving llvm to python3 if
>> possible.  I took a look some days/weeks ago, sadly I didn't note down
>> why the switch wasn't straightforward.  Maybe I was just busy with
>> something else.  Looks like a bunch of python files import __future__ so
>> this looks promising.
> For clarity, here are all RDEPs before
>
>   RUN_DEPENDS-main=devel/gtest lang/python/2.7
>   RUN_DEPENDS-python=lang/python/2.7
>   RUN_DEPENDS-lldb=devel/llvm,,-main lang/python/2.7 devel/py-six
>
> and after my diff:
>
>   RUN_DEPENDS-main=devel/gtest lang/python/2.7
>   RUN_DEPENDS-python=devel/gtest lang/python/2.7
>   RUN_DEPENDS-lldb=devel/llvm,,-main lang/python/2.7 devel/py-six
>
> Afterall, only gtest is added (and can be removed with a separate diff)
> once we have more insight.

So far I've tried to minimize churn in this port, that means try to
avoid changes if they don't bring a visible improvement.  Adding gtest
to RUN_DEPENDS-python is not an improvement per se.

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

Re: [gcc-archs/sparc64] Fix net/arping build

[Jeremie Courreges-Anglas]

On Mon, Mar 16 2020, Kurt Mosiejczuk  wrote:
> arping needs c99 mode. Adding this to CFLAGS fixes the build on sparc64
> (and presumably other base-gcc architectures).
>
> ok?

I'd prefer -std=gnu99.  -std=gnuXX is the default for both clang and gcc.

> (cc maintainer)

done :)

> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/arping/Makefile,v
> retrieving revision 1.50
> diff -u -p -r1.50 Makefile
> --- Makefile  9 Mar 2020 07:58:08 -   1.50
> +++ Makefile  16 Mar 2020 16:31:46 -
> @@ -19,6 +19,8 @@ MASTER_SITES =  http://www.habets.pp.se/s
>  
>  LIB_DEPENDS =net/libnet/1.1
>  
> +CFLAGS +=-std=c99
> +
>  CONFIGURE_STYLE = gnu
>  CONFIGURE_ENV = CFLAGS="${CFLAGS} -I${LOCALBASE}/include/libnet-1.1 \
>   `libnet-config-1.1 --defines`" \
>

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

Re: [gcc-archs/sparc64] Fix net/arping build

[Klemens Nanni]

OK kn

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/03/16 12:22:35

Modified files:
lang/seed7 : Makefile distinfo 
lang/seed7/pkg : PLIST 

Log message:
Update to seed7-20200308

CVS: cvs.openbsd.org: ports

[Martin Reindl]

CVSROOT:/cvs
Module name:ports
Changes by: mar...@cvs.openbsd.org  2020/03/16 12:06:29

Modified files:
math/py-cftime : Makefile distinfo 

Log message:
Update to py-cftime 1.1.1.

[gcc-archs/sparc64] Fix net/arping build

[Kurt Mosiejczuk]

arping needs c99 mode. Adding this to CFLAGS fixes the build on sparc64
(and presumably other base-gcc architectures).

ok?

(cc maintainer)

--Kurt

Index: Makefile
===
RCS file: /cvs/ports/net/arping/Makefile,v
retrieving revision 1.50
diff -u -p -r1.50 Makefile
--- Makefile9 Mar 2020 07:58:08 -   1.50
+++ Makefile16 Mar 2020 16:31:46 -
@@ -19,6 +19,8 @@ MASTER_SITES =http://www.habets.pp.se/s
 
 LIB_DEPENDS =  net/libnet/1.1
 
+CFLAGS +=  -std=c99
+
 CONFIGURE_STYLE = gnu
 CONFIGURE_ENV = CFLAGS="${CFLAGS} -I${LOCALBASE}/include/libnet-1.1 \
`libnet-config-1.1 --defines`" \

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/03/16 10:09:08

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 

Log message:
register rebar16 removal

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/03/16 10:08:53

Modified files:
devel/rebar: Makefile 

Log message:
retire rebar16

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/03/16 10:07:46

Modified files:
lang/erlang: Makefile Makefile.inc erlang.port.mk 
Removed files:
lang/erlang/16 : Makefile distinfo 
lang/erlang/16/patches: patch-Makefile_in 
patch-erts_emulator_Makefile_in 
patch-erts_etc_common_ct_run_c 
patch-erts_etc_common_dialyzer_c 
patch-erts_etc_common_erlc_c 
patch-erts_etc_common_escript_c 
patch-erts_etc_common_typer_c 
patch-erts_lib_src_Makefile_in 
patch-lib_asn1_c_src_asn1_erl_nif_c 
patch-lib_dialyzer_src_dialyzer_plt_erl 
patch-lib_os_mon_c_src_memsup_c 
patch-lib_tools_c_src_Makefile_in 
patch-lib_wx_c_src_wxe_gl_cpp 
patch-lib_wx_c_src_wxe_impl_cpp 
patch-lib_wx_configure_in 
patch-make_install_bin 
patch-make_target_mk 
lang/erlang/16/pkg: DESCR-main DESCR-wx PLIST-main PLIST-wx 

Log message:
remove arcane erlang 16 now that nothing in tree uses it anymore

ok solene@

Re: update security/sn0int

[kpcyrd]

hey!

thanks for pointing this out. The project does explicitly enable the
`use-pkg-config` feature to enforce dynamic linking, I just forgot to
add it to WANTLIB as well.

I've attached a new patch.

Thanks!

On Mon, Mar 16, 2020 at 11:58:54AM +0100, Sebastien Marie wrote:
> On Mon, Mar 16, 2020 at 03:49:11AM +, kpcyrd wrote:
> > hi!
> > 
> > this patch imports the latest version and drops the patches that have
> > been upstreamed (patch follows).
>  
> I will take a look.
>  
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/security/sn0int/Makefile,v
> > retrieving revision 1.6
> > diff -u -p -r1.6 Makefile
> > --- Makefile12 Mar 2020 10:30:05 -  1.6
> > +++ Makefile16 Mar 2020 03:41:39 -
> > @@ -7,7 +7,7 @@ COMMENT =   semi-automatic OSINT framework
> >  
> >  GH_ACCOUNT =   kpcyrd
> >  GH_PROJECT =   sn0int
> > -GH_TAGNAME =   v0.11.2
> > +GH_TAGNAME =   v0.18.0
> >  REVISION = 0
> 
> REVISION should be dropped on update.
>   
> >  CATEGORIES =   security
> > @@ -16,7 +16,7 @@ CATEGORIES =  security
> >  PERMIT_PACKAGE =   Yes
> >  
> >  # uses pledge()
> > -LIB_DEPENDS =  databases/sqlite3 ${MODLUA_LIB_DEPENDS}
> > +LIB_DEPENDS =  databases/sqlite3 security/libsodium 
> > ${MODLUA_LIB_DEPENDS}
> >  WANTLIB += c c++abi m pthread sqlite3 ${MODLUA_WANTLIB}
> 
> hum ? adding security/libsodium in LIB_DEPENDS and not in WANTLIB ? it means 
> the
> library is statically linked.
> 
> I just commited support for libsodium-sys crate in devel/cargo module. by
> default, libsodium library will be dynamically linked. could you add sodium to
> WANTLIB ?
> 
> Thanks.
> -- 
> Sebastien Marie
> 
Index: Makefile
===
RCS file: /cvs/ports/security/sn0int/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile	12 Mar 2020 10:30:05 -	1.6
+++ Makefile	16 Mar 2020 13:24:38 -
@@ -7,8 +7,7 @@ COMMENT =	semi-automatic OSINT framework
 
 GH_ACCOUNT =	kpcyrd
 GH_PROJECT =	sn0int
-GH_TAGNAME =	v0.11.2
-REVISION =	0
+GH_TAGNAME =	v0.18.0
 
 CATEGORIES =	security
 
@@ -16,8 +15,8 @@ CATEGORIES =	security
 PERMIT_PACKAGE =	Yes
 
 # uses pledge()
-LIB_DEPENDS =		databases/sqlite3 ${MODLUA_LIB_DEPENDS}
-WANTLIB +=		c c++abi m pthread sqlite3 ${MODLUA_WANTLIB}
+LIB_DEPENDS =		databases/sqlite3 security/libsodium ${MODLUA_LIB_DEPENDS}
+WANTLIB +=		c c++abi m pthread sqlite3 sodium ${MODLUA_WANTLIB}
 
 # as devel/cargo MODULES adds DISTFILES, GH_* didn't
 DISTFILES +=		${DISTNAME}${EXTRACT_SUFX}
@@ -32,102 +31,104 @@ BUILD_DEPENDS =		lang/rust>=1.34 \
 RUN_DEPENDS =		net/libmaxminddb,-asn \
 			net/libmaxminddb,-city
 
-# keep libc >=0.2.63 for sparc64 support
-MODCARGO_CRATES_UPDATE +=	libc
-MODCARGO_CRATES +=	libc	0.2.63	# MIT OR Apache-2.0
-
-MODCARGO_CRATES +=	adler32	1.0.3	# BSD-3-Clause AND Zlib
-MODCARGO_CRATES +=	aho-corasick	0.7.3	# Unlicense/MIT
+MODCARGO_CRATES +=	adler32	1.0.4	# Zlib
+MODCARGO_CRATES +=	aho-corasick	0.7.9	# Unlicense/MIT
 MODCARGO_CRATES +=	ansi_term	0.11.0	# MIT
-MODCARGO_CRATES +=	antidote	1.0.0	# MIT/Apache-2.0
-MODCARGO_CRATES +=	approx	0.1.1	# Apache-2.0
-MODCARGO_CRATES +=	argon2rs	0.2.5	# MIT
-MODCARGO_CRATES +=	arrayref	0.3.5	# BSD-2-Clause
-MODCARGO_CRATES +=	arrayvec	0.4.10	# MIT/Apache-2.0
-MODCARGO_CRATES +=	atty	0.2.11	# MIT
-MODCARGO_CRATES +=	autocfg	0.1.2	# Apache-2.0/MIT
-MODCARGO_CRATES +=	backtrace	0.3.15	# MIT/Apache-2.0
-MODCARGO_CRATES +=	backtrace-sys	0.1.28	# MIT/Apache-2.0
-MODCARGO_CRATES +=	base64	0.10.1	# MIT/Apache-2.0
+MODCARGO_CRATES +=	arrayref	0.3.6	# BSD-2-Clause
+MODCARGO_CRATES +=	arrayvec	0.4.12	# MIT/Apache-2.0
+MODCARGO_CRATES +=	arrayvec	0.5.1	# MIT/Apache-2.0
+MODCARGO_CRATES +=	atty	0.2.14	# MIT
+MODCARGO_CRATES +=	autocfg	0.1.7	# Apache-2.0/MIT
+MODCARGO_CRATES +=	autocfg	1.0.0	# Apache-2.0 OR MIT
+MODCARGO_CRATES +=	backtrace	0.3.41	# MIT/Apache-2.0
+MODCARGO_CRATES +=	backtrace-sys	0.1.33	# MIT/Apache-2.0
 MODCARGO_CRATES +=	base64	0.9.3	# MIT/Apache-2.0
-MODCARGO_CRATES +=	bitflags	1.0.4	# MIT/Apache-2.0
-MODCARGO_CRATES +=	blake2	0.8.0	# MIT OR Apache-2.0
-MODCARGO_CRATES +=	blake2-rfc	0.2.18	# MIT OR Apache-2.0
+MODCARGO_CRATES +=	base64	0.10.1	# MIT/Apache-2.0
+MODCARGO_CRATES +=	base64	0.11.0	# MIT/Apache-2.0
+MODCARGO_CRATES +=	bincode	1.2.1	# MIT
+MODCARGO_CRATES +=	bindgen	0.50.1	# BSD-3-Clause
+MODCARGO_CRATES +=	bitflags	1.2.1	# MIT/Apache-2.0
+MODCARGO_CRATES +=	blake2	0.8.1	# MIT OR Apache-2.0
+MODCARGO_CRATES +=	blake2b_simd	0.5.10	# MIT
 MODCARGO_CRATES +=	block-buffer	0.3.3	# MIT/Apache-2.0
 MODCARGO_CRATES +=	block-buffer	0.7.3	# MIT OR Apache-2.0
-MODCARGO_CRATES +=	block-padding	0.1.4	# MIT OR Apache-2.0
-MODCARGO_CRATES +=	boxxy	0.10.0	# LGPL-3.0
-MODCARGO_CRATES +=	bs58	0.2.2	# MIT/Apache-2.0
+MODCARGO_CRATES +=	block-padding	0.1.5	# MIT OR Apache-2.0
+MODCARGO_CRATES +=	boxxy	0.11.0	# LGPL-3.0

CVS: cvs.openbsd.org: ports

[Alexandre Ratchov]

CVSROOT:/cvs
Module name:ports
Changes by: ratc...@cvs.openbsd.org 2020/03/16 09:07:55

Modified files:
audio/gqmpeg   : Makefile 
audio/gqmpeg/patches: patch-src_mixer_c 
Added files:
audio/gqmpeg/patches: patch-src_Makefile_in 

Log message:
Use the new sioctl_open(3) API to manage the current audio level.

Now the programm displays and controls the current sndiod master
volume level, which is present on any device and always corresponds to
the device programs are playing on. This also fixes crashes when the
volume slider is touched.

ok rsadowski

Re: CVS: cvs.openbsd.org: ports

[Alexandre Ratchov]

On Mon, Mar 16, 2020 at 08:54:45AM -0600, Alexandre Ratchov wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   ratc...@cvs.openbsd.org 2020/03/16 08:54:45
> 
> Modified files:
>   x11/i3status   : Makefile 
> Added files:
>   x11/i3status/patches: patch-Makefile_am patch-configure_ac 
> patch-include_i3status_h 
> patch-src_print_volume_c patch-src_sndio_c 
> Removed files:
>   x11/i3status/patches: patch-Makefile_in 
> 
> Log message:
> Use the new sioctl_open(3) API to display current audio level.
> 
> Now the programm displays the current sndiod master volume level,
> which is present on any device and always corresponds to the device
> programs are playing on.
> 

Sorry, forgot to mention this is OK rsadowski@ for this one too.

CVS: cvs.openbsd.org: ports

[Alexandre Ratchov]

CVSROOT:/cvs
Module name:ports
Changes by: ratc...@cvs.openbsd.org 2020/03/16 08:54:45

Modified files:
x11/i3status   : Makefile 
Added files:
x11/i3status/patches: patch-Makefile_am patch-configure_ac 
  patch-include_i3status_h 
  patch-src_print_volume_c patch-src_sndio_c 
Removed files:
x11/i3status/patches: patch-Makefile_in 

Log message:
Use the new sioctl_open(3) API to display current audio level.

Now the programm displays the current sndiod master volume level,
which is present on any device and always corresponds to the device
programs are playing on.

Re: CVS: cvs.openbsd.org: ports

[Alexandre Ratchov]

On Mon, Mar 16, 2020 at 08:50:57AM -0600, Alexandre Ratchov wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   ratc...@cvs.openbsd.org 2020/03/16 08:50:57
> 
> Modified files:
>   sysutils/tray-app: Makefile 
>   sysutils/tray-app/patches: patch-sound_Makefile 
> Added files:
>   sysutils/tray-app/patches: patch-sound_sound_c 
> 
> Log message:
> Use the new sioctl_open(3) API to display current audio level.
> 
> Now the programm displays and controls the sndiod master volume knob,
> which is present on any device and always corresponds to the device
> programs are playing on.
> 

Sorry, forgot to mention this is OK rsadowski@.

CVS: cvs.openbsd.org: ports

[Alexandre Ratchov]

CVSROOT:/cvs
Module name:ports
Changes by: ratc...@cvs.openbsd.org 2020/03/16 08:50:57

Modified files:
sysutils/tray-app: Makefile 
sysutils/tray-app/patches: patch-sound_Makefile 
Added files:
sysutils/tray-app/patches: patch-sound_sound_c 

Log message:
Use the new sioctl_open(3) API to display current audio level.

Now the programm displays and controls the sndiod master volume knob,
which is present on any device and always corresponds to the device
programs are playing on.

Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2

[Elias M. Mariani]

Sorry, I do not follow.
Are you asking me why I send the diff of distinfo?

Cheers.

On Mon, Mar 16, 2020 at 10:04 AM Marc Espie  wrote:
>
> On Mon, Mar 16, 2020 at 08:26:35AM +, Stuart Henderson wrote:
> > On 2020/03/16 00:45, Marc Espie wrote:
> > > On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> > > > Sure.
> > > > + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
> > > > MASTER_SITES. (I guess that we want HTTPS first?).
> > >
> > > We don't really care about https, but the lip6 server is fairly reliable.
> >
> > I do - it doesn't matter for fetching an existing version where we
> > already have hashes, but guards against some problems for updates.
> > (obviously not all, but enough to be worthwhile)
> >
> >
> Ping, what's up with your signature diff ?
>

Re: llvm: -python: adjust RDEP

[Klemens Nanni]

On Mon, Mar 16, 2020 at 02:57:16PM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Mar 15 2020, Klemens Nanni  wrote:
> > All subpackages ave a RDEP on python, so explicitness for -python is
> > redundant.
> 
> -python ships a true python module, IMO it should have an rdep on python
> like other python modules in the tree.  Same goes for -lldb.
Note that i'm certainly not removing the RDEP, it is already registered
through the module.  I don't want to specify it twice because it is a)
redundant and b) brings other problems.

> -main ships a bunch of python scripts, but right now those scripts
> aren't properly MODPY_ADJ'd.  I think it makes more sense to discuss
> removing the python rdep in this subpackage.  scan-view for example is
> a python script, thankfully scan-build alone is enough.
> 
> > More importantly, this uncovers how the devel/gtest RDEP has been
> > clobbered by it;
> 
> The deps of the -python subpackage make sense to me as-is, without an
> explicit dependency on devel/gtest.
gtest already is an explicit RDEP for every subpackage through global
RUN_DEPENDS, but that is another story of its own as you elaborated.

> Not ok with this diff, but I'm happy with moving llvm to python3 if
> possible.  I took a look some days/weeks ago, sadly I didn't note down
> why the switch wasn't straightforward.  Maybe I was just busy with
> something else.  Looks like a bunch of python files import __future__ so
> this looks promising.
For clarity, here are all RDEPs before

RUN_DEPENDS-main=devel/gtest lang/python/2.7
RUN_DEPENDS-python=lang/python/2.7
RUN_DEPENDS-lldb=devel/llvm,,-main lang/python/2.7 devel/py-six

and after my diff:

RUN_DEPENDS-main=devel/gtest lang/python/2.7
RUN_DEPENDS-python=devel/gtest lang/python/2.7
RUN_DEPENDS-lldb=devel/llvm,,-main lang/python/2.7 devel/py-six

Afterall, only gtest is added (and can be removed with a separate diff)
once we have more insight.

Re: CVS: cvs.openbsd.org: ports

[Solene Rapenne]

On Mon, Mar 16, 2020 at 07:43:38AM -0600, Solene Rapenne wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   sol...@cvs.openbsd.org  2020/03/16 07:43:38
> 
> Removed files:
>   net/ejabberd   : Makefile distinfo 
>   net/ejabberd/patches: patch-src_Makefile_in 
> patch-src_ejabberd_c2s_erl 
> patch-src_ejabberd_cfg_example 
> patch-src_ejabberdctl_template 
>   net/ejabberd/pkg: DESCR PLIST README ejabberd.rc 
> 
> Log message:
> Remove net/ejabberd
> 
> our version is very old and lagging behind upstream
> no one volunteered to update it in one year time window
> 
> ok jca@ jasper@
> 

was also ok bcallah@

CVS: cvs.openbsd.org: ports

[Solene Rapenne]

CVSROOT:/cvs
Module name:ports
Changes by: sol...@cvs.openbsd.org  2020/03/16 08:06:58

Modified files:
net: Makefile 

Log message:
- ejabberd

Re: llvm: -python: adjust RDEP

[Jeremie Courreges-Anglas]

On Sun, Mar 15 2020, Klemens Nanni  wrote:
> All subpackages ave a RDEP on python, so explicitness for -python is
> redundant.

-python ships a true python module, IMO it should have an rdep on python
like other python modules in the tree.  Same goes for -lldb.

-main ships a bunch of python scripts, but right now those scripts
aren't properly MODPY_ADJ'd.  I think it makes more sense to discuss
removing the python rdep in this subpackage.  scan-view for example is
a python script, thankfully scan-build alone is enough.

> More importantly, this uncovers how the devel/gtest RDEP has been
> clobbered by it;

The deps of the -python subpackage make sense to me as-is, without an
explicit dependency on devel/gtest.

> I cannot yet say what inside LLVM actually requires
> gtest(1) at runtime and the dependency was added in 2017 for the 4.0.1
> update, but we can fix this in a different commit.

Actually gtest was added in Makefile rev 1.71 for an llvm 3.5 snapshot,
the two lines below were added to pkg/PLIST for llvm 3.0 and are now
outdated.  I'll do a few more tests but I'm about to delete the gtest
rdep, the installed files only reference gtest in three places which
don't seem relevant.  Brad, do you know if gtest is still useful in
RUN_DEPENDS?


Index: pkg/PLIST-main
===
RCS file: /cvs/ports/devel/llvm/pkg/PLIST-main,v
retrieving revision 1.16
diff -u -p -r1.16 PLIST-main
--- pkg/PLIST-main  6 Mar 2020 14:39:57 -   1.16
+++ pkg/PLIST-main  16 Mar 2020 00:50:52 -
@@ -2455,8 +2455,6 @@ lib/cmake/llvm/VersionFromVCS.cmake
 @static-lib lib/libclangStaticAnalyzerCore.a
 @static-lib lib/libclangStaticAnalyzerFrontend.a
 @static-lib lib/libclangTooling.a
-@comment lib/libgtest.a
-@comment lib/libgtest_main.a
 @static-lib lib/libclangToolingASTDiff.a
 @static-lib lib/libclangToolingCore.a
 @static-lib lib/libclangToolingInclusions.a


> Eventually, I want to use Python 3 inside LLVM - this diff is a first
> step, but it already showed side effects, so let's go one by one.
>
>
> Feedback? OK?

Not ok with this diff, but I'm happy with moving llvm to python3 if
possible.  I took a look some days/weeks ago, sadly I didn't note down
why the switch wasn't straightforward.  Maybe I was just busy with
something else.  Looks like a bunch of python files import __future__ so
this looks promising.

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

CVS: cvs.openbsd.org: ports

[Solene Rapenne]

CVSROOT:/cvs
Module name:ports
Changes by: sol...@cvs.openbsd.org  2020/03/16 07:48:00

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 

Log message:
Add ejabberd as an ancient software not maintained full of security holes

it is still maintained upstream though but our version is very old

CVS: cvs.openbsd.org: ports

[Solene Rapenne]

CVSROOT:/cvs
Module name:ports
Changes by: sol...@cvs.openbsd.org  2020/03/16 07:43:38

Removed files:
net/ejabberd   : Makefile distinfo 
net/ejabberd/patches: patch-src_Makefile_in 
  patch-src_ejabberd_c2s_erl 
  patch-src_ejabberd_cfg_example 
  patch-src_ejabberdctl_template 
net/ejabberd/pkg: DESCR PLIST README ejabberd.rc 

Log message:
Remove net/ejabberd

our version is very old and lagging behind upstream
no one volunteered to update it in one year time window

ok jca@ jasper@

Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2

[Marc Espie]

On Mon, Mar 16, 2020 at 08:26:35AM +, Stuart Henderson wrote:
> On 2020/03/16 00:45, Marc Espie wrote:
> > On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> > > Sure.
> > > + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
> > > MASTER_SITES. (I guess that we want HTTPS first?).
> > 
> > We don't really care about https, but the lip6 server is fairly reliable.
> 
> I do - it doesn't matter for fetching an existing version where we
> already have hashes, but guards against some problems for updates.
> (obviously not all, but enough to be worthwhile)
> 
> 
Ping, what's up with your signature diff ?

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2020/03/16 05:26:47

Modified files:
x11/qt5/qtbase : Makefile 

Log message:
fix spelling of REVISION

Re: update security/sn0int

[Sebastien Marie]

On Mon, Mar 16, 2020 at 03:49:11AM +, kpcyrd wrote:
> hi!
> 
> this patch imports the latest version and drops the patches that have
> been upstreamed (patch follows).
 
I will take a look.
 
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/sn0int/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- Makefile  12 Mar 2020 10:30:05 -  1.6
> +++ Makefile  16 Mar 2020 03:41:39 -
> @@ -7,7 +7,7 @@ COMMENT = semi-automatic OSINT framework
>  
>  GH_ACCOUNT = kpcyrd
>  GH_PROJECT = sn0int
> -GH_TAGNAME = v0.11.2
> +GH_TAGNAME = v0.18.0
>  REVISION =   0

REVISION should be dropped on update.
  
>  CATEGORIES = security
> @@ -16,7 +16,7 @@ CATEGORIES =security
>  PERMIT_PACKAGE = Yes
>  
>  # uses pledge()
> -LIB_DEPENDS =databases/sqlite3 ${MODLUA_LIB_DEPENDS}
> +LIB_DEPENDS =databases/sqlite3 security/libsodium 
> ${MODLUA_LIB_DEPENDS}
>  WANTLIB +=   c c++abi m pthread sqlite3 ${MODLUA_WANTLIB}

hum ? adding security/libsodium in LIB_DEPENDS and not in WANTLIB ? it means the
library is statically linked.

I just commited support for libsodium-sys crate in devel/cargo module. by
default, libsodium library will be dynamically linked. could you add sodium to
WANTLIB ?

Thanks.
-- 
Sebastien Marie

CVS: cvs.openbsd.org: ports

[Sebastien Marie]

CVSROOT:/cvs
Module name:ports
Changes by: sema...@cvs.openbsd.org 2020/03/16 04:55:36

Modified files:
devel/cargo: cargo.port.mk 

Log message:
devel/cargo: take care of libsodium-sys crate

- force dynamic linking
- remove embedded tarball

CVS: cvs.openbsd.org: ports

[Paco Esteban]

CVSROOT:/cvs
Module name:ports
Changes by: p...@cvs.openbsd.org2020/03/16 04:44:38

Modified files:
www/hugo   : Makefile distinfo 

Log message:
update www/hugo to latest versio 0.67.1

Changes for this release:
* metrics: Fix --templateMetricsHints [5eadc4c0]
* resources: Add data context to the key in ExecuteAsTemplate [18cb21ff]
* Improve Tailwind/PostCSS error messages [df298558]
* deps: Update Blackfriday [b1106f87]
* resources: Try to fix a Go 1.15 go vet error [c0177fe2]
* Add languageDirection to language configuration [5914f91b]

ok jca@

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2020/03/16 04:09:30

Modified files:
www/puppetboard: Makefile 
www/puppetboard/pkg: puppetboard.rc 

Log message:
fix the rcscript, gunicorn doesn't need to be prefixed with MODPY_BIN_SUFFIX
anymore

Re: [update] redis 5.0.8

[Uwe Werler]

On 16 Mar 08:20, Stuart Henderson wrote:
> Yes, please try to get a backtrace.
> 
> --
> Sent from a phone, apologies for poor formatting.
> 
> On 16 March 2020 07:00:06 Uwe Werler  wrote:
> 
> > Hi Stuart,
> > 
> > thanks for the advice!
> > 
> > The output is as follows:
> > 
> > ##
> > 
> > egdb /usr/local/sbin/redis-sentinel /tmp/redis-server.core
> > GNU gdb (GDB) 7.12.1
> > Copyright (C) 2017 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-unknown-openbsd6.6".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/local/sbin/redis-sentinel...done.
> > [New process 170084]
> > [New process 585452]
> > [New process 382927]
> > [New process 407733]
> > Core was generated by `redis-server'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x08a5b359cfe8 in sentinelRefreshInstanceInfo (ri=0x8a89bf44608,
> > info=) at sentinel.c:2161
> > 2161sentinel.c: No such file or directory.
> > [Current thread is 1 (process 170084)]
> > (gdb)
> > 
> > ##
> > 
> > Something else what I can do?
> > 
> > With kind regards
> > 
> > Uwe

egdb /usr/local/sbin/redis-sentinel /tmp/redis-server.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/redis-sentinel...done.
[New process 170084]
[New process 585452]
[New process 382927]
[New process 407733]
Core was generated by `redis-server'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x08a5b359cfe8 in sentinelRefreshInstanceInfo (ri=0x8a89bf44608, 
info=) at sentinel.c:2161
2161sentinel.c: No such file or directory.
[Current thread is 1 (process 170084)]
(gdb) backtrace full
#0  0x08a5b359cfe8 in sentinelRefreshInstanceInfo (ri=0x8a89bf44608, 
info=) at sentinel.c:2161
l = 
slave = 
role = 2
numlines = 149
j = 148
lines = 0x8a81a6c2008
#1  0x08a5b35ce843 in __redisRunCallback (ac=, cb=, reply=) at async.c:269
c = 
#2  redisProcessCallbacks (ac=0x8a87407fc00) at async.c:469
c = 0x8a87407fc00
reply = 0x8a7bb7cba00
status = 
#3  0x08a5b351b6c7 in aeProcessEvents (eventLoop=, flags=11) 
at ae.c:443
mask = 
fired = 
shortest = 
j = 0
processed = 
numevents = 1
#4  0x08a5b351ba3e in aeMain (eventLoop=0x8a7e628ee08) at ae.c:501
No locals.
#5  0x08a5b3528497 in main (argc=, argv=0x7f7de5b8) at 
server.c:4234
hashseed = "05b63ac8a3bb4659"
tv = {tv_sec = 1584341494, tv_usec = 882702}
j = 
(gdb) 


-- 

Need help for libtsk/sleuthkit

[Remi Pointel]

Hi,

I need to update sleuthkit for the new version of plaso.

Attached is the updated version of sleuthkit. It builds fine, but if I 
run the regress tests of the py-tsk port it segfaults on the libtsk.


If I add LDFLAGS="-lstdc++", it works fine but it's not the good way to 
fix it.


Any idea?

To test: build & install the sleuthkit port attached, and make test in 
the py-tsk port attached.


Thanks for helping,

Remi.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/sleuthkit/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile	14 Jul 2019 00:39:40 -	1.27
+++ Makefile	11 Mar 2020 06:36:22 -
@@ -2,11 +2,10 @@
 
 COMMENT=		forensic toolkit based on TCT
 
-DISTNAME=		sleuthkit-4.6.0
+DISTNAME=		sleuthkit-4.8.0
 CATEGORIES=		sysutils security
-REVISION=		2
 
-SHARED_LIBS +=		tsk	1.0 # 17.0
+SHARED_LIBS +=		tsk	2.0 # 17.0
 
 HOMEPAGE=		http://www.sleuthkit.org/
 
@@ -17,7 +16,7 @@ PERMIT_PACKAGE=	Yes
 
 MASTER_SITES =		https://github.com/sleuthkit/sleuthkit/releases/download/${DISTNAME}/
 
-WANTLIB += 		c m pthread ${COMPILER_LIBCXX} sqlite3 z
+WANTLIB += 		bfio c m pthread ${COMPILER_LIBCXX} sqlite3 vhdi vmdk z
 
 COMPILER =		base-clang ports-gcc
 
@@ -29,13 +28,21 @@ CONFIGURE_ARGS += 	--mandir='${PREFIX}/m
 			--without-afflib \
 			--without-libewf
 
-CONFIGURE_ENV =		ac_cv_path_CPPUNIT_CONFIG=no
+CONFIGURE_ENV =		ac_cv_path_CPPUNIT_CONFIG=no \
+			ac_cv_header_postgresql_libpq_fe_h=no
+#			LDFLAGS="-lstdc++"
 RUN_DEPENDS =		converters/p5-DateManip
-LIB_DEPENDS =		databases/sqlite3
+LIB_DEPENDS =		databases/sqlite3 \
+			devel/libbfio \
+			sysutils/libvhdi \
+			sysutils/libvmdk
 
 NO_TEST =		Yes
 
 pre-configure:
 	@sed -i 's:%%PREFIX%%:${PREFIX}:' ${WRKSRC}/man/sorter.1
+
+post-install:
+	mv ${PREFIX}/bin/pstat ${PREFIX}/bin/pstat.sleuthkit
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/sleuthkit/distinfo,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 distinfo
--- distinfo	14 Mar 2018 12:39:17 -	1.13
+++ distinfo	11 Mar 2020 06:36:22 -
@@ -1,2 +1,2 @@
-SHA256 (sleuthkit-4.6.0.tar.gz) = 9SoIqw3geBgsDy0Z0+GzQUJKngwWM6YcO4kvs4+ay5c=
-SIZE (sleuthkit-4.6.0.tar.gz) = 8634432
+SHA256 (sleuthkit-4.8.0.tar.gz) = 9YS0bIgmk7y9gZ+1j3XpvkWsir2/YFwZD4fvESLyj2w=
+SIZE (sleuthkit-4.8.0.tar.gz) = 8784392
Index: patches/patch-tools_srchtools_sigfind_cpp
===
RCS file: patches/patch-tools_srchtools_sigfind_cpp
diff -N patches/patch-tools_srchtools_sigfind_cpp
--- patches/patch-tools_srchtools_sigfind_cpp	7 Apr 2018 23:15:28 -	1.4
+++ /dev/null	1 Jan 1970 00:00:00 -
@@ -1,26 +0,0 @@
-$OpenBSD: patch-tools_srchtools_sigfind_cpp,v 1.4 2018/04/07 23:15:28 nigel Exp $
-
-Index: tools/srchtools/sigfind.cpp
 tools/srchtools/sigfind.cpp.orig
-+++ tools/srchtools/sigfind.cpp
-@@ -302,7 +302,7 @@ main(int argc, char **argv)
- break;
- }
- else if (retval == -1) {
--fprintf(stderr, "error reading bytes %"PRIuOFF"\n", i);
-+fprintf(stderr, "error reading bytes %" PRIuOFF "\n", i);
- exit(1);
- }
- 
-@@ -312,9 +312,9 @@ main(int argc, char **argv)
- ((sig_size < 3) || (block[rel_offset + 2] == sig[2])) &&
- ((sig_size < 4) || (block[rel_offset + 3] == sig[3]))) {
- if (prev_hit == -1)
--printf("Block: %"PRIuOFF" (-)\n",  i);
-+printf("Block: %" PRIuOFF " (-)\n",  i);
- else
--printf("Block: %"PRIuOFF" (+%"PRIuOFF")\n", i,
-+printf("Block: %" PRIuOFF " (+%" PRIuOFF ")\n", i,
-(i - prev_hit));
- 
- prev_hit = i;
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/sleuthkit/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 PLIST
--- pkg/PLIST	31 Oct 2017 21:38:28 -	1.9
+++ pkg/PLIST	11 Mar 2020 06:36:22 -
@@ -26,6 +26,7 @@ bin/mactime
 @bin bin/mmcat
 @bin bin/mmls
 @bin bin/mmstat
+@bin bin/pstat.sleuthkit
 @bin bin/sigfind
 bin/sorter
 @bin bin/srch_strings
@@ -36,12 +37,19 @@ bin/sorter
 @bin bin/usnjls
 include/tsk/
 include/tsk/auto/
+include/tsk/auto/guid.h
 include/tsk/auto/tsk_auto.h
 include/tsk/auto/tsk_is_image_supported.h
 include/tsk/base/
 include/tsk/base/tsk_base.h
 include/tsk/base/tsk_os.h
 include/tsk/fs/
+include/tsk/fs/apfs_compat.hpp
+include/tsk/fs/apfs_fs.h
+include/tsk/fs/apfs_fs.hpp
+include/tsk/fs/decmpfs.h
+include/tsk/fs/tsk_apfs.h
+include/tsk/fs/tsk_apfs.hpp
 include/tsk/fs/tsk_exfatfs.h
 include/tsk/fs/tsk_ext2fs.h
 include/tsk/fs/tsk_fatfs.h
@@ -55,9 +63,21 @@ include/tsk/fs/tsk_yaffs.h
 include/tsk/hashdb/
 include/tsk/hashdb/tsk_hashdb.h
 include/tsk/img/
+include/tsk/img/pool.hpp
 include/tsk/img/tsk_img.h
 include/tsk/libtsk.h

Re: [PATCH] Add /dev/fido unveil to enable FIDO support in firefox

[Landry Breuil]

On Mon, Mar 16, 2020 at 07:50:14AM +0100, Theo Buehler wrote:
> On Sat, Mar 14, 2020 at 11:04:21AM -0700, Greg Steuck wrote:
> > All reyk@'s changes are now merged upstream so this is the only patch
> > that remains.
> 
> Appears to work flawlessly for me.
> 
> ok tb

if it works for you i've fine with it, i have no way to test it.

Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2

[Stuart Henderson]

On 2020/03/16 00:45, Marc Espie wrote:
> On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> > Sure.
> > + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
> > MASTER_SITES. (I guess that we want HTTPS first?).
> 
> We don't really care about https, but the lip6 server is fairly reliable.

I do - it doesn't matter for fetching an existing version where we
already have hashes, but guards against some problems for updates.
(obviously not all, but enough to be worthwhile)

Re: [update] redis 5.0.8

[Stuart Henderson]

Yes, please try to get a backtrace.

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

On 16 March 2020 07:00:06 Uwe Werler  wrote:


On 15 Mar 17:34, Stuart Henderson wrote:

On 2020/03/15 17:27, Uwe Werler wrote:
>
> ###
>
>
> gdb /usr/local/sbin/redis-server /tmp/redis-server.core
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-unknown-openbsd6.6"...(no debugging 
symbols found)

>
> Core was generated by `redis-server'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.26.1...done.
> Loaded symbols for /usr/lib/libpthread.so.26.1
> Loaded symbols for /usr/local/sbin/redis-server
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Symbols already loaded for /usr/lib/libpthread.so.26.1
> Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
> Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
> Reading symbols from /usr/lib/libc.so.95.1...done.
> Loaded symbols for /usr/lib/libc.so.95.1
> Reading symbols from /usr/libexec/ld.so...Error while reading shared 
library symbols:
> Dwarf Error: wrong version in compilation unit header (is 4, should be 2) 
[in module /usr/libexec/ld.so]

> #0  0x127e6e9c4ff8 in SHA1Final () from /usr/local/sbin/redis-server

gdb in base is useless for many things on clang arches - pkg_add gdb and
use "egdb" not "gdb". also pkg_add debug-redis for debug symbols, then try
again and see if you can get a backtrace.



Hi Stuart,

thanks for the advice!

The output is as follows:

##

egdb /usr/local/sbin/redis-sentinel /tmp/redis-server.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/redis-sentinel...done.
[New process 170084]
[New process 585452]
[New process 382927]
[New process 407733]
Core was generated by `redis-server'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x08a5b359cfe8 in sentinelRefreshInstanceInfo (ri=0x8a89bf44608, 
info=) at sentinel.c:2161

2161sentinel.c: No such file or directory.
[Current thread is 1 (process 170084)]
(gdb)

##

Something else what I can do?

With kind regards

Uwe

--

[Update] security/p5-CryptX : UPdate to 0.068

[wen heping]

Hi, ports@:

  Here is a patch to update security/p5-CryptX to 0.068.
  It build well and passed all tests on amd64-head system.

  Two port depends on it: net/p5-Net-SSH-Perl and security/p5-Crypt-PKCS10.
  net/p5-Net-SSH-Perl build well and one tests failed in regression tests,
but it is not caused by this patch.
  security/p5-Crypt-PKCS10 build well and pass all tests.

Cheers !
wen

Index: Makefile
===
RCS file: /cvs/ports/security/p5-CryptX/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile30 Oct 2019 17:57:41 -  1.3
+++ Makefile16 Mar 2020 07:23:57 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.3 2019/10/30 17:57:41 sthen Exp $
 
 COMMENT =  cryptographic toolkit for Perl
-DISTNAME = CryptX-0.066
+DISTNAME = CryptX-0.068
 CATEGORIES =   security
 
 CPAN_AUTHOR =  MIK
Index: distinfo
===
RCS file: /cvs/ports/security/p5-CryptX/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo30 Oct 2019 17:57:41 -  1.2
+++ distinfo16 Mar 2020 07:23:57 -
@@ -1,2 +1,2 @@
-SHA256 (CryptX-0.066.tar.gz) = 5+gjrE2wtFLohbDg1a38ipxfaIk48a3z8dkUMrMjgzU=
-SIZE (CryptX-0.066.tar.gz) = 1633866
+SHA256 (CryptX-0.068.tar.gz) = sYBqH6TUuMkmX0SscG6wsFEH1kTtsk/+obUHFo6I/Vk=
+SIZE (CryptX-0.068.tar.gz) = 1646229
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/p5-CryptX/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST   9 Sep 2018 15:03:58 -   1.1.1.1
+++ pkg/PLIST   16 Mar 2020 07:23:57 -
@@ -100,7 +100,9 @@ ${P5ARCH}/Crypt/PK.pm
 ${P5ARCH}/Crypt/PK/DH.pm
 ${P5ARCH}/Crypt/PK/DSA.pm
 ${P5ARCH}/Crypt/PK/ECC.pm
+${P5ARCH}/Crypt/PK/Ed25519.pm
 ${P5ARCH}/Crypt/PK/RSA.pm
+${P5ARCH}/Crypt/PK/X25519.pm
 ${P5ARCH}/Crypt/PRNG/
 ${P5ARCH}/Crypt/PRNG.pm
 ${P5ARCH}/Crypt/PRNG/ChaCha20.pm
@@ -121,7 +123,7 @@ ${P5ARCH}/Math/BigInt/
 ${P5ARCH}/Math/BigInt/LTM.pm
 ${P5ARCH}/auto/
 ${P5ARCH}/auto/CryptX/
-${P5ARCH}/auto/CryptX/CryptX.so
+@so ${P5ARCH}/auto/CryptX/CryptX.so
 @man man/man3p/Crypt::AuthEnc.3p
 @man man/man3p/Crypt::AuthEnc::CCM.3p
 @man man/man3p/Crypt::AuthEnc::ChaCha20Poly1305.3p
@@ -214,7 +216,9 @@ ${P5ARCH}/auto/CryptX/CryptX.so
 @man man/man3p/Crypt::PK::DH.3p
 @man man/man3p/Crypt::PK::DSA.3p
 @man man/man3p/Crypt::PK::ECC.3p
+@man man/man3p/Crypt::PK::Ed25519.3p
 @man man/man3p/Crypt::PK::RSA.3p
+@man man/man3p/Crypt::PK::X25519.3p
 @man man/man3p/Crypt::PRNG.3p
 @man man/man3p/Crypt::PRNG::ChaCha20.3p
 @man man/man3p/Crypt::PRNG::Fortuna.3p

CVS: cvs.openbsd.org: ports

[Benoit Lecocq]

CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/03/16 01:09:55

Modified files:
devel/p5-Specio: Makefile distinfo 

Log message:
Update to p5-Specio-0.46 from wen heping (Maintainer).

Re: net/ejabberd remove or update?

[Jasper Lievisse Adriaanse]

> On 15 Mar 2020, at 22:03, Solene Rapenne  wrote:
> 
> On Fri, Feb 14, 2020 at 01:45:53PM +0100, Jasper Lievisse Adriaanse wrote:
>> 
>> 
>>> On 16 Oct 2019, at 16:58, Stuart Henderson  wrote:
>>> 
>>> On 2019/10/16 13:53, Solene Rapenne wrote:
 anyone willing to work on it?
 I see no reason to keep it otherwise.
 
>>> 
>>> When you asked, there were some people using it, so maybe?
>> 
>> How about now? I think we’d be doing people a favour by preventing them from 
>> using an xmpp server that’s almost 7 years old.
>> If someone really wants to keep using it, it can be revived from the attic 
>> and updated to the latest version.
>> 
>> Also, currently it’s the last port still using Erlang 16 — I’d like to 
>> remove both.
> 
> time to remove it before 6.7
> 
> ok someone?

Ok with me.

Re: [update] redis 5.0.8

[Uwe Werler]

On 15 Mar 17:34, Stuart Henderson wrote:
> On 2020/03/15 17:27, Uwe Werler wrote:
> > 
> > ###
> > 
> > 
> > gdb /usr/local/sbin/redis-server /tmp/redis-server.core
> > GNU gdb 6.3
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-unknown-openbsd6.6"...(no debugging 
> > symbols found)
> > 
> > Core was generated by `redis-server'.
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /usr/lib/libpthread.so.26.1...done.
> > Loaded symbols for /usr/lib/libpthread.so.26.1
> > Loaded symbols for /usr/local/sbin/redis-server
> > Reading symbols from /usr/lib/libm.so.10.1...done.
> > Loaded symbols for /usr/lib/libm.so.10.1
> > Symbols already loaded for /usr/lib/libpthread.so.26.1
> > Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
> > Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
> > Reading symbols from /usr/lib/libc.so.95.1...done.
> > Loaded symbols for /usr/lib/libc.so.95.1
> > Reading symbols from /usr/libexec/ld.so...Error while reading shared 
> > library symbols:
> > Dwarf Error: wrong version in compilation unit header (is 4, should be 2) 
> > [in module /usr/libexec/ld.so]
> > #0  0x127e6e9c4ff8 in SHA1Final () from /usr/local/sbin/redis-server
> 
> gdb in base is useless for many things on clang arches - pkg_add gdb and
> use "egdb" not "gdb". also pkg_add debug-redis for debug symbols, then try
> again and see if you can get a backtrace.
> 

Hi Stuart,

thanks for the advice!

The output is as follows:

##

egdb /usr/local/sbin/redis-sentinel /tmp/redis-server.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/redis-sentinel...done.
[New process 170084]
[New process 585452]
[New process 382927]
[New process 407733]
Core was generated by `redis-server'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x08a5b359cfe8 in sentinelRefreshInstanceInfo (ri=0x8a89bf44608, 
info=) at sentinel.c:2161
2161sentinel.c: No such file or directory.
[Current thread is 1 (process 170084)]
(gdb) 

##

Something else what I can do?

With kind regards

Uwe

-- 

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2020/03/16 00:59:37

Modified files:
www/sogo   : Makefile distinfo 
www/sogo/pkg   : PLIST 

Log message:
Update 4.1.1 -> 4.3.0
works for me since quite some time

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2020/03/16 00:59:00

Modified files:
www/sope   : Makefile distinfo 

Log message:
Update 4.1.1 -> 4.3.0
works for me since quite some time

Re: [PATCH] Add /dev/fido unveil to enable FIDO support in firefox

[Theo Buehler]

On Sat, Mar 14, 2020 at 11:04:21AM -0700, Greg Steuck wrote:
> All reyk@'s changes are now merged upstream so this is the only patch
> that remains.

Appears to work flawlessly for me.

ok tb

> 
> Tested post-install by adding the same line to
> /usr/local/lib/firefox/browser/defaults/preferences/unveil.main
> ---
>  www/mozilla-firefox/Makefile  | 1 +
>  www/mozilla-firefox/files/unveil.main | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git www/mozilla-firefox/Makefile www/mozilla-firefox/Makefile
> index 7dd69366e81..a1ed2693209 100644
> --- www/mozilla-firefox/Makefile
> +++ www/mozilla-firefox/Makefile
> @@ -9,6 +9,7 @@ MOZILLA_VERSION = 74.0
>  MOZILLA_BRANCH = release
>  MOZILLA_PROJECT = firefox
>  MOZILLA_CODENAME = browser
> +REVISION = 0
> 
>  WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
>  HOMEPAGE = https://www.mozilla.org/firefox/
> diff --git www/mozilla-firefox/files/unveil.main
> www/mozilla-firefox/files/unveil.main
> index 00e78a6d2ea..30dacd79996 100644
> --- www/mozilla-firefox/files/unveil.main
> +++ www/mozilla-firefox/files/unveil.main
> @@ -2,6 +2,7 @@
>  /dev/urandom r
>  /dev/video rw
>  /dev/video0 rw
> +/dev/fido rw
> 
>  /etc/fonts r
>  /etc/machine-id r
> -- 
> 2.25.1