Re: x11/nvidia-driver no longer works under -current (r338323)
On 26/08/2018 9:07 pm, John wrote: Hello lists, x11/nvidia-driver is broken again. Context: FreeBSD-12-ALPHA3 r338323 / ports 478102 / amd64. Tried to build with make distclean clean rmconfig && make MAKE_JOBS_UNSAFE=yes It fails here: Hi John, It fails earlier, can you find and paste the 'error: ' line(s) ? More importantly though, ports shouldn't be using -Werror so a good first step would be to identify its source and remove it. =kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.nvidia_pci.o -MTnvidia_pci.o -mcmodel=kernel -mno-r ed-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy pes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-nega tive-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_pci.c -o nvidia_pci.o cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel =kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.nvidia_subr.o -MTnvidia_subr.o -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-proto types -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-un known-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-ne gative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_subr.c -o nvidia_subr.o *** Error code 1 Stop. make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia *** Error code 1 Stop. make[3]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src *** Error code 1 Stop. make[2]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 *** Error code 1 Stop. make[1]: stopped in /usr/ports/x11/nvidia-driver *** Error code 1 Stop. Stop. make: stopped in /usr/ports/x11/nvidia-driver I can post more output if you need it. thanks, ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PR id=231810
On 30/09/2018 5:52 pm, Matthias Apitz wrote: > > Hello, > > Can some kind soul please modify this PR to reflect the Version and the > affected people: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810 > > Thanks > > matthias > Hi Matthias, I've updated the Severity, but the Version is better left at the lowest (earliest) reported/confirmed version, to ensure it gets merged back to the relevant stable branch. ./koobs ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
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 segfaults in `git-remote-https`, and the core dump shows the following stack trace: * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46 frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] getrn(lh=, data=0x0008013aba20) at lhash.c:434 frame #2: 0x000800d04ebb libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at lhash.c:207 frame #3: 0x000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x, type=, data="m\x04") at o_names.c:202 frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at c_allc.c:83 frame #5: 0x00080120a4b9 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] ossl_init_add_all_ciphers at init.c:216 frame #6: 0x00080120a4b4 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205 frame #7: 0x00080064de28 libthr.so.3`_pthread_once(once_control=0x00080128a3b0, init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at thr_once.c:97 frame #8: 0x000801209b69 libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) at threads_pthread.c:113 frame #9: 0x000801209f67 libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) at init.c:611 frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, settings=) at ssl_init.c:197 frame #11: 0x000800525cb4 libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883 frame #12: 0x0008004a4a92 libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722 frame #13: 0x0008004a935f libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271 frame #14: 0x00080045b455 libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405 frame #15: 0x0008004661ca libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154 frame #16: 0x00080047c436 libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934 frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222 frame #18: 0x0026a519 git-remote-https`step_active_slots at http.c:1293 frame #19: 0x0026a596 git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314 frame #20: 0x0026a9f8 git-remote-https`run_one_slot(slot=0x0008012fa4c0, results=0x7fffe0f8) at http.c:1509 frame #21: 0x0026dc6a git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack";, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793 frame #22: 0x0026ac5b git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack";, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869 frame #23: 0x0026ac1c git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack";, result=0x7fffe298, options=0x7fffe1f0) at http.c:1910 frame #24: 0x00264fbd git-remote-https`discover_refs(service="", for_push=0) at remote-curl.c:385 frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at remote-curl.c:465 frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, argv=0x7fffe470) at remote-curl.c:1369 frame #27: 0x002707d7 git-remote-https`main(argc=3, argv=0x7fffe470) at common-main.c:45 frame #28: 0x0026311b git-remote-https`_start(ap=, cleanup=) at crt1.c:76 Hi Brennan, git gets its HTTP/HTTPS/etc support via curl, so it's likely an issue there. Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... that seems wrong to me, but I'm not an expert. There have been many instances in the past where software (from ports/packages) ends up linked against *both* OpenSSL from base and OpenSSL from ports, due to various issues. This is probably a similar issue. The same problem can occur for anything that base provides, that can also be provided by ports, gssapi, ncurses, readline, among others come to mind. `/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me. If both exist in base, that's interesting (and probably a problem). I only have libcrypto.so.8 on a recent (month old) CURRENT build. The openssl port (which curl can use) provides libcrypto.so.9 (in /usr/local/lib) I can't reproduce this on a pristine install of 12.0-ALPHA10. Some more system information might prove useful: - FreeBSD version issue is reproducible on (uname -a) - Output of ldd /usr/local/bin/curl - Using quarterly or latest packages? - Wh
Re: Git segfaulting in libcrypto.so when trying to clone.
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 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # ldd /usr/local/bin/curl /usr/local/bin/curl: libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000) libz.so.6 => /lib/libz.so.6 (0x8002e7000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000) libthr.so.3 => /lib/libthr.so.3 (0x8003b1000) libc.so.7 => /lib/libc.so.7 (0x8003dc000) libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000) libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000) libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x800f52000) # ldd /usr/local/lib/libcurl.so.4 /usr/local/lib/libcurl.so.4: libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000) libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e) libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000) libz.so.6 => /lib/libz.so.6 (0x801189000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000) libthr.so.3 => /lib/libthr.so.3 (0x801253000) libc.so.7 => /lib/libc.so.7 (0x800248000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x80156b000) (aha - libcurl depends on .8 , and the curl binary depends on .9) From a cursory glance at the source tree, it seems libcrypto is part of openssl, is this right? It seems the openssl version is in flux right now, that might explain things... OpenSSL 1.1.1 import happened 7 days ago [1], which may partially explain the cause. Having two versions of the shared libraries in base is unexpected though, unless its intentional for some reason, or I'm missing/forgetting something. Do you run the delete-old / delete-old-lib targets during your upgrades? [1] https://svnweb.freebsd.org/changeset/base/339270 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
On 2/01/2019 4:56 pm, Matthew Macy wrote: I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:55 PM Matthew Macy wrote: I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz wrote: El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert escribió: In message , Antoine Brodin writes: On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrote: On Fri, 28 Dec 2018 at 16:31, Emiel Kollof wrot e: Confirmed with Chromium on my CURRENT box: … Thanks folks. Should I report it as a bug with devel/glib20? Hi, I think it's a regression in the toolchain (the problem doesn't occur on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ No issue here however I rebuilt glib on Dec 21. I see the same with www/chromium on r342378 and ports, both from Dec 23. matthias -- The issue is being tracked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 Per my last comment (comment 36), any base change(s) required to resolve the issue, once identified, should be tracked separately as a blocking issue. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipsec not working
On 12/05/2019 4:20 pm, Alexandr Krivulya wrote: Hi, after upgrading from r347050 to r347483 ipsec tunel on my notebook does not work any more. Connection is established as usual but no policies are installed. 2019-05-12 09:12:10 00[DMN] Starting IKE charon daemon (strongSwan 5.7.2, FreeBSD 13.0-CURRENT, amd64) 2019-05-12 09:12:10 00[KNL] unable to set IPSEC_POLICY on socket: Protocol not available 2019-05-12 09:12:10 00[NET] installing IKE bypass policy failed 2019-05-12 09:12:10 00[KNL] unable to set IPSEC_POLICY on socket: Protocol not available 2019-05-12 09:12:10 00[NET] installing IKE bypass policy failed 2019-05-12 09:12:10 00[KNL] unable to set UDP_ENCAP: Invalid argument 2019-05-12 09:12:10 00[NET] enabling UDP decapsulation for IPv6 on port 4500 failed 2019-05-12 09:12:10 00[KNL] unable to set IPSEC_POLICY on socket: Protocol not available 2019-05-12 09:12:10 00[NET] installing IKE bypass policy failed 2019-05-12 09:12:10 00[KNL] unable to set IPSEC_POLICY on socket: Protocol not available 2019-05-12 09:12:10 00[NET] installing IKE bypass policy failed 2019-05-12 09:12:10 00[KNL] unable to set UDP_ENCAP: Protocol not available 2019-05-12 09:12:10 00[NET] enabling UDP decapsulation for IPv4 on port 4500 failed ... 2019-05-12 09:12:10 01[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ 2019-05-12 09:12:10 01[KNL] unable to add SAD entry with SPI c96b2b97: Invalid argument (22) 2019-05-12 09:12:10 01[KNL] unable to add SAD entry with SPI cc951335: Invalid argument (22) 2019-05-12 09:12:10 01[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel 2019-05-12 09:12:10 01[IKE] failed to establish CHILD_SA, keeping IKE_SA See: https://svnweb.freebsd.org/changeset/base/347410 Ongoing thread: https://lists.freebsd.org/pipermail/svn-src-head/2019-May/124878.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
On 18/06/2019 5:42 pm, Michael Tuexen wrote: Dear all, I'm trying to run sudo make buildworld in a directory with r349168. The result is: cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD -MF.depend.lex.o -MTlex.o -std=gnu99 -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c lex.c -o lex.o /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such file or directory /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared identifier is reported only once /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it appears in.) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared (first use in this function) *** Error code 1 Stop. make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static *** Error code 1 Stop. make[2]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make[1]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve the issue. Any idea what is going wrong? Best regards Michael Have seen another report on Twitter yesterday. Didn't see a full build log, but theirs was had apparently without -j, apparently on June 14 sources: Error: /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found Have not heard back from them whether it continued after trying -j2 but I did ask them to hit up freebsd-current if it continued to be an issue ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SOEKRIS kernel config
On 28/09/2014 12:47 PM, Tom Everett wrote: > I see there is no SOEKRIS config on the tree, here > > https://svnweb.freebsd.org/base/head/sys/i386/conf/ > > I have attached one for addition to the tree. > > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Thanks Tom This is a good candidate for a Bugzilla Issue, under Base System -> conf so it doesn't get lost in the mail :) -- Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: About virtio-scsi and\or scsi.
On 31/07/2015 12:06 AM, Bryan Venteicher wrote: > On Wed, Jul 29, 2015 at 4:53 PM, Eliezer Croitoru > wrote: > >> I am testing couple VMs under kvm and from my tests it seems that there >> might not be support for hot-plug of virtio disks or virtio-scsi disks in >> freebsd? >> >> > > Hot plug of VirtIO block devices is not supported, but that is more > because of a lack PCI hot plug. Hot plugging of disks to an existing > VirtIO SCSI adapter is supported. I wonder if John-Marks (cc'd) recent work on PCIe Hot-Plug [1] is at all relevant to this: [1] https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Adding-PCIe-Hot-plug-Support ./koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
On 10/11/2015 8:42 PM, Dag-Erling Smørgrav wrote: > Some of you may have noticed that OpenSSH in base is lagging far behind > the upstream code. > > The main reason for this is the burden of maintaining the HPN patches. > They are extensive, very intrusive, and touch parts of the OpenSSH code > that change significantly in every release. Since they are not > regularly updated, I have to choose between trying to resolve the > conflicts myself (hoping I don't break anything) or waiting for them to > catch up and then figuring out how to apply the new version. > > Therefore, I would like to remove the HPN patches from base and refer > anyone who really needs them to the openssh-portable port, which has > them as a default option. I would also like to remove the NONE cipher > patch, which is also available in the port (off by default, just like in > base). > > DES > I for one, support our new consistent-with-upstream, improved-productivity and lower-risk-for-regressions-in-base overlords. ./koobs ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: D-link wireless not detected
On 30/12/2015 1:07 AM, Hans Petter Selasky wrote: > On 12/29/15 15:02, Hans Petter Selasky wrote: >> On 12/29/15 14:00, Daniel Braniss wrote: >>> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: On 12/29/15 13:36, Daniel Braniss wrote: > Until /etc/devd/usb.conf is regenerated, you'll need to manually load the kernel module for urtwn. Did you do that? --HPS >>> ok, set if_urtwn_load=yes >>> and now I get: >>> >>> ugen0.4: at usbus0 >>> urtwn0: on usbus0 >>> urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on write >>> trapframe: 0xda29fb88 >>> FSR=0805, FAR=, spsr=6013 >>> r0 =, r1 =, r2 =c0a72cb0, r3 =0165 >>> r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 = >>> r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20 >>> r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc >>> >>> [ thread pid 13 tid 100045 ] >>> Stopped at ieee80211_ifdetach+0x4c:str r0, [r1] >>> db> >>> >>> btw, as long as you are willing to help, I will keep testing, >>> in other words, i’m ok. >> >> Hi Andriy, >> >> Can you fix the crash above and verify this error patch? >> > > Hi, > > I see 11-current has a fix. Maybe MFC that to 10-stable? Is there a Bugzilla issue ID for it? >> Andriy: >> >> After: >> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); >> There is no need for: >> usbd_transfer_drain(sc->sc_xfer[x]); > > --HPS > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Requesting MFC's
On 4/02/2016 1:32 PM, Matthew Grooms wrote: > All, > > What is the correct way to request that patches be committed to STABLE? > In particular, I'd really like to see these in 10.3-RELEASE as they have > been required to build a working firewall in some cases. All are related > to problems that were fixed in HEAD, but never MFC'd ... > > https://svnweb.freebsd.org/base?view=revision&revision=264915 > https://svnweb.freebsd.org/base?view=revision&revision=272695 > https://svnweb.freebsd.org/base?view=revision&revision=288529 1) Create an issue in Bugzilla for it a) Assigned to original committer b) Set mfc-stableX flag to? Committer can then set mfc-stableX flag to + when done, or set it to - with comment about why not/invalid/inappropriate If a branch is in feature freeze, issues should either: - Have re@ CC'd so they can be informed of the request - Have maintainer-approval ? r...@freebsd.org set so that the release engineering team can approve/deny changes This is also the recommended method for changes that already have bugzilla issues created for them. > Thanks in advance, > > -Matthew > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Requesting MFC's
On 4/02/2016 5:44 PM, Allan Jude wrote: > On 2016-02-04 01:15, Kubilay Kocak wrote: >> On 4/02/2016 1:32 PM, Matthew Grooms wrote: >>> All, >>> >>> What is the correct way to request that patches be committed to STABLE? >>> In particular, I'd really like to see these in 10.3-RELEASE as they have >>> been required to build a working firewall in some cases. All are related >>> to problems that were fixed in HEAD, but never MFC'd ... >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=264915 >>> https://svnweb.freebsd.org/base?view=revision&revision=272695 >>> https://svnweb.freebsd.org/base?view=revision&revision=288529 >> >> 1) Create an issue in Bugzilla for it >> a) Assigned to original committer >> b) Set mfc-stableX flag to? >> >> Committer can then set mfc-stableX flag to + when done, or set it to - >> with comment about why not/invalid/inappropriate >> >> If a branch is in feature freeze, issues should either: >> >> - Have re@ CC'd so they can be informed of the request >> - Have maintainer-approval ? r...@freebsd.org set so that the release >> engineering team can approve/deny changes >> >> This is also the recommended method for changes that already have >> bugzilla issues created for them. >> > > RE@ has a specific procedure for requesting approval for an MFC during a > freeze: https://wiki.freebsd.org/Releng/ChangeRequestGuidelines > I would imagine they prefer not to be added to bugzilla issues until a > committer decides it is worth MFCing something > Yes, sorry. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On 18/02/2016 3:51 AM, Warren Block wrote: > On Wed, 17 Feb 2016, Eric van Gyzen wrote: > >> On 02/17/2016 08:19, Warren Block wrote: >>> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >>> A short note on the www.freebsd.org website would probably be helpful, as this case will produce a lot of noise. >>> >>> Maybe a short article like we did for leap seconds? >>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >>> >>> >> >> Articles are permanent, which makes sense for the recurring issue of >> leap seconds. This vulnerability is transient, so I would suggest a >> news item. > > Yes, but news items are usually just links. For the amount of > information we have so far, an article seems like the easiest way to do > this. Or maybe an addition to the security part of the web site? > > For now, I'll collect the information as just text. Don't we also want our sec teams to investigate/confirm it anyway, independent of how it's communicated? If so, doesn't a security advisory (with secteam and/or ports-secteam as appropriate) make the most sense here, given the scope of vulnerability for base/linux emulation/ports is yet to be completely established and is still to be investigated properly? Finally, would users expect a news item, an article or a heads up from our security teams for something like this, even in the case where it's only a "confirmed we're not affected" ? ./koobs ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On 18/02/2016 4:23 AM, Warren Block wrote: > On Thu, 18 Feb 2016, Kubilay Kocak wrote: > >> On 18/02/2016 3:51 AM, Warren Block wrote: >>> On Wed, 17 Feb 2016, Eric van Gyzen wrote: >>> >>>> On 02/17/2016 08:19, Warren Block wrote: >>>>> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >>>>> >>>>>> A short note on the www.freebsd.org website would probably be >>>>>> helpful, >>>>>> as this case will produce a lot of noise. >>>>> >>>>> Maybe a short article like we did for leap seconds? >>>>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >>>>> >>>>> >>>>> >>>> >>>> Articles are permanent, which makes sense for the recurring issue of >>>> leap seconds. This vulnerability is transient, so I would suggest a >>>> news item. >>> >>> Yes, but news items are usually just links. For the amount of >>> information we have so far, an article seems like the easiest way to do >>> this. Or maybe an addition to the security part of the web site? >>> >>> For now, I'll collect the information as just text. >> >> Don't we also want our sec teams to investigate/confirm it anyway, >> independent of how it's communicated? > > Absolutely. > >> If so, doesn't a security advisory (with secteam and/or ports-secteam as >> appropriate) make the most sense here, given the scope of vulnerability >> for base/linux emulation/ports is yet to be completely established and >> is still to be investigated properly? > > Have there been security advisories for unconfirmed or > not-actually-a-problem events before? My impression was that they have > only been announced when a problem exists and action needs to be taken. This "No SA, no problem" pattern is reasonable for default case, and the vast majority of issues. This glibc issue, like heartbleed and others may be sufficiently high-profile to warrant special treatment, even if not in "SA" form. > However, a real problem *does* exist for Linux VMs and applications on > FreeBSD, so it could be addressed that way. A "we are investigating" > advisory right now could do some good, if the protocols allow it. > >> Finally, would users expect a news item, an article or a heads up from >> our security teams for something like this, even in the case where it's >> only a "confirmed we're not affected" ? > > A news item linking to a "it's not us!" advisory would be no problem. > People have to go looking for that. > > Those who are subscribed to the security mailing list will receive those > notices directly, and because those are expected to be problems that > need to be addressed immediately, it might cause some initial > palpitations as if it were an actual problem with FreeBSD. Yup, and let me make clear an out-there-in-the-world distinction between 'an advisory by freebsd security people ' and a FreeBSD "SA" the implementation format. ./koobs ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r296272 breaks virtualbox
On 2/03/2016 9:29 AM, Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt - > not available or version mismatch > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > Michael > Please create a bugzilla issue to track this, including: * a link to this mailing list thread so the maintainers can see the suggestion by John. * An attachment containing a log with the errors observed * Reference/link to the commit that caused the regression * CC the committer of the base revision in question Attaching a patch to fix the issue will likely encourage it to be committed sooner, but is not compulsory ./koobs ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg SAT_SOLVER bugs
On 27/06/2016 8:38 PM, Hans Petter Selasky wrote: > Hi, > > I found some bugs in PKG with regard to the SAT_SOLVER environment > variable. Please find patch attached :-) Nice! Can you report upstream @ https://github.com/freebsd/pkg if you haven't already > Issues fixed: > 1) No need to use hash table when generating SAT rules for external > solver. Variables are already in a linear array. Fix encoding and > decoding of SAT data. > 2) Endless variable loop caused pkg to crash. > 3) it->inverse was checked for non-zero, while it should actually be > checked for -1 only. SAT rules produces were all negative. > > How to verify: > > make -C /usr/ports/math/picosat all install clean > > env SAT_SOLVER=picosat pkg upgrade > > --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg SAT_SOLVER bugs
On 27/06/2016 8:38 PM, Hans Petter Selasky wrote: > Hi, > > I found some bugs in PKG with regard to the SAT_SOLVER environment > variable. Please find patch attached :-) > > Issues fixed: > 1) No need to use hash table when generating SAT rules for external > solver. Variables are already in a linear array. Fix encoding and > decoding of SAT data. > 2) Endless variable loop caused pkg to crash. > 3) it->inverse was checked for non-zero, while it should actually be > checked for -1 only. SAT rules produces were all negative. > > How to verify: > > make -C /usr/ports/math/picosat all install clean > > env SAT_SOLVER=picosat pkg upgrade > > --HPS > Heads-up: Have just updated picosat to its latest version, enjoy! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 11.0-BETA2 Now Available
On 25/07/2016 5:25 AM, Glen Barber wrote: > The second BETA build of the 11.0-RELEASE release cycle is now > available. 11.0-BETA2 version added to Bugzilla for bug reports/regression/etc Bugs marked 11.0-BETA1 that are unresolved [1] should be updated to 11.0-BETA2 [1] https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New&bug_status=Open&bug_status=In%20Progress&list_id=127434&product=Base%20System&query_format=advanced&version=11.0-BETA1 > Installation images are available for: > > o 11.0-BETA2 amd64 GENERIC > o 11.0-BETA2 i386 GENERIC > o 11.0-BETA2 powerpc GENERIC > o 11.0-BETA2 powerpc64 GENERIC64 > o 11.0-BETA2 sparc64 GENERIC > o 11.0-BETA2 armv6 BANANAPI > o 11.0-BETA2 armv6 BEAGLEBONE > o 11.0-BETA2 armv6 CUBIEBOARD > o 11.0-BETA2 armv6 CUBIEBOARD2 > o 11.0-BETA2 armv6 CUBOX-HUMMINGBOARD > o 11.0-BETA2 armv6 GUMSTIX > o 11.0-BETA2 armv6 RPI-B > o 11.0-BETA2 armv6 RPI2 > o 11.0-BETA2 armv6 PANDABOARD > o 11.0-BETA2 armv6 WANDBOARD > o 11.0-BETA2 aarch64 GENERIC > > Note regarding arm/armv6 images: For convenience for those without > console access to the system, a freebsd user with a password of > freebsd is available by default for ssh(1) access. Additionally, > the root user password is set to root, which it is strongly > recommended to change the password for both users after gaining > access to the system. > > Installer images and memory stick images are available here: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/ > > The image checksums follow at the end of this e-mail. > > If you notice problems you can report them through the Bugzilla PR > system or on the -stable mailing list. > > If you would like to use SVN to do a source based update of an existing > system, use the "stable/11" branch. > > A summary of changes since 11.0-BETA1 includes: > > o Several build-/toolchain-related fixes. > > o WITNESS and INVARIANTS have been disabled on powerpc/powerpc64 and > arm/armv6 architectures. > > o freebsd-update(8) has been updated to allow '*-dbg' distribution sets. > > o ctld(8) no longer exits when reloading the configuration with invalid > initiator-portal clauses. > > o GENERIC-NODEBUG kernel configurations have been removed. > > o The callout code has been updated to avoid a system panic with TCP > timers. > > o Several other changes. > > A list of changes since 10.0-RELEASE are available on the stable/11 > release notes: > > https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html > > Please note, the release notes page is not yet complete, and will be > updated on an ongoing basis as the 11.0-RELEASE cycle progresses. > > === Virtual Machine Disk Images === > > VM disk images are available for the amd64 and i386 architectures. > Disk images may be downloaded from the following URL (or any of the > FreeBSD FTP mirrors): > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-BETA2/ > > The partition layout is: > > ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) > ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) > ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) > > The disk images are available in QCOW2, VHD, VMDK, and raw disk image > formats. The image download size is approximately 135 MB and 165 MB > respectively (amd64/i386), decompressing to a 21 GB sparse image. > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > loader file is needed for qemu-system-aarch64 to be able to boot the > virtual machine images. See this page for more information: > > https://wiki.freebsd.org/arm64/QEMU > > To boot the VM image, run: > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ > -bios QEMU_EFI.fd -serial telnet::,server -nographic \ > -drive if=none,file=VMDISK,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -device virtio-net-device,netdev=net0 \ > -netdev user,id=net0 > > Be sure to replace "VMDISK" with the path to the virtual machine image. > > === Amazon EC2 AMI Images === > > FreeBSD/amd64 EC2 AMIs are available in the following regions: > > us-east-1 region: ami-684bc37f > us-west-1 region: ami-2592d345 > us-west-2 region: ami-210cc041 > sa-east-1 region: ami-511b8f3d > eu-west-1 region: ami-3d12704e > eu-central-1 region: ami-92f80cfd > ap-northeast-1 region: ami-355ba354 > ap-northeast-2 region: ami-edef2583 > ap-southeast-1 region: ami-789d421b > ap-southeast-2 region: ami-1a81ab79 > > === Vagrant Images === > > FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can > be installed by running: > > % vagrant init freebsd/FreeBSD-11.0-BETA2 > % vagrant up > > Note to freebsd-update(8) consumers: An EN for earlier FreeBSD releases > is required before upgrading to 11.0-BETA2 will work properly, so it is > advised to wait until the ENs are published before attempting an upgrade > via freebsd-update(8). > > == ISO CHECKSUMS == > > o
Re: FreeBSD 11.0-BETA2 won't boot on an Acer Aspire 5560
On 27/07/2016 7:22 PM, Peter Jeremy wrote: > I'm trying to boot the 11.0-BETA2/amd64 memory stick image and the > kernel panics: (Following copied by hand): > > ACPI APIC Table: > ... > acpi0: on motherboard > ACPI Error: Hardware did not change modes (20160527/hwacpi-160) > ACPI Error: Could not transition to APCI mode (20160527/evxfevnt-105) > ACPI Warning: AcpiEnable failed (20160527/utxfinit-184) > acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE > device_attach: acpi0 attach returned 6 > > Followed by a NULL dereference panic at nexus_acpi_attach+0x89 > > The system boots a 10.0-RELEASE/amd64 memstick (the only other image I > have conveniently to date) without problem. > Thank you for the report Peter Did it boot prior to 11.0-BETA2? ie; is it a regression? Please report a bug in bugzilla with version: 11.0-BETA2 and cc r...@freebsd.org If it's possible to obtain a backtrace of the panic, please include it as an attachment: https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Setting debug.debugger_on_panic=1 in loader may help get it to the debugger. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gfx-next update: drm-4.8-rc2 tagged in drm-next
On 16/08/2016 5:12 PM, Matthew Macy wrote: > As of this moment sys/dev/drm in the drm-next tree is sync with > https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset > of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is > a bit of a milestone as it means that it is possible that in the future > graphics support on FreeBSD could proceed in lockstep with Linux. > > In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of today. > > Once I'm done working on Kaby Lake support I intend to get radeon and amdgpu > to the point where they work as well as i915. Following that we'll need to > spend some time resolving general correctness issues. > > -M > All of this is and means a huge deal for our users and us as a project, thank you to everyone on Team Graphics™ and every one else who has been involved for their ongoing effort. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: autoreconf missing boost?
On 6/9/17 2:52 AM, blubee blubeeme wrote: > I forgot to add this in my last email, here's the boost packages that I > have installed. > > me@blubee:~ % pkg info | grep boost > boost-jam-1.64.0 Build tool from the boost.org > boost-libs-1.64.0 Free portable C++ libraries (without > Boost.Python) > boost-python-libs-1.62.0 Framework for interfacing Python and C++ > boost_build-2.0.m12_4 Extensible cross-platform build tool suite > > > On Thu, Jun 8, 2017 at 11:56 PM, blubee blubeeme > wrote: > >> Hi >> >> I'm running a autoreconf trying to port a project; some printer code. >> Having a bit of trouble. >> >> I ran autoreconf -fi >> >> then I do: >> ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld >> --with-libintl-prefix=/usr/local >> >> that goes straight forward. >> >> Then when I run gmake, it seems to fail at linking boost or something like >> that. Here's the output of gmake, i've tried both make and gmake: >> me@blubee:~/Downloads/Epson/ut % gmake >> gmake all-recursive >> gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' >> Making all in . >> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' >> gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' >> Making all in lib >> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> Making all in . >> gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> CXX connexion.lo >> In file included from connexion.cpp:32:0: >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ >> include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a >> type >> typedef __vm_ooffset_t vm_ooffset_t; >> ^ >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ >> include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a >> type >> typedef __vm_pindex_t vm_pindex_t; >> ^ >> In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, >> from /usr/local/include/boost/core/demangle.hpp:39, >> from /usr/local/include/boost/core/typeinfo.hpp:119, >> from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, >> from /usr/local/include/boost/ >> smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, >> from /usr/local/include/boost/ >> smart_ptr/detail/sp_counted_base.hpp:54, >> from /usr/local/include/boost/ >> smart_ptr/detail/shared_count.hpp:29, >> from /usr/local/include/boost/ >> smart_ptr/shared_ptr.hpp:28, >> from /usr/local/include/boost/shared_ptr.hpp:17, >> from /usr/local/include/boost/filesystem/path.hpp:29, >> from /usr/local/include/boost/filesystem.hpp:16, >> from connexion.cpp:40: >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: >> error: expected initializer before '__nonnull' >> int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ >> ^ >> In file included from /usr/local/lib/gcc49/include/ >> c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, >> from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, >> from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, >> from /usr/local/lib/gcc49/include/c++/ios:42, >> from /usr/local/lib/gcc49/include/c++/ostream:38, >> from /usr/local/lib/gcc49/include/c++/iostream:39, >> from connexion.cpp:38: >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: >> error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_once) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: >> error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_getspecific) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: >> error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_setspecific) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: >> error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* >> (*)(void*), void*)' declared 'static' but never defined >> [-Werror=unused-function] >> __gthrw(pthread_create) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1: >> error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' >> but never defined [-Werror=unused-function] >> __gthrw(pthread_join) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-p
Re: lang/expect -- update coming
On 22/02/2014 2:51 AM, Dewey Hylton wrote: >> From: "Pietro Cerutti" >> To: freebsd-po...@freebsd.org, freebsd-sta...@freebsd.org, >> freebsd-current@FreeBSD.org >> Cc: jmoha...@bsd.hu, "Martin Wilke" , wrig...@gmail.com, >> fre...@deweyonline.com, pda...@gmail.com, >> "romain garbage" >> Sent: Friday, February 21, 2014 10:38:24 AM >> Subject: Re: lang/expect -- update coming >> >> On 2014-Feb-21, 15:38, Pietro Cerutti wrote: >>> All, >>> >>> I'm planning to commit an update to bring lang/expect up to the >>> latest >>> 5.45 version. At the same time, I'm going to kill >>> lang/expect-devel, >>> which would otherwise be left lagging behind at 5.44. >>> >>> The following ports use either expect or -devel (maintainers CC'd). >>> >>> devel/pecl-expect >>> net-mgmt/rancid >>> net-mgmt/rancid-devel >> >> Turns out my regexp-foo sucked this time.. Here's a more complete >> list. >> Thanks koobs@ for noticing. >> >> devel/pecl-expect >> misc/dejagnu >> misc/sshbuddy >> net/freenx >> net-mgmt/netmagis-topo >> et-mgmt/rancid >> net-mgmt/rancid-devel >> security/belier > > i'm no longer maintaining the freenx/nxserver ports. they are so outdated at > this point they should probably be killed off as well, but i have no idea who > might still be using them. While the MAINTAINER line references your email, you do, even if not for version updates. As maintainer, you have a couple of PR options up your sleeve: - Reset maintainer, so someone else can pick them up - Set EXPIRE with reason and an appropriate lead time to removal The above can also serve to communicate to users-come-would-be-maintainers that they might need attention and provide the impetus to jump in and have a go :) Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Change top's notion of idle processes / threads
On 24/05/2014 7:22 AM, Allan Jude wrote: > On 2014-05-23 16:05, John Baldwin wrote: >> Right now, when top is set to not display idle processes or threads, it only >> displays processes or threads that are currently in a runnable state or have >> a >> non-zero %cpu. However, our %cpu is quite imprecise. I have patch to >> change >> top to instead compare the thread or processes runtime (ki_runtime in >> kinfo_proc) against the runtime of the thread or process the last time data >> was fetched. In essence, top will consider any thread that has run on a CPU >> since the last update as non-idle. The end result is that mostly-idle >> threads >> and processes will now be visible in top's idle display. Personally, I find >> this more useful (and find the current implementation completely useless). >> The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch >> >> Comments? >> > > I think this makes good sense. I would definitely prefer it. Would it > make sense to maybe preserve the old behaviour behind a command line flag? > And an update to top(8) reflecting the algo :) I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users -- Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turning TESTS on by default
On 7/06/2014 5:14 AM, Julio Merino wrote: > Hello all, > > > TL;DR > - > > I plan to turn the TESTS src.conf knob ON by default on Tuesday once I > have been able to perform enough sanity-checks of the build and all of > them pass. > > The impact of this is that the FreeBSD Test Suite (see tests(7)) will > be built and installed by default under /usr/tests/ along with the > private atf libraries and binaries. There should be no other changes > and this should be transparent to everyone. > > If this happens to break the world in any way, we can trivially roll > the change back to fix the fallout. > > > Some details > > > TESTS was never intended to be disabled by default. However, the > original patches that were committed months ago related to this > feature broke the build and the easiest way out (instead of reverting > the commits) was to set the knob to disabled. Unfortunately, it stayed > that way even after the discovered problems were fixed. > > I am confident enough now that we have ironed out all major issues > that this might introduce, so it is about time to enable TESTS by > default again in HEAD. > > The benefits of this are that 1) we allow end users (especially > consumers of binary releases!) to run the tests out of the box, as it > has always been intended; and 2) we will be able to run the official > release builds through testing via Jenkins, instead of having to issue > custom builds. > > Actual change: https://phabric.freebsd.org/D188 > > > I will update this thread when the change is committed and/or with any > updates. > > Please let me know if I'm missing anything. > > Cheers > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Julio, Awesome! I look forward to automated review lint checks that test for addition of tests, coverage++ and issue ID's in a changeset :] On a related note, how challenging might it be to generate and expose coverage metrics? This is not to say they are a perfect measure of anything in particular, but ought to provide us a good high level idea of important candidate areas that would benefit from coverage and don't currently. -- Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libressl anyone?
On 12/07/2014 10:16 AM, Michael W. Lucas wrote: > On Fri, Jul 11, 2014 at 04:12:42PM -0700, Kevin Oberman wrote: >> Now that OpenBSD has released LibreSSL, can someone port it? And maybe try >> putting it into head? I'd love to see OpenSSL gone yesterday. >> >> The initial portable LibreSSL is available from >> http://ftp.openbsd.org/pub/OpenBSD/LibreSSL. Note that the OpenBSD folks >> say that this release is intended for testing and evealuation, so it is not >> a candidate for any stable or release, but it does build on FreeBSD. >> >> Yes, if I get some time today or tomorrow, I'll try to write up a port, but >> I'm still far from comfortable with the new porting stuff, so it will >> likely take longer that I'd like. Others can probably knock it out in >> nothing flat. > > Check out the discussion on t...@openbsd.org. > > A fair amount of software is breaking with LibreSSL. For example, > LibreSSL dropped EGD support. Various software (eg Python) checks for > egd, and won't build without EGD. > > Mind you, people should certainly try it and see what happens. > > ==ml > Upstream Python / LibreSSL issue tracking making EGD support optional: http://bugs.python.org/issue21356 -- koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Light humour
On 30/04/2013 1:27 PM, Teske, Devin wrote: > > On Apr 29, 2013, at 8:24 PM, Peter Wemm wrote: > > On Mon, Apr 29, 2013 at 7:33 PM, Teske, Devin > mailto:devin.te...@fisglobal.com>> wrote: > > On Apr 29, 2013, at 2:53 PM, Robison, Dave wrote: > > http://news.netcraft.com/archives/2013/04/01/most-reliable-hosting-company-sites-in-march-2013.html > > > (obligatory) netcraft confirms it! > > (smiles) > > You don't need netcraft.. the tools are built in! > > http://www.youtube.com/watch?v=SXmv8quf_xM > > (Please, don't be drinking anything.. I disclaim all responsibility > for keyboard damage) > > > My favorite YouTube video on FreeBSD… > > http://www.youtube.com/watch?v=evZMVVb_lhs > > -- > Devin > > _ > The information contained in this message is proprietary and/or confidential. > If you are not the intended recipient, please: (i) delete the message and all > copies; (ii) do not disclose, distribute or use the message in any manner; > and (iii) notify the sender immediately. In addition, please be aware that > any message addressed to our domain is subject to archiving and review by > persons other than the intended recipient. Thank you. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > That's beautiful Devin, can we get an updated version of that to include -current rendered in HD (1080)? It's a wonderful piece that should be shared, nice work -koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 2:03 PM, Waitman Gobble wrote: > On Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble > wrote: >> >> On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov > >> wrote: >>> >>> >>> >>> You cannot even guess what is going on without a proper debug information. >>> Recompile and reinstall the libc/libthr/rtld with the debugging symbols >>> to get proper backtraces. >>> >>> Anyway, two backtraces you demostrated, although not giving much useful >>> data, look very different. More, the second backtrace suggests that >>> there is either a bug in python interposing of malloc or memory > corruption. >> >> >> Thanks so much for your help, I'll rebuild with debug on next. >> > > > Hello, > > Perhaps a better backtrace, from python2.7.core created when trying to install > www/midori > > #0 thr_kill () at thr_kill.S:3 > #1 0x000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > #2 0x00080464aca1 in free (mem=0x8065015b0) > at > /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350 > #3 0x000800e4c1af in _pthread_mutex_destroy (mutex= out>) > at /usr/src/lib/libthr/thread/thr_mutex.c:273 > #4 0x0008010e0def in closedir (dirp=0x803b2dda0) > at /usr/src/lib/libc/gen/closedir.c:65 > #5 0x0053d482 in posix_listdir (self=0x0, args=0x806425ae0) > at ./../Modules/posixmodule.c:2543 > #6 0x0057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0, > > kw=0x0) at ./../Objects/methodobject.c:81 > #7 0x004e40dd in call_function (pp_stack=0x7fff9388, oparg=1) > at ./../Python/ceval.c:4021 > #8 0x004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0) > at ./../Python/ceval.c:2666 > > snipped, complete backtrace at https://dx.burplex.com/backtrace.txt > > > all ports have been rebuilt, lib_pkgchk returns no missing libraries. > running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun 1 03:21:48 PDT 2013 > > It seems that any program using Python crashes. also, Seamonkey. I do not so > far notice > any other issues with this system. It was working great until an update about > a week ago. > > seamonkey > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x00080316b585 in XRE_InstallX11ErrorHandler () >from /usr/local/lib/seamonkey/libxul.so > #2 0x000800f75286 in handle_signal (actp=, sig=11, > > info=0x7fffb7f0, ucp=0x7fffb480) > at /usr/src/lib/libthr/thread/thr_sig.c:237 > #3 0x000800f74e89 in thr_sighandler (sig=11, info=, > > _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:182 > #4 0x71d3 in ?? () > #5 0x000800f74d70 in sigaction () > at /usr/src/lib/libthr/thread/thr_sig.c:574 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently asm > > > Thank you. I wonder if Pythons regression test picks anything up: ./python -m test.regrtest Run that in $WRKSRC/portbld.static/ after building ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 2:32 PM, Kubilay Kocak wrote: > I wonder if Pythons regression test picks anything up: > > ./python -m test.regrtest > > Run that in $WRKSRC/portbld.static/ after building Infact, run this instead: ./python -bb -E -Wd -m test.regrtest -r -w -uall [1] http://docs.python.org/devguide/runtests.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 2/06/2013 3:33 PM, Waitman Gobble wrote: > On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak > wrote: >> >> On 2/06/2013 2:32 PM, Kubilay Kocak wrote: >>> I wonder if Pythons regression test picks anything up: >>> >>> ./python -m test.regrtest >>> >>> Run that in $WRKSRC/portbld.static/ after building >> >> Infact, run this instead: >> >> ./python -bb -E -Wd -m test.regrtest -r -w -uall >> >> [1] http://docs.python.org/devguide/runtests.html >> > > Hi, > > Thanks for your reply, I appreciate it. > > Here are some errors.. > > > > [1053] > ./python -bb -E -Wd -m test.regrtest -r -w -uall > == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD > Clang 3.3 (trunk 178860)] > == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian > == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 > Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, > division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, > no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, > unicode=0, bytes_warning=2, hash_randomization=0) > Using random seed 1989961 > test_global > ... > test_rfc822 > test_file > test_decimal > Abort (core dumped) > > test_dis > test_memoryio > test_importhooks > test_netrc > test_univnewlines2k > test_codecencodings_tw > test_property > test_zipimport_support > : > /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: > Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" > Abort (core dumped) > > test_distutils > : > /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: > Failed assertion: "arena_mapbits_allocated_get(chunk, pageind) != 0" > Abort (core dumped) > > > test_threading > test test_threading failed -- Traceback (most recent call last): > File > "/usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py", line > 307, in test_finalize_runnning_thread > self.assertEqual(rc, 42) > AssertionError: -10 != 42 > > > > -- > Waitman Gobble > San Jose California USA > +1.5108307875 > > That last failure in test_threading I can reproduce on 10.0-CURRENT but I don't think its related. Those coredumps on the other hand. Incidentally, what OPTIONS did you build Python with? I ask cause WITH_PYMALLOC is the port and upstream default -- Ta, koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issue with libthr?
On 4/06/2013 2:54 AM, Waitman Gobble wrote:
> On Mon, 3 Jun 2013 07:55:54 -0700, Marcel Moolenaar wrote:
>
>>
>>
>> On Jun 2, 2013, at 8:08 AM, Waitman Gobble =
>> wrote:
>>
>>> On Sun, 2 Jun 2013 10:43:35 -0400, Mark Johnston =
>> wrote:=20
=20
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
> =20
> Hi,
> =20
> I'm getting a ton of core dumps from Python and any software that =
>> uses
>>> Python,
> ie has USE_PYTHON_BUILD=3Dyes in Makefile.
> =20
> hundreds of msgs in dmesg:
> pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped)
> pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped)
> =20
> from gdb it seems to me to be libthr related? I've noticed a couple =
>> updates
>>> in
> May.. wonder if it's related? I've only noticed this issue in the =
>> past
>>> week,
> after a complete rebuild and updated.
=20
I've been running into this issue too - python 2.7 would crash when
trying to rebuild databases/tdb and databases/py-sqlite3 with =
>> backtraces
similar to what you have below. The python port itself hasn't changed =
>> in
a while.
=20
Reverting r250991 and rebuilding libc solves the issue for me:
http://svnweb.freebsd.org/base?view=3Drevision&revision=3D250991
=20
> =20
>>> =20
>>> Thanks for the info, I appreciate it. I had a heck of a time getting
>>> database/py-sqlite3 to build as well.=20
>>> My workaround to get it installed was to change the Makefile in WRKSRC
>>
>>
>> Can you apply the following patch to /usr/ports/lang/python27, rebuild
>> python, re-install and then try to build databases/py-sqlite3 again?
>>
>> Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- files/patch-Modules-_ctypes-libffi-fficonfig.py.in (revision 0)
>> +++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in (working copy)
>> @@ -0,0 +1,10 @@
>> +--- Modules/_ctypes/libffi/fficonfig.py.in.orig 2013-06-03 =
>> 07:16:44.0 -0700
>> Modules/_ctypes/libffi/fficonfig.py.in 2013-06-03 =
>> 07:17:03.0 -0700
>> +@@ -1,7 +1,6 @@
>> + ffi_sources =3D """
>> + src/prep_cif.c
>> + src/closures.c
>> +-src/dlmalloc.c
>> + """.split()
>> +=20
>> + ffi_platforms =3D {
>>
>>
>> It seems the root cause is a broken python build that accidentally
>> defines malloc(), free(), at al in _ctypes.so. A longer explanation
>> was sent to svn-src-head@ and svn-src-all@
>>
>> I expect that the patch also fixes the other problems mentioned in
>> this thread. It would be great if people can verify this.
>>
>> FYI,
>>
>> --=20
>> Marcel Moolenaar
>> mar...@xcllnt.net
>>
>>
>>
>
>
> yes, that patch seems to work on my machine. After rebuilding Python with the
> patch, I was able to install databases/py-sqlite3 without error, also the
> www/midori port now builds and installs without crashing. I'll let you know if
> I see any problems.
>
> Thank you,
>
Great work Marcel :)
What needs to be done to get this upstreamed?
Koobs
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
I'm seeing what I believe is related panic, reliably being generated by the Python regression test suite on a newly created FreeBSD 10-CURRENT buildbot. Symptoms first seen in an freebsd.org FTP snapshot dated "Thu May 30 20:01:46 UTC 2013" and also reproducible on a freshly updated r252400 It is additionally reproducible after checking out pure upstream python sources, using the following steps: hg clone http://hg.python.org/cpython cd cpython && configure && make buildbottest An interesting possible correlation is that it seems to drop out during/around "test_socket" Backtrace below: > koobs@10-CURRENT-amd64:~ % sudo kgdb /boot/kernel/kernel /var/crash/vmcore.1 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: negative refcount 0xfe0009316de8 > cpuid = 0 > KDB: enter: panic > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > #0 doadump (textdump=114425856) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=114425856) at pcpu.h:236 > #1 0x80338a75 in db_fncall (dummy1=, > dummy2=, dummy3=, dummy4= optimized out>) > at /usr/src/sys/ddb/db_command.c:578 > #2 0x8033875d in db_command (cmd_table=) at > /usr/src/sys/ddb/db_command.c:449 > #3 0x803384d4 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:502 > #4 0x8033ae80 in db_trap (type=, code=0) at > /usr/src/sys/ddb/db_main.c:231 > #5 0x808ec1b3 in kdb_trap (type=3, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0x80c4cadb in trap (frame=0xff80978a7880) at > /usr/src/sys/amd64/amd64/trap.c:579 > #7 0x80c35ca2 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #8 0x808eb98e in kdb_enter (why=0x80f10487 "panic", > msg=) at cpufunc.h:63 > #9 0x808b5a76 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:747 > #10 0x808b5926 in kassert_panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:642 > #11 0x80875b4f in closef (fp=, td= optimized out>) at refcount.h:66 > #12 0x80873890 in closefp (fdp=0xfe0009652000, fd= optimized out>, fp=0xfe0009316dc0, td=0xfe0009337490, > holdleaders=) > at /usr/src/sys/kern/kern_descrip.c:1140 > #13 0x80c4d725 in amd64_syscall (td=0xfe0009337490, traced=0) at > subr_syscall.c:134 > #14 0x80c35f8b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #15 0x00080119b00a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) -- koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
On 1/07/2013 3:26 PM, Gleb Kurtsou wrote: > On (30/06/2013 13:18), Mateusz Guzik wrote: >> On Sun, Jun 30, 2013 at 05:21:42PM +1000, Kubilay Kocak wrote: >>> I'm seeing what I believe is related panic, reliably being generated by >>> the Python regression test suite on a newly created FreeBSD 10-CURRENT >>> buildbot. >>> >>> Symptoms first seen in an freebsd.org FTP snapshot dated "Thu May 30 >>> 20:01:46 UTC 2013" and also reproducible on a freshly updated r252400 >>> >>> It is additionally reproducible after checking out pure upstream python >>> sources, using the following steps: >>> >>> hg clone http://hg.python.org/cpython >>> cd cpython && configure && make buildbottest >>> >>> An interesting possible correlation is that it seems to drop out >>> during/around "test_socket" >>> >> >> Turns out the bug is quite funny ;) > > Patch fixes chrome for me. > > Thanks! > >> +1 Python regression test no longer cause a panic after applying this. Fantastic work Mateusz, thank you. -- Kubilay Kocak ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r333240 - in head/sys: powerpc/powerpc sys [appears to have broken the builds of head for riscv64]
On 7/05/2018 9:05 pm, loader wrote: > On Sun, 6 May 2018 19:33:34 -0700, Mark Millard > wrote: > >> Conrad Meyer cem at freebsd.org wrote on >> Sun May 6 22:32:13 UTC 2018, as part of a reply: >> >>> P.S., Mark, your email server is misconfigured and most/all of your >>> emails get flagged as spam. I only saw this because I occasionally >>> check the spam folder. >> >> I wrote back directly indicating that I'd need evidence >> in order to submit something to yahoo.com. Although, the >> original was not sent directly to Conrad, so he likely >> got the message directly from a freebsd-current server, >> with a yahoo.com's Email server as an intermediate stage. >> (I do not run my own servers.) The Email was composed >> in macOS's Mail.app [V11.3 (3445.6.18)]. >> >> Of course, that reply was likely classified as spam. >> >> If anyone else has such problems with the classification >> of my Emails and can send material that would allow >> reporting evidence to be submitted someplace, please do >> so. > > It seems the freebsd-current@ list doesn't have > from_is_list = 1 "Munge From" enabled ... > https://wiki.list.org/DEV/DMARC > > Regards, > loader > See Also: Mail forwarded from list to members fails DKIM/SPF/DMARC authentication https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210457 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: how to browse svnweb source?
On 29/05/2018 4:29 pm, Peter Jeremy wrote: On 2018-May-28 18:06:07 -0700, Jeffrey Bouquet wrote: Suddenly the site www.secnetix.de/olli/FreeBSD/svnews which showed sequential source as for example xx1966 on april 3 xx2040 on april 4 this year, is not loading in the browser. That site is not associated with the FreeBSD Project so you would need to discuss the absence of information on that site with whoever runs it. I tried that url every which way, sorting the headings, etc, and onscreen would be at best, a description of the new source but not specifically which files were changed and their complete path. Nothing like the url mentioned above at .de in the latter's overview. Without knowing what that site displayed, it's very difficult to know where (or if) svnweb provides the information. Given a known revision, you can check (eg) https://svnweb.freebsd.org/base?view=revision&revision=333926 If you want a sequential list of commits, you might be better off with (eg) https://lists.freebsd.org/pipermail/svn-src-all/ svnweb (ViewVC) has a "Revision Log" link to see commit logs for files, but paths also support it too. Unfortauntely there's just no link to it in the UI. Just append ?view=log to the URL, which will show you a commit log history, at that path. Eg: https://svnweb.freebsd.org/ports/head/?view=log ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Pkg repository is broken...
On 3/03/2020 4:58 am, marco wrote: On Sun, Mar 01, 2020 at 04:50:59PM -0500, you (Brennan Vincent) sent the following to [freebsd-current] : Apparently something has its ABI erroneously listed as FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64. ``` $ sudo pkg update -f Updating FreeBSD repository catalogue... Fetching meta.conf: 100%163 B 0.2kB/s00:01 Fetching packagesite.txz: 100%6 MiB 6.4MB/s00:01 Processing entries: 72% pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64 pkg: repository FreeBSD contains packages with wrong ABI: FreeBSD:13.0:amd64 Processing entries: 100% Unable to update repository FreeBSD Error updating repositories! ``` Ran into this very same problem today too. Just learned on #freebsd that the repos are temporarily borked and people are working hard to fix it. I even tried bootstrapping pkg like: env ABI=FreeBSD:13:amd64 pkg bootstrap -f (pkg 1.13.2 already installed) to no avail. Hoping things get sorted soon. Tacked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: anyone else seeing bind fail on recent -current?
On 16/04/2020 10:24 am, Michael Butler wrote: On 4/15/20 7:19 PM, Michael Butler wrote: This instance is/was running in a jail but now fails sometime after SVN r359823 .. I'm trying to bisect but any hints appreciated .. named[98746]: named[98746]: BIND 9 is maintained by Internet Systems Consortium, named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit named[98746]: corporation. Support and training for BIND 9 are named[98746]: available at https://www.isc.org/support named[98746]: named[98746]: command channel listening on 127.0.0.1#953 named[98746]: command channel listening on ::1#953 named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back trace named[98746]: #0 0x2cbb35 in ?? named[98746]: #1 0x4a7b4a in ?? named[98746]: #2 0x4bd297 in ?? named[98746]: #3 0x4c12a1 in ?? named[98746]: #4 0x8009f67f4 in ?? named[98746]: #5 0x8009f87b8 in ?? named[98746]: #6 0x8009e7e81 in ?? named[98746]: #7 0x4bb6e9 in ?? named[98746]: #8 0x800a15f39 in ?? named[98746]: exiting (due to assertion failure) root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named As it turns out, the update to devel/libuv on SVN r531786 causes this failure .. :-( Tracked at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245653 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: linking to git revisions in bugzilla
On 12/04/2021 9:02 am, Yuri Pankov wrote: While filing a bug, I noticed that the help only mentions svn revision numbers, and "Preview" tab had no output when I tried putting "base ", so I'm wondering how do you link to git revisions? We'll (bugmeister) be adding parsing support for it (along with a few other related auto-linking things) I'd encourage people to use " " (repo = src|doc|ports) where short hash is at least 8 chars in the meantime. Once parsing is added all previous references will be linked. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Help wanted: volunteer yourselves in .github/CODEOWNERS
On 31/05/2021 9:13 am, Alan Somers wrote: Strangers are submitting pull requests to our Github mirror, but we rarely pay attention. I just added a .github/CODEOWNERS file to our repo to automatically assign reviewers to PRs. I based it off of the contents of the current MAINTAINERS file. But it's incomplete. Please add yourself if: * You don't have a github account associated with your FreeBSD email address. I'm talking to you, adrian@, macklem@, and rrs@ . * You are part of a team, like secteam@ or re@ . You'll have to create the team at https://github.com/orgs/freebsd/teams then you can add it to the list. * You previously signed up for Phabricator notifications with Herald, but didn't sign up in MAINTAINERS. I can't see everybody's Phabricator assignments. * You never signed up in MAINTAINERS before, but you really ought to because you care deeply about some particular subsystem. -Alan Thanks for this Alan. Bugmeister is (and has been for a while) also keen to finally solve the problem of better getting the right eyes on patches submitted to Bugzilla for particular code areas, which complements other areas of improvements in issue management, such as more and clearer components in Bugzilla for people to use. Ports has an explicit MAINTAINER line we use to automatically auto-assign and CC issues, it would be great to use CODEOWNERS for this, along with appropriate consistently declared MAINTAINER lines in specific component directories and/or Makefiles. I think this is a good time to raise the difficult question/issue of policy/guidelines around code maintainership and responsibilities around that, including: - Having one or more maintainers of tree areas/components - Maintainer review, approval and timeouts - Issue triage/management
linker errors with WITH_UBSAN and WITH_ASAN
Hi,
I'm seeing the following linker errors when using WITH_UBSAN (without
WITH_ASAN) and WITH_ASAN (without WITH_UBSAN), having isolated other
variables in src.conf and src-env.conf (attached below):
--- ftpd.full ---
ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libmd.so: undefined
reference to _libmd_SHA256_Transform [--no-allow-shlib-undefined]
cc: error: linker command failed with exit code 1 (use -v to see invocation)
_ERROR_CMD='cc -target x86_64-unknown-freebsd14.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -march=sandybridge
-mtune=sandybridge -O2 -pipe -fcolor-diagnostics -fno-common
-march=sandybridge -DSETPROCTITLE -DLOGIN_CAP -DVIRTUAL_HOSTING
-I/usr/src/libexec/ftpd -Dmain=ls_main -I/usr/src/bin/ls -DUSE_BLACKLIST
-I/usr/src/contrib/blacklist/include -DINET6 -DUSE_PAM -fPIE
-fsanitize=address -fPIC -fsanitize-recover=address -fsanitize=undefined
-fsanitize-recover=undefined -g -gz=zlib -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Qunused-arguments
-L/usr/obj/usr/src/amd64.amd64/lib/libblacklist -pie -fsanitize=address
-fsanitize=undefined
-resource-dir=/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/clang/12.0.1
-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib/ clang/12.0.1/lib/freebsd
-o ftpd.full ftpd.o ftpcmd.o logwtmp.o popen.o ls.o cmp.o print.o util.o
blacklist.o -lcrypt -lxo -lutil -lopie -lmd -lm -lblacklist
-lpam ;'
I believe Kyle (cc'd) may have identified the cause of it ("applying
__attribute__((optnone)) to SHA256_Transform fixes it")
WITH_ASAN (without WITH_UBSAN), fails to link with the following errors:
--- all_subdir_usr.bin ---
--- all_subdir_usr.bin/clang/lldb ---
--- lldb.full ---
ld: error: undefined symbol:
lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&,
lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)
>>> referenced by memory:1265
(/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/memory:1265)
>>> ObjCLanguage.o:(void
std::__1::__call_once_proxy
>(void*)) in archive
/usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
ld: error: undefined symbol: lldb_private::AppleObjCRuntimeV2::Initialize()
>>> referenced by AppleObjCRuntime.cpp:60
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:60)
>>>
AppleObjCRuntime.o:(lldb_private::lldb_initialize_AppleObjCRuntime()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
>>> referenced by AppleObjCRuntime.cpp:60
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:60)
>>>
AppleObjCRuntime.o:(lldb_private::AppleObjCRuntime::Initialize()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
ld: error: undefined symbol: lldb_private::AppleObjCRuntimeV1::Initialize()
>>> referenced by AppleObjCRuntime.cpp:61
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:61)
>>>
AppleObjCRuntime.o:(lldb_private::lldb_initialize_AppleObjCRuntime()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
>>> referenced by AppleObjCRuntime.cpp:61
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:61)
>>>
AppleObjCRuntime.o:(lldb_private::AppleObjCRuntime::Initialize()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
ld: error: undefined symbol: lldb_private::AppleObjCRuntimeV2::Terminate()
>>> referenced by AppleObjCRuntime.cpp:65
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:65)
>>>
AppleObjCRuntime.o:(lldb_private::lldb_terminate_AppleObjCRuntime()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
>>> referenced by AppleObjCRuntime.cpp:65
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:65)
>>>
AppleObjCRuntime.o:(lldb_private::AppleObjCRuntime::Terminate()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
ld: error: undefined symbol: lldb_private::AppleObjCRuntimeV1::Terminate()
>>> referenced by AppleObjCRuntime.cpp:66
(/usr/src/contrib/llvm-project/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp:66)
>>>
AppleObjCRuntime.o:(lldb_private::lldb_terminate_AppleObjCRuntime()) in
archive /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a
>>> referenced by AppleObjCRuntime.cpp:66
(/usr/src/contrib/llvm-proje
Re: Call for participation
Yep +1 > On 3 Sep 2021, at 12:46 am, Warner Losh wrote: > > Greetings, > > As teased on twitter, now that summer is over, it's a good time to start > working on the next steps with git. When we moved to git, we knew a number > of things would come in phase 2 since phase 1 was limited to moving away > from subversion and to git. > > Now's the time for phase 2. The deferred items included better CI > pipelines, better integration with popular hosting sites like github and > gitlab, a look at the tools we have today and how they fit together, and a > bunch of other items that were less well defined. I've spent the last > several months looking at the different practices in open source, > looking at our tools, etc. We have bits and pieces of many of these items, > but are missing some glue between what we have. Other areas need more > extensive work. > > To coordinate this work, I'll be leading a team to look at what we can do > in the short term, the medium term and where we think we want to be in the > long term. I plan on having bi-weekly meetings to discuss different issues > that come up, to coordinate work and experiments and to give some structure > to encouragement for progress to be made. > > This will be a collaborative effort between the developers and the user > community that contributes patches to any part of FreeBSD (the base, ports > and docs). If you are interested in participating, please drop me a line. > We'll have a core office hours to talk about this soon, and I'd like to > start discussions with those that are interested before hand, as well as > invite people to participate in the office hours. After that, we'll have a > kick off meeting that's open to everybody who can respectfully contribute. > > Looking forward to hearing from you. > > Warner
Re: Call for participation
No firm dates yet, we’ll make sure everyone has ample time ahead of, and communicate session schedules when determined > On 4 Sep 2021, at 12:59 am, Shawn Webb wrote: > > On Thu, Sep 02, 2021 at 08:43:21AM -0600, Warner Losh wrote: >> Greetings, >> >> As teased on twitter, now that summer is over, it's a good time to start >> working on the next steps with git. When we moved to git, we knew a number >> of things would come in phase 2 since phase 1 was limited to moving away >> from subversion and to git. >> >> Now's the time for phase 2. The deferred items included better CI >> pipelines, better integration with popular hosting sites like github and >> gitlab, a look at the tools we have today and how they fit together, and a >> bunch of other items that were less well defined. I've spent the last >> several months looking at the different practices in open source, >> looking at our tools, etc. We have bits and pieces of many of these items, >> but are missing some glue between what we have. Other areas need more >> extensive work. >> >> To coordinate this work, I'll be leading a team to look at what we can do >> in the short term, the medium term and where we think we want to be in the >> long term. I plan on having bi-weekly meetings to discuss different issues >> that come up, to coordinate work and experiments and to give some structure >> to encouragement for progress to be made. >> >> This will be a collaborative effort between the developers and the user >> community that contributes patches to any part of FreeBSD (the base, ports >> and docs). If you are interested in participating, please drop me a line. >> We'll have a core office hours to talk about this soon, and I'd like to >> start discussions with those that are interested before hand, as well as >> invite people to participate in the office hours. After that, we'll have a >> kick off meeting that's open to everybody who can respectfully contribute. >> >> Looking forward to hearing from you. > > Hey Warner, > > I'd be happy to talk about HardenedBSD's switch from GitHub to Gitea > and finally to GitLab. We had a lot of troubles with Gitea and ended > up with GitLab. > > When are you thinking of holding that meeting? > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
Re: Deprecate and remove publickey(5) stuff
On 16/12/2021 3:55 am, Emmanuel Vadot wrote: Hello, it's me again, I've posted some review some time ago but didn't follow up with some mail so users might see it. I'd like to remove publickey(5) related programs, those are the only DES users iirc and likely unused. https://reviews.freebsd.org/D30682 https://reviews.freebsd.org/D30683 I'll commit this in two weeks unless there is some valid argument to keep this. Cheers, We may not want to list every single deprecation, but: https://wiki.freebsd.org/DeprecationPlan
