Re: poudriere blocked after pkg build failed
> Am 27.02.2020 um 00:09 schrieb Tatsuki Makino : > > > The cause of this trouble is the following part of make.conf. > > .MAKE.JOBS=4 YEP, that’s it. Surprisingly this worked for days (weeks?) until pkg received an update. (-; Thank you for your great work, Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc Description: Message signed with OpenPGP
Re: poudriere blocked after pkg build failed
> Am 27.02.2020 um 00:09 schrieb Tatsuki Makino : > > .MAKE.JOBS=4 This was the only way to force a -j 4 to make. > > If you want to limit the number of parallel jobs to 4, write: > > MAKE_JOBS_NUMBER:=4 This has no effect here, if combined with ALLOW_MAKE_JOBS=yes in poudriere.conf A bug? Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc Description: Message signed with OpenPGP
Re: Timidity++ needs libarc as run dependency ??
On Thu, 27 Feb 2020, Mateusz Piotrowski wrote:
On 2/26/20 3:20 PM, Hans Petter Selasky wrote:
On 2020-02-26 13:18, Mateusz Piotrowski wrote:
On 2/26/20 10:55 AM, Hans Petter Selasky wrote:
ld-elf.so.1: Shared object "libarc.so.1" not found, required by
"timidity"
pkg install libarc
It looks like libarc is already included in LIB_DEPENDS. It is not
included in the timidity++ package. It is only included with the
timidity++-${PKGNAMESUFFIX} packages (like timidity++-emacs).
I've never used timidity myself, so I am not sure why this is this way.
Is there a reason why you installed timidity++ instead of one of the
timidity++-${PKGNAMESUFFIX} packages?
No specific reason. I just wanted to test some MIDI files.
And did "pkg instal xxx". Is timidity++ not a valid port/package?
It is a valid port. I am not sure why libarc is not a run-time dependency
here. Maybe just an oversight.
Maybe there is some bug with
.if !defined(PKGNAMESUFFIX)
during package building?
Marcin
smime.p7s
Description: S/MIME Cryptographic Signature
llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
I'm testing modifications of ports I maintain in a jail. I have nothing in make.conf(5) except DEVELOPER=true But I get messages regarding python versions like: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. But I make no demands on versions. What causes this, and how can I stop it. :) Thanks! --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Xorg 1.20 no mouse buttons
Roland, Your issue might be related to this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244110 On 2/26/2020 5:29 PM, Ronald Klop wrote: It works again. Changed back from virtualboxvideo from drm-devel-kmod to the driver from virtualbox-ose-additions. But did some other changes at the same time also. Not sure yet what happened, but it was integration of the mouse with virtualbox which failed somehow. Regards, Ronald. On Wed, 26 Feb 2020 20:40:14 +0100, Ronald Klop wrote: Hello, Since my upgrade to Xorg 1.20 things seem to work except that no mouse buttons work. Pointer movement works good still. I'm running a fairly recent FreeBSD 13-CURRENT in VirtualBox (On Windows 10). The mouse is a touchpad on my Lenovo IdeaPad laptop. Previously it worked using fine. What can I do or debug to fix this? Regards, Ronald. [ 23.241] X.Org X Server 1.20.7 X Protocol Version 11, Revision 0 [ 23.241] Build Operating System: FreeBSD 13.0-CURRENT amd64 [ 23.241] Current Operating System: FreeBSD sjakie 13.0-CURRENT FreeBSD 13.0-CURRENT #4 r357762M: Sun Feb 16 12:16:08 CET 2020 builder@sjakie:/data/src/obj-freebsd-current/data/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 [ 23.241] Build Date: 22 February 2020 07:06:47AM [ 23.241] [ 23.241] Current version of pixman: 0.38.4 [ 23.241] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 23.241] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 23.241] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 24 19:18:14 2020 [ 23.244] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d" [ 23.246] (==) No Layout section. Using the first Screen section. [ 23.246] (==) No screen section available. Using defaults. [ 23.246] (**) |-->Screen "Default Screen Section" (0) [ 23.246] (**) | |-->Monitor "" [ 23.247] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 23.247] (==) Automatically adding devices [ 23.247] (==) Automatically enabling devices [ 23.247] (==) Not automatically adding GPU devices [ 23.247] (==) Max clients allowed: 256, resource mask: 0x1f [ 23.262] (==) FontPath set to: /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/, catalogue:/usr/local/etc/X11/fontpath.d [ 23.263] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 23.263] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 23.263] (II) Loader magic: 0x435010 [ 23.263] (II) Module ABI versions: [ 23.263] X.Org ANSI C Emulation: 0.4 [ 23.263] X.Org Video Driver: 24.1 [ 23.263] X.Org XInput driver : 24.1 [ 23.263] X.Org Server Extension : 10.0 [ 23.263] (--) PCI:*(0@0:2:0) 80ee:beef:: rev 0, Mem @ 0xe000/134217728, BIOS @ 0x/65536 [ 23.263] (II) LoadModule: "glx" [ 23.265] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 23.292] (II) Module glx: vendor="X.Org Foundation" [ 23.292] compiled for 1.20.7, module version = 1.0.0 [ 23.292] ABI class: X.Org Server Extension, version 10.0 [ 23.292] (==) Matched vboxvideo as autoconfigured driver 0 [ 23.292] (==) Matched modesetting as autoconfigured driver 1 [ 23.292] (==) Matched scfb as autoconfigured driver 2 [ 23.292] (==) Matched vesa as autoconfigured driver 3 [ 23.292] (==) Assigned the driver to the xf86ConfigLayout [ 23.292] (II) LoadModule: "vboxvideo" [ 23.292] (II) Loading /usr/local/lib/xorg/modules/drivers/vboxvideo_drv.so [ 23.294] (II) Module vboxvideo: vendor="Oracle Corporation" [ 23.294] compiled for 1.20.7, module version = 1.0.1 [ 23.294] Module class: X.Org Video Driver [ 23.294] ABI class: X.Org Video Driver, version 24.1 [ 23.294] (**) Load address of symbol "VBOXVIDEO" is 0x801b8d010 [ 23.294] (II) LoadModule: "modesetting" [ 23.294] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so [ 23.295] (II) Module modesetting: vendor="X.Org Foundation" [ 23.295] compiled for 1.20.7, module version = 1.20.7 [ 23.295] Module class: X.Org Video Driver [ 23.295] ABI class: X.Org Video Driver, version 24.1 [ 23.295] (II) LoadModule: "scfb" [ 23.295] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so [ 23.297] (II) Module scfb: vendor="X.Org Foundation" [ 23.297] compiled for 1.20.7, module version = 0.0.5 [ 23.297] ABI class: X.Org Video Driver, version 24.1 [ 23.297] (II) LoadModule:
About protocols in openssl
Hi,
My ceph ports uses all kinds of python stuff, and now the trouble is
that I'm getting
an error on missing:
SSLv3_client_method
Which i guess, is because in the current openssl libs SSLv3 is disabled.
And I sort of get this, SSLv3 is unsafe.
But I need it to be able to run parts of the ceph port.
So how do I get a openssl lib dependancy that has SSLv3 enabled.
WjW
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
c = (_s=3, val='_exception:
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.to...ion
AsyncCompletion._on_complete..run at 0x80d5613b0>, id=34580530768,
name=_create_grafana, pr=NA, _next=None)
def raise_if_exception(c):
# type: (Completion) -> None
"""
:raises OrchestratorError: Some user error or a config error.
:raises Exception: Some internal error
"""
if c.serialized_exception is not None:
try:
e = pickle.loads(c.serialized_exception)
except (KeyError, AttributeError):
raise Exception('{}: {}'.format(type(c.exception), c.exception))
raise e
E ImportError:
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
Undefined symbol "SSLv3_client_method"
orchestrator/_interface.py:701: ImportError
-- Captured log call ---
ERRORorchestrator._interface:_interface.py:391 _Promise failed
Traceback (most recent call last):
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py",
line 334, in do_work
res = self._on_complete_(*args, **kwargs)
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py",
line 398, in call_self
return f(self, *inner_args)
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py",
line 2352, in _create_grafana
return self._create_daemon('grafana', daemon_id, host)
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py",
line 1874, in _create_daemon
j = self._generate_grafana_config()
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py",
line 2288, in _generate_grafana_config
cert, pkey = create_self_signed_cert('Ceph', 'cephadm')
File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/mgr_util.py", line
134, in create_self_signed_cert
from OpenSSL import crypto
File
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/__init__.py",
line 8, in
from OpenSSL import crypto, SSL
File
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/crypto.py",
line 15, in
from OpenSSL._util import (
File
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/_util.py",
line 6, in
from cryptography.hazmat.bindings.openssl.binding import Binding
File
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
line 15, in
from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError:
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
Undefined symbol "SSLv3_client_method"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: About protocols in openssl
Willem Jan Withagen wrote on 2020/02/27 20:00: Hi, My ceph ports uses all kinds of python stuff, and now the trouble is that I'm getting an error on missing: SSLv3_client_method Which i guess, is because in the current openssl libs SSLv3 is disabled. And I sort of get this, SSLv3 is unsafe. But I need it to be able to run parts of the ceph port. So how do I get a openssl lib dependancy that has SSLv3 enabled. You can build OpenSSL 1.1.1 from the ports where you can enable SSLv3 in the options dialog. https://www.freshports.org/security/openssl/ The defaults are: > Protocol Support NEXTPROTONEG=on: Next Protocol Negotiation (SPDY) SCTP=on: SCTP (Stream Control Transmission) SSL3=off: SSLv3 (unsafe) TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2) TLS1_1=on: TLSv1.1 (requires TLS1_2) TLS1_2=on: TLSv1.2 Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: About protocols in openssl
On 27-2-2020 20:25, Miroslav Lachman wrote: Willem Jan Withagen wrote on 2020/02/27 20:00: Hi, My ceph ports uses all kinds of python stuff, and now the trouble is that I'm getting an error on missing: SSLv3_client_method Which i guess, is because in the current openssl libs SSLv3 is disabled. And I sort of get this, SSLv3 is unsafe. But I need it to be able to run parts of the ceph port. So how do I get a openssl lib dependancy that has SSLv3 enabled. You can build OpenSSL 1.1.1 from the ports where you can enable SSLv3 in the options dialog. https://www.freshports.org/security/openssl/ The defaults are: > Protocol Support NEXTPROTONEG=on: Next Protocol Negotiation (SPDY) SCTP=on: SCTP (Stream Control Transmission) SSL3=off: SSLv3 (unsafe) TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2) TLS1_1=on: TLSv1.1 (requires TLS1_2) TLS1_2=on: TLSv1.2 Yup, this is what I did, and that works. But how do I do that for a port? And the make sure that the installer of the ceph-package gets an openssl that had SSLv3 --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: About protocols in openssl
On 2020-02-27 11:42, Willem Jan Withagen wrote: On 27-2-2020 20:25, Miroslav Lachman wrote: Willem Jan Withagen wrote on 2020/02/27 20:00: Hi, My ceph ports uses all kinds of python stuff, and now the trouble is that I'm getting an error on missing: SSLv3_client_method Which i guess, is because in the current openssl libs SSLv3 is disabled. And I sort of get this, SSLv3 is unsafe. But I need it to be able to run parts of the ceph port. So how do I get a openssl lib dependancy that has SSLv3 enabled. You can build OpenSSL 1.1.1 from the ports where you can enable SSLv3 in the options dialog. https://www.freshports.org/security/openssl/ The defaults are: > Protocol Support NEXTPROTONEG=on: Next Protocol Negotiation (SPDY) SCTP=on: SCTP (Stream Control Transmission) SSL3=off: SSLv3 (unsafe) TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2) TLS1_1=on: TLSv1.1 (requires TLS1_2) TLS1_2=on: TLSv1.2 Yup, this is what I did, and that works. But how do I do that for a port? And the make sure that the installer of the ceph-package gets an openssl that had SSLv3 It may be best to build an internal package with the options you need configured accordingly. I do this via poudriere for some of my internal software. For example I have this file on my package builder: /usr/local/etc/poudriere.d/make.conf which contains the following: x11-servers_xorg-server_SET=FIXDRM I think this matches the same format of make.conf you would use if building the ports tree locally. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > I'm testing modifications of ports I maintain in > a jail. I have nothing in make.conf(5) except > DEVELOPER=true > But I get messages regarding python versions like: > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > But I make no demands on versions. > What causes this, and how can I stop it. :) Is your set of packages fully up to date? IIRC other have had issues when they tried to install LLVM with out of date dependencies. -- Brooks signature.asc Description: PGP signature
Re: About protocols in openssl
On 27-2-2020 20:52, Pete Wright wrote: On 2020-02-27 11:42, Willem Jan Withagen wrote: On 27-2-2020 20:25, Miroslav Lachman wrote: Willem Jan Withagen wrote on 2020/02/27 20:00: Hi, My ceph ports uses all kinds of python stuff, and now the trouble is that I'm getting an error on missing: SSLv3_client_method Which i guess, is because in the current openssl libs SSLv3 is disabled. And I sort of get this, SSLv3 is unsafe. But I need it to be able to run parts of the ceph port. So how do I get a openssl lib dependancy that has SSLv3 enabled. You can build OpenSSL 1.1.1 from the ports where you can enable SSLv3 in the options dialog. https://www.freshports.org/security/openssl/ The defaults are: > Protocol Support NEXTPROTONEG=on: Next Protocol Negotiation (SPDY) SCTP=on: SCTP (Stream Control Transmission) SSL3=off: SSLv3 (unsafe) TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2) TLS1_1=on: TLSv1.1 (requires TLS1_2) TLS1_2=on: TLSv1.2 Yup, this is what I did, and that works. But how do I do that for a port? And the make sure that the installer of the ceph-package gets an openssl that had SSLv3 It may be best to build an internal package with the options you need configured accordingly. I do this via poudriere for some of my internal software. For example I have this file on my package builder: /usr/local/etc/poudriere.d/make.conf which contains the following: x11-servers_xorg-server_SET=FIXDRM I think this matches the same format of make.conf you would use if building the ports tree locally. Interesting, but not quite what I want It is not for personal usage, but for ports that I have commited to the ports collection, and want to upgrade. And yes, fixing openssl works for this problem, but it is not only my problem. I maintain these Ceph ports, and now upstream uses a python module that expects SSlv3 to be available in the openssl that encounters on the system. And the question is how to accommodate that? Short of embedding my own openssl libs with the ceph-libs, thus creating a huge maintenance problem. I could also argue that switching of SSLv3 in a generic library is sort of impractical, even if it is a protocol that we want to erradicate. But I guess that the maintainers of openssl have decided that this is the smart thing to do. And I'm in peace with that, but now require an escape from this catch-22. --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: About protocols in openssl
On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen, wrote: > > Interesting, but not quite what I want > It is not for personal usage, but for ports that I have commited to the > ports collection, and want to upgrade. > And yes, fixing openssl works for this problem, but it is not only my > problem. > > I maintain these Ceph ports, and now upstream uses a python module that > expects SSlv3 to be available in the openssl that encounters on the system. > And the question is how to accommodate that? > Short of embedding my own openssl libs with the ceph-libs, thus creating > a huge maintenance problem. > > I could also argue that switching of SSLv3 in a generic library is sort > of impractical, even if it is a protocol that we want to erradicate. > But I guess that the maintainers of openssl have decided that this is > the smart thing to do. > And I'm in peace with that, but now require an escape from this catch-22. > > --WjW > There's no mechanism in the ports tree framework for port X to depend on feature Y being enabled in port Z. All you can do is add a pkg-message alert to your ceph port saying the use needs to compile the openssl port with SSLv3 enabled. You could create a slave port for openssl that has that option enabled, then depend on that slave port. But that might create dependency issues elsewhere. Sub-packages might (eventually) allow you to work around this. Cheers, Freddie Typos due to smartphone keyboard. > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, Feb 27, 2020 at 07:52:23PM +, Brooks Davis wrote: > On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > > I'm testing modifications of ports I maintain in > > a jail. I have nothing in make.conf(5) except > > DEVELOPER=true > > But I get messages regarding python versions like: > > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > > But I make no demands on versions. > > What causes this, and how can I stop it. :) > > Is your set of packages fully up to date? IIRC other have had issues > when they tried to install LLVM with out of date dependencies. It was fixed on r522485. -- Mathieu Arnold signature.asc Description: PGP signature
Re: About protocols in openssl
On Thu, Feb 27, 2020 at 12:45:51PM -0800, Freddie Cash wrote: > On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen, wrote: > > > > > Interesting, but not quite what I want > > It is not for personal usage, but for ports that I have commited to the > > ports collection, and want to upgrade. > > And yes, fixing openssl works for this problem, but it is not only my > > problem. > > > > I maintain these Ceph ports, and now upstream uses a python module that > > expects SSlv3 to be available in the openssl that encounters on the system. > > And the question is how to accommodate that? > > Short of embedding my own openssl libs with the ceph-libs, thus creating > > a huge maintenance problem. > > > > I could also argue that switching of SSLv3 in a generic library is sort > > of impractical, even if it is a protocol that we want to erradicate. > > But I guess that the maintainers of openssl have decided that this is > > the smart thing to do. > > And I'm in peace with that, but now require an escape from this catch-22. > > > > --WjW > > > > There's no mechanism in the ports tree framework for port X to depend on > feature Y being enabled in port Z. > > All you can do is add a pkg-message alert to your ceph port saying the use > needs to compile the openssl port with SSLv3 enabled. > > You could create a slave port for openssl that has that option enabled, > then depend on that slave port. But that might create dependency issues > elsewhere. You can do it, but nobody will commit that kind of change. The choice of which OpenSSL version to use is a user facing change, and it is done globally. As a side note, SSLv3 is going away, anything done right now that needs it is doomed. > Sub-packages might (eventually) allow you to work around this. As probably the only one who knows the subpackages implementation, I don't see how it possibly could. -- Mathieu Arnold signature.asc Description: PGP signature
Re: About protocols in openssl
On 27-2-2020 21:53, Mathieu Arnold wrote: On Thu, Feb 27, 2020 at 12:45:51PM -0800, Freddie Cash wrote: On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen, wrote: Interesting, but not quite what I want It is not for personal usage, but for ports that I have commited to the ports collection, and want to upgrade. And yes, fixing openssl works for this problem, but it is not only my problem. I maintain these Ceph ports, and now upstream uses a python module that expects SSlv3 to be available in the openssl that encounters on the system. And the question is how to accommodate that? Short of embedding my own openssl libs with the ceph-libs, thus creating a huge maintenance problem. I could also argue that switching of SSLv3 in a generic library is sort of impractical, even if it is a protocol that we want to erradicate. But I guess that the maintainers of openssl have decided that this is the smart thing to do. And I'm in peace with that, but now require an escape from this catch-22. --WjW There's no mechanism in the ports tree framework for port X to depend on feature Y being enabled in port Z. All you can do is add a pkg-message alert to your ceph port saying the use needs to compile the openssl port with SSLv3 enabled. You could create a slave port for openssl that has that option enabled, then depend on that slave port. But that might create dependency issues elsewhere. You can do it, but nobody will commit that kind of change. The choice of which OpenSSL version to use is a user facing change, and it is done globally. As a side note, SSLv3 is going away, anything done right now that needs it is doomed. I wholehartedly agree, SSLv3 is a pain that should go. I've excluded it on webservers already for ages. And TLS1 and TLS1.1 going down the same path. But none the less I run into this problem that a python module does not want to load because the includes .so is looking for SSLv3 stuff during. Adding a openssl port with SSLv3 enabled would be an option, and as long a it builds on the regular openssl port it would be a compatible library. I only fear for the tantrum that `pkg install` is going to throw, when install openssl-sslv3 is going to override openssl. Nothing but matching paths. Doubt if that is going to be workable? --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Timidity++ needs libarc as run dependency ??
On 2/27/20 3:54 PM, Marcin Cieslak wrote:
On Thu, 27 Feb 2020, Mateusz Piotrowski wrote:
On 2/26/20 3:20 PM, Hans Petter Selasky wrote:
On 2020-02-26 13:18, Mateusz Piotrowski wrote:
On 2/26/20 10:55 AM, Hans Petter Selasky wrote:
ld-elf.so.1: Shared object "libarc.so.1" not found, required by
"timidity"
pkg install libarc
It looks like libarc is already included in LIB_DEPENDS. It is not
included in the timidity++ package. It is only included with the
timidity++-${PKGNAMESUFFIX} packages (like timidity++-emacs).
I've never used timidity myself, so I am not sure why this is this
way.
Is there a reason why you installed timidity++ instead of one of
the timidity++-${PKGNAMESUFFIX} packages?
No specific reason. I just wanted to test some MIDI files.
And did "pkg instal xxx". Is timidity++ not a valid port/package?
It is a valid port. I am not sure why libarc is not a run-time
dependency here. Maybe just an oversight.
Maybe there is some bug with
.if !defined(PKGNAMESUFFIX)
during package building?
No idea...
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: poudriere blocked after pkg build failed
Your poudriere.conf is written as PARALLEL_JOBS=4. Combining this with writing MAKE_JOBS_NUMBER:=4 in /usr/local/etc/poudriere.d/*make.conf, load average reaches 16. If you are concerned about that load average reaching 16, you need to adjust PARALLEL_JOBS and MAKE_JOBS_NUMBER. If it only rise up to about 4, problem will remain somewhere. There are some parts of bsd.port.mk that are not supposed to use -j, so using .MAKE.JOBS will make things go wrong. Some ports have problems with parallel build. (e.g. devel/doxygen has MAKE_JOBS_UNSAFE=yes) I think .MAKE.JOBS will not follow it. If slow port builds (e.g. cmake, llvm, qt5-webkit, texlive-texmf or etc.) hinder others, load average will temporarily drop. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: About protocols in openssl
On Thu, 27 Feb 2020, Willem Jan Withagen wrote: /home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: Undefined symbol "SSLv3_client_method" This looks to me that you are trying to build ceph in the virtualenv which probably pulls required python packages on its own. Can you make it to depend and use the existing security/py-cryptography port? I don't know how exactly the ceph port is supposed to work but it seems to require virtualenv for its inner workings. You might want to force virtual env to use FreeBSD-provided libraries with --system-site-packages but AFAIK it will no longer download anything, i.e. all dependencies need to packaged. I have just ran "make test" in my ports tree to test py-cryptography and got 1 error (TestECDSACertificate.test_load_ecdsa_no_named_curve) but nothing related to SSLv3_client_method being not there. Marcin smime.p7s Description: S/MIME Cryptographic Signature
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, 27 Feb 2020 19:52:23 + Brooks Davis bro...@freebsd.org said On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > I'm testing modifications of ports I maintain in > a jail. I have nothing in make.conf(5) except > DEVELOPER=true > But I get messages regarding python versions like: > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > But I make no demands on versions. > What causes this, and how can I stop it. :) Is your set of packages fully up to date? IIRC other have had issues when they tried to install LLVM with out of date dependencies. Thank you for taking the time to reply, Brooks! Yep. Fully synced. In fact the whole jail was fresh. Only a new world, and a fresh ports tree. Nothing had yet been built; which explains the need for llvm8. But not the Python discrepancy. :/ Thanks again! --Chris -- Brooks ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, 27 Feb 2020 21:46:12 +0100 Mathieu Arnold m...@freebsd.org said On Thu, Feb 27, 2020 at 07:52:23PM +, Brooks Davis wrote: > On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > > I'm testing modifications of ports I maintain in > > a jail. I have nothing in make.conf(5) except > > DEVELOPER=true > > But I get messages regarding python versions like: > > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > > But I make no demands on versions. > > What causes this, and how can I stop it. :) > > Is your set of packages fully up to date? IIRC other have had issues > when they tried to install LLVM with out of date dependencies. It was fixed on r522485. Thanks! :) --Chris -- Mathieu Arnold ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
