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

2020-03-16 Thread 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).

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

2020-03-16 Thread 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

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

2020-03-16 Thread 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

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

2020-03-16 Thread 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

2020-03-16 Thread 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&view=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

2020-03-16 Thread 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?.

2020-03-16 Thread 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

2020-03-16 Thread 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

Re: llvm: -python: adjust RDEP

2020-03-16 Thread 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

2020-03-16 Thread 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

2020-03-16 Thread Klemens Nanni 
OK kn

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

2020-03-16 Thread 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`" \

Re: update security/sn0int

2020-03-16 Thread 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
+MODCARGO

Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2

2020-03-16 Thread 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

2020-03-16 Thread 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: llvm: -python: adjust RDEP

2020-03-16 Thread 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

Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2

2020-03-16 Thread 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 ?

Re: update security/sn0int

2020-03-16 Thread 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

Re: [update] redis 5.0.8

2020-03-16 Thread 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

2020-03-16 Thread 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
+include/t

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

2020-03-16 Thread 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

2020-03-16 Thread 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

2020-03-16 Thread 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

2020-03-16 Thread 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

Re: net/ejabberd remove or update?

2020-03-16 Thread 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

2020-03-16 Thread 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

--