Re: cyrus-sasl-saslauthd won't build anymore
On 03/10/2015 14:32, Matthew Seaman wrote: That update was backed out after it was found not to work. Update your ports -- you should find cyrus-sasl-saslauthd-2.1.26_2 now. Sorry, my mail was confusing. I current have these installed: cyrus-sasl-2.1.26_12 cyrus-sasl-saslauthd-2.1.26_1 Updating to cyrus-sasl-saslauthd-2.1.26_3 is refusing to build, per the log: http://www.knigma.org/scratch/cyrus-sasl-saslauthd.txt -- Mark Knight Mobile: +44 7753 250584. http://www.knigma.org/ Email: ma...@knigma.org. Skype: knigma ___ 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: Help needed: ports builds on 10.X but breaks on 9.X
On 2015-10-03, "A.J. "Fonz" van Werven" wrote: > Unfortunately I don't have access to a 9.X machine right now, but does > anyone know what can cause an > > Error expanding embedded variable. As I wrote here two weeks ago... http://docs.freebsd.org/cgi/mid.cgi?slrnmvro62.94q.naddy -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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: Porting S3QL and ca-root-nss.crt: Python unable to find needed certificates
On 3/10/2015 11:20 PM, Niklaas Baudet von Gersdorff wrote:
> Hi,
>
> I'm porting S3QL, see https://bitbucket.org/nikratio/s3ql/overview. It
> creates a mountable filesystem on a Amazon S3 bucket. I already came
> this far: https://github.com/niklaas/freebsd-port-s3ql which also
> requires two python modules there are so far no ports for too:
>
> llfuse: https://github.com/niklaas/freebsd-port-llfuse
>
> dugong: https://github.com/niklaas/freebsd-port-dugong
>
> `poudriere testport` works fine. I installed the port on a FreeBSD
> system successfully and it seems to work fine. S3QL connects to the S3
> bucket via SSL. But the connection only works if I use the following
> command, explicitly stating the location of ca-root-nss.crt:
>
> mkfs.s3ql --backend-options
> ssl-ca-path=/usr/local/share/certs/ca-root-nss.crt s3://
>
> Not doing so causes the following errors:
>
>> Traceback (most recent call last):
>> File "/usr/local/bin/mount.s3ql", line 9, in
>> load_entry_point('s3ql==2.15', 'console_scripts', 'mount.s3ql')()
>> File "/usr/local/lib/python3.4/site-packages/s3ql/mount.py", line 120, in
>> main
>> options.authfile, options.compress)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/common.py", line 340, in
>> get_backend_factory
>> backend.fetch('s3ql_passphrase')
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py",
>> line 351, in fetch
>> return self.perform_read(do_read, key)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py",
>> line 107, in wrapped
>> return method(*a, **kw)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py",
>> line 314, in perform_read
>> fh = self.open_read(key)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py",
>> line 107, in wrapped
>> return method(*a, **kw)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
>> 302, in open_read
>> resp = self._do_request('GET', '/%s%s' % (self.prefix, key))
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
>> 437, in _do_request
>> query_string=query_string, body=body)
>> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
>> 668, in _send_request
>> self.conn.send_request(method, path, body=body, headers=headers)
>> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line
>> 508, in send_request
>> self.timeout)
>> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line
>> 1396, in eval_coroutine
>> if not next(crt).poll(timeout=timeout):
>> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line
>> 535, in co_send_request
>> self.connect()
>> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line
>> 444, in connect
>> self._sock = self.ssl_context.wrap_socket(self._sock,
>> server_hostname=server_hostname)
>> File "/usr/local/lib/python3.4/ssl.py", line 365, in wrap_socket
>> _context=self)
>> File "/usr/local/lib/python3.4/ssl.py", line 583, in __init__
>> self.do_handshake()
>> File "/usr/local/lib/python3.4/ssl.py", line 810, in do_handshake
>> self._sslobj.do_handshake()
>> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
>> (_ssl.c:600)
>
> I did some research and found this *fixed* bug which is more or less recent:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
>
> I was wondering whether there are still some issues with
> security/ca_root_nss or whether I forgot to specify something in the
> Makefile?
Hi Niklaas,
I'm not aware of any reported issues. You could confirm this by reducing
the test case to exclude your port, and attempting to test python/ssl
functionality alone with something like:
import socket, ssl
context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
context.verify_mode = ssl.CERT_REQUIRED
context.check_hostname = True
context.load_default_certs()
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = context.wrap_socket(s, server_hostname='www.verisign.com')
ssl_sock.connect(('www.verisign.com', 443))
This works for me (no errors) on my local Python 3.4 (from ports)
installation.
> How can I find out where python is looking for the certificates? This
> would enable me to create a symlink which could be added to the final
> version of my port of net/s3ql then too. (Note: I don't know python.)
As per the commit messages for the bugzilla issue you mentioned, python,
unlike other software (like curl iirc) uses an OpenSSL function, *not*
an internal list of paths, to derive CA certificate path locations. See
this commit message for full details:
https://svnweb.freebsd.org/ports?view=revision&revision=378720
Note: The path locations used by this function are determined at OpenSSL
*build time*. The changes made in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431 and
https://bugs.freebsd.org/bugzilla/show_bug.cg
Re: cyrus-sasl-saslauthd won't build anymore
On 03/10/2015 14:46, Mark Knight wrote: > Is anyone else having issues building: > > cyrus-sasl-saslauthd-2.1.26_1 > > cyrus-sasl-2.1.26_12 is building okay, and I've tried re-building all > dependencies and checking UPDATING. I'm on FreeBSD 10.2-RELEASE-p3 That update was backed out after it was found not to work. Update your ports -- you should find cyrus-sasl-saslauthd-2.1.26_2 now. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Porting S3QL and ca-root-nss.crt: Python unable to find needed certificates
Hi,
I'm porting S3QL, see https://bitbucket.org/nikratio/s3ql/overview. It
creates a mountable filesystem on a Amazon S3 bucket. I already came
this far: https://github.com/niklaas/freebsd-port-s3ql which also
requires two python modules there are so far no ports for too:
llfuse: https://github.com/niklaas/freebsd-port-llfuse
dugong: https://github.com/niklaas/freebsd-port-dugong
`poudriere testport` works fine. I installed the port on a FreeBSD
system successfully and it seems to work fine. S3QL connects to the S3
bucket via SSL. But the connection only works if I use the following
command, explicitly stating the location of ca-root-nss.crt:
mkfs.s3ql --backend-options
ssl-ca-path=/usr/local/share/certs/ca-root-nss.crt s3://
Not doing so causes the following errors:
> Traceback (most recent call last):
> File "/usr/local/bin/mount.s3ql", line 9, in
> load_entry_point('s3ql==2.15', 'console_scripts', 'mount.s3ql')()
> File "/usr/local/lib/python3.4/site-packages/s3ql/mount.py", line 120, in
> main
> options.authfile, options.compress)
> File "/usr/local/lib/python3.4/site-packages/s3ql/common.py", line 340, in
> get_backend_factory
> backend.fetch('s3ql_passphrase')
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py", line
> 351, in fetch
> return self.perform_read(do_read, key)
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py", line
> 107, in wrapped
> return method(*a, **kw)
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py", line
> 314, in perform_read
> fh = self.open_read(key)
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/common.py", line
> 107, in wrapped
> return method(*a, **kw)
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
> 302, in open_read
> resp = self._do_request('GET', '/%s%s' % (self.prefix, key))
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
> 437, in _do_request
> query_string=query_string, body=body)
> File "/usr/local/lib/python3.4/site-packages/s3ql/backends/s3c.py", line
> 668, in _send_request
> self.conn.send_request(method, path, body=body, headers=headers)
> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line 508,
> in send_request
> self.timeout)
> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line
> 1396, in eval_coroutine
> if not next(crt).poll(timeout=timeout):
> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line 535,
> in co_send_request
> self.connect()
> File "/usr/local/lib/python3.4/site-packages/dugong/__init__.py", line 444,
> in connect
> self._sock = self.ssl_context.wrap_socket(self._sock,
> server_hostname=server_hostname)
> File "/usr/local/lib/python3.4/ssl.py", line 365, in wrap_socket
> _context=self)
> File "/usr/local/lib/python3.4/ssl.py", line 583, in __init__
> self.do_handshake()
> File "/usr/local/lib/python3.4/ssl.py", line 810, in do_handshake
> self._sslobj.do_handshake()
> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
> (_ssl.c:600)
I did some research and found this *fixed* bug which is more or less recent:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
I was wondering whether there are still some issues with
security/ca_root_nss or whether I forgot to specify something in the
Makefile?
How can I find out where python is looking for the certificates? This
would enable me to create a symlink which could be added to the final
version of my port of net/s3ql then too. (Note: I don't know python.)
Any help is very much appreciated.
Best,
--
Niklaas
___
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"
cyrus-sasl-saslauthd won't build anymore
Is anyone else having issues building: cyrus-sasl-saslauthd-2.1.26_1 cyrus-sasl-2.1.26_12 is building okay, and I've tried re-building all dependencies and checking UPDATING. I'm on FreeBSD 10.2-RELEASE-p3 Full build log here: http://www.knigma.org/scratch/cyrus-sasl-saslauthd.txt Thanks for any ideas! -- Mark Knight Mobile: +44 7753 250584. http://www.knigma.org/ Email: ma...@knigma.org. Skype: knigma ___ 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: Help needed: ports builds on 10.X but breaks on 9.X
Olivier Duchateau wrote: > devel/gettext-tools is missing (according to build log). Good catch. > There're 2 ways to resolv your problem: > - Patch Makefile (probably search subdir word, where doc directory is > mentioned) > - Add USES=gettext-tools, but don't explicitly disable NLS I'll look into that, thanks. Fonz -- I'm not completely useless, I can be used as a bad example. signature.asc Description: PGP signature
Re: Help needed: ports builds on 10.X but breaks on 9.X
On Sat, 3 Oct 2015 11:06:30 +0200 "A.J. \"Fonz\" van Werven" wrote: > Hi all, > > The port x11-servers/Xfstt, which I maintain, apparently breaks on FreeBSD > 9.3-RELEASE while building just fine on 10.X-RELEASE. Initially I thought > it was just a random glitch, but I got a second pkg-fallout message, so > perhaps something is actually wrong indeed. > > Unfortunately I don't have access to a 9.X machine right now, but does > anyone know what can cause an > > Error expanding embedded variable. > > error right at the very start of the build phase on FreeBSD 9.X (happens > on both i386 and amd64), but not on FreeBSD 10.X? A complete build log > can be found here: > http://beefy2.nyi.freebsd.org/data/93amd64-default/398241/logs/xfstt-1.9.2.log > > Any input would be greatly appreciated. > > Fonz Hi, devel/gettext-tools is missing (according to build log). Excerpt build log: checking whether NLS is requested... no checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... no checking for msgmerge... no checking build system type... amd64-portbld-freebsd9.3 checking host system type... amd64-portbld-freebsd9.3 checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking whether to use NLS... no [skip] /usr/bin/make all-recursive Making all in doc GEN xfstt.1x Making all in po Error expanding embedded variable. *** [all-recursive] Error code 1 Makefile tries to build and translate xfstt.1 man page, but Gettext tools are missing. There're 2 ways to resolv your problem: - Patch Makefile (probably search subdir word, where doc directory is mentioned) - Add USES=gettext-tools, but don't explicitly disable NLS Regards > > -- > I'm not completely useless, I can be used as a bad example. -- olivier ___ 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: Uses/compiler.mk does not trigger under RBPi
José Pérez wrote:
> Hi Michelle,
> thank you for your suggestion. Is this another workaround?
As far as I was aware if you need Uses/compiler.mk it should be
specified (there are params if a particular compiler/feature set is
required) with USES+=compiler
>
> I mean: many port Makefiles are affected, in the sense that when built
> on Intel/AMD the ports just work because Uses/compiler.mk is sucked in
> automatically, but it is not on ARM.
But do they need Uses/compiler.mk ? If so then it might be someone
screwed up, if they don't actually need it then that would be why it's
not specified.
>
> So, shall I report a bug on all the ports that use COMPILER_TYPE, or
> is there a way to have ARM trigger Uses/compiler.mk?
If they use/require COMPILER_TYPE and don't specify USES+= compiler then
I would log a bug for each port and let the ports manager take care of
it as it's probably a change in default behavior that has caused the
mess... how many are we talking about? 10+, 100+, 1000+?
Regards,
Michelle
>
> Thank you.
>
> Regards,
>
>
> ---
> José Pérez
>
> El 2015-10-02 02:29, Michelle Sullivan escribió:
>> José Pérez wrote:
>>> Hi,
>>> I've notice that Uses/compiler.mk is not triggered and as a
>>> consequence does to set COMPILER_TYPE.
>>>
>>> me@raspberry-pi:~ % cat Makefile
>>> all:
>>> @${ECHO_CMD} ${LOCALBASE}
>>> @${ECHO_CMD} ${COMPILER_TYPE}
>>> .include
>>> me@raspberry-pi:~ % make
>>> /usr/local
>>>
>>> me@raspberry-pi:~ %
>>>
>>> As a result building ports is a nightmare.
>>>
>>> Note how in AMD64 it works:
>>> me@amd64:~ % make
>>> /usr/local
>>> clang
>>> me@amd64:~ %
>>>
>>> As a workaround I set COMPILER_TYPE=clang in /etc/make.conf but this
>>> is just an ugly hack.
>>>
>>> Can some expert trow a little light on this? Thank you.
>>>
>>> Regards,
>>>
>> Try adding:
>>
>> USES+= compiler
>>
>> to the makefile first...
>>
>> (and it still has some issues but that should solve the first)
> ___
> 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"
--
Michelle Sullivan
http://www.mhix.org/
___
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"
Help needed: ports builds on 10.X but breaks on 9.X
Hi all, The port x11-servers/Xfstt, which I maintain, apparently breaks on FreeBSD 9.3-RELEASE while building just fine on 10.X-RELEASE. Initially I thought it was just a random glitch, but I got a second pkg-fallout message, so perhaps something is actually wrong indeed. Unfortunately I don't have access to a 9.X machine right now, but does anyone know what can cause an Error expanding embedded variable. error right at the very start of the build phase on FreeBSD 9.X (happens on both i386 and amd64), but not on FreeBSD 10.X? A complete build log can be found here: http://beefy2.nyi.freebsd.org/data/93amd64-default/398241/logs/xfstt-1.9.2.log Any input would be greatly appreciated. Fonz -- I'm not completely useless, I can be used as a bad example. signature.asc Description: PGP signature
