Re: New: games/warsow
On Mon, Jun 03, 2019 at 08:38:02AM +0200, alf wrote: > Hello, > On Sun, Jun 02, 2019 at 10:58:39AM +0300, Leonid Bobrov wrote: > > So, I've made some progress in my fork. snd_openal module is removed, > > snd_qf should do a great job. I've also got rid of all GNU extentions > > and deprecated registers in C++17. So far this game compiles with one > > warning, but compiler prints a mess, so I've silenced it with > > -Wno-user-defined-warnings flag, now it can be built with -Werror flag. > > The install target is added to CMakeLists.txt, also warsow_2.1 branch > > from https://github.com/Qfusion/qfusion/ is merged (note: I didn't > > bother applying patches from that branch to Android because Android > > support was not ready in this game anyway). > > > > All relevant patches are sent to https://github.com/Qfusion/qfusion/ > > and this game was tested at OpenBSD, DragonFly BSD and NetBSD (couldn't > > test at FreeBSD due to kernel panic coming from radeonkms module). > > > > Note that FPS limiter is buggy: if you set limit to 60 you'll get 33 FPS > > and if you set limit to 500 you'll get 100 FPS, so far it happened only > > at OpenBSD, so I have no idea is that a problem in game or in OpenBSD. > > > Most likely there's some usleep somewhere with very small sleep intervals. > Since OpenBSD's default tic-rate is 100 on most machines, it can not > sleep for shorter periods then 1/100 sec. > I ran into this in fodquake (QW client), try to use a custom kernel with > a ticrate > 1000 (I used 5000 to 1 without any problems). > IIRC its > HZ 1 > in the kernel config. > > Good luck, > > Alf > Hi! I don't understand why OpenBSD has such a default, but how do other games implement FPS limiters to avoid such problem?
Re: [maintainer update] gzdoom-4.1.2
On Sun, Jun 02, 2019 at 12:29:36PM -0700, Ryan Freeman wrote: > On Sun, Jun 02, 2019 at 08:06:17AM +0300, Timo Myyrä wrote: > > ping, anyone had time to test this? > > Hey, > > Just built and tested this on a current snapshot (Jun 1), played for an > hour or so. IIRC Knee Deep in ZDoom was crashing with previous release, > whereas I played most of the way through the first map without issue > now. Also played some vanilla Doom2, HTH2 mod, and some other level > set, simplicity. > > Seems to run real good, thanks! > -Ryan > hi you dropped the patch on src/textures/animations.cpp and brutal doom is not playable anymore. The file is now in src/gamedata/textures/animations.cpp and still applies fine. ok solene@ but the animations.cpp patch must stay.
Re: New: games/warsow
On Mon, Jun 03, 2019 at 10:25:06AM +0300, Leonid Bobrov wrote: > On Mon, Jun 03, 2019 at 08:38:02AM +0200, alf wrote: > > Hello, > > On Sun, Jun 02, 2019 at 10:58:39AM +0300, Leonid Bobrov wrote: > > > So, I've made some progress in my fork. snd_openal module is removed, > > > snd_qf should do a great job. I've also got rid of all GNU extentions > > > and deprecated registers in C++17. So far this game compiles with one > > > warning, but compiler prints a mess, so I've silenced it with > > > -Wno-user-defined-warnings flag, now it can be built with -Werror flag. > > > The install target is added to CMakeLists.txt, also warsow_2.1 branch > > > from https://github.com/Qfusion/qfusion/ is merged (note: I didn't > > > bother applying patches from that branch to Android because Android > > > support was not ready in this game anyway). > > > > > > All relevant patches are sent to https://github.com/Qfusion/qfusion/ > > > and this game was tested at OpenBSD, DragonFly BSD and NetBSD (couldn't > > > test at FreeBSD due to kernel panic coming from radeonkms module). > > > > > > Note that FPS limiter is buggy: if you set limit to 60 you'll get 33 FPS > > > and if you set limit to 500 you'll get 100 FPS, so far it happened only > > > at OpenBSD, so I have no idea is that a problem in game or in OpenBSD. > > > > > > Most likely there's some usleep somewhere with very small sleep intervals. > > Since OpenBSD's default tic-rate is 100 on most machines, it can not > > sleep for shorter periods then 1/100 sec. > > I ran into this in fodquake (QW client), try to use a custom kernel with > > a ticrate > 1000 (I used 5000 to 1 without any problems). > > IIRC its > > HZ 1 > > in the kernel config. > > > > Good luck, > > > > Alf > > > > Hi! > > I don't understand why OpenBSD has such a default, but how do other > games implement FPS limiters to avoid such problem? > (Actually I think I encountered this in quakespasm, not fodquake, there it manifested as immense packet loss). Linux uses a ticless kernel, I guess Windows too. OpenBSD goes with conservative defaults for its ticrate since it wants to run on many platforms and machines without too much knob fiddling. It just sprang to my mind when you mentioned it as a OpenBSD only problem. Also I ran into this years ago. As what other games do, sorry, no idea:) Alf
devel/c2hs and audio/p5-CDDB_Get dangling ports
The devel/c2hs port was removed in January 2016 ("Broken and not
used by anything."), but its directory is still there when checking
out the ports repository from CVS. This is due to a patch file
("patches/patch-doc_man1_c2hs_1") which was never properly deleted.
Likewise, the audio/p5-CDDB_Get port (capital "G") is lingering due to
non-deleted files (since 2001).
Apologies if this is due to some quirk in my current checkout, but I
*believe* that what I'm seeing is real.
Cheers,
--
Kusalananda
Sweden
Re: devel/c2hs and audio/p5-CDDB_Get dangling ports
Hi,
On Mon, Jun 03, 2019 at 11:41:56AM +0200, Andreas Kusalananda Kähäri wrote:
> The devel/c2hs port was removed in January 2016 ("Broken and not
> used by anything."), but its directory is still there when checking
> out the ports repository from CVS. This is due to a patch file
> ("patches/patch-doc_man1_c2hs_1") which was never properly deleted.
Removed now. THanks for noticing.
> Likewise, the audio/p5-CDDB_Get port (capital "G") is lingering due to
> non-deleted files (since 2001).
This one is completely in the attic (i.e. all files properly cvs
rm'ed). Do you have some additional files in your tree? What doas
cvs -q up -dP
say?
Ciao,
Kili
Re: [maintainer update] gzdoom-4.1.2
Hi, Isn't the patch included on the second diff? Timo On Mon, Jun 3, 2019, at 10:50, Solene Rapenne wrote: > On Sun, Jun 02, 2019 at 12:29:36PM -0700, Ryan Freeman wrote: > > On Sun, Jun 02, 2019 at 08:06:17AM +0300, Timo Myyrä wrote: > > > ping, anyone had time to test this? > > > > Hey, > > > > Just built and tested this on a current snapshot (Jun 1), played for an > > hour or so. IIRC Knee Deep in ZDoom was crashing with previous release, > > whereas I played most of the way through the first map without issue > > now. Also played some vanilla Doom2, HTH2 mod, and some other level > > set, simplicity. > > > > Seems to run real good, thanks! > > -Ryan > > > hi > > you dropped the patch on src/textures/animations.cpp and brutal doom is > not playable anymore. > The file is now in src/gamedata/textures/animations.cpp and still > applies fine. > > ok solene@ but the animations.cpp patch must stay. > >
Re: [maintainer update] gzdoom-4.1.2
On Mon, Jun 03, 2019 at 01:47:29PM +0300, Timo Myyrä wrote: > Hi, > > Isn't the patch included on the second diff? > > Timo > indeed, I was using the diff in your first mail. ok solene@ for the diff in the second mail
[NEW] net/dnscontrol 2.9
Hello, Please find attached port for DNSControl latest stable version: "DNSControl is a system for maintaining DNS zones. It has two parts: a domain specific language (DSL) for describing DNS zones plus software that processes the DSL and pushes the resulting zones to DNS providers such as Route53, Cloudflare, and Gandi. It can talk to Microsoft Active Directory and it generates the most beautiful BIND zone files ever." Kind regards, Karlis dnscontrol.tar.gz Description: GNU Zip compressed data
Re: devel/c2hs and audio/p5-CDDB_Get dangling ports
On Mon, Jun 03, 2019 at 12:41:49PM +0200, Matthias Kilian wrote:
> Hi,
>
> On Mon, Jun 03, 2019 at 11:41:56AM +0200, Andreas Kusalananda Kähäri wrote:
> > The devel/c2hs port was removed in January 2016 ("Broken and not
> > used by anything."), but its directory is still there when checking
> > out the ports repository from CVS. This is due to a patch file
> > ("patches/patch-doc_man1_c2hs_1") which was never properly deleted.
>
> Removed now. THanks for noticing.
>
> > Likewise, the audio/p5-CDDB_Get port (capital "G") is lingering due to
> > non-deleted files (since 2001).
>
> This one is completely in the attic (i.e. all files properly cvs
> rm'ed). Do you have some additional files in your tree? What doas
>
> cvs -q up -dP
>
> say?
>
> Ciao,
> Kili
Hmm... The audio/p5-CDDB_Get port is still there even if I ask cvs to
prune empty directories while updating, but deleting its directory and
doing "cvs up -dP" in the port/audio directory does not make it come
back.
Odd. A filename case issue in cvs? There is a valid audio/p5-CDDB_get
port whose name only differs in case.
--
Kusalananda
Sweden
new wip: emulators/dosbox-x (was: Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours)
[trimming the Cc list a bit since this is a diff subject...] Haai, "Thomas Frohwein" wrote: Attached is the tarball of the most recent dosbox-x built against system SDL1 for testing and comments. Builds && runs on 6.5 on me Thinkpad R40. No further testing done yet, however... - This is built with dynamic core and USE_WXNEEDED=Yes for testing purposes. Indeed this is w/ 'USE_WXNEEDED=Yes', but needlessly so, as the dynamic core is not present in the generated executable. Is this only for amd64? (If so, you've lost me). --zeurkous. -- Friggin' Machines! dosbox-x.tgz Description: dosbox-x.tgz
FU: new wip: emulators/dosbox-x
And of course, volny *needed* to show that bug where an attachment is silently preserved in a reply... me sincere apologies. The modern Internet. Almost everything broken (try to send e-mail the normal way and see countless swervers, including OpenBSD's, reject it out of prejudice). Sigh, sigh, sigh, sigh, sigh... --zeurkous. -- Friggin' Machines!
[UPDATE] www/honk
Upgrade to v0.6.0
- add views/account.html
- cosmetics, use tab for WANTLIB
Changes: "After a few weeks with no releases, honk 0.6, Sixy Delights,
is here. It's probably time to start creating real changelogs, but not
today. In the mean time, some things got better, and some other things
got prettier, and the avatars now have better and prettier colors. And
most importantly, meme support!" --
https://humungus.tedunangst.com/r/honk/h?start=v0.5.0&end=v0.6.0
Index: Makefile
===
RCS file: /cvs/ports/www/honk/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile17 May 2019 16:50:48 - 1.5
+++ Makefile3 Jun 2019 12:15:28 -
@@ -2,8 +2,7 @@
COMMENT = federated status updater
-DISTNAME = honk-0.5.0
-REVISION = 0
+DISTNAME = honk-0.6.0
CATEGORIES = www
HOMEPAGE = https://humungus.tedunangst.com/r/honk
@@ -11,7 +10,7 @@ HOMEPAGE =https://humungus.tedunangst.
# ISC
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += c pthread sqlite3
+WANTLIB += c pthread sqlite3
MASTER_SITES = ${HOMEPAGE}/d/
EXTRACT_SUFX = .tgz
Index: distinfo
===
RCS file: /cvs/ports/www/honk/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo8 May 2019 19:08:34 - 1.3
+++ distinfo3 Jun 2019 12:15:28 -
@@ -1,2 +1,2 @@
-SHA256 (honk-0.5.0.tgz) = RnO9k4ogH7hMC/rPB5QPcuEvC1NJs56rBMOPScXMlF4=
-SIZE (honk-0.5.0.tgz) = 161585
+SHA256 (honk-0.6.0.tgz) = OjBaohbkm8Y/i1RawsOG/qF7dQluuKIGxvnApf+gwGE=
+SIZE (honk-0.6.0.tgz) = 166970
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/honk/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 2 May 2019 05:03:08 - 1.2
+++ pkg/PLIST 3 Jun 2019 12:15:28 -
@@ -23,6 +23,8 @@ share/examples/honk/
share/examples/honk/schema.sql
@sample ${VARBASE}/honk/schema.sql
share/examples/honk/views/
+share/examples/honk/views/account.html
+@sample ${VARBASE}/honk/views/account.html
share/examples/honk/views/combos.html
@sample ${VARBASE}/honk/views/combos.html
share/examples/honk/views/header.html
Re: [UPDATE] www/honk
On Mon, 03 Jun 2019 at 08:29:56 -0400, Horia Racoviceanu wrote:
> Upgrade to v0.6.0
> - add views/account.html
> - cosmetics, use tab for WANTLIB
>
> Changes: "After a few weeks with no releases, honk 0.6, Sixy Delights,
> is here. It's probably time to start creating real changelogs, but not
> today. In the mean time, some things got better, and some other things
> got prettier, and the avatars now have better and prettier colors. And
> most importantly, meme support!" --
> https://humungus.tedunangst.com/r/honk/h?start=v0.5.0&end=v0.6.0
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/honk/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- Makefile 17 May 2019 16:50:48 - 1.5
> +++ Makefile 3 Jun 2019 12:15:28 -
> @@ -2,8 +2,7 @@
>
> COMMENT =federated status updater
>
> -DISTNAME = honk-0.5.0
> -REVISION = 0
> +DISTNAME = honk-0.6.0
> CATEGORIES = www
>
> HOMEPAGE = https://humungus.tedunangst.com/r/honk
> @@ -11,7 +10,7 @@ HOMEPAGE = https://humungus.tedunangst.
> # ISC
> PERMIT_PACKAGE_CDROM = Yes
>
> -WANTLIB += c pthread sqlite3
> +WANTLIB += c pthread sqlite3
>
> MASTER_SITES = ${HOMEPAGE}/d/
> EXTRACT_SUFX = .tgz
> Index: distinfo
> ===
> RCS file: /cvs/ports/www/honk/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 8 May 2019 19:08:34 - 1.3
> +++ distinfo 3 Jun 2019 12:15:28 -
> @@ -1,2 +1,2 @@
> -SHA256 (honk-0.5.0.tgz) = RnO9k4ogH7hMC/rPB5QPcuEvC1NJs56rBMOPScXMlF4=
> -SIZE (honk-0.5.0.tgz) = 161585
> +SHA256 (honk-0.6.0.tgz) = OjBaohbkm8Y/i1RawsOG/qF7dQluuKIGxvnApf+gwGE=
> +SIZE (honk-0.6.0.tgz) = 166970
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/www/honk/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- pkg/PLIST 2 May 2019 05:03:08 - 1.2
> +++ pkg/PLIST 3 Jun 2019 12:15:28 -
> @@ -23,6 +23,8 @@ share/examples/honk/
> share/examples/honk/schema.sql
> @sample ${VARBASE}/honk/schema.sql
> share/examples/honk/views/
> +share/examples/honk/views/account.html
> +@sample ${VARBASE}/honk/views/account.html
> share/examples/honk/views/combos.html
> @sample ${VARBASE}/honk/views/combos.html
> share/examples/honk/views/header.html
Same diff here (now :P) - OK abieber@ if someone wants to commit (I will commit
later this evening if it isn't in)!
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
UPDATE: sysutils/cloud-agent
Hi, Update cloud-agent to v0.8. This release includes the following fixes: * Builds with LibreSSL on OpenBSD 6.5 and newer * Unbreaks OpenStack support It includes the following enhancements: * Support for growing the disk and the last partition of the root disk (disabled by default) * Improved OpenNebula support OK? Reyk Index: sysutils/cloud-agent/Makefile === RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v retrieving revision 1.2 diff -u -p -u -p -r1.2 Makefile --- sysutils/cloud-agent/Makefile 9 Nov 2018 10:08:20 - 1.2 +++ sysutils/cloud-agent/Makefile 3 Jun 2019 13:25:05 - @@ -1,10 +1,8 @@ # $OpenBSD: Makefile,v 1.2 2018/11/09 10:08:20 sthen Exp $ -BROKEN=needs to adapt to libressl changes - COMMENT= cloud provisioning for OpenBSD VMs -V= 0.6 +V= 0.8 DISTNAME= cloud-agent-$V CATEGORIES=sysutils HOMEPAGE= https://github.com/reyk/cloud-agent/ Index: sysutils/cloud-agent/distinfo === RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 distinfo --- sysutils/cloud-agent/distinfo 16 May 2018 11:58:32 - 1.1.1.1 +++ sysutils/cloud-agent/distinfo 3 Jun 2019 13:25:05 - @@ -1,2 +1,2 @@ -SHA256 (cloud-agent-0.6.tar.gz) = HDtRHrNAFRNqAvg9BU+qbY/jRR+IN6As3zyTD5sFX58= -SIZE (cloud-agent-0.6.tar.gz) = 127325 +SHA256 (cloud-agent-0.8.tar.gz) = cj9SOZvbaxd/OVBo1xtxF7uxI3uwIn7ftiiRc4cP94Q= +SIZE (cloud-agent-0.8.tar.gz) = 132601 Index: sysutils/cloud-agent/pkg/DESCR === RCS file: /cvs/ports/sysutils/cloud-agent/pkg/DESCR,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 DESCR --- sysutils/cloud-agent/pkg/DESCR 16 May 2018 11:58:32 - 1.1.1.1 +++ sysutils/cloud-agent/pkg/DESCR 3 Jun 2019 13:25:05 - @@ -1,3 +1,3 @@ This is a simple OpenBSD-specific agent that handles provisioning and cloud initialization on clouds such as Microsoft Azure, Amazon AWS, -Apache CloudStack, or OpenStack. +Apache CloudStack, OpenNebula, or OpenStack.
Re: UPDATE: sysutils/cloud-agent
OK kn
Re: [NEW] net/dnscontrol 2.9
On 2019/06/03 12:10, karlis.mikels...@lf.lv wrote:
> Hello,
>
> Please find attached port for DNSControl latest stable version:
> "DNSControl is a system for maintaining DNS zones. It has two parts: a
> domain specific language (DSL) for describing DNS zones plus software
> that processes the DSL and pushes the resulting zones to DNS providers
> such as Route53, Cloudflare, and Gandi. It can talk to Microsoft Active
> Directory and it generates the most beautiful BIND zone files ever."
>
>
> Kind regards,
> Karlis
Diff below tidies the Makefile a bit. Build fails though:
$ make
===> dnscontrol-2.9 depends on: go-=1.12.5 -> go-1.12.5
===> dnscontrol-2.9 depends on: ccache-* -> ccache-3.7.1
===> Verifying specs: c pthread
===> found c.95.1 pthread.26.1
===> Checking files for dnscontrol-2.9
`/y/Download/ftp/pub/OpenBSD/distfiles/dnscontrol-2.9.tar.gz' is up to date.
>> (SHA256) dnscontrol-2.9.tar.gz: OK
===> Extracting for dnscontrol-2.9
===> Patching for dnscontrol-2.9
===> Compiler link: clang -> ccache /usr/bin/clang
===> Compiler link: clang++ -> ccache /usr/bin/clang++
===> Compiler link: cc -> ccache /usr/bin/cc
===> Compiler link: c++ -> ccache /usr/bin/c++
===> Generating configure for dnscontrol-2.9
===> Configuring for dnscontrol-2.9
===> Building for dnscontrol-2.9
cd /usr/obj/ports/dnscontrol-2.9/go/src/github.com/StackExchange/dnscontrol &&
go generate -tags nosystemd
build/generate/featureMatrix.go:9:2: cannot find package
"github.com/StackExchange/dnscontrol/providers" in any of:
/usr/local/go/src/github.com/StackExchange/dnscontrol/providers (from $GOROOT)
/home/sthen/go/src/github.com/StackExchange/dnscontrol/providers (from
$GOPATH)
build/generate/featureMatrix.go:10:2: cannot find package
"github.com/StackExchange/dnscontrol/providers/_all" in any
of:
/usr/local/go/src/github.com/StackExchange/dnscontrol/providers/_all (from
$GOROOT)
/home/sthen/go/src/github.com/StackExchange/dnscontrol/providers/_all (from
$GOPATH)
build/generate/generate.go:6:2: cannot find package
"github.com/mjibson/esc/embed" in any of:
/usr/local/go/src/github.com/mjibson/esc/embed (from $GOROOT)
/home/sthen/go/src/github.com/mjibson/esc/embed (from $GOPATH)
main.go:14: running "go": exit status 1
*** Error 1 in . (Makefile:23 'do-build')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2811
'/usr/obj/ports/dnscontrol-2.9/build-amd64/.build_done
')
*** Error 1 in /usr/ports/mystuff/net/dnscontrol
(/usr/ports/infrastructure/mk/bsd.port.mk:2481 'all')
diff --git a/Makefile b/Makefile
index 7843c5b..2845ffb 100644
--- a/Makefile
+++ b/Makefile
@@ -2,22 +2,20 @@
COMMENT = manage DNS configuration across any number of DNS hosts
-VERSION = 2.9
-DISTNAME = dnscontrol-${VERSION}
GH_ACCOUNT = StackExchange
GH_PROJECT = dnscontrol
-GH_TAGNAME = v${VERSION}
+GH_TAGNAME = v2.9
CATEGORIES = net
HOMEPAGE = https://github.com/StackExchange/dnscontrol
-# The MIT License
+# MIT
PERMIT_PACKAGE_CDROM = Yes
WANTLIB = c pthread
-MODULES= lang/go
+MODULES = lang/go
do-build:
cd ${WRKSRC} && ${MODGO_ENV} go generate -tags nosystemd
@@ -25,10 +23,11 @@ do-build:
cd ${WRKSRC}/cmd/convertzone && ${MODGO_ENV} go build -tags nosystemd
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/${GH_PROJECT} ${PREFIX}/bin
+ ${INSTALL_PROGRAM} ${WRKSRC}/dnscontrol ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKSRC}/cmd/convertzone/convertzone ${PREFIX}/bin
do-test:
- cd ${WRKSRC}/integrationTest && GOPATH=${MODGO_WORKSPACE} go test -v
-verbose -provider BIND
+ cd ${WRKSRC}/integrationTest && \
+ GOPATH=${MODGO_WORKSPACE} go test -v -verbose -provider BIND
.include
Re: security/burpsuite MODJAVA_VER
On 6/2/19 10:42 PM, Lawrence Teo wrote: Thanks. I tried what you suggested: /usr/local/jdk-11/bin/java -Xms1G -Xmx4G -XX:MaxPermSize=1024M -jar \ /usr/local/share/java/classes/burpsuite.jar I got the same result where Firefox showed the Secure Connection Failed page with error code SSL_ERROR_RX_RECORD_TOO_LONG. I noticed that the person who posted those -X options in that thread was using Burp Suite Professional Edition instead of the Community Edition. According to an Apr 9, 2019 post by Paul Johnston (a Support Center agent) in that thread: "The latest versions of Burp Professional have fixes so that Burp correctly works with the latest Java versions. At the moment there isn't a Community Edition release with these features." So it seems like that error is unfortunately related to the Java version itself. Do you have other ideas or suggestions on how to overcome this instead of reverting to jdk 1.8? No, given that it's a known problem between Burp CE and Java 11, I'd set it to 1.8 for the time being. Thx Ian
Re: [NEW] net/dnscontrol 2.9
Thank you, Stuart, for the prompt reply.
Diff below tidies the Makefile a bit. Build fails though:
Can you please try with attached Makefile? I've added GOCACHE and GOPATH
environment variables to the Makefile.
Kind regards,
Karlis
# $OpenBSD$
COMMENT = manage DNS configuration across any number of DNS hosts
GH_ACCOUNT =StackExchange
GH_PROJECT =dnscontrol
GH_TAGNAME =v2.9
CATEGORIES =net
HOMEPAGE = https://github.com/StackExchange/dnscontrol
# MIT
PERMIT_PACKAGE_CDROM = Yes
WANTLIB = c pthread
MODULES = lang/go
do-build:
cd ${WRKSRC} && GOMAXPROCS=${MAKE_JOBS} GOCACHE=${MODGO_GOCACHE} \
GOPATH=${MODGO_WORKSPACE} \
go generate -tags nosystemd
cd ${WRKSRC} && GOMAXPROCS=${MAKE_JOBS} GOCACHE=${MODGO_GOCACHE} \
GOPATH=${MODGO_WORKSPACE} \
go build -tags nosystemd
cd ${WRKSRC}/cmd/convertzone && GOMAXPROCS=${MAKE_JOBS}
GOCACHE=${MODGO_GOCACHE} \
GOPATH=${MODGO_WORKSPACE} \
go build -tags nosystemd
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/dnscontrol ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKSRC}/cmd/convertzone/convertzone ${PREFIX}/bin
do-test:
cd ${WRKSRC}/integrationTest && GOCACHE=${MODGO_GOCACHE} \
GOPATH=${MODGO_WORKSPACE} \
go test -v -verbose -provider BIND
.include
Re: enable Theora in ffmpeg (again)
On Sun, Jun 02, 2019 at 04:58:41PM -0700, Thomas Frohwein wrote: > On Sat, Jun 01, 2019 at 11:00:46PM +0200, Juan Francisco Cantero Hurtado > wrote: > [...] > > > > Can you remove the flavor and just enable the codec? Sorry for missing to actually enable it. > That would be this (built it again without issues): Looks good; I agree with the others on not using flavors for this. Using a WebM container with VP9 video and Opus audio, without this diff `ffmpeg -i foo.webm foo.ogv' would use VP8 and Vorbis respectively. With your diff, it successfully produces Theora video: Stream mapping: Stream #0:0 -> #0:0 (vp9 (native) -> theora (libtheora)) Stream #0:1 -> #0:1 (opus (native) -> vorbis (libvorbis)) Tested on amd64. OK kn
Re: [UPDATE] devel/openmpi 4.0.1
On Sat, Jun 01, 2019 at 08:03:17PM +0100, Stuart Henderson wrote:
> That needs fixing then..
> --
> Sent from a phone, apologies for poor formatting.
Looks like a candidate for USE_LIBTOOL=gnu, I'll come up with a new diff once
I've done some more testing.
-m
>
> On 1 June 2019 17:15:19 Jeremie Courreges-Anglas wrote:
>
> > On Sat, Jun 01 2019, Stuart Henderson wrote:
> > > Please don't do the huge bump for SHARED_LIBS, just a standard major
> > > bump for the existing libraries and start the new ones at 0.0
> >
> > IIRC the problem is that SHARED_LIBS isn't respected.
> >
> > > --
> > > Sent from a phone, apologies for poor formatting.
> > >
> > > On 31 May 2019 18:55:23 Martin Reindl wrote:
> > >
> > > > Hello ports@,
> > > >
> > > >
> > > > here is an update for another port that probably get's not much
> > > > widespread
> > > > usage. Nevertheless, this is worthwhile for people running in an MPI-3.1
> > > > environment. Tested on macppc, arm64 and amd64. I only needed this
> > > > once, so
> > > > I am not too keen on taking MAINTAINER. Note all fortran bits pass make
> > > > test
> > > > with the new egfortran from ports-gcc on the aforementioned archs.
> > > >
> > > >
> > > > -m
> > > >
> > > >
> > > >
> > > >
> > > > Index: Makefile
> > > > ===
> > > > RCS file: /cvs/ports/devel/openmpi/Makefile,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 Makefile
> > > > --- Makefile 21 Jan 2019 14:24:30 - 1.26
> > > > +++ Makefile 30 May 2019 17:19:34 -
> > > > @@ -1,52 +1,46 @@
> > > > # $OpenBSD: Makefile,v 1.26 2019/01/21 14:24:30 jca Exp $
> > > >
> > > > -BROKEN-hppa = error: Could not determine global symbol label prefix
> > > > -BROKEN-powerpc = checking if Fortran 77 compiler works... no
> > > > +COMMENT = open source MPI-3.1 implementation
> > > >
> > > > -COMMENT = open source MPI-2 implementation
> > > > -
> > > > -V= 1.4.1
> > > > +V= 4.0.1
> > > > DISTNAME = openmpi-$V
> > > > -REVISION = 8
> > > > -
> > > > -SHARED_LIBS = mca_common_sm 1.0 \
> > > > - mpi 0.1 \
> > > > - mpi_cxx 0.0 \
> > > > - mpi_f77 0.0 \
> > > > - open-pal 0.0 \
> > > > - open-rte 0.0
> > > >
> > > > CATEGORIES = devel
> > > >
> > > > +MASTER_SITES =
> > > > ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
> > > > +
> > > > HOMEPAGE = http://www.open-mpi.org/
> > > >
> > > > +# BSD
> > > > +PERMIT_PACKAGE_CDROM = Yes
> > > > +
> > > > +SHARED_LIBS += mca_common_dstore 1.0 \
> > > > + mca_common_monitoring 60.0 \
> > > > + mca_common_ompio 60.1 \
> > > > + mca_common_sm 60.0 \
> > > > + mpi 60.1 \
> > > > + mpi_cxx 60.0 \
> > > > + mpi_mpifh 60.1 \
> > > > + mpi_usempi_ignore_tkr 60.0 \
> > > > + mpi_usempif08 60.0 \
> > > > + ompitrace 60.0 \
> > > > + open-pal 60.1 \
> > > > + open-rte 60.1
> > > > +
> > > > MODULES = fortran
> > > > -MODFORTRAN_COMPILER = g77
> > > > +MODFORTRAN_COMPILER = gfortran
> > > > BUILD_DEPENDS += ${MODFORTRAN_BUILD_DEPENDS}
> > > >
> > > > -# BSD
> > > > -PERMIT_PACKAGE_CDROM = Yes
> > > > +LIB_DEPENDS += devel/libexecinfo
> > > >
> > > > WANTLIB += c m pthread ${COMPILER_LIBCXX} util z
> > > > +WANTLIB += pciaccess execinfo
> > > >
> > > > COMPILER = base-clang ports-gcc base-gcc
> > > >
> > > > -MASTER_SITES =
> > > > ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
> > > > -
> > > > -# XXX: uses a locally modified libtool.
> > > > -USE_LIBTOOL = No
> > > > -
> > > > -FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
> > > > CONFIGURE_STYLE = gnu
> > > > -CONFIGURE_ENV = F77=${MODFORTRAN_COMPILER}
> > > > +CONFIGURE_ARGS += --enable-mpi-cxx
> > > >
> > > > -.include
> > > > -.if ${PROPERTIES:Mclang}
> > > > -CONFIGURE_ARGS = --disable-visibility
> > > > -.endif
> > > > -
> > > > -# openmpi's otfinfo conflicts with the one from texlive
> > > > -post-install:
> > > > - mv ${PREFIX}/bin/otfinfo ${PREFIX}/bin/otfinfompi
> > > > +FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
> > > >
> > > > .include
> > > > Index: distinfo
> > > > ===
> > > > RCS file: /cvs/ports/devel/openmpi/distinfo,v
> > > > retrieving revision 1.3
> > > > diff -u -p -u -p -r1.3 distinfo
> > > > --- distinfo 18 Jan 2015 03:13:19 - 1.3
> > > > +++ distinfo 30 May 2019 17:19:34 -
> > > > @@ -1,2 +1,2 @@
> > > > -SHA256 (openmpi-1.4.1.tar.gz) =
> > > > quq9IhjNxPEejgPhVTkQEpzIQw6TN2xANsqW/BoVubU=
> > > > -SIZE (openmpi-1.4.1.tar.gz) = 9960381
> > > > +SHA256 (openmpi-4.0.1.tar.gz) =
> > > > 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
> > > > +SIZE (openmpi-4.0.1.tar.gz) = 17513706
> > > > Index: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
> > > > ===
> > > > RC
Re: devel/shellcheck update for ghc 8.6.4
On Sun, Jun 02, 2019 at 03:06:28PM -0700, Greg Steuck wrote: > In my quest to update the ports [tree] to ghc 8.6.4 I arrived at a fork re > ShellCheck. > > The first blocker is ANN/TemplateHaskell is [broken] enough that > patching is required to get rid of all ShellCheck testing code. Now, > the next snag is the ancient version of ShellCheck in ports. At least > a couple of places need to be patched for Semigroup and MonadFail > issues. My natural impulse would be to upgrade ShellCheck to the most > recent version 0.6.0, except it has a larger dependency > set and at least aeson is not in ports. At this point I'm not sure > which way to go. Is the new version with a larger set of deps a better > option? Or the patched-up old version? Since I personally don't use > ShellCheck, I can't make the call easily. Opinions? Patches? > > [broken]https://marc.info/?l=openbsd-ports&m=155949514223604&w=2 > [tree]https://github.com/blackgnezdo/ports/commits/ghc_864_jun1 I realize the ShellCheck port is quite out of date. Indeed, as you noticed, ShellCheck now depends on aeson, a piece of software that used to be in the ports tree but was removed. A quick look indicates that re-importing aeson would require a number of new ports to be imported as well, including contravariant, unordered-containers, uuid-types, th-abstraction, transformers. This list may not be complete. devel/hs-json could then be removed. The question is whether adding new hs ports is worth the maintenance burden. That's not a question I can answer. If ShellCheck is the only program that actually depends on aeson and it increases the maintenance burden too much, maybe the best option would be to just remove ShellCheck. Users can still install ShellCheck through cabal in this case. Thanks, Caspar Schutijser
Re: UPDATE: security/keepassxc
On Sun Jun 02, 2019 at 05:41:37PM +0200, Jeremie Courreges-Anglas wrote:
> On Sun, Jun 02 2019, Rafael Sadowski wrote:
> > Update keepassxc to 2.4.2
> >
> > CHANGELOG:
> > https://github.com/keepassxreboot/keepassxc/releases/tag/2.4.2
> >
> > I send the Alloc class patch upsteream as usual. Tests and feedback
> > welcome.
>
> I didn't check anything else, but the Alloc class patch shouldn't be
> sent upstream as-is, IMO. Please see below.
>
> > RS
> >
> > ===
> > RCS file: patches/patch-src_core_Alloc_cpp
> > diff -N patches/patch-src_core_Alloc_cpp
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-src_core_Alloc_cpp2 Jun 2019 09:44:06 -
> > @@ -0,0 +1,23 @@
> > +$OpenBSD$
> > +
> > +Index: src/core/Alloc.cpp
> > +--- src/core/Alloc.cpp.orig
> > src/core/Alloc.cpp
> > +@@ -20,6 +20,8 @@
> > + #include
> > + #ifdef Q_OS_MACOS
> > + #include
> > ++#elif defined(Q_OS_OPENBSD)
> > ++#include
> > + #else
> > + #include
> > + #endif
> > +@@ -61,7 +63,7 @@ void operator delete(void* ptr) noexcept
> > + ::operator delete(ptr, _msize(ptr));
> > + #elif defined(Q_OS_MACOS)
> > + ::operator delete(ptr, malloc_size(ptr));
> > +-#elif defined(Q_OS_UNIX)
> > ++#elif defined(Q_OS_LINUX)
> > + ::operator delete(ptr, malloc_usable_size(ptr));
> > + #else
> > + // whatever OS this is, give up and simply free stuff
> >
>
> I think the port's cmake setup should check for malloc_usable_size and
> malloc.h, use them if available, and fall back on stdlib.h / std::free()
> if not. OpenBSD is not the only OS where malloc.h isn't available, and
> Linux (glibc really) isn't the only OS where malloc_usable_size() is
> available. This kind of #ifdef practice is actively harmful for
> portability.
>
> Also if the goal is to securely erase memory before freeing it,
> maybe freezero(3) is a possible alternative?
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
Thanks Jeremie for saving me from a mistake.
There is no way to fix this on OpenBSD so let's disable for now. New
diff which disabled the custom delete operator.
General question, what does it make sense to delete each heap allocated
(just allocated memory with "new") memory so?
In my opinion, we're not losing anything here.
Index: Makefile
===
RCS file: /cvs/ports/security/keepassxc/Makefile,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 Makefile
--- Makefile21 Apr 2019 11:29:44 - 1.20
+++ Makefile3 Jun 2019 19:17:16 -
@@ -2,7 +2,7 @@
COMMENT = management tool for password and sensitive data
-V =2.4.1
+V =2.4.2
DISTNAME = keepassxc-${V}
CATEGORIES = security
@@ -16,7 +16,7 @@ PERMIT_PACKAGE_CDROM =Yes
WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5DBus Qt5Gui
WANTLIB += Qt5Network Qt5Svg Qt5Widgets Qt5X11Extras X11 Xi Xtst
-WANTLIB += argon2 c gcrypt gpg-error m qrencode z
+WANTLIB += argon2 c gcrypt gpg-error m qrencode sodium z
MASTER_SITES =
https://github.com/keepassxreboot/keepassxc/releases/download/${V}/
EXTRACT_SUFX = -src.tar.xz
@@ -25,6 +25,7 @@ MODULES = x11/qt5 \
devel/cmake
LIB_DEPENDS = security/libgcrypt \
+ security/libsodium \
security/argon2 \
graphics/libqrencode \
x11/qt5/qtsvg \
@@ -36,8 +37,8 @@ RUN_DEPENDS = devel/desktop-file-utils \
CONFIGURE_ARGS=-DCMAKE_INSTALL_MANDIR="man" \
-DWITH_GUI_TESTS=ON \
- -DWITH_XC_SSHAGENT=ON \
- -DWITH_XC_AUTOTYPE=ON
+ -DWITH_XC_AUTOTYPE=ON \
+ -DWITH_XC_SSHAGENT=ON
TEST_IS_INTERACTIVE = X11
@@ -52,10 +53,8 @@ WANTLIB += yubikey ykpers-1
.endif
.if ${FLAVOR:Mbrowser}
-LIB_DEPENDS += security/libsodium
CONFIGURE_ARGS += -DWITH_XC_BROWSER=ON \
-DWITH_XC_NETWORKING=ON
-WANTLIB+= sodium
.endif
post-patch:
Index: distinfo
===
RCS file: /cvs/ports/security/keepassxc/distinfo,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 distinfo
--- distinfo21 Apr 2019 11:29:44 - 1.11
+++ distinfo3 Jun 2019 19:17:16 -
@@ -1,2 +1,2 @@
-SHA256 (keepassxc-2.4.1-src.tar.xz) =
Dal70SedG5sGpjufcjtDq4wHi38SA9bBNQT91HNUias=
-SIZE (keepassxc-2.4.1-src.tar.xz) = 3277856
+SHA256 (keepassxc-2.4.2-src.tar.xz) =
FfptCikgVYZLGXnGcfE+W65QVuGeKAwwzBzwuW6lYTg=
+SIZE (keepassxc-2.4.2-src.tar.xz) = 3290468
Index: patches/patch-src_CMakeLists_txt
===
RCS file: patches/patch-src_CMakeLists_txt
diff -N patches/patch-src_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_CMakeLists_txt3 Jun 2019 19:17:16 -
@@ -0,0 +
Re: UPDATE: security/keepassxc
On 2019/06/02 17:41, Jeremie Courreges-Anglas wrote:
> > Index: patches/patch-src_core_Alloc_cpp
> > ===
> > RCS file: patches/patch-src_core_Alloc_cpp
> > diff -N patches/patch-src_core_Alloc_cpp
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-src_core_Alloc_cpp2 Jun 2019 09:44:06 -
> > @@ -0,0 +1,23 @@
> > +$OpenBSD$
> > +
> > +Index: src/core/Alloc.cpp
> > +--- src/core/Alloc.cpp.orig
> > src/core/Alloc.cpp
> > +@@ -20,6 +20,8 @@
> > + #include
> > + #ifdef Q_OS_MACOS
> > + #include
> > ++#elif defined(Q_OS_OPENBSD)
> > ++#include
> > + #else
> > + #include
> > + #endif
> > +@@ -61,7 +63,7 @@ void operator delete(void* ptr) noexcept
> > + ::operator delete(ptr, _msize(ptr));
> > + #elif defined(Q_OS_MACOS)
> > + ::operator delete(ptr, malloc_size(ptr));
> > +-#elif defined(Q_OS_UNIX)
> > ++#elif defined(Q_OS_LINUX)
> > + ::operator delete(ptr, malloc_usable_size(ptr));
> > + #else
> > + // whatever OS this is, give up and simply free stuff
> >
>
> I think the port's cmake setup should check for malloc_usable_size and
> malloc.h, use them if available, and fall back on stdlib.h / std::free()
> if not. OpenBSD is not the only OS where malloc.h isn't available, and
> Linux (glibc really) isn't the only OS where malloc_usable_size() is
> available. This kind of #ifdef practice is actively harmful for
> portability.
+1
> Also if the goal is to securely erase memory before freeing it,
> maybe freezero(3) is a possible alternative?
The upstream commit does a couple of things.
One part is overriding the delete operator as a best-effort way to try to
wipe all their c++ dynamic allocations. They're using malloc_usable_size()
to identify how much memory should be zeroed. In their case they use
sodium_memzero() to do this, but freezero() would be pretty much equivalent,
and neither would work for them: for both you need to know how much
memory should be zeroed at the time you want to free it.
I'm not sure there's much that can be done about that without major changes
to track allocations which are well out of scope for doing in ports patches.
The other part is that they're using libgcrypt's alloc_secure_func for some
pieces which they know are keys ("As a further improvement, this patch
uses libgcrypt and libsodium to write long-lived master key component
hashes into a secure memory area and wipe it afterwards.") - seems like
malloc_conceal would be perfect for this, probably in gcrypt itself
rather than programs using gcrypt, though I soon got lost in the pools
stuff in gcrypt src/secmem.c when trying to figure out how to do it.
Re: UPDATE: security/keepassxc
On 2019/06/03 21:38, Rafael Sadowski wrote:
> On Sun Jun 02, 2019 at 05:41:37PM +0200, Jeremie Courreges-Anglas wrote:
> > On Sun, Jun 02 2019, Rafael Sadowski wrote:
> > > Update keepassxc to 2.4.2
> > >
> > > CHANGELOG:
> > > https://github.com/keepassxreboot/keepassxc/releases/tag/2.4.2
> > >
> > > I send the Alloc class patch upsteream as usual. Tests and feedback
> > > welcome.
> >
> > I didn't check anything else, but the Alloc class patch shouldn't be
> > sent upstream as-is, IMO. Please see below.
> >
> > > RS
> > >
> > > ===
> > > RCS file: patches/patch-src_core_Alloc_cpp
> > > diff -N patches/patch-src_core_Alloc_cpp
> > > --- /dev/null 1 Jan 1970 00:00:00 -
> > > +++ patches/patch-src_core_Alloc_cpp 2 Jun 2019 09:44:06 -
> > > @@ -0,0 +1,23 @@
> > > +$OpenBSD$
> > > +
> > > +Index: src/core/Alloc.cpp
> > > +--- src/core/Alloc.cpp.orig
> > > src/core/Alloc.cpp
> > > +@@ -20,6 +20,8 @@
> > > + #include
> > > + #ifdef Q_OS_MACOS
> > > + #include
> > > ++#elif defined(Q_OS_OPENBSD)
> > > ++#include
> > > + #else
> > > + #include
> > > + #endif
> > > +@@ -61,7 +63,7 @@ void operator delete(void* ptr) noexcept
> > > + ::operator delete(ptr, _msize(ptr));
> > > + #elif defined(Q_OS_MACOS)
> > > + ::operator delete(ptr, malloc_size(ptr));
> > > +-#elif defined(Q_OS_UNIX)
> > > ++#elif defined(Q_OS_LINUX)
> > > + ::operator delete(ptr, malloc_usable_size(ptr));
> > > + #else
> > > + // whatever OS this is, give up and simply free stuff
> > >
> >
> > I think the port's cmake setup should check for malloc_usable_size and
> > malloc.h, use them if available, and fall back on stdlib.h / std::free()
> > if not. OpenBSD is not the only OS where malloc.h isn't available, and
> > Linux (glibc really) isn't the only OS where malloc_usable_size() is
> > available. This kind of #ifdef practice is actively harmful for
> > portability.
> >
> > Also if the goal is to securely erase memory before freeing it,
> > maybe freezero(3) is a possible alternative?
> >
> > --
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> >
>
> Thanks Jeremie for saving me from a mistake.
>
> There is no way to fix this on OpenBSD so let's disable for now. New
> diff which disabled the custom delete operator.
>
> General question, what does it make sense to delete each heap allocated
> (just allocated memory with "new") memory so?
AIUI they aren't tracking every allocation which _does_ use memory to hold
some sensitive data, so are blindly zeroing everything they can when the
allocation is deleted. Might slow things down a bit but this shouldn't be
a performance critical program anyway and why not wipe the things where
they can.
> In my opinion, we're not losing anything here.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/keepassxc/Makefile,v
> retrieving revision 1.20
> diff -u -p -u -p -r1.20 Makefile
> --- Makefile 21 Apr 2019 11:29:44 - 1.20
> +++ Makefile 3 Jun 2019 19:17:16 -
> @@ -2,7 +2,7 @@
>
> COMMENT =management tool for password and sensitive data
>
> -V = 2.4.1
> +V = 2.4.2
> DISTNAME = keepassxc-${V}
>
> CATEGORIES = security
> @@ -16,7 +16,7 @@ PERMIT_PACKAGE_CDROM = Yes
>
> WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5DBus Qt5Gui
> WANTLIB += Qt5Network Qt5Svg Qt5Widgets Qt5X11Extras X11 Xi Xtst
> -WANTLIB += argon2 c gcrypt gpg-error m qrencode z
> +WANTLIB += argon2 c gcrypt gpg-error m qrencode sodium z
>
> MASTER_SITES =
> https://github.com/keepassxreboot/keepassxc/releases/download/${V}/
> EXTRACT_SUFX = -src.tar.xz
> @@ -25,6 +25,7 @@ MODULES = x11/qt5 \
> devel/cmake
>
> LIB_DEPENDS =security/libgcrypt \
> + security/libsodium \
> security/argon2 \
> graphics/libqrencode \
> x11/qt5/qtsvg \
> @@ -36,8 +37,8 @@ RUN_DEPENDS = devel/desktop-file-utils \
>
> CONFIGURE_ARGS= -DCMAKE_INSTALL_MANDIR="man" \
> -DWITH_GUI_TESTS=ON \
> - -DWITH_XC_SSHAGENT=ON \
> - -DWITH_XC_AUTOTYPE=ON
> + -DWITH_XC_AUTOTYPE=ON \
> + -DWITH_XC_SSHAGENT=ON
>
> TEST_IS_INTERACTIVE =X11
>
> @@ -52,10 +53,8 @@ WANTLIB += yubikey ykpers-1
> .endif
>
> .if ${FLAVOR:Mbrowser}
> -LIB_DEPENDS += security/libsodium
> CONFIGURE_ARGS +=-DWITH_XC_BROWSER=ON \
> -DWITH_XC_NETWORKING=ON
> -WANTLIB += sodium
> .endif
>
> post-patch:
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/keepassxc/distinfo,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 distinfo
> --- distinfo 21 Apr 2019 11:29:44 - 1.11
> +++ distinfo 3 Jun 2019 19:
Re: UPDATE: security/keepassxc
On Mon, Jun 03 2019, Stuart Henderson wrote: > On 2019/06/02 17:41, Jeremie Courreges-Anglas wrote: >> > Index: patches/patch-src_core_Alloc_cpp >> > === >> > RCS file: patches/patch-src_core_Alloc_cpp >> > diff -N patches/patch-src_core_Alloc_cpp >> > --- /dev/null 1 Jan 1970 00:00:00 - >> > +++ patches/patch-src_core_Alloc_cpp 2 Jun 2019 09:44:06 - >> > @@ -0,0 +1,23 @@ >> > +$OpenBSD$ >> > + >> > +Index: src/core/Alloc.cpp >> > +--- src/core/Alloc.cpp.orig >> > src/core/Alloc.cpp >> > +@@ -20,6 +20,8 @@ >> > + #include >> > + #ifdef Q_OS_MACOS >> > + #include >> > ++#elif defined(Q_OS_OPENBSD) >> > ++#include >> > + #else >> > + #include >> > + #endif >> > +@@ -61,7 +63,7 @@ void operator delete(void* ptr) noexcept >> > + ::operator delete(ptr, _msize(ptr)); >> > + #elif defined(Q_OS_MACOS) >> > + ::operator delete(ptr, malloc_size(ptr)); >> > +-#elif defined(Q_OS_UNIX) >> > ++#elif defined(Q_OS_LINUX) >> > + ::operator delete(ptr, malloc_usable_size(ptr)); >> > + #else >> > + // whatever OS this is, give up and simply free stuff >> > >> >> I think the port's cmake setup should check for malloc_usable_size and >> malloc.h, use them if available, and fall back on stdlib.h / std::free() >> if not. OpenBSD is not the only OS where malloc.h isn't available, and >> Linux (glibc really) isn't the only OS where malloc_usable_size() is >> available. This kind of #ifdef practice is actively harmful for >> portability. > > +1 > >> Also if the goal is to securely erase memory before freeing it, >> maybe freezero(3) is a possible alternative? > > The upstream commit does a couple of things. > > One part is overriding the delete operator as a best-effort way to try to > wipe all their c++ dynamic allocations. They're using malloc_usable_size() > to identify how much memory should be zeroed. In their case they use > sodium_memzero() to do this, but freezero() would be pretty much equivalent, > and neither would work for them: for both you need to know how much > memory should be zeroed at the time you want to free it. I was thinking of freezero(3) as an alternative to sodium_memzero(), not as a solution for the lack of malloc_usable_size(3). I should have made this clearer, or not mention freezero(3) at all, sorry about that. > I'm not sure there's much that can be done about that without major changes > to track allocations which are well out of scope for doing in ports patches. IIUC their use of -fsized-deallocation means that delete(ptr, size) will be preferred by the compiler when possible, ie when the size of the object is known. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html So while delete(ptr) can't be properly implemented as intended by upstream as long as we don't have malloc_usable_size(3), OpenBSD users can still benefit from (parts of) the improvements in https://github.com/keepassxreboot/keepassxc/pull/3020 In my opinion the code in Alloc.cpp should be kept and made portable as suggested, preferably by someone who uses keepassxc and knows his way in cmake and C++ land, ie not me. ;) Bonus: keepassxc would build without patches on OpenBSD. [...] -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[security update] www/py-django/stable: update to 2.2.2
Hi, ports@:
Here is a patch to update www/py-django/stable to 2.2.2 and
www/py-django/lts to 1.11.21. It is security release.
Both build well and run well. No other ports depends on it.
But multiprocessing test still failed as the current version.
Comments ? OK ?
Regards,
wen
Index: lts/Makefile
===
RCS file: /cvs/ports/www/py-django/lts/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- lts/Makefile28 Apr 2019 20:51:59 - 1.37
+++ lts/Makefile4 Jun 2019 02:23:00 -
@@ -4,9 +4,8 @@ PORTROACH = limit:^1\.11
COMMENT = high-level Python web framework (LTS version)
-MODPY_EGG_VERSION =1.11.20
+MODPY_EGG_VERSION =1.11.21
LNAME =django-lts
-REVISION = 0
post-install:
${INSTALL_DATA_DIR}
${PREFIX}/share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}
Index: lts/distinfo
===
RCS file: /cvs/ports/www/py-django/lts/distinfo,v
retrieving revision 1.31
diff -u -p -r1.31 distinfo
--- lts/distinfo18 Mar 2019 13:27:50 - 1.31
+++ lts/distinfo4 Jun 2019 02:23:00 -
@@ -1,2 +1,2 @@
-SHA256 (Django-1.11.20.tar.gz) = Q6mdoI/uMpSA0nhg1oJ5lFt9i/e1NziO4siTjHCbIEE=
-SIZE (Django-1.11.20.tar.gz) = 7846576
+SHA256 (Django-1.11.21.tar.gz) = unI+Uk+s/6Kp2MLpEW24ceFrkgfmSOHT5K+KrhFnsCk=
+SIZE (Django-1.11.21.tar.gz) = 7847136
Index: lts/pkg/PLIST
===
RCS file: /cvs/ports/www/py-django/lts/pkg/PLIST,v
retrieving revision 1.34
diff -u -p -r1.34 PLIST
--- lts/pkg/PLIST 18 Mar 2019 13:27:50 - 1.34
+++ lts/pkg/PLIST 4 Jun 2019 02:23:45 -
@@ -6828,6 +6828,7 @@ share/doc/${MODPY_PY_PREFIX}-${LNAME}-${
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.17.txt
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.18.txt
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.19.txt
+share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.20.txt
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.2.txt
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/${MODPY_EGG_VERSION}.txt
share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}/releases/1.11.3.txt
Index: stable/Makefile
===
RCS file: /cvs/ports/www/py-django/stable/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- stable/Makefile 28 Apr 2019 20:51:59 - 1.27
+++ stable/Makefile 4 Jun 2019 02:23:45 -
@@ -2,10 +2,12 @@
COMMENT = high-level Python web framework
-MODPY_EGG_VERSION =2.1.7
-REVISION = 0
+MODPY_EGG_VERSION =2.2.2
LNAME =django
+
+RUN_DEPENDS += devel/py-tz,python3 \
+ databases/py-sqlparse,python3
post-install:
${INSTALL_DATA_DIR}
${PREFIX}/share/doc/${MODPY_PY_PREFIX}-${LNAME}-${MODPY_EGG_VERSION}
Index: stable/distinfo
===
RCS file: /cvs/ports/www/py-django/stable/distinfo,v
retrieving revision 1.23
diff -u -p -r1.23 distinfo
--- stable/distinfo 18 Mar 2019 13:27:50 - 1.23
+++ stable/distinfo 4 Jun 2019 02:23:45 -
@@ -1,2 +1,2 @@
-SHA256 (Django-2.1.7.tar.gz) = k5ZS6dNNfVPXTV2O+CoZ5fi7LedWGPflNgaRtulmeWM=
-SIZE (Django-2.1.7.tar.gz) = 8608548
+SHA256 (Django-2.2.2.tar.gz) = dT0w0+sHgGTS3a3+plCDyYSAdKf5PXtNx/prE4DSePU=
+SIZE (Django-2.2.2.tar.gz) = 8841523
Index: stable/pkg/PLIST
===
RCS file: /cvs/ports/www/py-django/stable/pkg/PLIST,v
retrieving revision 1.24
diff -u -p -r1.24 PLIST
--- stable/pkg/PLIST18 Mar 2019 13:27:50 - 1.24
+++ stable/pkg/PLIST4 Jun 2019 02:24:49 -
@@ -383,6 +383,10 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hu/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hu/${MODPY_PYCACHE}formats.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hu/formats.py
+lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hy/
+lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hy/LC_MESSAGES/
+lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hy/LC_MESSAGES/${LNAME}.mo
+lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/hy/LC_MESSAGES/${LNAME}.po
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/ia/
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/ia/LC_MESSAGES/
lib/python${MODPY_VERSION}/site-packages/${LNAME}/conf/locale/ia/LC_MESSAGES/${LNAME}.mo
@@ -1038,6 +1042,12 @@ lib/python${MODPY_VERSION
portgen.hs
I noticed the undeadly [story] about Python joining the cool kids generating their ports with portgen(1). Superficially the language specific packages in OpenBSD::PortGen::Port appear short enough to contemplate adding support for Haskell. Should I try reviving my 15 year old Perl skillz or is the problem harder than it looks? [story] http://undeadly.org/cgi?action=article;sid=20190603185210 Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: portgen.hs
On Mon, Jun 03, 2019 at 07:47:55PM -0700, Greg Steuck wrote: > I noticed the undeadly [story] about Python joining the cool kids > generating their ports with portgen(1). Superficially the language specific > packages in OpenBSD::PortGen::Port appear short enough to contemplate > adding support for Haskell. Should I try reviving my 15 year old Perl > skillz or is the problem harder than it looks? > > [story] http://undeadly.org/cgi?action=article;sid=20190603185210 If you have some perl skills that will help. What's most important though is knowing what a Haskell port's Makefile should look like. We also need an API that we can use to query for the distfile name[1] and a way to figure out the dependencies, preferably via some sort of API, but doing it by querying the package can also work. The actual language specific bits should be relatively simple, mostly just converting from the metadata we gather to the correct variables to put into the Makefile. I'm sure there will be some special problems to solve because of version numbers or some other thing that nobody can agree on, but it looks like https://hackage.haskell.org/api should work, although I can't figure out how to get it to give my JSON, although it says it will. I'm more than happy to help with any questions you have. [1] although if there is just a central repository for all dists with a standard layout, we can probably work with that. l8rZ, -- andrew - http://afresh1.com ($do || !$do) && undef($try) ; # Master of Perl, Yoda is. H?
update dnscrypt-proxy 2.0.25
This is a diff for dnscrypt-proxy 2.0.25, released June 3, 2019.
release notes:
https://github.com/jedisct1/dnscrypt-proxy/releases/tag/2.0.25
https://github.com/jedisct1/dnscrypt-proxy/releases/tag/2.0.24
The "fastest" load-balancing strategy has been renamed to "first". I
noted this in the README and existing dnscrypt-proxy.toml files may have
to be changed.
Also, I enabled logging by specifying log_file =
'${LOCALSTATEDIR}/log/dnscrypt-proxy.log'. `log_file' and `use_syslog'
are mutually exclusive options. `log_file' allows you to specify a file
and `use_syslog' uses /var/log/messages.
Thoughts on enabling logging? If it is better to just leave logging
disabled, as it is by default, let me know and I can fix the diff as
needed.
Lightly tested on amd64.
Index: Makefile
===
RCS file: /cvs/ports/net/dnscrypt-proxy/Makefile,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 Makefile
--- Makefile4 May 2019 21:46:17 - 1.41
+++ Makefile4 Jun 2019 03:28:31 -
@@ -4,7 +4,7 @@ COMMENT = flexible DNS proxy with suppor
GH_ACCOUNT = jedisct1
GH_PROJECT = dnscrypt-proxy
-GH_TAGNAME = 2.0.23
+GH_TAGNAME = 2.0.25
CATEGORIES = net
Index: distinfo
===
RCS file: /cvs/ports/net/dnscrypt-proxy/distinfo,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 distinfo
--- distinfo30 Apr 2019 08:51:13 - 1.18
+++ distinfo4 Jun 2019 03:28:31 -
@@ -1,2 +1,2 @@
-SHA256 (dnscrypt-proxy-2.0.23.tar.gz) =
1AWlYrDUsBAaETR8Fke7VTUZRdgtZ1ZbOWeUur8paQU=
-SIZE (dnscrypt-proxy-2.0.23.tar.gz) = 2552615
+SHA256 (dnscrypt-proxy-2.0.25.tar.gz) =
d0aWAEyeMG4XI7TLvmapYRKKM1VD0xjQeGSSzmm5Bvo=
+SIZE (dnscrypt-proxy-2.0.25.tar.gz) = 2596674
Index: patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
===
RCS file:
/cvs/ports/net/dnscrypt-proxy/patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-dnscrypt-proxy_example-dnscrypt-proxy_toml
--- patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml16 Apr 2019
15:26:11 - 1.3
+++ patches/patch-dnscrypt-proxy_example-dnscrypt-proxy_toml4 Jun 2019
03:28:31 -
@@ -1,5 +1,9 @@
$OpenBSD: patch-dnscrypt-proxy_example-dnscrypt-proxy_toml,v 1.3 2019/04/16
15:26:11 bket Exp $
+run as _dnscrypt-proxy user
+enable logging
+fix directory for public-resolvers.md
+
Index: dnscrypt-proxy/example-dnscrypt-proxy.toml
--- dnscrypt-proxy/example-dnscrypt-proxy.toml.orig
+++ dnscrypt-proxy/example-dnscrypt-proxy.toml
@@ -12,7 +16,22 @@ Index: dnscrypt-proxy/example-dnscrypt-p
## Require servers (from static + remote sources) to satisfy specific
properties
-@@ -497,7 +497,7 @@ cache_neg_max_ttl = 600
+@@ -130,12 +130,12 @@ refused_code_in_responses = false
+
+ ## Log level (0-6, default: 2 - 0 is very verbose, 6 only contains fatal
errors)
+
+-# log_level = 2
++log_level = 2
+
+
+ ## log file for the application
+
+-# log_file = 'dnscrypt-proxy.log'
++log_file = '${LOCALSTATEDIR}/log/dnscrypt-proxy.log'
+
+
+ ## Use the system logger (syslog on Unix, Event Log on Windows)
+@@ -514,7 +514,7 @@ cache_neg_max_ttl = 600
[sources.'public-resolvers']
urls =
['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md',
'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md']
Index: pkg/README
===
RCS file: /cvs/ports/net/dnscrypt-proxy/pkg/README,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 README
--- pkg/README 30 Apr 2019 08:51:13 - 1.2
+++ pkg/README 4 Jun 2019 03:28:31 -
@@ -9,35 +9,54 @@ them to a DNSCrypt resolver over an encr
To use this package, several things are required.
-First, ensure that ${SYSCONFDIR}/dnscrypt-proxy.toml fits your needs.
+Customizing dnscrypt-proxy.toml
+===
-Uncomment 'server_names' to have a smaller set of public resolvers to be
-used for load balancing. If this line is commented, all registered
-servers matching the require_* filters will be used for load balancing.
+Ensure that ${SYSCONFDIR}/dnscrypt-proxy.toml fits your needs.
+Resolvers
+-
+Uncomment 'server_names' to have a smaller set of public resolvers to be used
+for load balancing. If this line is commented, all registered servers matching
+the require_* filters will be used for load balancing. Refer to
+${LOCALSTATEDIR}/dnscrypt-proxy/public-resolvers.md for a list of all public
+resolvers.
+
+Load balancing strategy
+---
Note the load balancing strategy, controlled by 'lb_strategy'. It can be
set to one of the following values:
- - 'fastest' (always pick the fastest server in the list)
+ - 'first' (always pick the fastest server in the list)
- 'p2' (randoml
Re: portgen.hs
On Mon, Jun 3, 2019 at 8:39 PM Andrew Hewus Fresh
wrote:
> What's most important though is knowing what a Haskell port's Makefile
> should look like. We also need an API that we can use to query for the
> distfile name[1] and a way to figure out the dependencies, preferably
> via some sort of API, but doing it by querying the package can also
> work.
Stackage snapshots may be the best bet as they seem to have consistent
versioned snapshots:
https://www.stackage.org/lts-13.24
> The actual language specific bits should be relatively simple, mostly
> just converting from the metadata we gather to the correct variables to
> put into the Makefile.
I spent some quality time with Haskell ports recently so I have partial
knowledge.
> I'm sure there will be some special problems to solve because of version
> numbers or some other thing that nobody can agree on, but it looks like
> https://hackage.haskell.org/api should work, although I can't figure out
> how to get it to give my JSON, although it says it will.
Something like this works for some APIs thought I didn't figure out enough
to make me confident it is sufficient:
$ curl -H'Accept: application/json'
https://hackage.haskell.org/package/ACME/preferred; echo
{"normal-version":["0.0.0.1","0.0.0.0"]}
Let me see if I have enough gumption to wade back into Perl...
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: UPDATE: security/keepassxc
First off all thanks jca@ and sthen@ for the energy you put in this
topic.
On Mon Jun 03, 2019 at 09:39:16PM +0100, Stuart Henderson wrote:
> On 2019/06/03 21:38, Rafael Sadowski wrote:
> > On Sun Jun 02, 2019 at 05:41:37PM +0200, Jeremie Courreges-Anglas wrote:
> > > On Sun, Jun 02 2019, Rafael Sadowski wrote:
> > > > Update keepassxc to 2.4.2
> > > >
> > > > CHANGELOG:
> > > > https://github.com/keepassxreboot/keepassxc/releases/tag/2.4.2
> > > >
> > > > I send the Alloc class patch upsteream as usual. Tests and feedback
> > > > welcome.
> > >
> > > I didn't check anything else, but the Alloc class patch shouldn't be
> > > sent upstream as-is, IMO. Please see below.
> > >
> > > > RS
> > > >
> > > > ===
> > > > RCS file: patches/patch-src_core_Alloc_cpp
> > > > diff -N patches/patch-src_core_Alloc_cpp
> > > > --- /dev/null 1 Jan 1970 00:00:00 -
> > > > +++ patches/patch-src_core_Alloc_cpp2 Jun 2019 09:44:06 -
> > > > @@ -0,0 +1,23 @@
> > > > +$OpenBSD$
> > > > +
> > > > +Index: src/core/Alloc.cpp
> > > > +--- src/core/Alloc.cpp.orig
> > > > src/core/Alloc.cpp
> > > > +@@ -20,6 +20,8 @@
> > > > + #include
> > > > + #ifdef Q_OS_MACOS
> > > > + #include
> > > > ++#elif defined(Q_OS_OPENBSD)
> > > > ++#include
> > > > + #else
> > > > + #include
> > > > + #endif
> > > > +@@ -61,7 +63,7 @@ void operator delete(void* ptr) noexcept
> > > > + ::operator delete(ptr, _msize(ptr));
> > > > + #elif defined(Q_OS_MACOS)
> > > > + ::operator delete(ptr, malloc_size(ptr));
> > > > +-#elif defined(Q_OS_UNIX)
> > > > ++#elif defined(Q_OS_LINUX)
> > > > + ::operator delete(ptr, malloc_usable_size(ptr));
> > > > + #else
> > > > + // whatever OS this is, give up and simply free stuff
> > > >
> > >
> > > I think the port's cmake setup should check for malloc_usable_size and
> > > malloc.h, use them if available, and fall back on stdlib.h / std::free()
> > > if not. OpenBSD is not the only OS where malloc.h isn't available, and
> > > Linux (glibc really) isn't the only OS where malloc_usable_size() is
> > > available. This kind of #ifdef practice is actively harmful for
> > > portability.
> > >
> > > Also if the goal is to securely erase memory before freeing it,
> > > maybe freezero(3) is a possible alternative?
> > >
> > > --
> > > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524
> > > E7EE
> > >
> >
> > Thanks Jeremie for saving me from a mistake.
> >
> > There is no way to fix this on OpenBSD so let's disable for now. New
> > diff which disabled the custom delete operator.
> >
> > General question, what does it make sense to delete each heap allocated
> > (just allocated memory with "new") memory so?
>
> AIUI they aren't tracking every allocation which _does_ use memory to hold
> some sensitive data, so are blindly zeroing everything they can when the
> allocation is deleted. Might slow things down a bit but this shouldn't be
> a performance critical program anyway and why not wipe the things where
> they can.
>
> > In my opinion, we're not losing anything here.
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/security/keepassxc/Makefile,v
> > retrieving revision 1.20
> > diff -u -p -u -p -r1.20 Makefile
> > --- Makefile21 Apr 2019 11:29:44 - 1.20
> > +++ Makefile3 Jun 2019 19:17:16 -
> > @@ -2,7 +2,7 @@
> >
> > COMMENT = management tool for password and sensitive data
> >
> > -V =2.4.1
> > +V =2.4.2
> > DISTNAME = keepassxc-${V}
> >
> > CATEGORIES = security
> > @@ -16,7 +16,7 @@ PERMIT_PACKAGE_CDROM =Yes
> >
> > WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5DBus Qt5Gui
> > WANTLIB += Qt5Network Qt5Svg Qt5Widgets Qt5X11Extras X11 Xi Xtst
> > -WANTLIB += argon2 c gcrypt gpg-error m qrencode z
> > +WANTLIB += argon2 c gcrypt gpg-error m qrencode sodium z
> >
> > MASTER_SITES =
> > https://github.com/keepassxreboot/keepassxc/releases/download/${V}/
> > EXTRACT_SUFX = -src.tar.xz
> > @@ -25,6 +25,7 @@ MODULES = x11/qt5 \
> > devel/cmake
> >
> > LIB_DEPENDS = security/libgcrypt \
> > + security/libsodium \
> > security/argon2 \
> > graphics/libqrencode \
> > x11/qt5/qtsvg \
> > @@ -36,8 +37,8 @@ RUN_DEPENDS = devel/desktop-file-utils \
> >
> > CONFIGURE_ARGS=-DCMAKE_INSTALL_MANDIR="man" \
> > -DWITH_GUI_TESTS=ON \
> > - -DWITH_XC_SSHAGENT=ON \
> > - -DWITH_XC_AUTOTYPE=ON
> > + -DWITH_XC_AUTOTYPE=ON \
> > + -DWITH_XC_SSHAGENT=ON
> >
> > TEST_IS_INTERACTIVE = X11
> >
> > @@ -52,10 +53,8 @@ WANTLIB += yubikey ykpers-1
> > .endif
> >
> > .if ${FLAVOR:Mbrowser}
> > -LIB_DEPENDS += security/libsodium
> > CONFIGURE_ARGS += -DWITH_XC_BROWSER=ON \
> >
x11/kde-applications #2
Take #2 Nothing's happened here since the February. I know, no active porter interested in KDE5 expect kn@ (THANKS!). It would still be nice to import the following: kde-applications |-- development | |-- grantleetheme-18.12.0.tar.gz | `-- kcontacts-18.12.0.tar.gz |-- education | |-- kturtle-18.12.0.tar.gz | |-- kwordquiz-18.12.0.tar.gz | |-- minuet-18.12.0.tar.gz | `-- rocs-18.12.0.tar.gz |-- games | |-- knights-18.12.0.tar.gz | `-- picmi-18.12.0.tar.gz |-- graphics | |-- kamera-18.12.0.tar.gz | |-- kcolorchooser-18.12.0.tar.gz | |-- kdegraphics-thumbnailers-18.12.0.tar.gz | |-- kolourpaint-18.12.0.tar.gz | `-- kruler-18.12.0.tar.gz |-- kdesdk |-- network | |-- kdenetwork-filesharing-18.12.0.tar.gz | `-- kget-18.12.0.tar.gz |-- pim `-- utilities `-- sweeper-18.12.0.tar.gz On https://sizeofvoid.org/pub/OpenBSD/kde-applications/ you can always find the latest WIP KDE ports. Here is a simple example how to test one port from the list: $ cd /usr/ports $ ftp -M -o - https://sizeofvoid.org/pub/OpenBSD/kde-applications/education/kturtle-18.12.0.tar.gz | tar xfzv - $ cd x11/kde-applications/kturtle $ # review, check, install and give me feedback (and ok)... Thank you RS
Re: x11/kde-applications/kdenlive keep crashing and is unusable
On Fri Apr 26, 2019 at 05:25:22PM +0200, Solene Rapenne wrote: > I'm trying to get kdenlive to work, each time I try to load a video sample in > the editing tracks, kdenlive crashs and I can't even find where is the > coredump. > > I have no idea why this is happening. I did a ktrace -d but this procuded a 1 > GB file and I don't know what to look. > > I bumped a lot my user limits, here is ulimit -a output: > > time(cpu-seconds)unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 3620864 > stack(kbytes)8192 > lockedmem(kbytes)3072000 > memory(kbytes) 3072000 > nofiles(descriptors) 4096 > processes512 > > > When I start kdenlive with egdb and reroduce the issue, I can get a backtrace > as the following: > > (gdb) bt > #0 thrkill () at -:3 > #1 0x06d485da1ffe in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x06d485dc4ac2 in _libc_pthread_mutex_unlock (mutexp=) > at /usr/src/lib/libc/thread/rthread_mutex.c:265 > #3 0x06d4aa9d43d6 in producer_set_up_video (self=, > frame=0x6d4b7666000) at producer_avformat.c:2350 > #4 producer_get_frame (producer=, frame=, > index=) at producer_avformat.c:2987 > #5 0x06d4c414fcca in producer_get_frame (service=0x6d46c52ab00, > frame=0x6d408a12390, index=) at mlt_producer.c:643 > #6 0x06d4c414eb85 in mlt_service_get_frame (self=0x6d46c52ab00, > frame=0x6d408a12390, index=) at mlt_service.c:593 > #7 0x06d41c00eb0c in Mlt::Service::get_frame (this=, > index=0) at MltService.cpp:115 > #8 0x06d1e7966d77 in ProjectClip::doExtractImage() () > #9 0x06d1e75eda39 in non-virtual thunk to > QtConcurrent::RunFunctionTask::run() () > #10 0x06d4cfb4eca7 in QThreadPoolThread::run() () from > /usr/local/lib/libQt5Core.so.2.2 > #11 0x06d4cfb57820 in QThreadPrivate::start(void*) () from > /usr/local/lib/libQt5Core.so.2.2 > #12 0x06d4d869f021 in _rthread_start (v=) at > /usr/src/lib/librthread/rthread.c:96 > #13 0x06d485e201ab in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:72 > #14 0x in ?? () > Reported upstream: https://github.com/mltframework/mlt/issues/444
