FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/ucommon | 6.1.11 | 6.3.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
current/ports/security/nss (fwd)
Hi po...@freebsd.org current/ports/security/nss is broken. How to fix it ? PS I first asked via Makefile MAINTAINER= address freebsd-ge...@freebsd.org but no reply, (list swamped in noise from freebsd.org robots). http://lists.freebsd.org/pipermail/freebsd-gecko/2015-March/005233.html To: ge...@freebsd.org Date: Sun, 22 Mar 2015 16:01:01 +0100 Anyone else see this or know the fix ?: (with a fresh current ports/ & /var/db/ports ) cd /usr/ports/www/firefox ; make .. ../../../dist/FreeBSD11.0_OPT.OBJ/lib/libnss3.so: undefined reference to `PR_htons' cc: error: linker command failed with exit code 1 (use -v to see invocation) ../../coreconf/rules.mk:245: recipe for target 'FreeBSD11.0_OPT.OBJ/addbuiltin' failed gmake[6]: *** [FreeBSD11.0_OPT.OBJ/addbuiltin] Error 1 gmake[6]: Leaving directory '/1s4/release/11.0-CURRENT/usr/ports/security/nss/work/nss-3.17.4/nss/cmd/addbuiltin' ../coreconf/rules.mk:104: recipe for target 'libs' failed gmake[5]: *** [libs] Error 2 gmake[5]: Leaving directory '/1s4/release/11.0-CURRENT/usr/ports/security/nss/work/nss-3.17.4/nss/cmd' coreconf/rules.mk:104: recipe for target 'libs' failed gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory '/1s4/release/11.0-CURRENT/usr/ports/security/nss/work/nss-3.17.4/nss' *** Error code 1 Stop. make[3]: stopped in /1s4/release/11.0-CURRENT/usr/ports/security/nss Cheers, Julian - -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
I want to tell pkg to just forget about an installed port
Hello, How can I tell pkg to completely forget about an installed port, without deleting it? Specifically, I installed net-mgmt/observium a couple of months ago. I really like it and have paid for a subscription so what is currently on disk is mostly *not* what was installed by the port, so I'd like to tell pkg to forget about it. Thanks! - Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
cad/openscad fails to build on 9.3/i386
Hello. I'm trying to upgrade OpensCAD to 2015.03, which was committed yesterday. However it fails to build. Following is the log. # make ===> License GPLv2 accepted by the user ===> openscad-2015.03 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by openscad-2015.03 for building ===> Extracting for openscad-2015.03 => SHA256 Checksum OK for openscad-2015.03.src.tar.gz. ===> Patching for openscad-2015.03 /usr/bin/sed -i.bak -e 's,share/man,man,' /tmp/usr/ports/cad/openscad/work/openscad-2015.03/openscad.pro ===> openscad-2015.03 depends on file: /usr/local/bin/flex - found ===> openscad-2015.03 depends on file: /usr/local/libdata/pkgconfig/eigen3.pc - found ===> openscad-2015.03 depends on file: /usr/local/include/boost/tuple/tuple.hpp - found ===> openscad-2015.03 depends on executable: msgfmt - found ===> openscad-2015.03 depends on executable: bison - found ===> openscad-2015.03 depends on executable: update-desktop-database - found ===> openscad-2015.03 depends on executable: pkgconf - found ===> openscad-2015.03 depends on file: /usr/local/libdata/pkgconfig/glproto.pc - found ===> openscad-2015.03 depends on file: /usr/local/libdata/pkgconfig/dri2proto.pc - found ===> openscad-2015.03 depends on file: /usr/local/lib/qt4/libQtCore.so - found ===> openscad-2015.03 depends on file: /usr/local/lib/qt4/libQtGui.so - found ===> openscad-2015.03 depends on file: /usr/local/bin/moc-qt4 - found ===> openscad-2015.03 depends on file: /usr/local/lib/qt4/libQtOpenGL.so - found ===> openscad-2015.03 depends on file: /usr/local/bin/qmake-qt4 - found ===> openscad-2015.03 depends on file: /usr/local/bin/rcc - found ===> openscad-2015.03 depends on file: /usr/local/bin/uic-qt4 - found ===> openscad-2015.03 depends on shared library: libgmp.so - found (/usr/local/lib/libgmp.so.10.1.3) ===> openscad-2015.03 depends on shared library: libmpfr.so - found (/usr/local/lib/libmpfr.so.4.1.2) ===> openscad-2015.03 depends on shared library: libCGAL.so - found (/usr/local/lib/libCGAL.so.10) ===> openscad-2015.03 depends on shared library: libqscintilla2.so - found (/usr/local/lib/qt4/libqscintilla2.so.11.3.0) ===> openscad-2015.03 depends on shared library: libharfbuzz.so - found (/usr/local/lib/libharfbuzz.so.0.936.0) ===> openscad-2015.03 depends on shared library: libopencsg.so - found (/usr/local/lib/libopencsg.so.1.3.2) ===> openscad-2015.03 depends on shared library: libGLU.so - found (/usr/local/lib/libGLU.so.1.3.1) ===> openscad-2015.03 depends on shared library: libGLEW.so - found (/usr/local/lib/libGLEW.so.1) ===> Configuring for openscad-2015.03 Project MESSAGE: If you're building a development binary, consider adding CONFIG+=experimental Project MESSAGE: User set EIGEN location: /usr/local/include/eigen3 ===> Building for openscad-2015.03 /usr/local/bin/moc-qt4 -DOPENSCAD_VERSION=2015.03 -DOPENSCAD_YEAR=2015.0 -DOPENSCAD_MONTH=03.0 -DOPENSCAD_DAY=.0 -DENABLE_CGAL -DENABLE_OPENCSG -DUSE_SCINTILLA_EDITOR -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/eigen3 -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4 -Isrc -I/usr/local/include/qt4 -Isrc/libtess2/Include -I/usr/local/include -Iobjects -I/usr/local/include/qt4 -I/usr/local/include src/Dock.h -o objects/moc_Dock.cpp /usr/local/bin/uic-qt4 src/MainWindow.ui -o objects/ui_MainWindow.h -tr _ /usr/local/bin/moc-qt4 -DOPENSCAD_VERSION=2015.03 -DOPENSCAD_YEAR=2015.0 -DOPENSCAD_MONTH=03.0 -DOPENSCAD_DAY=.0 -DENABLE_CGAL -DENABLE_OPENCSG -DUSE_SCINTILLA_EDITOR -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/eigen3 -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4 -Isrc -I/usr/local/include/qt4 -Isrc/libtess2/Include -I/usr/local/include -Iobjects -I/usr/local/include/qt4 -I/usr/local/include src/QGLView.h -o objects/moc_QGLView.cpp /usr/local/bin/uic-qt4 src/Preferences.ui -o objects/ui_Preferences.h -tr _ /usr/local/bin/uic-qt4 src/OpenCSGWarningDialog.ui -o objects/ui_OpenCSGWarningDialog.h -tr _ /usr/local/bin/uic-qt4 src/AboutDialog.ui -o objects/ui_AboutDialog.h -tr _ /usr/local/bin/uic-qt4 src/FontListDialog.ui -o objects/ui_FontListDialog.h -tr _ /usr/local/bin/moc-qt4 -DOPENSCAD_VERSION=2015.03 -DOPENSCAD_YEAR=2015.0 -DOPENSCAD_MONTH=03.0 -DOPENSCAD_DAY=.0 -DENABLE_CGAL -DENABLE_OPENCSG -DUSE_SCINTILLA_EDITOR -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/eigen3 -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4 -Isrc -I/usr/local/include/qt4 -Isrc/libtess2/I
Re: I want to tell pkg to just forget about an installed port
On Fri, 27 Mar 2015 09:41:21 -0400 Richard Kuhns wrote > Hello, > > How can I tell pkg to completely forget about an installed port, without > deleting it? > > Specifically, I installed net-mgmt/observium a couple of months ago. I > really like it and have paid for a subscription so what is currently on > disk is mostly *not* what was installed by the port, so I'd like to tell > pkg to forget about it. You're most probably interested in: lock see pkg(8) for details on how, and where to set this option (command). --Chris > > Thanks! > > - > Richard Kuhns Main Number: 765-742-8428 > Wintek Corporation Direct: 765-269-8541 > 427 N 6th Street Internet Support: 765-269-8503 > Lafayette, IN 47901-2211 Consulting: 765-269-8504 > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fwd: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598
About the below Miacheal Tuexen wrote back:
> I guess there is something wrong with the build system / Makefiles such that
> the entries in the search path for include files are in the wrong order. I
> don't think this is related to the concrete patch you are referring to. It
> only exposes the problem. As I see, you experience similar problems in other
> situations to.
>
> Maybe someone knowing the build system has to look into it. And it seems to
> be somewhat platform specific, since I have not observed this problem when
> testing the build on amd64 and arm.
>
> Best regards
> Michael
===
Mark Millard
markmi at dsl-only.net
Begin forwarded message:
From: Mark Millard
Subject: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859
vs. updating to head snaphot -r280598
Date: 2015-March-26 at 07:36:01 PM PDT
Cc: FreeBSD PowerPC ML
To: freebsd-curr...@freebsd.org, tue...@freebsd.org
Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc powerpc64 1100062 1100062
The problem:
Summary of the details that are listed later. Both of the following exist:
/usr/src/sys/netinet/sctp.h
/usr/include/netinet/sctp.h
The first can be newer than the 2nd during buildworld.
The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an updated
/usr/src can/does end up using the second instead of the first, at least for
the powerpc64-xtoolchain-gcc style of buildworld activity that I am trying.
The recent addition of SCTP_MAX_CWND ends up with its definition missing
because of this: during the build /usr/include/netinet/sctp.h ends up being the
file included and the compile fails from the missing additional definition.
Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the command
line arguments should force the /usr/src/sys/netinet/sctp.h vintage file to be
found. The 3 netinet/ relevant includes are shown below...
> ...
> #include
> #include
> #include
> #include
More than sctp.h might have such issues since there are 3 netinet/ include
paths in /head/lib/libc/net/sctp_sys_calls.c .
I have not checked for other .c files with similar issues for
usage during buildworld.
The problem details:
/head/lib/libc/net/sctp_sys_calls.c -r279859 added:
> case SCTP_MAX_CWND:
> ((struct sctp_assoc_value *)arg)->assoc_id = id;
> break;
and head (20150325 r280598) contains it.
But the SCTP_MAX_CWND reference blocks buildworld (for at least
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc (powerpc64-xtoolchain=gcc)
use):
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 -pipe
> -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include
> -I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE
> -I/usr/src/lib/libc/../../contrib/gdtoa
> -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6
> -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
> -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd
> -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION
> -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime
> -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN
> -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING
> -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Wall
> -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c
> /usr/src/lib/libc/net/sctp_sys_calls.c -o sctp_sys_calls.So
>
> /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info':
> /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND'
> undeclared (first use in this function)
> case SCTP_MAX_CWND:
^
Looking to see where usage and definitions might be in /usr/src for -r280598 ...
> # pwd
> /usr/src
> $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep
> SCTP_MAX_CWND {} \; -print \) | more
>case SCTP_MAX_CWND:
> ./lib/libc/net/sctp_sys_calls.c
>case SCTP_MAX_CWND:
>case SCTP_MAX_CWND:
> ./sys/netinet/sctp_usrreq.c
> #define SCTP_MAX_CWND 0x0032
> ./sys/netinet/sctp.h
And looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c for
-r279859 shows:
> #include
> __FBSDID("$FreeBSD$");
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
That there was no complaint about sctp.h being missing suggests that a
was found but did not contain a SCTP_MAX_CWND definition: so a
different one than the above find/grep reported.
Using a find to report other sctp.h files shows:
> # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h -print
> \) | more
> /usr/src/sys/netinet/sctp.h
> /usr/include/netinet/sctp.h
The diff of those shows the
Re: I want to tell pkg to just forget about an installed port
On Fri, Mar 27, 2015, at 08:41, Richard Kuhns wrote: > Hello, > > How can I tell pkg to completely forget about an installed port, without > deleting it? > > Specifically, I installed net-mgmt/observium a couple of months ago. I > really like it and have paid for a subscription so what is currently on > disk is mostly *not* what was installed by the port, so I'd like to tell > pkg to forget about it. > Why not just move /usr/local/www/observium out of the way, pkg delete observium, and then move it back? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: mc-4.8.14
Dear maintainer:
I tried to upgrade well working mc-4.8.13_3 to mc-4.8.14 on FreeBSD 9.3 (AMD64)
with subshell using the port misc/mc. My shell is 'bash'.
The result was:
1. Very long start-up time
2. Subshell not working (has not read ~/.bashrc).
Following patch resolved the situation:
==
--- src/subshell.c.orig
+++ src/subshell.c
@@ -874,8 +874,7 @@
{
case BASH:
g_snprintf (precmd, sizeof (precmd),
-" PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND;
}'pwd>&%d;kill -STOP $$'\n",
-subshell_pipe[WRITE]);
+" PROMPT_COMMAND='pwd>&%d;kill -STOP $$'\n",
subshell_pipe[WRITE]);
break;
case ZSH:
===
The output of 'mc -V' is
GNU Midnight Commander 4.8.14
Built with GLib 2.42.2
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
Please analyse the reasons and try to update the port.
Best regards
Jiri Lazansky
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fwd: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs. updating to head snaphot -r280598
About the below Ian Lepore wrote:
> This and the other similar reports on current@ appear to be problems
> with the xtoolchain ports, not the base build system, and probably
> should have been reported to the port's maintainer, or on ports@. Or
> perhaps it's some sort of usage error, I don't know anything about the
> xtoolchain stuff. In any case, there doesn't seem to be anything wrong
> with the base build using the supported build mechanisms.
===
Mark Millard
markmi at dsl-only.net
Begin forwarded message:
Subject: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs.
updating to head snaphot -r280598
From: Mark Millard
Date: 2015-March-26 at 09:15:46 PM PDT
Cc: FreeBSD PowerPC ML
To: freebsd-curr...@freebsd.org, Ian Lepore
Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc powerpc64 1100062 1100062
The problem:
Summary of the details that are listed later. Both of the following exist:
/usr/src/sys/sys/sbuf.h
/usr/include/sys/sbuf.h
The first can be newer than the 2nd during buildworld.
The buildworld compile of /head/sys/kern/subr_sbuf.c from an updated /usr/src
can/does end up using the second instead of the first, at least for the
powerpc64-xtoolchain-gcc style of buildworld activity that I am trying.
The recent addition of SBUF_INCLUDENUL use ends up with its definition missing
because of this: during the build /usr/include/sys/sbuf.h ends up being the
file included and the compile fails from the missing additional definition.
Either the #include paths in /head/sys/kern/subr_sbuf.c or the command line
arguments should force the /usr/src/sys/sys/sbuf.h vintage file to be found.
The /head/sys/kern/subr_sbuf.c relevant includes are shown below...
> #include
> __FBSDID("$FreeBSD: head/sys/kern/subr_sbuf.c 280193 2015-03-17 21:00:31Z ian
> $");
>
> #include
>
> #ifdef _KERNEL
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #else /* _KERNEL */
> #include
> #include
> #include
> #include
> #include
> #include
> #endif /* _KERNEL */
>
> #include
I have not checked for other .c files with similar issues for
usage during buildworld.
The problem details:
/head/sys/kern/subr_sbuf.c -r280193 added:
> #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL)
and head (20150325 r280598) contains it.
But the SBUF_INCLUDENUL reference blocks buildworld (for at least
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc (powerpc64-xtoolchain=gcc)
use):
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 -pipe
> -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-pro
> totypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
> -Wnested-externs -Wredundant-decls -Wold-style-definition
> -Wno-pointer-sign -c /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c -o
> subr_sbuf.So
> ...
> /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c:73:45: error:
> 'SBUF_INCLUDENUL' undeclared (first use in this function)
> #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL)
> ^
Looking to see where SBUF_INCLUDENUL usage and definitions might be in /usr/src
for -r280598 ...
> # pwd
> /usr/src
> # find . \( -type d -name .svn -prune \) -or \( -type f -exec grep
> SBUF_INCLUDENUL {} \; -print \) | more
> .It Dv SBUF_INCLUDENUL
> ./share/man/man9/sbuf.9
> #define SBUF_INCLUDENUL 0x0002 /* nulterm byte is counted in len */
> ./sys/sys/sbuf.h
>sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL);
> ./sys/vm/uma_core.c
>SBUF_INCLUDENUL);
> ./sys/netinet/tcp_hostcache.c
>sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL);
> ./sys/kern/kern_malloc.c
>SBUF_INCLUDENUL);
> ./sys/kern/kern_cons.c
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
> ./sys/kern/kern_descrip.c
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
>sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
> ./sys/kern/kern_proc.c
>sbuf_new(&sb, NULL, 256, SBUF_AUTOEXTEND | SBUF_INCLUDENUL);
> ./sys/kern/kern_et.c
>sbuf_new(&sb, NULL, 128, SBUF_AUTOEXTEND | SBUF_INCLUDENUL);
> ./sys/kern/kern_fail.c
>s = sbuf_new(s, buf, length, SBUF_FIXEDLEN | SBUF_INCLUDENUL);
> ./sys/kern/kern_sysctl.c
> #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL)
> ./sys/kern/subr_sbuf.c
Looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c for
-r280193 shows:
> #include
> __FBSDID("$FreeB
FreeBSD Port: security/py-kerberos
Hello, Why does security/py-kerberos require security/krb5? I ask because we already have Kerberos in base. Why do we need two installations of Kerberos? I'm confused. :/ I ask because I just added security/py-requests-kerberos to the tree. — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
> On Mar 27, 2015, at 5:36 PM, Roland van Laar wrote: > > On 27-03-15 21:11, Dan Langille wrote: >> Hello, >> >> Why does security/py-kerberos require security/krb5? >> >> I ask because we already have Kerberos in base. Why do we need two >> installations of Kerberos? >> >> I'm confused. :/ >> >> I ask because I just added security/py-requests-kerberos to the tree. > > py-kerberos depends on gssapi/gssapi_generic.h. > This file isn't included in the base kerberos, but it is in the security/krb5 > port. I see. So we need it only for compiling, not for running? I want to avoid having two Kerberos installed on the server. :) — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
On 27-03-15 21:11, Dan Langille wrote: Hello, Why does security/py-kerberos require security/krb5? I ask because we already have Kerberos in base. Why do we need two installations of Kerberos? I'm confused. :/ I ask because I just added security/py-requests-kerberos to the tree. py-kerberos depends on gssapi/gssapi_generic.h. This file isn't included in the base kerberos, but it is in the security/krb5 port. Regards, Roland — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
> On Mar 27, 2015, at 5:58 PM, Roland van Laar wrote: > > On 27-03-15 22:56, Roland van Laar wrote: >> On 27-03-15 22:39, Dan Langille wrote: On Mar 27, 2015, at 5:36 PM, Roland van Laar wrote: On 27-03-15 21:11, Dan Langille wrote: > Hello, > > Why does security/py-kerberos require security/krb5? > > I ask because we already have Kerberos in base. Why do we need two > installations of Kerberos? > > I'm confused. :/ > > I ask because I just added security/py-requests-kerberos to the tree. py-kerberos depends on gssapi/gssapi_generic.h. This file isn't included in the base kerberos, but it is in the security/krb5 port. >>> I see. >>> >>> So we need it only for compiling, not for running? >> ;-) I haven't tried running it without the krb5 package. > The resulting python module is: kerberos.so. > Which actually depends on libkrb5support.so from security/krb5 > See: > > # ldd ./kerberos.so > ./kerberos.so: >libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x801606000) >libgssapi_krb5.so => /usr/local/lib/libgssapi_krb5.so (0x8019c1000) >libkrb5.so => /usr/local/lib/libkrb5.so (0x801c08000) >libk5crypto.so => /usr/local/lib/libk5crypto.so (0x801ee8000) >libcom_err.so => /usr/local/lib/libcom_err.so (0x802117000) >libc.so.7 => /lib/libc.so.7 (0x80081f000) >libthr.so.3 => /lib/libthr.so.3 (0x80231a000) >libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80253f000) >libutil.so.9 => /lib/libutil.so.9 (0x802748000) >libm.so.5 => /lib/libm.so.5 (0x80295a000) >libkrb5support.so => /usr/local/lib/libkrb5support.so (0x802b82000) That looks like what I found on my server after installing. >>> I want to avoid having two Kerberos installed on the server. :) I wonder why it needs security/krb5 and can't use Kerberos from base. It seems odd to me... — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
On 27-03-15 22:39, Dan Langille wrote: On Mar 27, 2015, at 5:36 PM, Roland van Laar wrote: On 27-03-15 21:11, Dan Langille wrote: Hello, Why does security/py-kerberos require security/krb5? I ask because we already have Kerberos in base. Why do we need two installations of Kerberos? I'm confused. :/ I ask because I just added security/py-requests-kerberos to the tree. py-kerberos depends on gssapi/gssapi_generic.h. This file isn't included in the base kerberos, but it is in the security/krb5 port. I see. So we need it only for compiling, not for running? ;-) I haven't tried running it without the krb5 package. I want to avoid having two Kerberos installed on the server. :) — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
On 27-03-15 22:56, Roland van Laar wrote: On 27-03-15 22:39, Dan Langille wrote: On Mar 27, 2015, at 5:36 PM, Roland van Laar wrote: On 27-03-15 21:11, Dan Langille wrote: Hello, Why does security/py-kerberos require security/krb5? I ask because we already have Kerberos in base. Why do we need two installations of Kerberos? I'm confused. :/ I ask because I just added security/py-requests-kerberos to the tree. py-kerberos depends on gssapi/gssapi_generic.h. This file isn't included in the base kerberos, but it is in the security/krb5 port. I see. So we need it only for compiling, not for running? ;-) I haven't tried running it without the krb5 package. The resulting python module is: kerberos.so. Which actually depends on libkrb5support.so from security/krb5 See: # ldd ./kerberos.so ./kerberos.so: libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x801606000) libgssapi_krb5.so => /usr/local/lib/libgssapi_krb5.so (0x8019c1000) libkrb5.so => /usr/local/lib/libkrb5.so (0x801c08000) libk5crypto.so => /usr/local/lib/libk5crypto.so (0x801ee8000) libcom_err.so => /usr/local/lib/libcom_err.so (0x802117000) libc.so.7 => /lib/libc.so.7 (0x80081f000) libthr.so.3 => /lib/libthr.so.3 (0x80231a000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80253f000) libutil.so.9 => /lib/libutil.so.9 (0x802748000) libm.so.5 => /lib/libm.so.5 (0x80295a000) libkrb5support.so => /usr/local/lib/libkrb5support.so (0x802b82000) I want to avoid having two Kerberos installed on the server. :) — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: security/py-kerberos
On 27-03-15 23:02, Dan Langille wrote: On Mar 27, 2015, at 5:58 PM, Roland van Laar wrote: On 27-03-15 22:56, Roland van Laar wrote: On 27-03-15 22:39, Dan Langille wrote: On Mar 27, 2015, at 5:36 PM, Roland van Laar wrote: On 27-03-15 21:11, Dan Langille wrote: Hello, Why does security/py-kerberos require security/krb5? I ask because we already have Kerberos in base. Why do we need two installations of Kerberos? I'm confused. :/ I ask because I just added security/py-requests-kerberos to the tree. py-kerberos depends on gssapi/gssapi_generic.h. This file isn't included in the base kerberos, but it is in the security/krb5 port. I see. So we need it only for compiling, not for running? ;-) I haven't tried running it without the krb5 package. The resulting python module is: kerberos.so. Which actually depends on libkrb5support.so from security/krb5 See: # ldd ./kerberos.so ./kerberos.so: libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x801606000) libgssapi_krb5.so => /usr/local/lib/libgssapi_krb5.so (0x8019c1000) libkrb5.so => /usr/local/lib/libkrb5.so (0x801c08000) libk5crypto.so => /usr/local/lib/libk5crypto.so (0x801ee8000) libcom_err.so => /usr/local/lib/libcom_err.so (0x802117000) libc.so.7 => /lib/libc.so.7 (0x80081f000) libthr.so.3 => /lib/libthr.so.3 (0x80231a000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80253f000) libutil.so.9 => /lib/libutil.so.9 (0x802748000) libm.so.5 => /lib/libm.so.5 (0x80295a000) libkrb5support.so => /usr/local/lib/libkrb5support.so (0x802b82000) That looks like what I found on my server after installing. I want to avoid having two Kerberos installed on the server. :) I wonder why it needs security/krb5 and can't use Kerberos from base. It seems odd to me... In what way is it odd? The base kerberos is a different one than the MIT one. py-kerberos is developed by Apple for their calendarserver software and I think they just used the MIT implementation. — Dan Langille http://langille.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How could I increase "runaway" timer for package build cluster?
On 3/7/2015 3:43 PM, Lev Serebryakov wrote: > > One of my ports (devel/gcc-arm-embedded) doesn't produce much output > on build (output is redirected to log files), but takes severa hours > to be built. > > Looks like pkg building cluster doesn't like such behavior. > > Could I notify build cluster (poudrere?) that this package takes a > lot of time without output? > Well, consider the user's perspective too. "Is anything actually happening?" Can you modify it to produce output? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
