Re: [UPDATE]: sysutils/opam -> 2.0.4
ok krw@, but I assume for after the ports tree is unlocked?
Ken
> On Apr 13, 2019, at 6:53 AM, Christopher Zimmermann
> wrote:
>
> Hello,
>
> this is a very simple update. OK?
>
> Christopher
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/opam/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile12 Mar 2019 05:36:06 -1.11
> +++ Makefile13 Apr 2019 13:49:57 -
> @@ -4,8 +4,7 @@ COMMENT =OCaml source-based package ma
>
> CATEGORIES =sysutils devel
>
> -V =2.0.3
> -REVISION =0
> +V =2.0.4
> PKGNAME =opam-${V}
> DISTNAME =opam-full-${V}
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/opam/distinfo,v
> retrieving revision 1.4
> diff -u -p -r1.4 distinfo
> --- distinfo12 Mar 2019 05:36:06 -1.4
> +++ distinfo13 Apr 2019 13:49:57 -
> @@ -1,2 +1,2 @@
> -SHA256 (opam-full-2.0.3.tar.gz) =
> BYnaTaGEWEpURdWThQCVNlNPYLwOJ3ciRbL0nl+o8OI=
> -SIZE (opam-full-2.0.3.tar.gz) = 7870020
> +SHA256 (opam-full-2.0.4.tar.gz) =
> 3r+4KLQA+1EcopDxv8ko25HK107BzL3c/b/v8m9wmeU=
> +SIZE (opam-full-2.0.4.tar.gz) = 7868547
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
kmousetool: yet another kde4 vs kde5 oddity
Hi. There's something unhandled between x11/kde-applications/kmousetool and x11/kde4/kmousetool. They share the same PKGNAME, obviously not the same PKGPATH. "pkg_add kmousetool" will only install the kde5 version. If you want the kde4 version you must explictely say so "pkg_add -z kmousetool-4.14.3". And you can't build both: $ cd /usr/ports/x11/kde-applications/kmousetool && make package <...> $ cd /usr/ports/x11/kde4/kmousetool && make package <...> Found newer package kmousetool-18.12.0p0 in /hack/cvs/ports/plist/amd64 *** Error 1 in . (/hack/cvs/ports/infrastructure/mk/bsd.port.mk:2026 '/hack/cvs/ports/packages/amd64/all/kmousetool-4.14.3p5.tgz') Did we forget to rename one of them? -- Antoine
Re: SSL errors on 6.4 after apache-httpd with mpm_event_module was updated to 2.4.39
On Fri, Apr 12, 2019, at 01:00, Stuart Henderson wrote: > On 2019/04/11 23:22, Stuart Henderson wrote: > > On 2019/04/11 20:25, Stuart Henderson wrote: > > > On 2019/04/10 05:12, Frank Groeneveld wrote: > > > > Last week an update to apache-httpd was released which fixes an > > > > important security issue. I updated a number of servers right away, but > > > > after receiving some traffic they started to produce SSL errors. I've > > > > tried to debug this as far as I could and have come to the conclusion > > > > that it only happens when using mpm_event_module. My configs are > > > > default, but I enable SSL and switch to the evented MPM. For > > > > certificates I use Let's Encrypt (using acme-client). ab prints the > > > > following errors. > > > > > > > > SSL handshake failed (1). > > > > 140321585887104:error:0407008A:rsa > > > > routines:RSA_padding_check_PKCS1_type_1:invalid > > > > padding:crypto/rsa/rsa_pk1.c:66: > > > > 140321585887104:error:04067072:rsa > > > > routines:rsa_ossl_public_decrypt:padding check > > > > failed:crypto/rsa/rsa_ossl.c:655: > > > > 140321585887104:error:1416D07B:SSL > > > > routines:tls_process_key_exchange:bad > > > > signature:ssl/statem/statem_clnt.c:2414: > > > > > > > > Web browsers show an error also, but some refreshing sometimes fixes > > > > the problem. Is anybody else able to reproduce this? Can I do anything > > > > to help resolve it? > > > > > > > > Thanks in advance. > > > > > > > > Frank > > > > > > > > > > I can replicate this on 6.4 but not -current, I'll see if I can figure > > > out what's up. > > > > > > > Seems it was introduced between 2.4.35 and 2.4.37. I don't see > > anything particularly suspicious in the main code diff between those > > two versions, but one of the subtler changes is that it switches off > > MODSSL_USE_OPENSSL_PRE_1_1_API for libressl 2.7+. > > > > So probably one of the ifdef blocks is taking a code path that fails > > with the libressl code in 6.4 but has been changed post-6.4-release. > > > > Builds are taking ages on the machine I'm testing on and the wifi > > connection I'm on at the moment is stalling every few minutes and > > I'm losing patience now but if anyone wants to pick it up I'd suggest > > looking through the various #if MODSSL_USE_OPENSSL_PRE_1_1_API blocks > > and see if adding "&& !defined(LIBRESSL_VERSION_NUMBER)" to any of > > them fixes things (the usual libressl-porting whack-a-mole..). > > > > ...oh I have something that works now :) Works great, thank you very much! Frank
Re: "build conflict"? - was Re: Build failure: math/py-pandas,python3
In this case it *is* just a standard "hidden" dependency - if it's present at configure time then cython is used for the build. It just needs either enabling properly with whatever *_DEPENDS lines are appropriate, or disabling either via flags/environment or patches. Generally if it's just a build conflict then it should just be fixed. -- Sent from a phone, apologies for poor formatting. On 12 April 2019 18:51:48 Kurt Mosiejczuk wrote: On Fri, Apr 12, 2019 at 03:59:45PM +0100, Stuart Henderson wrote: On 2019/04/12 16:14, Christian Weisgerber wrote: math/py-pandas,python3 failed to build in my latest amd64 bulk build. Any idea what happened there? Hidden optional dep. py3-Cython was present when configure started running. but then got junked. I see this sort of thing come up more than once where something isn't a dependency per se, but if it happens to be there, it causes chaos. It's not really a conflict, would the idea of a mechanism to document a "build conflict" be useful for ports building? Something that might allow making sure such a package is not installed when building? --Kurt
