Memory modified after free Kernel panic with current (r278031)
Hallo, I'm still fighting with MinnowBoard... When I set the network interface I get a bunch of Memory modified after free messages. If I wait long enough (a couple of minutes) I get a kernel panic. Here an example with the dmesg (https://pastebin.mozilla.org/8657938) I've tested it using 10.1-STABLE, same messages after ifconfig, but the kernel panic is different. Here a verbose example of it (https://pastebin.mozilla.org/8658082) On 10, I see really often the value 0x3201c040 causing segmentation fault (!), but I don't know where it comes from. I'm still debugging it, but it could be that the init procedure of re(4) cannot correctly stop the device (a normal Realtek 8168) and the dma address are rewritten by receiving packets. Has someone some tip/ideas? thanks in advance for the help Best regards, pizzamig ___ 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
LOCAL_MTREE vs DB_FROM_SRC
(Apologies for google mail, I moved a while back and my office at home is
still not up and hence my regular FreeBSD machine at home is also not up.)
In Makefile.inc1 we have:
.if defined(DB_FROM_SRC)
INSTALLFLAGS+= -N ${.CURDIR}/etc
MTREEFLAGS+= -N ${.CURDIR}/etc
.endif
which is fine as far as it goes, but then if ${LOCAL_MTREE} is defined we
have this:
.for _mtree in ${LOCAL_MTREE}
mtree -deU -f ${.CURDIR}/${_mtree} -p ${WORLDTMP} /dev/null
.endfor
which omits the -N flag, even with DB_FROM_SRC set. This means if a local
mtree file wants user and/or group names that are not on your build
system, but are in the new (but not yet installed anywhere) master.passwd
and/or group files, the build fails when prepping the worldtmp area. Seems
like this should be mtree ${MTREEFLAGS} ..., shouldn't it?
Chris
___
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: nagios vs w/uptime
On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... -- Marcel Moolenaar mar...@xcllnt.net ___ 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: nagios vs w/uptime
On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). -- Marcel Moolenaar mar...@xcllnt.net ___ 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 ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #672
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/672/ ___ 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: nagios vs w/uptime
On Tue, 2015-02-10 at 22:24 +0100, Michael Gmelin wrote: On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). I wonder if that implies that any non-normal exit from a program that has been xo'd will result in the loss of output that would not have been lost before the xo changes? That could lead to all kinds of subtle failures of existing scripts and apps. -- Ian ___ 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: nagios vs w/uptime
I wonder if that implies that any non-normal exit from a program that has been xo'd will result in the loss of output that would not have been lost before the xo changes? That could lead to all kinds of subtle failures of existing scripts and apps. Well, so long as the app doesn't crash in a way that would bypass it shouldn't registering that with atexit() flush any pending output? -K ___ 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: nagios vs w/uptime
On Tue, 10 Feb 2015 22:24:59 +0100 Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). I opened a code review request: https://reviews.freebsd.org/D1821 -- Michael Gmelin ___ 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
[ZFS] [panic] Fatal trap 12: page fault while in kernel mode.
I do not know the conditions - it just happened. http://pastebin.com/BASJB599 ___ 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
nagios vs w/uptime
[Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven’t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #675
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/675/ ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #674
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/674/ ___ 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: [RFC] Removin the old make
On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. How does this affect non-system Makefiles that depend on pmake? Is bmake completely upward compatible? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgp_RZIFijEsv.pgp Description: PGP signature
Re: [RFC] Removin the old make
On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. How does this affect non-system Makefiles that depend on pmake? Is bmake completely upward compatible? There are very few issues, not that fmake is available from ports, I think 99% of the compatibility are preserved I know about a couple of incompatibilities that are bothering me in ports (for the infrastructure) but I would say this is very much a corner case Bapt pgpx_C4PWzPwI.pgp Description: PGP signature
[RFC] Removin the old make
Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. Note that bmake is the default since FreeBSD 10. FreeBSD 9.3 is also providing bmake (as bmake) on default installation. Best regards, Bapt pgpLzfnuGT6oy.pgp Description: PGP signature
Re: [RFC] Removin the old make
On Tue, Feb 10, 2015 at 04:04:16PM -0700, Ian Lepore wrote: On Tue, 2015-02-10 at 23:59 +0100, Baptiste Daroussin wrote: On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. How does this affect non-system Makefiles that depend on pmake? Is bmake completely upward compatible? There are very few issues, not that fmake is available from ports, I think 99% of the compatibility are preserved I know about a couple of incompatibilities that are bothering me in ports (for the infrastructure) but I would say this is very much a corner case Bapt By far the biggest incompatibility I've run into is the change from :U and :L to :tu and :tl, mostly because any existing makefiles that contain :U or :L variable modifiers just silently do the wrong thing under bmake. It's especially annoying because :L is really common in fmake and its meaning in bmake is all but useless. Ah yes I forgot that one :) which is the reason why I have blocked migration to bmake for a while :) Still fmake is available via ports so might not be a problem Best regards, Bapt pgp_NXinKGWCc.pgp Description: PGP signature
Re: [RFC] Removin the old make
On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin b...@freebsd.org wrote Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. Please note; I am not expressing any objection to it's removal. But would a 30-day window not be a more friendly. So as to better accommodate those whom will need to make the/a transition? --Chris Note that bmake is the default since FreeBSD 10. FreeBSD 9.3 is also providing bmake (as bmake) on default installation. Best regards, Bapt ___ 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: nagios vs w/uptime
On Tue, Feb 10, 2015 at 02:32:44PM -0700, Ian Lepore wrote: On Tue, 2015-02-10 at 22:24 +0100, Michael Gmelin wrote: On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? Seems most likely, although I haven?t seen any differences in output in my (admittedly limited) testing. In what way does Nagios not like w/uptime? Any concrete errors, output or misbehavior? Ideally: can you reproduce the problem? Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). I wonder if that implies that any non-normal exit from a program that has been xo'd will result in the loss of output that would not have been lost before the xo changes? That could lead to all kinds of subtle failures of existing scripts and apps. I suspect that for most programs with more than a few exit points, adding an atexit() registration to call xo_finish() is going to be a good odea. -- Brooks pgpX0Tdut1MhO.pgp Description: PGP signature
Re: [RFC] Removin the old make
On Tue, 2015-02-10 at 23:59 +0100, Baptiste Daroussin wrote: On Wed, Feb 11, 2015 at 09:49:37AM +1100, Greg 'groggy' Lehey wrote: On Tuesday, 10 February 2015 at 23:38:54 +0100, Baptiste Daroussin wrote: Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. How does this affect non-system Makefiles that depend on pmake? Is bmake completely upward compatible? There are very few issues, not that fmake is available from ports, I think 99% of the compatibility are preserved I know about a couple of incompatibilities that are bothering me in ports (for the infrastructure) but I would say this is very much a corner case Bapt By far the biggest incompatibility I've run into is the change from :U and :L to :tu and :tl, mostly because any existing makefiles that contain :U or :L variable modifiers just silently do the wrong thing under bmake. It's especially annoying because :L is really common in fmake and its meaning in bmake is all but useless. -- Ian ___ 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
Jenkins build is unstable: FreeBSD_HEAD-tests2 #671
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/671/ ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #673
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/673/ ___ 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
Build failed in Jenkins: FreeBSD_HEAD-tests2 #670
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/670/ -- [...truncated 1016 lines...] lib/atf/libatf-c/macros_test:require_errno - passed [0.034s] lib/atf/libatf-c/macros_test:require_match - passed [0.041s] lib/atf/libatf-c/macros_test:require_streq - passed [0.055s] lib/atf/libatf-c/macros_test:use - passed [0.071s] lib/atf/libatf-c/tc_test:config - passed [0.015s] lib/atf/libatf-c/tc_test:init - passed [0.014s] lib/atf/libatf-c/tc_test:init_pack - passed [0.014s] lib/atf/libatf-c/tc_test:vars - passed [0.015s] lib/atf/libatf-c/tp_test:getopt - passed [0.015s] lib/atf/libatf-c/utils_test:cat_file__empty - passed [0.016s] lib/atf/libatf-c/utils_test:cat_file__no_newline_eof - passed [0.018s] lib/atf/libatf-c/utils_test:cat_file__one_line - passed [0.018s] lib/atf/libatf-c/utils_test:cat_file__several_lines - passed [0.018s] lib/atf/libatf-c/utils_test:compare_file__empty__match - passed [0.017s] lib/atf/libatf-c/utils_test:compare_file__empty__not_match - passed [0.017s] lib/atf/libatf-c/utils_test:compare_file__long__match - passed [0.017s] lib/atf/libatf-c/utils_test:compare_file__long__not_match - passed [0.016s] lib/atf/libatf-c/utils_test:compare_file__short__match - passed [0.016s] lib/atf/libatf-c/utils_test:compare_file__short__not_match - passed [0.017s] lib/atf/libatf-c/utils_test:copy_file__empty - passed [0.017s] lib/atf/libatf-c/utils_test:copy_file__some_contents - passed [0.020s] lib/atf/libatf-c/utils_test:create_file - passed [0.016s] lib/atf/libatf-c/utils_test:file_exists - passed [0.018s] lib/atf/libatf-c/utils_test:fork - passed [0.021s] lib/atf/libatf-c/utils_test:free_charpp__empty - passed [0.015s] lib/atf/libatf-c/utils_test:free_charpp__some - passed [0.017s] lib/atf/libatf-c/utils_test:grep_file - passed [0.020s] lib/atf/libatf-c/utils_test:grep_string - passed [0.016s] lib/atf/libatf-c/utils_test:readline__none - passed [0.015s] lib/atf/libatf-c/utils_test:readline__some - passed [0.020s] lib/atf/libatf-c/utils_test:redirect__other - passed [0.019s] lib/atf/libatf-c/utils_test:redirect__stderr - passed [0.018s] lib/atf/libatf-c/utils_test:redirect__stdout - passed [0.020s] lib/atf/libatf-c/utils_test:wait__invalid_exitstatus - passed [0.020s] lib/atf/libatf-c/utils_test:wait__invalid_stderr - passed [0.023s] lib/atf/libatf-c/utils_test:wait__invalid_stdout - passed [0.023s] lib/atf/libatf-c/utils_test:wait__ok - passed [0.021s] lib/atf/libatf-c/utils_test:wait__ok_nested - passed [0.024s] lib/atf/libatf-c/utils_test:wait__save_stderr - passed [0.022s] lib/atf/libatf-c/utils_test:wait__save_stdout - passed [0.064s] lib/atf/libatf-c/detail/dynstr_test:append_ap - passed [0.081s] lib/atf/libatf-c/detail/dynstr_test:append_fmt - passed [0.081s] lib/atf/libatf-c/detail/dynstr_test:clear - passed [0.017s] lib/atf/libatf-c/detail/dynstr_test:copy - passed [0.017s] lib/atf/libatf-c/detail/dynstr_test:cstring - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:equal_cstring - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:equal_dynstr - passed [0.016s] lib/atf/libatf-c/detail/dynstr_test:fini_disown - passed [0.016s] lib/atf/libatf-c/detail/dynstr_test:init - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:init_ap - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:init_fmt - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:init_raw - passed [0.014s] lib/atf/libatf-c/detail/dynstr_test:init_rep - passed [0.077s] lib/atf/libatf-c/detail/dynstr_test:init_substr - passed [0.015s] lib/atf/libatf-c/detail/dynstr_test:length - passed [0.062s] lib/atf/libatf-c/detail/dynstr_test:prepend_ap - passed [0.081s] lib/atf/libatf-c/detail/dynstr_test:prepend_fmt - passed [0.078s] lib/atf/libatf-c/detail/dynstr_test:rfind_ch - passed [0.015s] lib/atf/libatf-c/detail/env_test:get - passed [0.015s] lib/atf/libatf-c/detail/env_test:get_with_default - passed [0.014s] lib/atf/libatf-c/detail/env_test:has - passed [0.015s] lib/atf/libatf-c/detail/env_test:set - passed [0.014s] lib/atf/libatf-c/detail/env_test:unset - passed [0.015s] lib/atf/libatf-c/detail/fs_test:eaccess - passed [0.017s] lib/atf/libatf-c/detail/fs_test:exists - passed [5.689s] lib/atf/libatf-c/detail/fs_test:getcwd - passed [0.197s] lib/atf/libatf-c/detail/fs_test:mkdtemp_err - passed [0.138s] lib/atf/libatf-c/detail/fs_test:mkdtemp_ok - passed [0.136s] lib/atf/libatf-c/detail/fs_test:mkdtemp_umask - passed [0.017s] lib/atf/libatf-c/detail/fs_test:mkstemp_err - passed [0.126s] lib/atf/libatf-c/detail/fs_test:mkstemp_ok - passed [0.018s] lib/atf/libatf-c/detail/fs_test:mkstemp_umask - passed [0.017s] lib/atf/libatf-c/detail/fs_test:path_append - passed [0.017s] lib/atf/libatf-c/detail/fs_test:path_branch_path - passed [0.017s]
Re: [RFC] Removin the old make
On Tue, Feb 10, 2015 at 03:13:29PM -0800, Chris H wrote: On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin b...@freebsd.org wrote Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. Please note; I am not expressing any objection to it's removal. But would a 30-day window not be a more friendly. So as to better accommodate those whom will need to make the/a transition? What transition, since 10.0 noone have fmake by default anymore? if one want to keep using fmake he has to explicitly state it when building. Not that I'm against a 30-day windows but that does not seems worth it. Best regards, Bapt pgpqXT4WP4T50.pgp Description: PGP signature
Re: nagios vs w/uptime
On Tue, Feb 10, 2015 at 10:24:59PM +0100, Michael Gmelin wrote: On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: Just compared 10.1 to current, unmodified output looks the same, but pipelines don't work properly: 10.1: # uptime | wc 1 12 68 Current: # uptime | wc 0 0 0 # uptime | cat # uptime 10:16PM up 9 mins... Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). % man xo_finish ... Calling this function is vital to the proper operation of libxo, especially for the non-TEXT output styles. ... Note, the word vital is underlined in xterm for emphasis. PS: To whomever is responsible for libxo, some (most?) libxo manpages have the wrong NAME information. For example, % man xo_finish LIBXO(3) FreeBSD Library Functions Manual LIBXO(3) NAME xo_emit - emit formatted output based on format string and arguments % man xo_attr LIBXO(3) FreeBSD Library Functions Manual LIBXO(3) NAME xo_emit - emit formatted output based on format string and arguments % man xo_create LIBXO(3) FreeBSD Library Functions Manual LIBXO(3) NAME xo_emit - emit formatted output based on format string and arguments -- Steve ___ 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: [RFC] Removin the old make
On Wed, 11 Feb 2015 00:20:05 +0100 Baptiste Daroussin b...@freebsd.org wrote On Tue, Feb 10, 2015 at 03:13:29PM -0800, Chris H wrote: On Tue, 10 Feb 2015 23:38:54 +0100 Baptiste Daroussin b...@freebsd.org wrote Hi, I would like to start using bmake only syntax on our infrastructure for that I want to make sure noone is using the old make, so I plan to remove the old make from base, I plan to do it by Feb 16th. Please note; I am not expressing any objection to it's removal. But would a 30-day window not be a more friendly. So as to better accommodate those whom will need to make the/a transition? What transition, since 10.0 noone have fmake by default anymore? if one want to keep using fmake he has to explicitly state it when building. Ahh. Sure. In all honesty, it was probably more of a knee jerk reaction on my part, when I noticed it was only a week away. :) Not that I'm against a 30-day windows but that does not seems worth it. Best regards, Bapt --Chris -- ___ 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: nagios vs w/uptime
On Tue, 2015-02-10 at 22:55 +, Brooks Davis wrote: On Tue, Feb 10, 2015 at 02:32:44PM -0700, Ian Lepore wrote: On Tue, 2015-02-10 at 22:24 +0100, Michael Gmelin wrote: On 10 Feb 2015, at 22:17, Michael Gmelin gre...@freebsd.org wrote: On 10 Feb 2015, at 21:13, Marcel Moolenaar mar...@xcllnt.net wrote: [Moving to current@] On Feb 10, 2015, at 11:52 AM, Peter Wemm pe...@wemm.org wrote: Surprises: * nagios doesn't like w / uptime anymore. libxo perhaps? [...] Adding xo_finish() to w.c line 268 just right before exit(0); fixes that issue (I don't know libxo well enough to say if this is the proper fix or just a workaround, but it seems logical to me). I wonder if that implies that any non-normal exit from a program that has been xo'd will result in the loss of output that would not have been lost before the xo changes? That could lead to all kinds of subtle failures of existing scripts and apps. I suspect that for most programs with more than a few exit points, adding an atexit() registration to call xo_finish() is going to be a good odea. I assume there is some sort of xo_start() call if there's an xo_finish(), so the library could do that for itself? -- Ian ___ 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
