This also happens in the stock `git` installed from `pkg`, but I have installed
it also from `/usr/ports` so I could enable debug symbols and get a proper
stacktrace.
When cloning any https repo (or at least the ones from github that I tried),
git segfaults in `git-remote-https`, and the core d
On 17/10/2018 6:34 pm, Brennan Vincent wrote:
This also happens in the stock `git` installed from `pkg`, but I have installed
it also from `/usr/ports` so I could enable debug symbols and get a proper
stacktrace.
When cloning any https repo (or at least the ones from github that I tried),
git
Hi Kubilay (or do you prefer "koobs"?). Thanks for the response.
To answer your questions:
* I am using latest packages
* My /etc/make.conf was empty when I built the system, and now just has
`WITH_DEBUG=yes`.
# uname -a
FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:2
On 17/10/2018 7:14 pm, Brennan Vincent wrote:
Hi Kubilay (or do you prefer "koobs"?). Thanks for the response.
To answer your questions:
* I am using latest packages
* My /etc/make.conf was empty when I built the system, and now just has
`WITH_DEBUG=yes`.
# uname -a
FreeBSD freebsd 12.0-ALPHA9
oh, actually I should point out that /usr/local/lib/libcurl.so.4 depends on
*both* /lib/libcrypto.so.8 and /lib/libcrypto.so.9 , from the output I showed
in my last email.
I'm not sure how to get the PORTVERSION and PORTREVISION...
___
freebsd-current@
No, I've never run `delete-old` and `delete-old-lib` while upgrading.
I can try upgrading again tomorrow and running those. But if my installation of
curl is for whatever reason
depending on libcrypto.so.8 and that command deletes it, won't that just cause
curl to stop working? (I tried manually
I think this just depends on when packages were built in relation to the
upgrade of openssl on current. I have just got over this problem by
rebuilding and installing the ftp/curl port (different problem here,
curl was failing but referred to older version of libssl and libcrypto -
which I didn't h
Compiling ftp/curl from source and installing it has fixed the issue. Thank you
both for the help/suggestions!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "free
Hello,
I have encountered an issue with a kernel application that I have written,
the application allocates and deallocates contiguous memory using
contigmalloc() and contigfree().
The application will fail after a period of time because there is not enough
free contiguous memory left.
There co
On a powerpc64 with builworld buildkernel built via
devel/powerpc64-xtoolchain-gcc for head -r339076
(some source adjustments), and a system-cc-is-clang
I attempted a:
# kyua test -k /usr/tests/Kyuafile
It got to:
sys/netinet/reuseport_lb:basic_ipv4 -> failed:
/usr/src/tests/sys/netinet/reuse
[I got another data storage interrupt failure, again
during kyaua showing:
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ->
but the backtrace looks different. See below.]
On 2018-Oct-17, at 4:58 PM, Mark Millard wrote:
> On a powerpc64 with builworld buildkernel built via
> devel/powerpc64-xto
[Booting a debug kernel reported a lock order
reversal that might be relevant. The problem
repeated again: seems to always fail in my
context. The backtrace is like the prior
one, but for the debug kernel build being used
this time.]
On 2018-Oct-17, at 6:29 PM, Mark Millard wrote:
> [I got anoth
12 matches
Mail list logo
