Breakage with sys.kern.ptrace_test.{ptrace__parent_sees_exit_after_child_debugger, parent_sees_exit_after_unrelated_debugger} after r325719:325721

[Ngie Cooper (yaneurabeya)]

Hi Mateusz,
Per Jenkins, these two tests are broken after r325719:325721: 
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4987/ 
 .
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

"make universe" broken by r325697

[Ngie Cooper (yaneurabeya)]

Per Jenkins: https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/5391/ .
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 29, 2017, at 10:26, Kevin Oberman  wrote:

…

> But I thought that all modern wireless interfaces and many others load blobs. 
> Is the source for the firmware blob for iwn (which is in GENERIC)  available?

There’s a piece that’s open sourced that a BSD developer has written, 
but there’s also a binary payload that we have no insight into.
Cheers,
-Ngie

$ file sys/contrib/dev/iwm/*.uu
sys/contrib/dev/iwm/iwm-3160-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7260-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8265-22.fw.uu:  uuencoded or xxencoded, ASCII text


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 29, 2017, at 02:46, Thomas Mueller  wrote:

…

> Is that binary blob the reason why rsu is not in GENERIC?
> 
> I use rsu for Hiro H50191 USB wireless adapter.

Yup.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 28, 2017, at 18:09, Gordon Tetlow  wrote:
> 
> I have an Intel NUC that uses an Intel 8260 wireless driver. This works
> flawlessly if I load the module if_iwm via the loader or the rc.conf
> kld_list directive.
> 
> Do we know if the iwm driver not being in GENERIC is an oversight or on
> purpose? I couldn't find anything in the list history.

It’s on purpose since it has a binary blob firmware driver that it relies on, 
IIRC.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

r324870 breaks boot on amd64 with WITNESS (was "svn commit: r324870 - in head/sys: amd64/include kern")

[Ngie Cooper (yaneurabeya)]

All,
I highly advise not upgrading to this revision if you use WITNESS. 
Please see the attached message for more details and reply to the commit log.
Cheers,
-Ngie

> Begin forwarded message:
> 
> From: "Ngie Cooper (yaneurabeya)" 
> Subject: Re: svn commit: r324870 - in head/sys: amd64/include kern
> Date: October 22, 2017 at 17:19:32 PDT
> To: Mateusz Guzik 
> Cc: src-committers , svn-src-...@freebsd.org, 
> svn-src-h...@freebsd.org
> 
> 
>> On Oct 22, 2017, at 13:43, Mateusz Guzik  wrote:
>> 
>> Author: mjg
>> Date: Sun Oct 22 20:43:50 2017
>> New Revision: 324870
>> URL: https://svnweb.freebsd.org/changeset/base/324870
>> 
>> Log:
>> Make the sleepq chain hash size configurable per-arch and bump on amd64.
>> 
>> While here cache-align chains.
>> 
>> This shortens longest found chain during poudriere -j 80 from 32 to 16.
>> 
>> Pushing this higher up will probably require allocation on boot.
> 
> Hi Mateusz,
>   This change causes the Jenkins VMs to panic at boot with "panic: 
> witness_init: pending locks list is too small, increase WITNESS_PENDLIST” 
> when WITNESS is enabled: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4781/console .
>   Please fix or revert.
> Thanks,
> -Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BSD awk bug ?

[Ngie Cooper (yaneurabeya)]

> On Aug 15, 2017, at 20:15, KIRIYAMA Kazuhiko  wrote:
> 
> At Wed, 16 Aug 2017 10:36:36 +0900,
> Tomoya Tabuchi wrote:
>> 
>> On Wed, Aug 16, 2017 at 10:14:46AM +0900, KIRIYAMA Kazuhiko wrote:
>>> admin@tbedfpc:~/tmp % ll
>>> total 12
>>> -rw-r--r--  1 admin  admin  235 Aug 16 10:01 regex-1.sh
>>> -rw-r--r--  1 admin  admin  236 Aug 16 10:01 regex-2.sh
>>> -rw-r--r--  1 admin  admin  260 Aug 16 10:01 regex.sh
>>> admin@tbedfpc:~/tmp % cat regex.sh
>>> #!/bin/sh
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> IFS=$'\n'
>>> for datum in $data; do
>>>if echo "$datum" | egrep -q  '^([^[:space:]]+[[:space:]]+){5}'; then
>>>echo "$datum"
>>>else
>>>echo "Not 6 components! : \"$datum\""
>>>fi
>>> done
>>> admin@tbedfpc:~/tmp % sh ./regex.sh
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4 5"
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % cat regex-1.sh
>>> #!/bin/sh
>>> 
>>> _f_awk='
>>> {
>>>if ($0 ~ /^([^[:space:]]+[[:space:]]+){5}/) {
>>>print $0
>>>} else {
>>>print "Not 6 components! : \"" $0 "\""
>>>}
>>> }'
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> echo "$data" | awk "$_f_awk"
>>> admin@tbedfpc:~/tmp % sh ./regex-1.sh
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4 5"
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % cat regex-2.sh
>>> #!/bin/sh
>>> 
>>> _f_awk='
>>> {
>>>if ($0 ~ /^([^[:space:]]+[[:space:]]+){5}/) {
>>>print $0
>>>} else {
>>>print "Not 6 components! : \"" $0 "\""
>>>}
>>> }'
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> echo "$data" | gawk "$_f_awk"
>>> admin@tbedfpc:~/tmp % sh ./regex-2.sh
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4 5"
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % uname -a
>>> FreeBSD tbedfpc 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r321597: Thu Jul 27 
>>> 12:30:57 UTC 2017 root@tbedfc:/usr/obj/usr/src/sys/GENERIC  amd64
>>> admin@tbedfpc:~/tmp % pkg info -aI|grep gawk
>>> gawk-4.1.4_1   GNU version of Awk
>>> admin@tbedfpc:~/tmp %
>>> 
>>> 
>>> Is this the BSD awk (/usr/bin/awk) bug ?
>> 
>> Hello Kiriyama-san,
>> 
>> The man page awk(1) says that {m,n} matcning is not supported. The "{5}"
>> part matches the literal sequence of characters it's made out of, I suppose.
> 
> Oops. I missed "STANDARDS" section. Thanks for pointed out.
> 
> # But as it says in front "awk supports extended regular
> # expressions (EREs).  See re_format(7) for more information
> # on regular expressions.", I'd like to coinside with
> # re_format(7) spec.

Hello Kiriyama-san,
I asked this same question a while back and was told that the {n} form 
didn’t work with nawk. I’ll have to dig up the exact post if it’s somewhere 
public.
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 14:57, Ian Lepore  wrote:

…

> The thanks seem appropriate enough, given the tone and content of your
> previous emails.  What's missing is the very-much-required apology.

I don’t need an apology, I just hope/ask for a bit more patience next 
time. I’ve made similar claims out of surprise and frustration in the past, so 
I’m equally guilty of the same/similar tone.
Take care,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 13:47, Julian H. Stacey  wrote:
> 
> Hi, Reference:
>> From:"Julian H. Stacey" 
>> Date:Sun, 06 Aug 2017 22:25:02 +0200
> 
> "Julian H. Stacey" wrote:
> The half baked mod. to src/libexec/Makefile could be backed out
>> 
>> I was wrong, sorry, code is not half baked, cos further down I spotted :
>>  .if ${MK_RCMDS} != "no"
>>  _rlogind=   rlogind
>>  _rshd=  rshd
>>  .endif
>> 
>> cd /usr/src; find . -type f | xargs grep MK_RCMDS | grep -v Makefile:
>>  ./tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_RCMDS} == no
>> 
>> I'm reading that while make world continues.
> 
> Finaly found it, after guessing some shell might roll MK_RCMDS from
> a list including RCMDS, & finding man src.conf with WITH_RCMDS
> Took me a while to find.  Thanks Ngie for your time.

Hi Julian,
Oh, ok.
Yes, the default for MK_RCMDS was changed recently from on to off. 
UPDATING also mentions it.
You must have upgraded from a major version to another recently or over 
a several month period — MK_* has been enhanced quite a bit over the past few 
months to “better respect optional features”. I left things on by default for 
POLA sake, but you’re free to remove them as need be. The defaults may change 
in the future (as you discovered with MK_RCMDS).
Cheers,
-Ngie

$ svn blame ^/head/share/mk/src.opts.mk | grep RCMDS
320530jlh RCMDS \
$ svn log -c 320530 ^/

r320530 | jlh | 2017-07-01 03:04:42 -0700 (Sat, 01 Jul 2017) | 12 lines

Disable RCMDS by default.

This was announced in this thread:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html

Applying plan proposed by ngie@ in:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018249.html

The port has been submitted as net/bsdrcmds in r444814.

Approved by:bapt, roberto, and others


$ grep -n 20170701 -A 2 UPDATING
66:20170701:
67- WITHOUT_RCMDS is now the default. Set WITH_RCMDS if you need them to be
68- built with the base system.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 09:36, Julian H. Stacey  wrote:
> 
> Hi freebsd-current@freebsd.org
> with current src
>   .ctm_status src-cur 13120
>   .svn_revision322111
> libexec/Makefile has been butchered, eg
> rshd & other builds silently omitted
> unless one debugs & learns to do eg
>   setenv _rshd Something
> A find & grep of src/ shows no other ref. to _rshd except
>   ./libexec/Makefile: ${_rshd} \
>   ./libexec/Makefile:_rshd=   rshd
> 
> I sampled _pppoed same error !
>   ./libexec/Makefile: ${_pppoed} \
>   ./libexec/Makefile:_pppoed= pppoed
> 
> Others turned off are:
>${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>\ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
> 
> If src/ annoyingly insists to force everyone to silently Not build src/,
> there should at least be some switch & reference doc in eg
>   src/share/mk
>   src/share/man/man5/src.conf

Julian,
Could you please post your build error (in its entirety) somewhere?
Thank you,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 09:54, Ngie Cooper (yaneurabeya)  
> wrote:
> 
>> 
>> On Aug 6, 2017, at 09:36, Julian H. Stacey  wrote:
>> 
>> Hi freebsd-current@freebsd.org
>> with current src
>>  .ctm_status src-cur 13120
>>  .svn_revision322111
>> libexec/Makefile has been butchered, eg
>> rshd & other builds silently omitted
>> unless one debugs & learns to do eg
>>  setenv _rshd Something
>> A find & grep of src/ shows no other ref. to _rshd except
>>  ./libexec/Makefile: ${_rshd} \
>>  ./libexec/Makefile:_rshd=   rshd
>> 
>> I sampled _pppoed same error !
>>  ./libexec/Makefile: ${_pppoed} \
>>  ./libexec/Makefile:_pppoed= pppoed
>> 
>> Others turned off are:
>>   ${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>>   ${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>>   \ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>>   ${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
>> 
>> If src/ annoyingly insists to force everyone to silently Not build src/,
>> there should at least be some switch & reference doc in eg
>>  src/share/mk
>>  src/share/man/man5/src.conf
> 
> Julian,
>   Could you please post your build error (in its entirety) somewhere?
> Thank you,

Also, please provide your make.conf and src.conf.
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper (yaneurabeya)]

> On Aug 1, 2017, at 09:21, John Baldwin  wrote:
> 
> On Tuesday, August 01, 2017 09:47:41 AM Andriy Gapon wrote:
>> On 01/08/2017 02:31, Ngie Cooper wrote:
>>> Hi,
>>> I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
>>> didn’t work because abd_is_linear is an undefined symbol (it exists in 
>>> sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
>>> sys/modules/zfs/Makefile and it didn’t immediately fix my compilation 
>>> problem (ran into a linker error instead).
>>> If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
>>> problem.
>> 
>> I am not sure what exact problem you have...
>> abd.c should be added to the list of source files via
>> .include "${SUNW}/uts/common/Makefile.files"
>> 
>> Perhaps something to do with "inline"...
> 
> Oh, yes.  If you use -fno-inline-funcs or the like.  I forgot to
> send this to Andriy earlier, but here is the fix I'm using:
> 
> https://github.com/freebsd/freebsd/commit/574dc95cf8272e16f6d44aff6cb4e08dede08886

Unfortunately… this is head, verbatim, which means that the bug still 
exists.
This gives me an idea of where I should look though.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: tools/tools/zfsboottest doesn't compile on ^/head

[Ngie Cooper (yaneurabeya)]

> On Jul 31, 2017, at 16:39, Ngie Cooper (yaneurabeya)  
> wrote:

…

>   The declaration for putchar is not ANSI compliant either — which is 
> probably another fun hurdle that someone’s going to have to deal with in 
> terms of fixing sys/boot and lib stand.

I fixed the prototypes in r321849. I’m running a tinderbox build that 
will fix the prototype of printf/*putchar to be more POSIX-conformant.
Thanks,
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper (yaneurabeya)]

> On Jul 31, 2017, at 16:31, Ngie Cooper  wrote:
> 
> Hi,
>   I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
> didn’t work because abd_is_linear is an undefined symbol (it exists in 
> sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
> sys/modules/zfs/Makefile and it didn’t immediately fix my compilation problem 
> (ran into a linker error instead).
>   If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
> problem.

(Resending to fix my sending email address)
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: tools/tools/zfsboottest doesn't compile on ^/head

[Ngie Cooper (yaneurabeya)]

> On Jul 31, 2017, at 16:21, Ngie Cooper  wrote:
> 
> Hi,
>   It looks like zfsboottest no longer compiles on ^/head (guessing it has 
> to do with the clang upgrade).
>   If someone doesn’t fix this build breakage in the next few hours, I’ll 
> take a stab at fixing it.
> Thanks,
> -Ngie
> 
> PS zfsboottest should really be compiled with world if MK_ZFS != no.
> 
> $ (cd tools/tools/zfsboottest/; make obj; make)
> cc  -O1  -I/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs  
> -I/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs  -I.  
> -fdiagnostics-show-option  -W -Wextra -Wno-sign-compare -Wno-unused-parameter 
> -m32   -g --coverage -MD  -MF.depend.zfsboottest.o -MTzfsboottest.o 
> -std=gnu99 -fstack-protector-strong-Qunused-arguments  -c 
> /usr/src/tools/tools/zfsboottest/zfsboottest.c -o zfsboottest.o
> In file included from /usr/src/tools/tools/zfsboottest/zfsboottest.c:56:
> /usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:797:9: 
> error: returning 'void' from a function with incompatible result type 'int'
>return (pager_output(line));
>   ^~~~
> /usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:2356:17: 
> warning: array index 264 is past the end of the array (which contains 192 
> elements) [-Warray-bounds]
>memcpy(path, &dn->dn_bonus[sizeof(znode_phys_t)], psize);
>  ^
> /usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs/zfsimpl.h:910:2: 
> note: array 'dn_bonus' declared here
>uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)];
>^
> 1 warning and 1 error generated.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/tools/tools/zfsboottest
> 
> 157873imp void
> 157873imp printf(const char *fmt,…)
> 104679phk static void printf(const char *,...);

The declaration for putchar is not ANSI compliant either — which is 
probably another fun hurdle that someone’s going to have to deal with in terms 
of fixing sys/boot and libstand.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Compiler more strict on 12 with r320337 ?

[Ngie Cooper (yaneurabeya)]

> On Jun 26, 2017, at 23:31, Kurt Jaeger  wrote:
> 
> Hi!
> 
> Compiling devel/lfcbase, it fails while including sys/socketvar.h with
> this error:
> 
> In file included from Net.cc:36:
> /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
>  anonymous struct
>enum {
>^
> 1 error generated.
> 
> Should sys/socketvar.h be included at all ?

Hi Kurt,
What compiler/CFLAGS (in particular, -std=) are you using to 
compile devel/lfcbase?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old syslog (jail) and new kernel = 100% CPU

[Ngie Cooper (yaneurabeya)]

> On Jun 5, 2017, at 08:20, Bryan Drewery  wrote:
> 
> On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
>> 
>> Quoting Bryan Drewery  (from Sun, 4 Jun 2017 14:38:07
>> -0700):
>> 
>>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
 Hi,
 
 new kernel (surely r318877 and later) and old syslog in a jail = NOK.
 
>>> 
>>> What branch and revision is the syslogd? From my understanding the bug
>>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
>>> not released.  If it was MFC'd we need to fix it before the 11.1 release.
>> 
>> This was a syslogd from head for sure.
>> 
>> So the issue was that for an intermediate period of time a bug was in
>> syslogd in head which was causing this, and if I would have upgraded a
>> system were the jail would have been head from before the or after the
>> bug, then I wouldn't have noticed it?
>> 
> 
> Yes, that's my understanding.  So it's ultimately a non-issue for
> releases since it is just a temporary issue on head.

Yes. syslogd was refactored on ^/head. Some of the refactoring caused the issue 
Alexander brought up. The changes were never backported though, so the concern 
you had in the previous message isn’t something to be worried about, since the 
code hasn’t seen the changes the ^/head copy has.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r318757 - head

[Ngie Cooper (yaneurabeya)]

> On May 24, 2017, at 11:10, O. Hartmann  wrote:
> 
> Am Wed, 24 May 2017 13:04:30 -0500
> Larry Rosenman  schrieb:

…

> I use the traditional "make" way (via portmaster)

There were some reports about needing to do “make clean” before “make 
install”. Memory serves me correctly there are ways in portmaster to bypass 
“make clean” before running “make install”. Could you please provide your 
portmasterrc file?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 11:01, Beeblebrox  wrote:
> 
>> I was looking at the "make: Unknown modifier ‘c’” warnings — which
>> were a symptom of the bug that was fixed late last week. I don’t
>> genuinely know if ccache works or doesn’t work. Thanks, -Ngie
> 
> Thanks,
> I still do see those exact "make: Unknown modifier ‘c’” warnings
> along with the original fail.

More up-to-date information would help someone trying to diagnose your issue. 
Based on the original report, you are currently using sources from April 20th, 
which means that you would be affected by the bmake bug.

Would you please execute the following and attach your output?

$ make -VMAKE_VERSION
20170510

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 10:46, Beeblebrox  wrote:
> 
>> Upgrade make — it was a bug with it, fixed in the past few days.
>> HTH,
> 
> I just rebuilt and installed a clean world without using ccache
> After reboot I tried buildworld with ccache enabled, but got same error.
> 
> So, did not work unless you meant a particular port?

I was looking at the "make: Unknown modifier ‘c’” warnings — which were a 
symptom of the bug that was fixed late last week. I don’t genuinely know if 
ccache works or doesn’t work.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 01:20, Beeblebrox  wrote:
> 
> I have been getting ccache errors during buildworld. Ports for example does 
> not have this problem. I compleely reset the cache data some 2 months ago and 
> ccache seemed to play with that much more nicely.
> 
> Apart from the error below, I'm also getting some "cc not found" errors when 
> doing src stuff, whether ccache is enabled or not. For example installworld 
> (no ccache) broke with that message so I decided to re-build.
> 
> uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 2017
> 
> /etc/make.conf
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
> CXX:=${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1}
> 
> ls /usr/local/libexec/ccache/world/
> c++   CCclang clang++40 g++5
> ccccacheclang++   clang40   gcc5
> 
> # make buildworld =>
> make: Unknown modifier 'c'
> make: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> --
 World build started
> .
 stage 1.2: bootstrap tools
> --
> cd /asp/git/src; MAKEOBJDIRPREFIX=/asp/obj/asp/git/src/tmp  INSTALL="sh 
> /asp/git/src/tools/install.sh"  TOOLS_PREFIX=/asp/obj/asp/git/src/tmp  
> PATH=/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/legacy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>   WORLDTMP=/asp/obj/asp/git/src/tmp  MAKEFLAGS="-m 
> /asp/git/src/tools/build/mk  -m /asp/git/src/share/mk" make  -f Makefile.inc1 
>  DESTDIR=  BOOTSTRAPPING=1200030  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes 
> MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no 
> MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no  
> MK_INCLUDES=yes bootstrap-tools
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> ===> lib/clang/libllvmminimal (obj,all,install)
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> -O2 -pipe -I/asp/git/src/lib/clang/include 
> -I/asp/git/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DDEFAULT_SYSROOT=\"/asp/obj/asp/git/src/tmp\" -ffunction-sections 
> -fdata-sections -DNDEBUG -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o 
> -Qunused-arguments -I/asp/obj/asp/git/src/tmp/legacy/usr/include -std=c++11 
> -fno-exceptions -fno-rtti  -stdlib=libc++ -Wno-c++11-extensions  -c 
> /asp/git/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
> /bin/sh: -O2: not found
> *** Error code 127

Upgrade make — it was a bug with it, fixed in the past few days.
HTH,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 11:05, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya)  
>> wrote:
>> 
>> Hi,
>>  I’ve been noticing some really weird behavior with terminal input after 
>> updating my kernel/userland — in particular, if I do `arc diff —create` 
>> (which opens vi/vim), and try to do edits/use ^c, it will terminate the 
>> running process for `arc diff —create`. Similarly, I was seeing really weird 
>> input via vim (when doing `svn ci`) where if I had one of the editing modes 
>> on, like insert, it would delete several lines at once; I worked around this 
>> by using ^c to terminate insert mode, but that’s a really bad hack. It 
>> worked ok with r316745, got worse in r317727, and doesn’t seem to be any 
>> better in r318250.
> 
> I forgot to mention: I’m using SSH to access my machine.

My gut feeling is the sc(4) commits might have tickled or introduced some bugs. 
I’ll try reverting the following commits over the next couple days to see 
whether or not my experience improves: r316827 r316830 r316865 r316878 r316974 
r316977 r317190 r317198 r317199 r317245 r317256 r317264.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I’ve been noticing some really weird behavior with terminal input after 
> updating my kernel/userland — in particular, if I do `arc diff —create` 
> (which opens vi/vim), and try to do edits/use ^c, it will terminate the 
> running process for `arc diff —create`. Similarly, I was seeing really weird 
> input via vim (when doing `svn ci`) where if I had one of the editing modes 
> on, like insert, it would delete several lines at once; I worked around this 
> by using ^c to terminate insert mode, but that’s a really bad hack. It worked 
> ok with r316745, got worse in r317727, and doesn’t seem to be any better in 
> r318250.

I forgot to mention: I’m using SSH to access my machine.
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

Hi,
I’ve been noticing some really weird behavior with terminal input after 
updating my kernel/userland — in particular, if I do `arc diff —create` (which 
opens vi/vim), and try to do edits/use ^c, it will terminate the running 
process for `arc diff —create`. Similarly, I was seeing really weird input via 
vim (when doing `svn ci`) where if I had one of the editing modes on, like 
insert, it would delete several lines at once; I worked around this by using ^c 
to terminate insert mode, but that’s a really bad hack. It worked ok with 
r316745, got worse in r317727, and doesn’t seem to be any better in r318250.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make warning: ?: No such file or directory.

[Ngie Cooper (yaneurabeya)]

> On May 9, 2017, at 21:37, O. Hartmann  wrote:
> 
> On recent CURRENT, the source tree /usr/src seems to have issues on some of my
> boxes and whenever I issue "make build", the message:
> 
> make warning: �: No such file or directory.
> 
> pops up. "svn st" doesn't reveal anything wrong.
> 
> My locale settings are:
> 
> LANG=
> LC_CTYPE="C"
> LC_COLLATE="C"
> LC_TIME="C"
> LC_NUMERIC="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_ALL=
> 
> (just for the record). Those spooky non-printables are seen on xterm(s) of
> various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the
> systems in question.
> 
> What is this?
> 
> Kind regards and thanks in advance,

I see similar oddness when running some commands. It seems to be happening as 
of the last month or two.
Thanks,
-Ngie

$ make buildenv TARGET_ARCH=armv6
make warning: I: No such file or directory.
make warning: I: No such file or directory.
Entering world for armv6:arm
$


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ${src}/release/release.sh fails at makefs state

[Ngie Cooper (yaneurabeya)]

> On May 8, 2017, at 06:07, Alastair Hogge  wrote:
> 
> On Fri, 5 May 2017 11:26:44 PM Ngie Cooper wrote:
>> (CCing emaste)
>> 
>>> On May 5, 2017, at 21:55, Alastair Hogge  wrote:
>> …
>> 
>>> Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes
>>> Extent size set to 8192
>>> memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size
>>> 1024
>>> 
>>>   using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes.
>>> 
>>> super-block backups (for fsck -b #) at:
>>>32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912,
>>> 
>>> Populating `memstick.img.part'
>>> makefs: bread: read 8192 (684294144) returned 0: No error: 0
>>> makefs failed
>>> *** Error code 1
> 
> Thanks Ngie.
> 
> It look like r317744 is causing the problem:
> https://svnweb.freebsd.org/base?view=revision&revision=317744
> 
> That is the checkout that breaks release building for me, prior revisions
> cause no problem.

Hi Alastair,
r317967 should allow you to build release images again.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: filemon: weird full-time build although filemon enabled

[Ngie Cooper (yaneurabeya)]

> On May 6, 2017, at 00:22, O. Hartmann  wrote:
> 
> I build CURRENT on two technically similar systems on a almost daily basis. 
> Therefore, it
> was a great relief having WITH_META_MODE=yes set in /etc/src-env.conf for 
> incremental
> builds. To make my understanding of this clear (just in case I'm wrong): 
> setting
> WITH_META_MODE builds only portions that does not need to be build in the 
> make context.
> 
> Well, the reason writing this email is: on one system, I run almost every 
> reboot into a
> "full build" and this puzzles me a bit. The long-lasting and time exhausting 
> builds are
> within the LLVM/CLANG tree. They consume a lot of time. The box in question 
> does have a
> weak CPU, only two physical cores, four threads, 8GB of RAM and builds the 
> /usr/obj
> residing on a SSD. The reference machine does have the same motherboard, also 
> a SSD, but
> has 16 GB RAM and a 4-core/8 threads XEON CPU - but both are "IvyBridge". The 
> XEON
> usually needs 30 - 40 minutes to compile a full world/kernel from a clean 
> /usr/obj, the
> "weak" box takes approximately 120 minutes - it is understandable that a 
> shortage of the
> build time is appreciated.
> 
> Well, having said this, I need to mention that both systems use almost
> identical /etc/src.conf setting - except the order of appearance of the WITH_ 
> tags. In
> fact, they are identical except the KERNCONF (naming of the kernel) and 
> PORTS_MODULES=,
> the "weak" box incorporates x11/nvidia-driver and 
> emulators/virtualbox-ose-kmod, so these
> modules are build every time the system gets rebuild, but the time taken by 
> those is
> negligible.
> 
> The problem: to make my point clear: the "weak" box starts compiling almost 
> everytime now
> the LLVM/CLANG tree while the XEON box does not. This is spooky.
> 
> I deleted on both  systems recently /usr/obj completely from its content and 
> restarted a
> buildworld again to hope, that the problem was introduced due to some files
> necessary for the BSD make environment to indicate the incremental build. But 
> no success.
> Even more spooky is the fact, that after a build on the "weak" box and a 
> build again, the
> box bevaves as expected not rebuilding everything again, but in some cases 
> after a
> reboot, a rebuild the hits again the build of LLVM/CLANG tree, while the XEON 
> box does
> not.
> 
> I think there is something missing an I'd like to ask what is the suggested 
> way to
> initially restart a full build to ensure that WITH_META_MODE gets initialised 
> correctly.
> 
> Well, I'm not a developer, so please be patient with my naive report.
> 
> Thanks in advance,

Dumb question: which kernel are you using on which machine (GENERIC, 
GENERIC-NODEBUG, a custom kernel with or without debug hooks, e.g., INVARIANTS, 
enabled)? Also, how are you building the system (locally using UFS or ZFS, 
remotely, e.g., over NFS, etc)?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ${src}/release/release.sh fails at makefs state

[Ngie Cooper (yaneurabeya)]

(CCing emaste)

> On May 5, 2017, at 21:55, Alastair Hogge  wrote:

…

> Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes
> Extent size set to 8192
> memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size
> 1024
>using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes.
> super-block backups (for fsck -b #) at:
> 32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912,
> Populating `memstick.img.part'
> makefs: bread: read 8192 (684294144) returned 0: No error: 0
> makefs failed
> *** Error code 1

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old snapshot install images?

[Ngie Cooper (yaneurabeya)]

> On May 3, 2017, at 10:39, Michael W. Lucas  wrote:
> 
> On Wed, May 03, 2017 at 09:52:09AM -0700, Ngie Cooper wrote:
>> Ok. How big is your freebsd-boot partition?
> 
> The size created by the installer. ;)
> 
> I've run another install, this one with the r317181 snapshot (20
> April.)
> 
> gpart show ada4 shows this (hand-copied)
> 
> 40   125045344ada4  GPT (60G)
> 40   1024 1 freebsd-boot (512K)
> 1064 984- free - (492K)
> 2048 4194304  2 freebsd-swap (2.0G)
> 4196352  1208483843 freebsd-zfs (58G)
> 125044736  648  - free - (324K)
> 
> ada5 is identical. It's a two-satadom mirror.
> 
> I used the guided install, had it blow the disks away.

Ok. You aren’t afflicted by the “freebsd-boot” partition is too small issue 
that many legacy users will have to suffer with coming from 8.x/9.x.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old snapshot install images?

[Ngie Cooper (yaneurabeya)]

> On May 3, 2017, at 09:34, Michael W. Lucas  wrote:
> 
> On Wed, May 03, 2017 at 01:01:10AM -0700, Ngie Cooper wrote:
>> Hi Michael!
>> - What sources are you using/revision are you at?
> 
> Using r311461 amd64 install memstick at the moment. Uname says built
> "Thu Jan 5 22:46:38 UTC 2017”

Ok. What version were you going to?

>> - Are your drives the 512 byte/sector or 4kB/sector variety?
> 
> They all claim to be 512 byte/sector. FWIW. ;-)

Ok. I was curious because there has been a period of time when 512b/sector 
disks have been broken and vice versa.

I’m going to operate under the impression that one of tsoome’s recent changes 
to zfsboot fixed things (there was some breakage over the past couple months 
based on posts to current@ and svn-src-*@), but I can’t count on it 100%.

HTH,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2017, at 19:53, Mark Millard  wrote:
> 
> On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer  wrote:
> 
>> On Thu, 13 Apr 2017, Pedro Giffuni wrote:
>>> I didn’t want to get into this but the problem is that as part of it's
>>> build/bootstrapping process, GCC historically takes system headers
>>> and attempts to “fix” them. I am unsure the fixes do anything at all
>>> nowadays but the effect is that the compiler tends to take snapshots
>>> of the system headers when it is built. cdefs.h is used by all the
>>> system headers so changes in cdefs.h have good chances affecting
>>> such builds but any change are likely to cause similar trouble.
>>> 
>>> In the case of gcc-aux, it appears the compilation is based on a
>>> bootstrap compiler which already carries outdated headers.
>>> A workaround, suggested by gerald@ the last time a similar issue
>>> happened was to run for install-tools/fixinc.sh. I think that may
>>> regenerate the headers and let the build use updated headers.
>>> Ultimately gcc-aux needs maintainer intervention and using
>>> outdated headers will break sooner or later: especially on -current.
>> 
>> Indeed, thanks for the analysis/background, Pedro!
>> 
>> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,
>> and perhaps John (as the maintainer of that port) has plans to update
>> it?  Let me copy him.
> 
> [As I have a prior E-mail exchange with John M. indicating that
> he was not intending to be the lang/gcc6-aux maintainer, I
> avoid spamming him with this material: I've removed him from
> the CC list in this reply. I can send the material to him if I
> see evidence of his wanting it.]
> 
> Just FYI:
> 
> [Previously: temporarily adding __nonnull and __nonnull_all
> back into into my local head FreeBSD variant got problems
> with: __vm_ooffset_t and __vm_pindex_t no longer existing and
> also the same pid_t issue indicated below.]
> 
> 
> I tried using [on a Pine64+ 2GB aarch64 system]:
> 
> # 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders
>  /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap
> 
> to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t.
> 
> I then built via portmaster -CDK usage. Various header issues
> did go away but the build of lang/gcc6-aux still stopped with:
> 
> In file included from 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0:
> ./config.h:556:15: error: two or more data types in declaration specifiers
> #define pid_t int
>   ^
> 
> I'm guessing that the define for pid_t in config.h resulted
> in something like:
> 
> typedef ??? pid_t;
> 
> that turned into something like a:
> 
> typedef ??? int;
> 
> for the error listed above.
> 
> There were also implicit-declaration warnings:
> 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
>  In function 'simple_object_internal_read':
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21:
>  warning: implicit declaration of function 'read' 
> [-Wimplicit-function-declaration]
>   ssize_t got = read (descriptor, buffer, size);
> ^~~~
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
>  In function 'simple_object_internal_write':
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23:
>  warning: implicit declaration of function 'write' 
> [-Wimplicit-function-declaration]
>   ssize_t wrote = write (descriptor, buffer, size);
>   ^
> 
> The implicit-declaration warnings for read and write may well
> also not be expected/desirable.
> 
> It may be that more than a script run is needed to make
> things be appropriate.

Is there a reason why you need ada support (that seems to be the only 
real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of gcc6 
with custom options.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

buildkernel broken for META_MODE

[Ngie Cooper (yaneurabeya)]

Hi,
I ran into this error when trying to run a meta mode build (for the 
first time). It might be related to the recent assym* ordering changes.
Thanks!
-Ngie

$ cat /etc/src-env.conf
WITH_AUTO_OBJ=  yes
WITH_META_MODE= yes
UPDATE_DEPENDFILE=  yes
$ pwd
/usr/src
$ svnversion
316603M
$ svn st | grep -v \?
M   usr.bin/grep/tests/Makefile
$ env SRCCONF=/dev/null NO_FILEMON=1 script ~/bk.ts make buildkernel -j3
Script started on Fri Apr  7 11:52:38 2017
Command: time make buildkernel -j3
--- buildkernel ---
make[1]: "/usr/src/Makefile.inc1" line 146: SYSTEM_COMPILER: Determined that 
CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
--- buildkernel ---
--
>>> Kernel build for GENERIC started on Fri Apr  7 11:52:39 PDT 2017
--
===> GENERIC
mkdir -p /usr/obj/usr/src/sys
--
>>> stage 1: configuring the kernel
--
...
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/acpi_quirks.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_eq_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_rate_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/snd_fxdiv_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/miidevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/pccarddevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/teken_state.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/usbdevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/vnode_if.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o
--- ia32_genassym.o ---
:1:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
 ^~
1 error generated.
*** [ia32_genassym.o] Error code 1

make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
.ERROR_TARGET='ia32_genassym.o'
.ERROR_META_FILE='/usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o.meta'


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: problem with ls, not show a correct list

[Ngie Cooper (yaneurabeya)]

> On Apr 6, 2017, at 22:15, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Apr 6, 2017, at 21:28, Nilton José Rizzo  wrote:
> 
> …
> 
>> [966] root@valfenda rizzo #locale
>> LANG=pt_BR.UTF-8
>> LC_CTYPE="pt_BR.UTF-8"
>> LC_COLLATE="pt_BR.UTF-8"
>> LC_TIME="pt_BR.UTF-8"
>> LC_NUMERIC="pt_BR.UTF-8"
>> LC_MONETARY="pt_BR.UTF-8"
>> LC_MESSAGES="pt_BR.UTF-8"
>> LC_ALL=
> 
>   I bet the fact that you’re using a non-ASCII-US locale is the reason 
> why you’re running into this. Could you please try the same thing with all of 
> these values unset.

I just saw your follow up email. Let me do some checking (in the meantime, 
please file a bug for this).
Thanks!
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: problem with ls, not show a correct list

[Ngie Cooper (yaneurabeya)]

> On Apr 6, 2017, at 21:28, Nilton José Rizzo  wrote:

…

> [966] root@valfenda rizzo #locale
> LANG=pt_BR.UTF-8
> LC_CTYPE="pt_BR.UTF-8"
> LC_COLLATE="pt_BR.UTF-8"
> LC_TIME="pt_BR.UTF-8"
> LC_NUMERIC="pt_BR.UTF-8"
> LC_MONETARY="pt_BR.UTF-8"
> LC_MESSAGES="pt_BR.UTF-8"
> LC_ALL=

I bet the fact that you’re using a non-ASCII-US locale is the reason 
why you’re running into this. Could you please try the same thing with all of 
these values unset?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: increased power consumption lately?

[Ngie Cooper (yaneurabeya)]

> On Apr 5, 2017, at 10:39, Adrian Chadd  wrote:
> 
> hm, you could use dtrace to find what's calling that function and
> print out the call stack?

*does shrug* something like this (I realize it’s not printing out arg0 
— arg0 is a union that would need decoding)?
Thanks,
-Ngie

$ cat AcpiNsLookup.d
fbt:kernel:AcpiNsLookup:entry
{
printf("PathInfo: %s\nType: %d\nFlags: %u",
stringof(arg1), arg2, arg3);
}
$ sudo dtrace -s AcpiNsLookup.d


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: inetd startup script missing from /etc/rc.d in both -current and 11-stable

[Ngie Cooper (yaneurabeya)]

> On Apr 3, 2017, at 07:00, tech-lists  wrote:
> 
> Hello current@,
> 
> From https://www.freebsd.org/doc/handbook/network-inetd.html I should be
> able to start inetd like this:
> 
> service inetd start
> 
> ...after enabling it in /etc/rc.conf. The inetd options look like this:
> 
> inetd_enable="YES"
> inetd_program="/usr/sbin/inetd"
> inetd_flags="-wW -C 60"
> 
> The problem is that the startup script doesn't exist in /etc/rc.d. I get
> this error:
> 
> # service inetd start
> inetd does not exist in /etc/rc.d or the local startup
> directories (/usr/local/etc/rc.d), or is not executable
> 
> and the lines in rc.conf have no effect (inetd doesn't start).
> 
> I can, however, start it manually, as root, like this:
> 
> # inetd -wW -C 60
> 
> and it runs as expected.
> 
> This problem exists in 11-stable as well as -current. How can I fix this
> please?

Please double check your build options. If MK_INETD=no (WITHOUT_INETD=, 
typically) is set in src.conf, it won’t install this and other inetd-related 
items.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

[Ngie Cooper (yaneurabeya)]

> On Mar 29, 2017, at 01:26, Bruce Evans  wrote:
> 
> On Tue, 28 Mar 2017, Ngie Cooper wrote:
> 
>>> On Mar 28, 2017, at 21:40, Bruce Evans  wrote:
>>> 
 On Wed, 29 Mar 2017, Bruce Evans wrote:
 
> On Wed, 29 Mar 2017, Andrey Chernov wrote:
> ...
> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode
> anymore - nothing happens. In the vt mode I can, but can't exit via "c"
> properly, all chars typed after "c" produce beep unless I switch to
> another screen and back.
> All it means that syscons becomes very broken now by itself and even
> damages the kernel operations.
> 
> I found a bug in screen resizing (the console context doesn't get resized).
> This doesn't cause any keyboard problems.
> 
 ...
 But I suspect it is a usb keyboard problem.  Syscons now does almost
 correct locking for the screen, but not for the keyboard, and the usb
 keyboard is especially fragile, especially in ddb mode.  Console input
 is not used in normal operation except for checking for characters on
 reboot.
 
 Try using vt with syscons unconfigured.  Syscons shouldn't be used when
 vt is selected, but unconfigure it to be sure.  vt has different bugs
 using the usb keyboard.  I haven't tested usb keyboards recently.
>>> 
>>> ...
>>> I tested usb keyboards again.  They sometimes work, much the same as
>>> a few months ago after some fixes:
>>> ...
>>> 
>>> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.
>>> Other combinations and dynamic switching move the bugs around, and a
>>> serial console is needed to recover in cases where the bugs prevent any
>>> keyboard input.
>> 
>> I filed a bug a few years ago about USB keyboards and usability in ddb. If 
>> you increase the timeout so the USB hubs have enough time to probe/attach, 
>> they will work.
> 
> Is that for user mode or earlier?  ukb has some other fixes for ddb now, but
> of course it can't work before it finds the device.
> 
> I recently found that usb boot drives sometimes don't have enough time to
> probe/attach before they are used in mountroot, and the mount -a prompt
> does locking that doesn't allow them enough time if they are not ready
> before it.  The usb maintainers already know about this.

Ah, I misremembered my filing the bug — someone else did it: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133989 (it happens at 
mountroot, for example, because of probing order being what it is).
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: shutdown -r doesn't execute rc.d sequence

[Ngie Cooper (yaneurabeya)]

> On Mar 28, 2017, at 14:27, Andrey Chernov  wrote:

…

>> Using rc_debug=yes I see that it is the kernel problem, not rc problem.
>> Sometimes rc backward sequence executed even fully, sometimes only
>> partly, but in unpredictable moment inside rc sequence the kernel decide
>> to reboot quickly (or even deadly hang in rare cases). Always without
>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS,
>> no EFI, no GPT.
>> I change GELI swap to normal one, but it does not help. The same
>> untouched config works for years, I see this bug for the first time in
>> FreeBSD.
>> 
> 
> I forget to mention that typescript and dmesg does not survive after
> this reboot (or rare hang).

Good to note.
The simple explanation to the problem might be r307755, depending on when you 
last synced/built ^/head.

I have a few more questions (if reverting that doesn't pan out):
- What make/model of x86_64 are you running AMD (Bulldozer, etc) or Intel 
(Conroe/Nehalem/Westmere/Sandybridge/Haswell)?
- Is this a custom built machine? If so, what is your motherboard? If not, 
who’s the vendor?
- Is your system firmware up to date?
- What does your make.conf/src.conf look like?
- Are you running GENERIC or a custom kernel? If custom, could you please 
include the config somewhere?
- Are you loading any drivers in loader.conf?
- Are you using Linux emulation?
- Are you running any blob drivers, like nvidia?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: shutdown -r doesn't execute rc.d sequence

[Ngie Cooper (yaneurabeya)]

> On Mar 28, 2017, at 12:30, Andrey Chernov  wrote:
> 
> With latest -current amd64, reboot happens almost immediately, leaving
> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence
> execution is shown. No deactivating GELI swap too.

Hi Andrey,
Do you have a typescript demonstrating this? Adding rc_debug=yes to 
/etc/rc.conf would be super helpful, along with `boot -v`, to see whether the 
issue is in userspace or rc(5).
I’ll double check my amd64/i386 VMs too (if possible, redirect the 
output over serial to a typescript for analysis).
Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, 
nanobsd, etc)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 2:19 PM, Bryan Drewery  wrote:
> 
> On 3/15/2017 2:10 PM, Bryan Drewery wrote:
>> On 3/15/2017 11:23 AM, David Wolfskill wrote:
>>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
 ...
 So where is /common/S4/obj coming from?
 
 Is there a symlink involved here for /usr/obj?
 
>>> 
>>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>>> a couple of decades, now
>> 
>> Ok, I don't think the symlink is the problem.  It's just the meta mode
>> handling forcing a realpath(3) on some of the output which causes the
>> confusion.
>> 
>> Still looking...
>> 
>> 
> 
> This should fix it: https://svnweb.freebsd.org/changeset/base/315332 
> 

Yeah, that would do it >_>…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:24, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Mar 15, 2017, at 11:23, David Wolfskill  wrote:
>> 
>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>>> ...
>>> So where is /common/S4/obj coming from?
>>> 
>>> Is there a symlink involved here for /usr/obj?
>>> 
>> 
>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>> a couple of decades, now
> 
> What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade 
> and supporting commit)?

Alternatively, could you please revert just r313650 in another branch/workspace 
(I wonder if changing from .OBJDIR to OBJTOP had some unintended consequences 
that unrooted issues with how bmake evaluates paths)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:23, David Wolfskill  wrote:
> 
> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>> ...
>> So where is /common/S4/obj coming from?
>> 
>> Is there a symlink involved here for /usr/obj?
>> 
> 
> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
> a couple of decades, now

What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade and 
supporting commit)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:09, Bryan Drewery  wrote:
> 
> On 3/15/2017 10:04 AM, David Wolfskill wrote:
> 
>> --
> stage 1.1: legacy release compatibility shims
>> --
>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp
> 
> Ok it is trying to use MAKEOBJDIRPREFIX=/usr/obj
> 
>> Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui
> 
> But all of the 'Building' lines are tryign to use
> MAKEOBJDIRPREFIX=/common/S4/obj/ ...
> 
>> --- all_subdir_cddl ---
>> --- all_subdir_cddl/usr.bin ---
>> --- all_subdir_cddl/usr.bin/zinject ---
>> ===> cddl/usr.bin/zinject (all)
>> --- all_subdir_gnu ---
>> --- gdbtui ---
>> cc: error: no such file or directory: 
>> '/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'
> 
> But then complains about a missing file in MAKEOBJDIRPREFIX=/usr/obj
> 
>> *** [gdbtui] Error code 1
>> 
>> bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
>> .ERROR_TARGET='gdbtui'
>> .ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
>> .MAKE.LEVEL='6'
>> MAKEFILE=''
>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
>> .CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
>> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
> ...
>> .OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'
> 
> And says here that there is an existing directory for
> MAKEOBJDIRPREFIX=/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which is
> throwing off its paths for libbfd.a.
> 
> ...
>> MAKEOBJDIRPREFIX='/usr/obj'
> 
> And the meta error agrees it wants MAKEOBJDIRPREFIX=/usr/obj
> 
> 
> So where is /common/S4/obj coming from?
> 
> Is there a symlink involved here for /usr/obj?

^/head@r315175 doesn’t look like it’s causing a problem here. I don’t 
think my commit here recently (^/head@r313650) was a problem, but I wonder if 
it exposed a race or incomplete dependency logic…
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildworld error

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 18:24, Ngie Cooper (yaneurabeya)  
> wrote:

Hi Roberto,
The sbin/setkey issue should be resolved by r315181. Thank you for the 
report!
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 18:27, Lawrence Stewart  wrote:
> 
> Hi Ian,

…

>> The MAKEOBJDIRPREFIX variable must be set in the environment, not in
>> make.conf or on the make command line (documented in build(7)).
> 
> Your assertion seems at odds with my past experience and my reading of
> the man page... from build(7):
> 
>   The build may be controlled by defining make(1) variables
>   described in the ENVIRONMENT section below, and by the
>   variables documented in make.conf(5).
> 
> ... which indicates they are make variables, not environment variables
> specifically. As a concrete example, TARGET and DESTDIR are listed under
> the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows:
> 
>   make TARGET=sparc64 buildworld
>   make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld
> 
> I've certainly always set build vars documented in the "ENVIRONMENT"
> section of the man page on the make command line without issue. Pretty
> sure I've set MAKEOBJDIRPREFIX from the make command line also in the
> past, though perhaps it has been working for me "by accident" and a
> documentation tweak is in order if the distinction you make is in fact
> relevant...

Hi Lawrence,

Ian’s right per historical behavior, which should still be in effect today.

Unfortunately, setting MAKEOBJDIRPREFIX on the command line will result in bad 
things happening because of how bsd.obj.mk works and how MAKEOBJDIRPREFIX is 
manipulated in the build itself (see Makefile.libcompat — it affects some 
architectures, but maybe not sparc64). From …/Makefile (which should have 
triggered this error message to begin with):

171 MAKEOBJDIRPREFIX?=  /usr/obj
172 _MAKEOBJDIRPREFIX!= /usr/bin/env -i PATH=${PATH} MK_AUTO_OBJ=no ${MAKE} \
173 ${.MAKEFLAGS:MMAKEOBJDIRPREFIX=*} __MAKE_CONF=${__MAKE_CONF} \
174 -f /dev/null -V MAKEOBJDIRPREFIX dummy
175 .if !empty(_MAKEOBJDIRPREFIX)
176 .error MAKEOBJDIRPREFIX can only be set in environment, not as a global\
177 (in make.conf(5)) or command-line variable.
178 .endif

Are you sure your script/process didn’t catch a relevant build error?

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildworld error

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 15:51, Roberto Rodriguez Jr  
> wrote:
> 
> I figured the script command... here is the new error r315090
> 
> --- .depend ---
> echo setkey.full: /usr/obj/usr/src/tmp/usr/lib/libc.a
> /usr/obj/usr/src/tmp/usr/lib/libl.a
> /usr/obj/usr/src/tmp/usr/lib/liby.a
> /usr/obj/usr/src/tmp/usr/lib/libipsec.a >> .depend
> --- setkey.o ---
> /usr/local/libexec/ccache/cc  -O2 -pipe -march=btver2
> -I/usr/src/sbin/setkey -I/usr/src/lib/libipsec -I/usr/src/lib/libipsec
> -I/usr/src/sys/netipsec -DIPSEC_DEBUG -DYY_NO_UNPUT -DINET6 -I. -g -MD
> -MF.depend.setkey.o -MTsetkey.o -std=gnu99 -fstack-protector-strong
> -Wsystem-headers -Werror -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter
> -Wno-parentheses  -Qunused-arguments  -c /usr/src/sbin/setkey/setkey.c
> -o setkey.o
> --- all_subdir_lib ---
> --- jemalloc_nstime.po ---
> /usr/local/libexec/ccache/cc -pg  -O2 -pipe -march=btver2
> -I/usr/src/lib/libc/include -I/usr/src/include
> -I/usr/src/lib/libc/amd64 -DNLS  -D__DBINTERFACE_PRIVATE
> -I/usr/src/contrib/gdtoa -I/usr/src/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/libmd
> -I/usr/src/contrib/jemalloc/include -I/usr/src/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 -DWANT_HYPERV -DYP
> -DNS_CACHING -DSYMBOL_VERSIONING -MD  -MF.depend.jemalloc_nstime.po
> -MTjemalloc_nstime.po -std=gnu99 -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-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter  -Qunused-arguments
> -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64
> -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_nstime.c
> -o jemalloc_nstime.po
> --- all_subdir_rescue ---
> --- suffix.o ---
> /usr/local/libexec/ccache/cc  -O2 -pipe -DHAVE_CONFIG_H
> -I/usr/src/usr.bin/xz/../../lib/liblzma
> -I/usr/src/usr.bin/xz/../../contrib/xz/src/common -march=btver2
> -DRESCUE -MD  -MF.depend.suffix.o -MTsuffix.o -std=gnu99
> -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -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  -Qunused-arguments  -c
> /usr/src/usr.bin/xz/../../contrib/xz/src/xz/suffix.c -o suffix.o
> --- all_subdir_sbin ---
> /usr/src/sbin/setkey/setkey.c:154:15: error: use of undeclared
> identifier 'IPSEC_POLICYSCOPE_GLOBAL'
>f_scope |= IPSEC_POLICYSCOPE_GLOBAL;
>   ^
> /usr/src/sbin/setkey/setkey.c:157:15: error: use of undeclared
> identifier 'IPSEC_POLICYSCOPE_IFNET'
>f_scope |= IPSEC_POLICYSCOPE_IFNET;
>   ^

Some new symbols were added to sys/netipsec/… and unfortunately the system 
headers don’t provide that symbol.

This should fix the issue — I’ll run the change through make tinderbox before 
committing, then analyze the .depend files, just to make sure it's 
bootstrapping properly.

Thanks!
-Ngie

$ svn diff Makefile
Index: Makefile
===
--- Makefile(revision 315094)
+++ Makefile(working copy)
@@ -46,7 +46,7 @@
 # ipsec_strerror.c is for avoiding shlib reference to non-exported function.
 .PATH: ${SRCTOP}/lib/libipsec ${SRCTOP}/sys/netipsec
 SRCS+= pfkey.c pfkey_dump.c key_debug.c ipsec_strerror.c
-CFLAGS+= -I${SRCTOP}/sys/netipsec
+CFLAGS+= -I${SRCTOP}/sys

 SRCS+= y.tab.h
 y.tab.h: parse.y



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build Fail: -CURRENT

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 11:50, Larry Rosenman  wrote:
> 
> --- all_subdir_usr.sbin/amd ---
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x13e): undefined reference 
> to `xdr_symlinkargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x14c): undefined reference 
> to `xdr_diropres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x151): undefined reference 
> to `xdr_createargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x15f): undefined reference 
> to `xdr_nfsstat'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x164): undefined reference 
> to `xdr_diropargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x172): undefined reference 
> to `xdr_readdirres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x177): undefined reference 
> to `xdr_readdirargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x185): undefined reference 
> to `xdr_statfsres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18a): undefined reference 
> to `xdr_nfs_fh'
> 
> stubs.o: In function `nfsproc_readlink_2_svc':
> 
> /usr/src/contrib/amd/hlfsd/stubs.c:356: undefined reference to 
> `xdr_readlinkres'
> 
> --- all_subdir_rescue ---
> 
> Building /usr/obj/usr/src/rescue/rescue/usr/src/sbin/ipf/ipf/printlookup.o
> 
> --- all_subdir_usr.sbin ---
> 
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> *** [hlfsd.full] Error code 1

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 12:12, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Mar 4, 2017, at 09:33, Michael Butler  wrote:
>> 
>> Seems that SVN r314659 broke this :-(
>> 
>>  Michael
> 
> Working on it :(.
> -Ngie

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 09:33, Michael Butler  wrote:
> 
> Seems that SVN r314659 broke this :-(
> 
>   Michael

Working on it :(.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Boot failure - svn up from this morning

[Ngie Cooper (yaneurabeya)]

> On Mar 2, 2017, at 21:16, Chris H  wrote:
> 
> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  wrote
> 
>> Hi:
>> 
>> I'm having a major problem after updating a 12-current machine today.
>> After buildworld/kernel/install cycle on reboot I'm getting the following
>> failure:
>> 
>> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel/kernel': input/output error
>> can't load file '/boot/kernel/kernel': input/output error
>> 
>> OK boot kernel.old
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel.old/kernel': input/output error
>> can't load file '/boot/kernel.old/kernel': input/output error"
>> 
>> I have never experienced this failure before, and don't know how to
>> proceed.  Any help recovering from this would be greatly appreciated.
>> Thanks in advance.
> 
> I don't suppose you could post the output of
> uname -a
> 
> and maybe a copy of dmesg(8) could you?

That would be good, but I don’t know if it’s possible (the OP is noting that 
the boot is broken when executing loader(8)..).
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper (yaneurabeya)]

> On Feb 17, 2017, at 13:09, Bryan Drewery  wrote:

…

> Ignore me, my yacc is just outdated.

I’ll try again. This might have been part of my issue too.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: xdev fixed

[Ngie Cooper (yaneurabeya)]

> On Feb 17, 2017, at 16:13, Bryan Drewery  wrote:
> 
> The issue reported here:
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-June/014065.html
> 
>> make XDEV=arm XDEV_ARCH=armv6 xdev
>> 
>> It failed!
>> 
>> sh /usr/src/tools/install.sh  -C -o root -g wheel -m 444  
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dialog.h 
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dlg_colors.h 
>> /usr/src/gnu/lib/libdialog/dlg_config.h 
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dlg_keys.h 
>> //usr/armv6-freebsd/usr/include/
>> ===> lib/libc++ (obj,all,install)
>> /usr/obj/armv6-freebsd/usr/src/lib/libc++ created for /usr/src/lib/libc++
>> echo libc++.so.1.full: //usr/armv6-freebsd/usr/lib/libcxxrt.a >> .depend
>> c++ -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib  
>> --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec  
>> -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib -mlong-calls -O 
>> -pipe -isystem /usr/src/lib/libc++/../../contrib/libc++/include -isystem 
>> /usr/src/lib/libc++/../../contrib/libcxxrt -nostdinc++ -nostdlib -DLIBCXXRT 
>> -MD -MF.depend.algorithm.o -MTalgorithm.o -Qunused-arguments  -std=c++11 
>> -Wno-c++11-extensions  -c 
>> /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10:
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:624:
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/include/initializer_list:47:
>> /usr/src/lib/libc++/../../contrib/libc++/include/cstddef:43:15: fatal error:
>>  'stddef.h' file not found
>> #include_next 
>>  ^
>> 1 error generated.
>> *** Error code 1
> 
> 
> This should now be fixed in head as of r313907.  Sorry for the long
> delay on it.  It likely came about due to the libc++ upgrade around
> r300873 in May 2016.  I will MFC the fix to stable/11 once I get more
> feedback or in 2 weeks otherwise.

*does a happy dance*
Thanks so much :)!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper (yaneurabeya)]

> On Feb 16, 2017, at 07:30, Oleg V. Nauman  wrote:
> 
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong -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-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -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-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
> 'struct _compiler_state'
>cstate.ai = NULL;
>~~ ^
> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "direction applied to 'gateway'");
>  ^
> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
> identifier 'cstate'
>switch (cstate->linktype) {
>^
> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
> identifier 'cstate'
>b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
> Q_HOST);
>  ^
> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
> identifier 'cstate'
>tmp = gen_host(cstate, **alist++, 0x, proto,
> Q_OR,
>   ^
> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "illegal modifier of 'gateway'");
>  ^
> 6 errors generated.
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/lib/libpcap
> *** Error code 1

CCing Xin, who did the libpcap upgrade.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r313495 make perl File::Temp broken

[Ngie Cooper (yaneurabeya)]

> On Feb 10, 2017, at 05:55, Iblis Lin  wrote:
> 
> I just found i miss-typed the revision number in subject.
> It's r313495.
> 
> (https://svnweb.freebsd.org/base/head/sys/kern/vfs_vnops.c?r1=313495&r2=313494&pathrev=313495)
> 
> On Fri, Feb 10, 2017 at 09:09:52PM +0800, Iblis Lin wrote:
>> Hi,
>> 
>> as not a perl programmer myself. I have no idea what is going on.
>> I found this issue while compiling math/openblas.
>> 
>> [iblis@ns]% uname -a
>> FreeBSD ns 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r313500: Fri Feb 10 16:39:21
>> CST 2017 root@ns:/usr/obj/usr/src/sys/GENERIC  amd64
>> 
>> [iblis@ns]% cat test.pl
>> use File::Temp qw(tempfile);
>> $tmpf = new File::Temp( UNLINK => 1 );
>> 
>> [iblis@ns]% perl test.pl
>> Error in tempfile() using template /tmp/XX: Could not create temp 
>> file
>> /tmp/dI5uhUsijR: Bad file descriptor at test.pl line 2.
>> 
>> 
>> And part of truss's output:
>> 
>> close(3) = 0 (0x0)
>> stat("/tmp/",{ mode=drwxrwxrwt ,inode=24317568,size=1024,blksize=32768 }) = 
>> 0 (0x0)
>> stat("/tmp/",{ mode=drwxrwxrwt ,inode=24317568,size=1024,blksize=32768 }) = 
>> 0 (0x0)
>> openat(AT_FDCWD,"/tmp/Nn0Epra5ff",O_RDWR|O_EXLOCK|O_NOFOLLOW|O_CREAT|O_EXCL,0600)
>>  ERR#9 'Bad file descriptor'
>> stat("/usr/share/nls/C/libc.cat",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> stat("/usr/share/nls/libc/C",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> stat("/usr/local/share/nls/C/libc.cat",0x7fffdcf8) ERR#2 'No such file 
>> or directory'
>> stat("/usr/local/share/nls/libc/C",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> Error in tempfile() using template /tmp/XX: Could not create temp 
>> file /tmp/Nn0Epra5ff: Bad file descriptor at test.pl line 2.
>> write(2,"Error in tempfile() using templa"...,135) = 135 (0x87)

Hi,
kib@ has a patch out for another related issue that was reported with 
dhclient — please give his patch a shot: 
https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064780.html .
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper (yaneurabeya)]

Hi,
I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don’t have 
enough space or ability to resize the partition and make it bigger. So, I’m in 
need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_i386 - Build #4653 - Failure

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 18:18, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #4653 - Failure:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/console
> 
> Change summaries:
> 
> 312104 by cem:
> Fix broken fstyp exfat testcase
> 
> Introduced in r312010.
> 
> It helps to read the documentation before trying to test something.
> 
> 312103 by cem:
> Revert r310994
> 
> Don't implement some terrible hack on a test by test basis.  The
> framework fix is straightforward and can be chased up in the original
> bug.
> 
> Reviewed by:  ngie ("be my guest")
> 
> 312102 by ngie:
> Note that sys/types.h is required on FreeBSD for kqueue(2), unlike NetBSD
> 
> MFC after:12 days
> X-MFC with:   r305358
> Sponsored by: Dell EMC Isilon

Broken by r312103.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 14:48, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Jan 13, 2017, at 12:23, Eric Joyner  wrote:
>> 
>> ^ Message ^
>> 
>> It takes forever, but I keep on forgetting to time how long it takes, so I
>> don't know how long "forever" is.
> 
> Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware 
> Fusion + open-vmtools VM…
> - … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
> - …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
> MODULES_OVERRIDE: 14 minutes
> 
> Overall time: 40 minutes
> 
> Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
> but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
> shouldn’t take any longer than 30 mins (if you optimize things heavily, it 
> can be less than that).
> 
> If you need a beefy box to play with for building en masse (since you’re a 
> FreeBSD dev), try the universe*.freebsd.org boxes.

Important note: unless I have a good reason to test out GENERIC, I always used 
GENERIC-NODEBUG, so needless to say witness and other debug bits don’t add time 
to my build.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 12:23, Eric Joyner  wrote:
> 
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.

Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware Fusion 
+ open-vmtools VM…
- … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
- …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
MODULES_OVERRIDE: 14 minutes

Overall time: 40 minutes

Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
shouldn’t take any longer than 30 mins (if you optimize things heavily, it can 
be less than that).

If you need a beefy box to play with for building en masse (since you’re a 
FreeBSD dev), try the universe*.freebsd.org boxes.

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 02:22, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I spotted these compilation errors on universe12a.freebsd.org for both 
> powerpc.LINT and powerpc.LINT64:
> 
> cc1: warnings being treated as errors
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
> 'generic_set_tx_event':
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the 
> address of 'generic_mbuf_destructor' will always evaluate as 'true' 
> [-Waddress]
> --- netmap_generic.o ---
> *** [netmap_generic.o] Error code 1
> 
>   I haven’t yet dug into why this only surfaces on powerpc, yet…

(CC -powerpc; BCC +powerpc)
Hi,
sparc64 has the same issue as powerpc*, so I suspect that gcc is 
flagging this as an issue.
Thanks,
-Ngie

PS. Sidenote: why was the SET_MBUF_DESTRUCTOR macro added, but not used in 
nm_os_get_mbuf ?


signature.asc
Description: Message signed with OpenPGP using GPGMail

powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

Hi,
I spotted these compilation errors on universe12a.freebsd.org for both 
powerpc.LINT and powerpc.LINT64:

cc1: warnings being treated as errors
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
'generic_set_tx_event':
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the address 
of 'generic_mbuf_destructor' will always evaluate as 'true' [-Waddress]
--- netmap_generic.o ---
*** [netmap_generic.o] Error code 1

I haven’t yet dug into why this only surfaces on powerpc, yet…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: vt(4) chops off the leftmost three columns

[Ngie Cooper (yaneurabeya)]

> On Jan 12, 2017, at 18:13, Ed Maste  wrote:
> 
> On 12 January 2017 at 18:50, Alan Somers  wrote:
>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>> off the leftmost three columns of the screen.  Rendering simply starts
>> at the beginning of the fourth column.  In all cases, setting
>> "kern.vty=sc" corrects the problem.
> 
> Or try setting hw.vga.textmode=1
> 
> Did you observe this with IPMI redirected video or an attached monitor
> (or a combination)?

I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell 
box (Escher) over VGA using my projector.
Thanks,
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: SVN r311568 breaks build

[Ngie Cooper (yaneurabeya)]

> On Jan 6, 2017, at 17:33, Michael Butler  wrote:
> 
> With the introduction of MSG_MORETOCOME, the build of libsysdecode is
> broken.
> 
> Was the following patch the intended but missed fix?

Addressed in r311584 — thank you for the submission!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: SVN r310931 Bad code

[Ngie Cooper (yaneurabeya)]

> On Dec 31, 2016, at 06:14, Michael Butler  wrote:
> 
> At line 1949 of head/contrib/bsnmp/lib/snmpclient.c, you changed ..
> 
> - if ((sc->chost = malloc(strlen(s) + 1)) == NULL) {
> + if ((sc->chost = strdup(strlen(s))) == NULL) {
> 
> This can't work as intended since strlen returns the length of the
> string not a pointer to it.
> 
> I expect this should be ..
> 
>   if ((sc->chost = strdup(s)) == NULL) {

Yeah… egg on my face... I fixed it in r310942.
Sorry for the breakage :/…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r 310850: buildkernel failure: ip_carp.c:615:28: error: incomplete definition

[Ngie Cooper (yaneurabeya)]

> On Dec 30, 2016, at 12:07, O. Hartmann  wrote:
> 
> 
> [...]
> 
> ===> cas (all)
> --- all_subdir_carp ---
> --- ip_carp.o ---
> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:615:28: error: incomplete 
> definition of
> type 'struct ip6_hdr' return (memcmp(&in6, &ip6->ip6_src, sizeof(in6)) == 0);
>  ~~~^
> /usr/src/sys/netinet6/in6.h:662:8: note: forward declaration of 'struct 
> ip6_hdr'
> struct ip6_hdr;
>   ^
> --- all_subdir_cam ---
> Building 
> /usr/obj/usr/src/sys/WALHALL/modules/usr/src/sys/modules/cam/scsi_pass.o
> --- all_subdir_carp ---
> 1 error generated.
> *** [ip_carp.o] Error code 1

Should be addressed in r310864.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: syslogd: select: Bad File descriptor

[Ngie Cooper (yaneurabeya)]

> On Dec 24, 2016, at 04:16, Daniel Braniss  wrote:
> 
> latest changes is causing cpu load and ‘last message repeated  times, 
> I guess the eggnog is affecting too early

Fixed in r310504.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: syslogd 100% cpu usage on recent FreeBSD version

[Ngie Cooper (yaneurabeya)]

> On Dec 24, 2016, at 04:14, Subbsd  wrote:
> 
> Probably after https://svnweb.freebsd.org/base?view=revision&revision=310494,
> syslogd eat 100% cpu with follow messages:
> 
> Dec 24 14:19:15 samson syslogd: select: Bad file descriptor
> Dec 24 14:19:45 samson last message repeated 464140 times
> Dec 24 14:20:38 samson last message repeated 835899 times

Fixed in r310504.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r 307698: buildworld failure: tconfig.h:6:10: fatal error: 'auto-host.h' file not found

[Ngie Cooper (yaneurabeya)]

> On Oct 20, 2016, at 21:39, O. Hartmann  wrote:
> 
> Recent r307698 is preventued from beeing built by a compiler error, see below.
> 
> I also face a problem with the subversion tree a couple of day right now:
> 
> # svn update
> Updating '.':
> Restored 'tests/sys/geom/class/uzip/1_endian_little.img.uzip.uue'
> At revision 307698.
> 
> This 'restored' message occurs all the time until I emmit a restore command in
> svn.
> 
> Kind regards,

Jenkins agrees. I reverted r307689 via r307699.
Thank you for the report!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is back to stable : FreeBSD_HEAD #578

[Ngie Cooper (yaneurabeya)]

> On Aug 31, 2016, at 23:35, Craig Rodrigues  wrote:
> 
> Thank you for fixing this.

No problem :)!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make universe and /etc/src.conf

[Ngie Cooper (yaneurabeya)]

> On Aug 22, 2016, at 09:25, Eric van Gyzen  wrote:
> 
> On 08/22/2016 11:00, Ngie Cooper wrote:
>> 
>>> On Aug 22, 2016, at 08:24, Eric van Gyzen  wrote:
>>> 
>>> I just tried a "make universe", and all the kernels failed because they
>>> couldn't find the config files.  I had forgotten that I have this in
>>> /etc/src.conf:
>>> 
>>> KERNCONF=NUMA KERNCONFDIR=/etc
>> 
>> Alternatively, use KERNCONF?= and KERNCONFDIR?=..
>> 
>> A conditional will be needed to deal with MODULES_OVERRIDE, but it's
>> trivial.. I'll dig up my old src.conf a bit later on today if needed. It's
>> how I dealt with that caveat before I switched to GENERIC*.
> 
> Thanks for the suggestion.  Moving these to /etc/make.conf seems easiest, so
> I'll just do that.

The problem with using make.conf is that it pollutes all uses of make, whereas 
src.conf just pollutes compilation of the source tree.

Here’s what I used: 
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/etc/src.conf-local#L39
 — I used some additional magic because of the reasons I mentioned in my 
previous email. Now, I just set KERNCONF= GENERIC GENERIC-NODEBUG (but I should 
use `?=` if I cared about running make universe on my VM on my laptop — heh).

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: kernel options

[Ngie Cooper (yaneurabeya)]

> On Jul 24, 2016, at 01:51, tech-lists  wrote:
> 
> Hi,
> 
> In -HEAD there is a generic kernel GENERIC-NODEBUG. The syntax of
> OPTIONS appears to be NOOPTIONS. Is there an inverse for DEVICE ?
> 
> For example, there is a line
> 
> device  fdc
> 
> in GENERIC. Would NODEVICE negate it?
> 
> I didn't see anything in NOTES to confirm.

`nodevice` works. See `man 5 config` for more details.
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: kernel no longer builds without nvme

[Ngie Cooper (yaneurabeya)]

> On Jul 21, 2016, at 06:45, Michael Butler  wrote:
> 
> For those of us who build "minimal" kernels:
> 
> Building /usr/obj/usr/src/sys/VM02/vers.c
> Building /usr/obj/usr/src/sys/VM02/vers.o
> Building /usr/obj/usr/src/sys/VM02/kernel
> --- kernel ---
> linking kernel
> cam_xpt.o: In function `xpt_announce_periph':
> /usr/src/sys/cam/cam_xpt.c:(.text+0xcd2): undefined reference to
> `nvme_print_ident'
> cam_xpt.o: In function `xpt_denounce_periph':
> /usr/src/sys/cam/cam_xpt.c:(.text+0xe76): undefined reference to
> `nvme_print_ident'
> cam_xpt.o: In function `xpt_run_devq':
> /usr/src/sys/cam/cam_xpt.c:(.text+0x2bc0): undefined reference to
> `nvme_op_string'
> /usr/src/sys/cam/cam_xpt.c:(.text+0x2bd8): undefined reference to
> `nvme_cmd_string'
> cam_xpt.o: In function `xpt_bus_register':
> /usr/src/sys/cam/cam_xpt.c:(.text+0x620b): undefined reference to
> `nvme_get_xport'
> *** [kernel] Error code 1

CCing Scott and Warner. This is one of many reports I’ve seen related to this 
issue.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r302773: non-removable files with "make delete-old"

[Ngie Cooper (yaneurabeya)]

> On Jul 13, 2016, at 11:20, O. Hartmann  wrote:
> 
> Am Wed, 13 Jul 2016 09:40:05 -0700
> David Wolfskill  schrieb:
> 
>> On Wed, Jul 13, 2016 at 06:35:10PM +0200, O. Hartmann wrote:
>>> make delete-old removes these files on CURRENT (FreeBSD 12.0-CURRENT #12 
>>> r302773: Wed
>>> Jul 13 18:10:55 CEST 2016), but they seem not to disappear. They are 
>>> present after an
>>> installation of world again and again:
>>> 
>>> [...]
>>> remove /usr/share/locale/kk_KZ.UTF-8/LC_COLLATE? y
>>> 
>> 
>> Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211046
>> 
>> (Above applies to both head & stable/11.)
>> 
>> Peace,
>> david
> 
> All right, I'm not the only one.

Fixed in ^/head@r302842; will be MFCed after a week to ^/stable/11 .
Thanks for the report!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

[Ngie Cooper (yaneurabeya)]

> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Paweł Tyll wrote on 07/12/2016 01:22:
> 
>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>> CD-R? :)
> 
> It is not only about the target media size. The size matters when you need to 
> boot some recovery media from you desktop on remote server via KVM.
> 
> And there is one thing I don't understand - why is the bootonly so large? I 
> remember days when this fits to 50MB and now it is almost 235MB which renders 
> it almost useless. For recoveries and remote installs I always use mfsbsd 
> images (about 45MB).

I wholeheartedly agree.

It sucks having to transfer more than 50 MB over our work link across a few 
thousand miles with IPMI remote KVM redirection.

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: More -Wformat warnings with r302403 -> Jenkins failure (was Re: FreeBSD_HEAD_amd64_gcc - Build #1358 - Still Failing)

[Ngie Cooper (yaneurabeya)]

> On Jul 8, 2016, at 09:12, Li-Wen Hsu  wrote:
> 
> On Fri, Jul 08, 2016 at 09:01:41 -0700, Ngie Cooper (yaneurabeya) wrote:
>> 
>> How were the copies of gcc48/gcc49/gcc5 installed on the Jenkins slaves and 
>> were they customized to include this support?
> 
> In short, it uses devel/amd64-xtoolchain-gcc .
> 
> That job basically executes this script:
> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
> 
> with TARGET_ARCH=TARGET_ARCH
> 
> And MAKE_CONF_FILE as:
> 
> NO_WERROR=yes
> WERROR=
> WITH_FAST_DEPEND=yes

Ok. I finally figured it out.

lang/gcc{48,49,5} lacks -fformat-extensions support, but devel/powerpc64-gcc 
has it. I will revert the commit to base and request an MFC to ^/stable/11. The 
support for -fformat-extensions needs to be added to lang/gcc* for consistency 
— I will file a ports bug for that.

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

More -Wformat warnings with r302403 -> Jenkins failure (was Re: FreeBSD_HEAD_amd64_gcc - Build #1358 - Still Failing)

[Ngie Cooper (yaneurabeya)]

> On Jul 8, 2016, at 05:17, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_amd64_gcc - Build #1358 - Still Failing:
> 
> Build information: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1358/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1358/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1358/console
> 
> Change summaries:
> 
> 302420 by gjb:
> Spell '12.x' correctly in UPDATING.
> 
> Submitted by: lidl
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 302419 by gjb:
> Spell 10.2, 10.3, 12.0 correctly in various places.
> 
> Submitted by: markj
> Approved by:  re (implicit)
> Pointyhat:gjb (myself)
> Sponsored by: The FreeBSD Foundation
> 
> 302418 by gjb:
> Add freebsd12 to contrib/gcc/config.gcc.
> 
> Submitted by: bdrewery
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 302417 by gjb:
> Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h
> 
> Submitted by: bdrewery
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 302414 by gjb:
> Default manual pages to 12.0 in head, and add missing 10.x
> releases.
> 
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 302413 by gjb:
> Spell 120 correctly.
> 
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 302409 by gjb:
> Reflect head is now 12.0-CURRENT.
> 
> Approved by:  re (implicit)
> Sponsored by: The FreeBSD Foundation
> 
> 
> 
> The end of the build log:
> 
> [...truncated 313350 lines...]
> /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
>  
> -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
>  
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
>  -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe 
> -fno-strict-aliasing  -g -nostdinc  -I. -I/builds/FreeBSD_HEAD_amd64_gcc/sys 
> -I/builds/FreeBSD_HEAD_amd64_gcc/sys/contrib/libfdt -D_KERNEL 
> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
> -mno-omit-leaf-frame-pointer -MD  -MF.depend.identcpu.o -MTidentcpu.o 
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign   -Wmissing-include-dirs -fdiagnostics-show-option  
> -Wno-unkno
> wn-pragmas  -Wno-error=inline -Wno-error=enum-compare 
> -Wno-error=unused-but-set-variable  -Wno-error=aggressive-loop-optimizations 
> -Wno-error=maybe-uninitialized  -Wno-error=array-bounds -Wno-error=address  
> -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes  
> -Wno-error=strict-overflow -Wno-error=overflow  -fno-common -fms-extensions 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -std=iso9899:1999   
> /builds/FreeBSD_HEAD_amd64_gcc/sys/x86/x86/identcpu.c
> --- dump_machdep.o ---
> ctfconvert -L VERSION -g dump_machdep.o
> --- intr_machdep.o ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
>  
> -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
>  
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
>  -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe 
> -fno-strict-aliasing  -g -nostdinc  -I. -I/builds/FreeBSD_HEAD_amd64_gcc/sys 
> -I/builds/FreeBSD_HEAD_amd64_gcc/sys/contrib/libfdt -D_KERNEL 
> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
> -mno-omit-leaf-frame-pointer -MD  -MF.depend.intr_machdep.o -MTintr_machdep.o 
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign   -Wmissing-include-dirs -fdiagnostics-show-option  -W
> no-unknown-pragmas  -Wno-error=inline -Wno-error=enum-compare 
> -Wno-error=unused-but-set-variable  -Wno-error=aggressive-loop-optimizations 
> -Wno-error=maybe-uninitialized  -Wno-error=array-bounds -Wno-error=address  
> -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes  
> -Wno-error=strict-overflow -Wno-error=overflow  -fno-common -fms-extensions 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -std=iso9899:1999   
> /builds/FreeBSD_HEAD_amd64_gcc/sys/x86/x86/intr_machdep.c
> --- identcpu.o ---
> /builds/FreeBSD_HEAD_amd64_gcc/sys/x86/x86/identcpu.c: In function 
> 'printcpuinfo':
> /builds/FreeBSD_HEAD_amd64_gcc/sys

clang 3.3/3.4 fails to build items that use stdlib.h because of __alloc_size attribute assigned to posix_memalign

[Ngie Cooper (yaneurabeya)]

Hi,
It looks like clang 3.3/3.4 from ports both don’t like __alloc_size 
being attached to posix_memalign. This only concerns me because it might make 
the src upgrade path from 9.3/10.3 to 11.0 painful.
Thoughts on how this should be fixed or whether or not we care?
Thanks,
-Ngie

$ cd usr.sbin/bhyve; make clean; script ts make all CC=clang34
...
In file included from /usr/src/svn/usr.sbin/bhyve/atkbdc.c:40:
/usr/include/stdlib.h:176:6: error: '__alloc_size__' attribute only applies to 
functions that return a pointer [-Werror,-Wignored-attributes]
__alloc_size(3);/* (ADV) */
^
/usr/include/sys/cdefs.h:241:40: note: expanded from macro '__alloc_size'
#define __alloc_size(x) __attribute__((__alloc_size__(x)))
   ^
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/src/svn/usr.sbin/bhyve
$ (set -x; clang33 --version; clang34 --version)
+ clang33 --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-portbld-freebsd11.0
Thread model: posix
+ clang34 --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-portbld-freebsd11.0
Thread model: posix

282988pfg intposix_memalign(void **, size_t, size_t) __nonnull(1) 
__alloc_align(2)
281130pfg   __alloc_size(3);/* (ADV) */


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing

[Ngie Cooper (yaneurabeya)]

> On Jul 5, 2016, at 12:29, Ngie Cooper (yaneurabeya)  
> wrote:

…

> Actually, there’s a better #define:
> 
> /usr/include/x86/specialreg.h:#define   CPUID2_SSE410x0008

Submitted a potential fix via: https://reviews.freebsd.org/D7119 .
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing

[Ngie Cooper (yaneurabeya)]

> On Jul 5, 2016, at 11:54, Ngie Cooper (yaneurabeya)  
> wrote:
> 
>> 
>> On Jul 5, 2016, at 11:52, Dimitry Andric  wrote:
>> 
>> On 05 Jul 2016, at 18:03, jenkins-ad...@freebsd.org wrote:
>>> 
>>> FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
>>> 
>>> Build information: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/
>>> Full change log: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/changes
>>> Full build log: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/console
>> ...
>>> /builds/FreeBSD_HEAD_amd64_gcc/usr.sbin/bhyve/rfb.c: In function 
>>> 'sse42_supported':
>>> /builds/FreeBSD_HEAD_amd64_gcc/usr.sbin/bhyve/rfb.c:885:17: error: 
>>> 'bit_SSE42' undeclared (first use in this function)
>>> return ((ecx & bit_SSE42) != 0);
>>>   ^
>> 
>> So, this is because clang's and gcc's versions of cpuid.h use slightly 
>> different naming for these bits:
>> 
>> clang's cpuid.h:
>> 
>> #define bit_SSE41   0x0008
>> #define bit_SSE42   0x0010
>> 
>> gcc's cpuid.h:
>> 
>> #define bit_SSE4_1  (1 << 19)
>> #define bit_SSE4_2  (1 << 20)
>> 
>> Unfortunately there are more bit defines that differ.  No standardization on 
>> this point, it seems. :-/
>> 
>> For this specific compile error, we could put in a little crutch like:
>> 
>> #if defined(bit_SSE4_2) && !defined(bit_SSE42)
>> #define bit_SSE42 bit_SSE4_2
>> #endif
>> 
>> Thoughts?
> 
>   Seems ok to me. I was going to submit a patch to fix the other issues 
> with bhyve (because I am getting annoyed by the build failure emails).

Actually, there’s a better #define:

/usr/include/x86/specialreg.h:#define   CPUID2_SSE410x0008

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing

[Ngie Cooper (yaneurabeya)]

> On Jul 5, 2016, at 11:52, Dimitry Andric  wrote:
> 
> On 05 Jul 2016, at 18:03, jenkins-ad...@freebsd.org wrote:
>> 
>> FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
>> 
>> Build information: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/
>> Full change log: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/changes
>> Full build log: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/console
> ...
>> /builds/FreeBSD_HEAD_amd64_gcc/usr.sbin/bhyve/rfb.c: In function 
>> 'sse42_supported':
>> /builds/FreeBSD_HEAD_amd64_gcc/usr.sbin/bhyve/rfb.c:885:17: error: 
>> 'bit_SSE42' undeclared (first use in this function)
>> return ((ecx & bit_SSE42) != 0);
>>^
> 
> So, this is because clang's and gcc's versions of cpuid.h use slightly 
> different naming for these bits:
> 
> clang's cpuid.h:
> 
> #define bit_SSE41   0x0008
> #define bit_SSE42   0x0010
> 
> gcc's cpuid.h:
> 
> #define bit_SSE4_1  (1 << 19)
> #define bit_SSE4_2  (1 << 20)
> 
> Unfortunately there are more bit defines that differ.  No standardization on 
> this point, it seems. :-/
> 
> For this specific compile error, we could put in a little crutch like:
> 
> #if defined(bit_SSE4_2) && !defined(bit_SSE42)
> #define bit_SSE42 bit_SSE4_2
> #endif
> 
> Thoughts?

Seems ok to me. I was going to submit a patch to fix the other issues 
with bhyve (because I am getting annoyed by the build failure emails).
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode

[Ngie Cooper (yaneurabeya)]

> On Jun 13, 2016, at 06:57, Joel Dahl  wrote:
> 
> Hi,
> 
> I've just rebuilt and installed latest current on a machine here. I noticed
> the following message in dmesg after a reboot:
> 
> _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode
> 
> I don't remember seeing this before.

Hi Joe,
Try reverting r301867. Let Robert know if that fixes your issue.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: smartmontools now broken on -current (by svn r301771, r301778?)

[Ngie Cooper (yaneurabeya)]

> On Jun 11, 2016, at 09:40, Michael Butler  wrote:
> 
> The recent nvme updates have broken smartmontools ..
> 
> imb@toshi:/home/imb> sudo smartctl -a /dev/ada0
> smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-ALPHA2 amd64] (local build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> /dev/ada0: Inappropriate ioctl for device
> Please specify device type with the -d option.
> 
> Attempts to recompile the utility also fail:

Hi Michael,
Please file a bug — in ports first, and if necessary in the base system.
Thank you!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket

[Ngie Cooper (yaneurabeya)]

> On May 29, 2016, at 00:32, O. Hartmann  wrote:
> 
> After updating sources and build- and installworld, I realize that all 
> rpcbind related
> services, so far NFS, are not working. On a client I check the start of 
> rpcbind by
> setting option -d and receive the output shown below.
> 
> Well, prior to r300949 rpcbind started without complains - as it did with 
> r300901.
> 
> [...]
> rpcbind not running?
> Starting rpcbind.
> rpcbind debugging enabled.
> can't get local ip6 address: hostname nor servname provided, or not known
> couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start rpcbind

Hi,
Could you please try this patch with -d (it’ll continue on instead of 
exiting… I’m curious as to why it was failing before).
Does IPv6 work in your environment?
Thanks!
-Ngie


ohartmann-rpcbind-util-break.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: installworld woes

[Ngie Cooper (yaneurabeya)]

> On May 28, 2016, at 17:31, Shawn Webb  wrote:

…

> No worries. No rush here. I appreciate the help! Can you add “Reported by: 
> HardenedBSD” to the commit log?

Fixed in r300922 — thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: exports(5) no longer allows multiple paths per line?

[Ngie Cooper (yaneurabeya)]

> On May 26, 2016, at 23:28, Ed Schouten  wrote:
> 
> Hi there,
> 
> 2016-05-27 4:12 GMT+02:00 Ngie Cooper :
>>It seems like the following /etc/exports should work, but for some
>> odd reason specifying both paths on a single line doesn't work (I
>> swore it was working on a kernel/userland built in the past month,
>> i.e. ^/head@r297950, but I might be misremembering things).
> 
> I'm not sure, but I seem to remember that an entry may only apply to a
> single filesystem. In your case, /tftpboot and /home/ngie are both on
> different filesystems, right? That's why you need two separate
> entries.

Hi Ed,
Oy, I was misreading things and likely changed my mount points between 
when I restarted mountd.. Rereading exports(4) it’s an NFSv3 exports/mountd 
implementation item on FreeBSD — NFSv4 doesn’t necessarily have the same 
limitations.
Thanks for clarifying that!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libarchive update SVN r299529 breaks "ezjail update"

[Ngie Cooper (yaneurabeya)]

> On May 14, 2016, at 16:29, Martin Matuska  wrote:
> 
> Ian, we are here talking about cpio, not libarchive. The flag in
> libarchive is not active by default.
> 
> On 14.05.2016 22:08, Ian Lepore wrote:

>> The real damage will happen to out-of-tree users.  I think this will
>> impact our software updater for $work for example, and it has to work
>> with both old and new versions of libarchive, and now the new version
>> will require a flag that the old version will reject as unknown.
>> 
>> Ick.

Ian’s comment was valid.. cpio doesn’t recognize the new switch on older 
versions, so something like cpio `cpio --help | grep -- switch && echo switch` 
would need to be employed everywhere for backwards compatibility — ew.
Thanks,
-Ngie
___
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: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:59, Ben Woods  wrote:
> 
> On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya)  
> wrote:
> glebius changed the defaults to fix POLA, but the naming per the behavior is 
> confusing. Right now the behavior between ^/head and ^/stable/10 before/now 
> match -- I just had to wrap my mind around the default being the affirmative 
> of a negative (i.e. only install one kernel, as opposed to install all extra 
> kernels by default).
> -Ngie
> 
> Indeed, I am not sure I understand the POLA violation entirely (ignoring the 
> fact that this variable requires affirmation of a negative).

It’s tricky… KERNCONF with multiple kernel configurations wasn’t properly 
supported at install time until 2016 AFAIK (r291611, r293391), so again (AFAIK) 
it’s a new [functional] feature, even though make.conf(5) says one can specify 
multiple kernel configurations in KERNCONF at build time.

> If you list 2 kernels in the KERNCONF variable, why is it astonishing that 2 
> kernels get installed? Even if the old behaviour was to only install 1 
> kernel, if you are listing 2 kernels in KERNCONF presumably that is because 
> you want to install 2 kernels?

From a literal perspective, it makes perfect sense. From a usability 
perspective though, or in terms of actual behavior, it makes less sense.

If FreeBSD required more explicit pathing for kernels like Linux in the boot 
loader (e.g. grub) on many distros (e.g. CentOS), this would likely be a 
non-issue.

> Regardless, perhaps it is ok to leave behaviour on stable 9/10 unchanged, but 
> to make the behaviour on head to install multiple kernels by default? That is 
> the option that makes sense for PkgBase (build multiple kernel packages if 
> more than one are listed in KERNCONF).

Yes, but the knob should be renamed for clarity. imp@ had a very good point — 
NO_* options aren’t as flexible/intuitive as MK_* options and lead to confusing 
behavior.

Thanks!
-Ngie
___
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: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:46, Ben Woods  wrote:
> 
> 
> On 7 May 2016 at 09:41, Glen Barber  wrote:
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?
> 
> Glen
> 
> I am talking about head, which no longer installs/packages multiple kernels 
> by default.
> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088&view=markup
> 
> Whilst the r299088 commit is referring to a stable POLA violation, the commit 
> itself is a change to head with a proposed MFC after 3 days. Its interesting, 
> because this has surprised me when testing PkgBase on head, as the behaviour 
> has changed from the initial announcement.

The behavior in and of itself (to me) is unintuitive. I use a different wrapper 
script [*] to install kernels with a different name because I want them to be 
versioned based on $KERNCONF + revision data. I only fixed building multiple 
kernels because the change that glebius tested didn’t work with more than one 
KERNCONF (hence the double commit).

I think the default behavior should be “yes” (not “no”) as many folks use a 
single KERNCONF, not multiple (on head), but I’m biased in this thinking...

Thanks!
-Ngie

* 
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/root/bin/installkernel.sh
___
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: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:41, Glen Barber  wrote:
> 
> On Sat, May 07, 2016 at 12:35:10AM -0700, Ngie Cooper (yaneurabeya) wrote:
>> (Replying because I kicked the hornet’s nest when my build failed)
>> Hi Ben,
>> 
>>> On May 7, 2016, at 00:27, Ben Woods  wrote:
>>> 
>>> On Saturday, 7 May 2016, Glen Barber  wrote:
>>> 
>>>> With 'installkernel', the first kernel listed in KERNCONF is installed
>>>> as the default (/boot/kernel), and subsequent kernels are installed with
>>>> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
>>>> both cases (source-based upgrades and with pkgbase), the behavior will
>>>> remain the same.
>>>> 
>>>> Glen
>>>> 
>>> 
>>> Hi Glen,
>>> 
>>> With the recent commit mentioned previously, only the first kernel listed
>>> in KERNCONF is installed unless make.conf contains the following line:
>>> NO_INSTALLEXTRAKERNELS=no
>>> 
>>> This affects both source-based upgrades (make installkernel) and package
>>> building (make packages).
>>> 
>>> Is this the desired behaviour?
>> 
>> The naming is very confusing. It should be:
>> 
>> - MK_INSTALLEXTRAKERNELS=no -> only install one
>> - MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.
>> 
>> Since I kicked the hornet’s nest (and imp@ complained about the
>> NO_*), I’ll introduce a new WITH/WITHOUT option for this and
>> release/release.sh can use it.
>> 
> 
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?

glebius changed the defaults to fix POLA, but the naming per the behavior is 
confusing. Right now the behavior between ^/head and ^/stable/10 before/now 
match -- I just had to wrap my mind around the default being the affirmative of 
a negative (i.e. only install one kernel, as opposed to install all extra 
kernels by default).
-Ngie
___
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: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

(Replying because I kicked the hornet’s nest when my build failed)
Hi Ben,

> On May 7, 2016, at 00:27, Ben Woods  wrote:
> 
> On Saturday, 7 May 2016, Glen Barber  wrote:
> 
>> With 'installkernel', the first kernel listed in KERNCONF is installed
>> as the default (/boot/kernel), and subsequent kernels are installed with
>> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
>> both cases (source-based upgrades and with pkgbase), the behavior will
>> remain the same.
>> 
>> Glen
>> 
> 
> Hi Glen,
> 
> With the recent commit mentioned previously, only the first kernel listed
> in KERNCONF is installed unless make.conf contains the following line:
> NO_INSTALLEXTRAKERNELS=no
> 
> This affects both source-based upgrades (make installkernel) and package
> building (make packages).
> 
> Is this the desired behaviour?

The naming is very confusing. It should be:

- MK_INSTALLEXTRAKERNELS=no -> only install one
- MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.

Since I kicked the hornet’s nest (and imp@ complained about the NO_*), I’ll 
introduce a new WITH/WITHOUT option for this and release/release.sh can use it.

Thanks!
-Ngie
___
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: for the build aversed

[Ngie Cooper (yaneurabeya)]

> On May 4, 2016, at 18:13, Steve Kargl  
> wrote:
> 
> Index: lib/libkvm/kvm_cptime.c
> ===
> --- lib/libkvm/kvm_cptime.c (revision 299099)
> +++ lib/libkvm/kvm_cptime.c (working copy)
> @@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$");
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 
> Index: lib/libkvm/kvm_pcpu.c
> ===
> --- lib/libkvm/kvm_pcpu.c   (revision 299099)
> +++ lib/libkvm/kvm_pcpu.c   (working copy)
> @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 

I hit this on my box too. I’m going to revert r299096 — it needs to be tested, 
and also probably needs an exp run to make sure it doesn’t break downstream 
consumers.
___
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: please test your commits

[Ngie Cooper (yaneurabeya)]

> On May 4, 2016, at 17:56, Steve Kargl  
> wrote:
> 
> % make -j7  buildworld |& tee sgk.log
> 
> --- lib/libkvm__L ---
> In file included from /usr/src/lib/libkvm/kvm_pcpu.c:43:
> /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name 
> 'device_t'
>device_tpc_device;
>^

Adrian CCed.
___
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_HEAD_i386 - Build #2857 - Still Failing

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2016, at 19:14, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #2857 - Still Failing:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/console
> 
> Change summaries:
> 
> 298018 by araujo:
> Initialize pointer with NULL instead of 0.
> 
> Submitted by: pfg
> 
> 298017 by asomers:
> Add more debugging statements in vdev_geom.c
> 
> Log a debugging message whenever geom functions fail in vdev_geom_attach.
> Printing these messages is controlled by vfs.zfs.debug
> 
> MFC after:4 weeks
> Sponsored by: Spectra Logic Corp
> 

...

> ctfconvert -L VERSION -g ar5111.o
> --- all_subdir_cam ---
> /usr/src/sys/modules/cam/../../cam/scsi/scsi_da.c:1274:1: error: incompatible 
> pointer types initializing 'long *' with an expression of type 'sbintime_t *' 
> (aka 'long long *') [-Werror,-Wincompatible-pointer-types]
> TUNABLE_LONG("kern.cam.da.default_softtimeout", &da_default_softtimeout);
> ^~~~
> /usr/src/sys/sys/kernel.h:292:3: note: expanded from macro 'TUNABLE_LONG'
>(var),  \
>^
> --- all_subdir_ath ---
> --- ar5112.o ---
> cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
> -I. -I/usr/src/sys/modules/ath/../../dev/ath 
> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. 
> -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> -DHAVE_KERNEL_OPTION_HEADERS -include 
> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
> -I/usr/obj/usr/src/sys/GENERIC  -MD  -MF.depend.ar5112.o -MTar5112.o -mno-mmx 
> -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 
> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option  -Wno-unknown-pragmas  
> -Wno-error-tautological-compare -Wno-error-empty-body  
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
> -std=iso9899:1999 -c /usr/src/sys/modules/ath/../../dev
> /ath/ath_hal/ar5212/ar5112.c -o ar5112.o
> --- all_subdir_cam ---
> 1 error generated.
> *** [scsi_da.o] Error code 1
> 
> bmake[4]: stopped in /usr/src/sys/modules/cam
> 1 error

Build’s still broken..
___
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"