Re: [DISCUSS] Release Notes

2020-04-10 Thread Abdelatif Guettouche
> I don't need them anymore.

Okay. I removed them.

I also tried to re-organize a little bit.  Please refer to this
version of the document to have a look at the original organization:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645728

"Bug fixes" under "Major Changes to Core OS" should only contain bug
fixes to the OS not arch or drivers.
Similarly, "Security Issues Fixed in this Release" should contain only
security vulnerabilities.


On Fri, Apr 10, 2020 at 2:58 AM Nathan Hartman  wrote:
>
> On Thu, Apr 9, 2020 at 7:09 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Also, I didn't want to remove the PRs number, maybe Nathan still needs
> > them.
>
>
> I don't need them anymore.
>
> Initially I thought that when writing the release notes, we could (in
> parenthesis) link to the corresponding PR and/or Issue number(s) for anyone
> reading the release notes who might be interested in seeing more about a
> particular change. But I forgot to mention that so we can go ahead and
> remove them.
>
> Cheers,
> Nathan


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Abdelatif Guettouche
> Speaking about the branch, Brennan is suggesting to have a different
> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
> reasons behind this are here:
> https://github.com/apache/incubator-nuttx/pull/757)

Is everyone okay with changing the branches naming convention?
I personally do not mind.

For that PR, I asked Brennan on how to proceed with signing the tarballs.
The original flow was:
1. Generate the tarballs
2. Sign the tarballs and create the hashes.
3. Then upload everything (tarballs, hashes, signatures)
Everything was done locally and then uploaded.
With the PR757 the release tarballs are generated with a push to the
release branch.
Do we download them, sign and then upload the signatures?
We need at least one way to check the downloads before signing, like
by creating the hashes with the tarballs.


On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>
> Xiang,
>
> Ok, thanks. It's great that this doesn't block the release!
>
> -adam
>
> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao  wrote:
>
> > This build error happen for several special config only, and already exist
> >
> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer  wrote:
> > >
> > > Xiang,
> > >
> > > Do the parallel build failures block our release? If so, what can we do
> >
> > Shouldn't, because:
> > 1.The build error already exist for a long time
> > 2.Only several seldom used configs(all related to binfmt/module/so)
> > hit this issue
> > 3.The single thread build can always finish successfully
> >
> > > temporarily to unblock it? Or is there a fix in the works that will be
> > > ready soon?
> > >
> >
> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent
> > month, some issue get fixed, but some need more time to investigate.
> >
> > > -adam
> > >
> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao 
> > wrote:
> > >
> > > > At least, the parallel build still fail randomly which block our
> > > > nightly checker.
> >
>
>
> --
> Adam Feuer 


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Alan Carvalho de Assis
Hi guys,

I finished including the apps/ improvements and bugfixes.

Is there anything else we need to take care?

BR,

Alan

On 4/10/20, Abdelatif Guettouche  wrote:
>> Speaking about the branch, Brennan is suggesting to have a different
>> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
>> reasons behind this are here:
>> https://github.com/apache/incubator-nuttx/pull/757)
>
> Is everyone okay with changing the branches naming convention?
> I personally do not mind.
>
> For that PR, I asked Brennan on how to proceed with signing the tarballs.
> The original flow was:
> 1. Generate the tarballs
> 2. Sign the tarballs and create the hashes.
> 3. Then upload everything (tarballs, hashes, signatures)
> Everything was done locally and then uploaded.
> With the PR757 the release tarballs are generated with a push to the
> release branch.
> Do we download them, sign and then upload the signatures?
> We need at least one way to check the downloads before signing, like
> by creating the hashes with the tarballs.
>
>
> On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>>
>> Xiang,
>>
>> Ok, thanks. It's great that this doesn't block the release!
>>
>> -adam
>>
>> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao 
>> wrote:
>>
>> > This build error happen for several special config only, and already
>> > exist
>> >
>> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer  wrote:
>> > >
>> > > Xiang,
>> > >
>> > > Do the parallel build failures block our release? If so, what can we
>> > > do
>> >
>> > Shouldn't, because:
>> > 1.The build error already exist for a long time
>> > 2.Only several seldom used configs(all related to binfmt/module/so)
>> > hit this issue
>> > 3.The single thread build can always finish successfully
>> >
>> > > temporarily to unblock it? Or is there a fix in the works that will
>> > > be
>> > > ready soon?
>> > >
>> >
>> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent
>> > month, some issue get fixed, but some need more time to investigate.
>> >
>> > > -adam
>> > >
>> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao 
>> > wrote:
>> > >
>> > > > At least, the parallel build still fail randomly which block our
>> > > > nightly checker.
>> >
>>
>>
>> --
>> Adam Feuer 
>


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Adam Feuer
Alan,

Next we need to check for features/improvements and bugfixes between 23
December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
November 2019, the date of NuttX release 8.2. The main source of info for
this would be commit messages in the current master branch.

Would you be willing to look through those? Or figure out a way to divide
them up among you, me, Nathan, and Abdelatif?

-adam

On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis 
wrote:

> Hi guys,
>
> I finished including the apps/ improvements and bugfixes.
>
> Is there anything else we need to take care?
>
> BR,
>
> Alan
>
> On 4/10/20, Abdelatif Guettouche  wrote:
> >> Speaking about the branch, Brennan is suggesting to have a different
> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
> >> reasons behind this are here:
> >> https://github.com/apache/incubator-nuttx/pull/757)
> >
> > Is everyone okay with changing the branches naming convention?
> > I personally do not mind.
> >
> > For that PR, I asked Brennan on how to proceed with signing the tarballs.
> > The original flow was:
> > 1. Generate the tarballs
> > 2. Sign the tarballs and create the hashes.
> > 3. Then upload everything (tarballs, hashes, signatures)
> > Everything was done locally and then uploaded.
> > With the PR757 the release tarballs are generated with a push to the
> > release branch.
> > Do we download them, sign and then upload the signatures?
> > We need at least one way to check the downloads before signing, like
> > by creating the hashes with the tarballs.
> >
> >
> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
> >>
> >> Xiang,
> >>
> >> Ok, thanks. It's great that this doesn't block the release!
> >>
> >> -adam
> >>
> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao 
> >> wrote:
> >>
> >> > This build error happen for several special config only, and already
> >> > exist
> >> >
> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer  wrote:
> >> > >
> >> > > Xiang,
> >> > >
> >> > > Do the parallel build failures block our release? If so, what can we
> >> > > do
> >> >
> >> > Shouldn't, because:
> >> > 1.The build error already exist for a long time
> >> > 2.Only several seldom used configs(all related to binfmt/module/so)
> >> > hit this issue
> >> > 3.The single thread build can always finish successfully
> >> >
> >> > > temporarily to unblock it? Or is there a fix in the works that will
> >> > > be
> >> > > ready soon?
> >> > >
> >> >
> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent
> >> > month, some issue get fixed, but some need more time to investigate.
> >> >
> >> > > -adam
> >> > >
> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
> xiaoxiang781...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > At least, the parallel build still fail randomly which block our
> >> > > > nightly checker.
> >> >
> >>
> >>
> >> --
> >> Adam Feuer 
> >
>


-- 
Adam Feuer 


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Adam Feuer
P.S. I think this would have to be done for both nuttx and nuttx-apps.

On Fri, Apr 10, 2020 at 10:43 AM Adam Feuer  wrote:

> Alan,
>
> Next we need to check for features/improvements and bugfixes between 23
> December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
> November 2019, the date of NuttX release 8.2. The main source of info for
> this would be commit messages in the current master branch.
>
> Would you be willing to look through those? Or figure out a way to divide
> them up among you, me, Nathan, and Abdelatif?
>
> -adam
>
> On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis 
> wrote:
>
>> Hi guys,
>>
>> I finished including the apps/ improvements and bugfixes.
>>
>> Is there anything else we need to take care?
>>
>> BR,
>>
>> Alan
>>
>> On 4/10/20, Abdelatif Guettouche  wrote:
>> >> Speaking about the branch, Brennan is suggesting to have a different
>> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
>> >> reasons behind this are here:
>> >> https://github.com/apache/incubator-nuttx/pull/757)
>> >
>> > Is everyone okay with changing the branches naming convention?
>> > I personally do not mind.
>> >
>> > For that PR, I asked Brennan on how to proceed with signing the
>> tarballs.
>> > The original flow was:
>> > 1. Generate the tarballs
>> > 2. Sign the tarballs and create the hashes.
>> > 3. Then upload everything (tarballs, hashes, signatures)
>> > Everything was done locally and then uploaded.
>> > With the PR757 the release tarballs are generated with a push to the
>> > release branch.
>> > Do we download them, sign and then upload the signatures?
>> > We need at least one way to check the downloads before signing, like
>> > by creating the hashes with the tarballs.
>> >
>> >
>> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>> >>
>> >> Xiang,
>> >>
>> >> Ok, thanks. It's great that this doesn't block the release!
>> >>
>> >> -adam
>> >>
>> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao 
>> >> wrote:
>> >>
>> >> > This build error happen for several special config only, and already
>> >> > exist
>> >> >
>> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer  wrote:
>> >> > >
>> >> > > Xiang,
>> >> > >
>> >> > > Do the parallel build failures block our release? If so, what can
>> we
>> >> > > do
>> >> >
>> >> > Shouldn't, because:
>> >> > 1.The build error already exist for a long time
>> >> > 2.Only several seldom used configs(all related to binfmt/module/so)
>> >> > hit this issue
>> >> > 3.The single thread build can always finish successfully
>> >> >
>> >> > > temporarily to unblock it? Or is there a fix in the works that will
>> >> > > be
>> >> > > ready soon?
>> >> > >
>> >> >
>> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent
>> >> > month, some issue get fixed, but some need more time to investigate.
>> >> >
>> >> > > -adam
>> >> > >
>> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
>> xiaoxiang781...@gmail.com>
>> >> > wrote:
>> >> > >
>> >> > > > At least, the parallel build still fail randomly which block our
>> >> > > > nightly checker.
>> >> >
>> >>
>> >>
>> >> --
>> >> Adam Feuer 
>> >
>>
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Nathan Hartman
On Fri, Apr 10, 2020 at 1:44 PM Adam Feuer  wrote:
> Next we need to check for features/improvements and bugfixes between 23
> December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
> November 2019, the date of NuttX release 8.2. The main source of info for
> this would be commit messages in the current master branch.
>
> Would you be willing to look through those? Or figure out a way to divide
> them up among you, me, Nathan, and Abdelatif?

Let's split them up 3 ways.

Is this incantation producing the correct range?

git log --since 2019/11/16 --until 2019/12/23 --oneline

Asking because this would seem to indicate otherwise:

https://stackoverflow.com/questions/37311494/how-to-get-git-to-show-commits-in-a-specified-date-range-for-author-date

Thanks,
Nathan


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Alan Carvalho de Assis
Hi Adam,

Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
tag. But I didn't checked for improvements because I thought you,
Nathan and Abdelatif did it.

I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no problem.

BR,

Alan

On 4/10/20, Adam Feuer  wrote:
> Alan,
>
> Next we need to check for features/improvements and bugfixes between 23
> December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
> November 2019, the date of NuttX release 8.2. The main source of info for
> this would be commit messages in the current master branch.
>
> Would you be willing to look through those? Or figure out a way to divide
> them up among you, me, Nathan, and Abdelatif?
>
> -adam
>
> On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis 
> wrote:
>
>> Hi guys,
>>
>> I finished including the apps/ improvements and bugfixes.
>>
>> Is there anything else we need to take care?
>>
>> BR,
>>
>> Alan
>>
>> On 4/10/20, Abdelatif Guettouche  wrote:
>> >> Speaking about the branch, Brennan is suggesting to have a different
>> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
>> >> reasons behind this are here:
>> >> https://github.com/apache/incubator-nuttx/pull/757)
>> >
>> > Is everyone okay with changing the branches naming convention?
>> > I personally do not mind.
>> >
>> > For that PR, I asked Brennan on how to proceed with signing the
>> > tarballs.
>> > The original flow was:
>> > 1. Generate the tarballs
>> > 2. Sign the tarballs and create the hashes.
>> > 3. Then upload everything (tarballs, hashes, signatures)
>> > Everything was done locally and then uploaded.
>> > With the PR757 the release tarballs are generated with a push to the
>> > release branch.
>> > Do we download them, sign and then upload the signatures?
>> > We need at least one way to check the downloads before signing, like
>> > by creating the hashes with the tarballs.
>> >
>> >
>> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>> >>
>> >> Xiang,
>> >>
>> >> Ok, thanks. It's great that this doesn't block the release!
>> >>
>> >> -adam
>> >>
>> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao 
>> >> wrote:
>> >>
>> >> > This build error happen for several special config only, and already
>> >> > exist
>> >> >
>> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer  wrote:
>> >> > >
>> >> > > Xiang,
>> >> > >
>> >> > > Do the parallel build failures block our release? If so, what can
>> >> > > we
>> >> > > do
>> >> >
>> >> > Shouldn't, because:
>> >> > 1.The build error already exist for a long time
>> >> > 2.Only several seldom used configs(all related to binfmt/module/so)
>> >> > hit this issue
>> >> > 3.The single thread build can always finish successfully
>> >> >
>> >> > > temporarily to unblock it? Or is there a fix in the works that
>> >> > > will
>> >> > > be
>> >> > > ready soon?
>> >> > >
>> >> >
>> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the
>> >> > recent
>> >> > month, some issue get fixed, but some need more time to investigate.
>> >> >
>> >> > > -adam
>> >> > >
>> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
>> xiaoxiang781...@gmail.com>
>> >> > wrote:
>> >> > >
>> >> > > > At least, the parallel build still fail randomly which block our
>> >> > > > nightly checker.
>> >> >
>> >>
>> >>
>> >> --
>> >> Adam Feuer 
>> >
>>
>
>
> --
> Adam Feuer 
>


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Adam Feuer
Ok thanks Alan. I'm sorry I wasn't clear about what we had done.

-adam

On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis 
wrote:

> Hi Adam,
>
> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
> tag. But I didn't checked for improvements because I thought you,
> Nathan and Abdelatif did it.
>
> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no
> problem.
>
> BR,
>
> Alan
>
> On 4/10/20, Adam Feuer  wrote:
> > Alan,
> >
> > Next we need to check for features/improvements and bugfixes between 23
> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
> > November 2019, the date of NuttX release 8.2. The main source of info for
> > this would be commit messages in the current master branch.
> >
> > Would you be willing to look through those? Or figure out a way to divide
> > them up among you, me, Nathan, and Abdelatif?
> >
> > -adam
> >
> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis <
> acas...@gmail.com>
> > wrote:
> >
> >> Hi guys,
> >>
> >> I finished including the apps/ improvements and bugfixes.
> >>
> >> Is there anything else we need to take care?
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 4/10/20, Abdelatif Guettouche 
> wrote:
> >> >> Speaking about the branch, Brennan is suggesting to have a different
> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
> >> >> reasons behind this are here:
> >> >> https://github.com/apache/incubator-nuttx/pull/757)
> >> >
> >> > Is everyone okay with changing the branches naming convention?
> >> > I personally do not mind.
> >> >
> >> > For that PR, I asked Brennan on how to proceed with signing the
> >> > tarballs.
> >> > The original flow was:
> >> > 1. Generate the tarballs
> >> > 2. Sign the tarballs and create the hashes.
> >> > 3. Then upload everything (tarballs, hashes, signatures)
> >> > Everything was done locally and then uploaded.
> >> > With the PR757 the release tarballs are generated with a push to the
> >> > release branch.
> >> > Do we download them, sign and then upload the signatures?
> >> > We need at least one way to check the downloads before signing, like
> >> > by creating the hashes with the tarballs.
> >> >
> >> >
> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
> >> >>
> >> >> Xiang,
> >> >>
> >> >> Ok, thanks. It's great that this doesn't block the release!
> >> >>
> >> >> -adam
> >> >>
> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao  >
> >> >> wrote:
> >> >>
> >> >> > This build error happen for several special config only, and
> already
> >> >> > exist
> >> >> >
> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer 
> wrote:
> >> >> > >
> >> >> > > Xiang,
> >> >> > >
> >> >> > > Do the parallel build failures block our release? If so, what can
> >> >> > > we
> >> >> > > do
> >> >> >
> >> >> > Shouldn't, because:
> >> >> > 1.The build error already exist for a long time
> >> >> > 2.Only several seldom used configs(all related to binfmt/module/so)
> >> >> > hit this issue
> >> >> > 3.The single thread build can always finish successfully
> >> >> >
> >> >> > > temporarily to unblock it? Or is there a fix in the works that
> >> >> > > will
> >> >> > > be
> >> >> > > ready soon?
> >> >> > >
> >> >> >
> >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the
> >> >> > recent
> >> >> > month, some issue get fixed, but some need more time to
> investigate.
> >> >> >
> >> >> > > -adam
> >> >> > >
> >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
> >> xiaoxiang781...@gmail.com>
> >> >> > wrote:
> >> >> > >
> >> >> > > > At least, the parallel build still fail randomly which block
> our
> >> >> > > > nightly checker.
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Adam Feuer 
> >> >
> >>
> >
> >
> > --
> > Adam Feuer 
> >
>


-- 
Adam Feuer 


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Alan Carvalho de Assis
Ok, done!

On 4/10/20, Alan Carvalho de Assis  wrote:
> Hi Adam,
>
> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
> tag. But I didn't checked for improvements because I thought you,
> Nathan and Abdelatif did it.
>
> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no
> problem.
>
> BR,
>
> Alan
>
> On 4/10/20, Adam Feuer  wrote:
>> Alan,
>>
>> Next we need to check for features/improvements and bugfixes between 23
>> December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
>> November 2019, the date of NuttX release 8.2. The main source of info for
>> this would be commit messages in the current master branch.
>>
>> Would you be willing to look through those? Or figure out a way to divide
>> them up among you, me, Nathan, and Abdelatif?
>>
>> -adam
>>
>> On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis
>> 
>> wrote:
>>
>>> Hi guys,
>>>
>>> I finished including the apps/ improvements and bugfixes.
>>>
>>> Is there anything else we need to take care?
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 4/10/20, Abdelatif Guettouche  wrote:
>>> >> Speaking about the branch, Brennan is suggesting to have a different
>>> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the
>>> >> reasons behind this are here:
>>> >> https://github.com/apache/incubator-nuttx/pull/757)
>>> >
>>> > Is everyone okay with changing the branches naming convention?
>>> > I personally do not mind.
>>> >
>>> > For that PR, I asked Brennan on how to proceed with signing the
>>> > tarballs.
>>> > The original flow was:
>>> > 1. Generate the tarballs
>>> > 2. Sign the tarballs and create the hashes.
>>> > 3. Then upload everything (tarballs, hashes, signatures)
>>> > Everything was done locally and then uploaded.
>>> > With the PR757 the release tarballs are generated with a push to the
>>> > release branch.
>>> > Do we download them, sign and then upload the signatures?
>>> > We need at least one way to check the downloads before signing, like
>>> > by creating the hashes with the tarballs.
>>> >
>>> >
>>> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>>> >>
>>> >> Xiang,
>>> >>
>>> >> Ok, thanks. It's great that this doesn't block the release!
>>> >>
>>> >> -adam
>>> >>
>>> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao 
>>> >> wrote:
>>> >>
>>> >> > This build error happen for several special config only, and
>>> >> > already
>>> >> > exist
>>> >> >
>>> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer 
>>> >> > wrote:
>>> >> > >
>>> >> > > Xiang,
>>> >> > >
>>> >> > > Do the parallel build failures block our release? If so, what can
>>> >> > > we
>>> >> > > do
>>> >> >
>>> >> > Shouldn't, because:
>>> >> > 1.The build error already exist for a long time
>>> >> > 2.Only several seldom used configs(all related to binfmt/module/so)
>>> >> > hit this issue
>>> >> > 3.The single thread build can always finish successfully
>>> >> >
>>> >> > > temporarily to unblock it? Or is there a fix in the works that
>>> >> > > will
>>> >> > > be
>>> >> > > ready soon?
>>> >> > >
>>> >> >
>>> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the
>>> >> > recent
>>> >> > month, some issue get fixed, but some need more time to
>>> >> > investigate.
>>> >> >
>>> >> > > -adam
>>> >> > >
>>> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
>>> xiaoxiang781...@gmail.com>
>>> >> > wrote:
>>> >> > >
>>> >> > > > At least, the parallel build still fail randomly which block
>>> >> > > > our
>>> >> > > > nightly checker.
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Adam Feuer 
>>> >
>>>
>>
>>
>> --
>> Adam Feuer 
>>
>


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Alan Carvalho de Assis
No problem, I didn't realize that you didn't include the previous
commit after reviewing all PRs.

I think now we have a better picture about all improvements and
bugfixes from 8.2 to 9.0.

BR,

Alan

On 4/10/20, Adam Feuer  wrote:
> Ok thanks Alan. I'm sorry I wasn't clear about what we had done.
>
> -adam
>
> On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis 
> wrote:
>
>> Hi Adam,
>>
>> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
>> tag. But I didn't checked for improvements because I thought you,
>> Nathan and Abdelatif did it.
>>
>> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no
>> problem.
>>
>> BR,
>>
>> Alan
>>
>> On 4/10/20, Adam Feuer  wrote:
>> > Alan,
>> >
>> > Next we need to check for features/improvements and bugfixes between 23
>> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16
>> > November 2019, the date of NuttX release 8.2. The main source of info
>> > for
>> > this would be commit messages in the current master branch.
>> >
>> > Would you be willing to look through those? Or figure out a way to
>> > divide
>> > them up among you, me, Nathan, and Abdelatif?
>> >
>> > -adam
>> >
>> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis <
>> acas...@gmail.com>
>> > wrote:
>> >
>> >> Hi guys,
>> >>
>> >> I finished including the apps/ improvements and bugfixes.
>> >>
>> >> Is there anything else we need to take care?
>> >>
>> >> BR,
>> >>
>> >> Alan
>> >>
>> >> On 4/10/20, Abdelatif Guettouche 
>> wrote:
>> >> >> Speaking about the branch, Brennan is suggesting to have a
>> >> >> different
>> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY
>> >> >> (the
>> >> >> reasons behind this are here:
>> >> >> https://github.com/apache/incubator-nuttx/pull/757)
>> >> >
>> >> > Is everyone okay with changing the branches naming convention?
>> >> > I personally do not mind.
>> >> >
>> >> > For that PR, I asked Brennan on how to proceed with signing the
>> >> > tarballs.
>> >> > The original flow was:
>> >> > 1. Generate the tarballs
>> >> > 2. Sign the tarballs and create the hashes.
>> >> > 3. Then upload everything (tarballs, hashes, signatures)
>> >> > Everything was done locally and then uploaded.
>> >> > With the PR757 the release tarballs are generated with a push to the
>> >> > release branch.
>> >> > Do we download them, sign and then upload the signatures?
>> >> > We need at least one way to check the downloads before signing, like
>> >> > by creating the hashes with the tarballs.
>> >> >
>> >> >
>> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer  wrote:
>> >> >>
>> >> >> Xiang,
>> >> >>
>> >> >> Ok, thanks. It's great that this doesn't block the release!
>> >> >>
>> >> >> -adam
>> >> >>
>> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao
>> >> >> > >
>> >> >> wrote:
>> >> >>
>> >> >> > This build error happen for several special config only, and
>> already
>> >> >> > exist
>> >> >> >
>> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer 
>> wrote:
>> >> >> > >
>> >> >> > > Xiang,
>> >> >> > >
>> >> >> > > Do the parallel build failures block our release? If so, what
>> >> >> > > can
>> >> >> > > we
>> >> >> > > do
>> >> >> >
>> >> >> > Shouldn't, because:
>> >> >> > 1.The build error already exist for a long time
>> >> >> > 2.Only several seldom used configs(all related to
>> >> >> > binfmt/module/so)
>> >> >> > hit this issue
>> >> >> > 3.The single thread build can always finish successfully
>> >> >> >
>> >> >> > > temporarily to unblock it? Or is there a fix in the works that
>> >> >> > > will
>> >> >> > > be
>> >> >> > > ready soon?
>> >> >> > >
>> >> >> >
>> >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the
>> >> >> > recent
>> >> >> > month, some issue get fixed, but some need more time to
>> investigate.
>> >> >> >
>> >> >> > > -adam
>> >> >> > >
>> >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
>> >> xiaoxiang781...@gmail.com>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > > > At least, the parallel build still fail randomly which block
>> our
>> >> >> > > > nightly checker.
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Adam Feuer 
>> >> >
>> >>
>> >
>> >
>> > --
>> > Adam Feuer 
>> >
>>
>
>
> --
> Adam Feuer 
>


Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Adam Feuer
Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki
page. Many of the improvements were changes to conform to style, or small
fixes that would not be relevant for release notes.

I think we're done summarizing. Are we ready to create a PR for the Release
Notes? In other words, get them into the text file form?

cheers
adam

On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis 
wrote:

> No problem, I didn't realize that you didn't include the previous
> commit after reviewing all PRs.
>
> I think now we have a better picture about all improvements and
> bugfixes from 8.2 to 9.0.
>
> BR,
>
> Alan
>
> On 4/10/20, Adam Feuer  wrote:
> > Ok thanks Alan. I'm sorry I wasn't clear about what we had done.
> >
> > -adam
> >
> > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis <
> acas...@gmail.com>
> > wrote:
> >
> >> Hi Adam,
> >>
> >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
> >> tag. But I didn't checked for improvements because I thought you,
> >> Nathan and Abdelatif did it.
> >>
> >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no
> >> problem.
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 4/10/20, Adam Feuer  wrote:
> >> > Alan,
> >> >
> >> > Next we need to check for features/improvements and bugfixes between
> 23
> >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the
> 16
> >> > November 2019, the date of NuttX release 8.2. The main source of info
> >> > for
> >> > this would be commit messages in the current master branch.
> >> >
> >> > Would you be willing to look through those? Or figure out a way to
> >> > divide
> >> > them up among you, me, Nathan, and Abdelatif?
> >> >
> >> > -adam
> >> >
> >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis <
> >> acas...@gmail.com>
> >> > wrote:
> >> >
> >> >> Hi guys,
> >> >>
> >> >> I finished including the apps/ improvements and bugfixes.
> >> >>
> >> >> Is there anything else we need to take care?
> >> >>
> >> >> BR,
> >> >>
> >> >> Alan
> >> >>
> >> >> On 4/10/20, Abdelatif Guettouche 
> >> wrote:
> >> >> >> Speaking about the branch, Brennan is suggesting to have a
> >> >> >> different
> >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY
> >> >> >> (the
> >> >> >> reasons behind this are here:
> >> >> >> https://github.com/apache/incubator-nuttx/pull/757)
> >> >> >
> >> >> > Is everyone okay with changing the branches naming convention?
> >> >> > I personally do not mind.
> >> >> >
> >> >> > For that PR, I asked Brennan on how to proceed with signing the
> >> >> > tarballs.
> >> >> > The original flow was:
> >> >> > 1. Generate the tarballs
> >> >> > 2. Sign the tarballs and create the hashes.
> >> >> > 3. Then upload everything (tarballs, hashes, signatures)
> >> >> > Everything was done locally and then uploaded.
> >> >> > With the PR757 the release tarballs are generated with a push to
> the
> >> >> > release branch.
> >> >> > Do we download them, sign and then upload the signatures?
> >> >> > We need at least one way to check the downloads before signing,
> like
> >> >> > by creating the hashes with the tarballs.
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer 
> wrote:
> >> >> >>
> >> >> >> Xiang,
> >> >> >>
> >> >> >> Ok, thanks. It's great that this doesn't block the release!
> >> >> >>
> >> >> >> -adam
> >> >> >>
> >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao
> >> >> >>  >> >
> >> >> >> wrote:
> >> >> >>
> >> >> >> > This build error happen for several special config only, and
> >> already
> >> >> >> > exist
> >> >> >> >
> >> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer 
> >> wrote:
> >> >> >> > >
> >> >> >> > > Xiang,
> >> >> >> > >
> >> >> >> > > Do the parallel build failures block our release? If so, what
> >> >> >> > > can
> >> >> >> > > we
> >> >> >> > > do
> >> >> >> >
> >> >> >> > Shouldn't, because:
> >> >> >> > 1.The build error already exist for a long time
> >> >> >> > 2.Only several seldom used configs(all related to
> >> >> >> > binfmt/module/so)
> >> >> >> > hit this issue
> >> >> >> > 3.The single thread build can always finish successfully
> >> >> >> >
> >> >> >> > > temporarily to unblock it? Or is there a fix in the works that
> >> >> >> > > will
> >> >> >> > > be
> >> >> >> > > ready soon?
> >> >> >> > >
> >> >> >> >
> >> >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the
> >> >> >> > recent
> >> >> >> > month, some issue get fixed, but some need more time to
> >> investigate.
> >> >> >> >
> >> >> >> > > -adam
> >> >> >> > >
> >> >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao <
> >> >> xiaoxiang781...@gmail.com>
> >> >> >> > wrote:
> >> >> >> > >
> >> >> >> > > > At least, the parallel build still fail randomly which block
> >> our
> >> >> >> > > > nightly checker.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Adam Feuer 
> >> >> >
> >> >>
> >> >
> >> >
> >> > --
> >> > Adam Feuer 
> >> >
> >>
> >
> >
> > --
> > Adam Feuer 
> >
>

Re: Start of the NuttX 9.0 release cycle

2020-04-10 Thread Abdelatif Guettouche
I think we still need some organization before creating the PR. Mainly
the driver section, I think it should be divided for all other
subsystems.

But, please, let's take this conversation to the Release Note thread.
I'm still trying to get everyone's opinion on the branch naming convention.

On Fri, Apr 10, 2020 at 8:12 PM Adam Feuer  wrote:
>
> Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki
> page. Many of the improvements were changes to conform to style, or small
> fixes that would not be relevant for release notes.
>
> I think we're done summarizing. Are we ready to create a PR for the Release
> Notes? In other words, get them into the text file form?
>
> cheers
> adam
>
> On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis 
> wrote:
>
> > No problem, I didn't realize that you didn't include the previous
> > commit after reviewing all PRs.
> >
> > I think now we have a better picture about all improvements and
> > bugfixes from 8.2 to 9.0.
> >
> > BR,
> >
> > Alan
> >
> > On 4/10/20, Adam Feuer  wrote:
> > > Ok thanks Alan. I'm sorry I wasn't clear about what we had done.
> > >
> > > -adam
> > >
> > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis <
> > acas...@gmail.com>
> > > wrote:
> > >
> > >> Hi Adam,
> > >>
> > >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0
> > >> tag. But I didn't checked for improvements because I thought you,
> > >> Nathan and Abdelatif did it.
> > >>
> > >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no
> > >> problem.
> > >>
> > >> BR,
> > >>
> > >> Alan
> > >>
> > >> On 4/10/20, Adam Feuer  wrote:
> > >> > Alan,
> > >> >
> > >> > Next we need to check for features/improvements and bugfixes between
> > 23
> > >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the
> > 16
> > >> > November 2019, the date of NuttX release 8.2. The main source of info
> > >> > for
> > >> > this would be commit messages in the current master branch.
> > >> >
> > >> > Would you be willing to look through those? Or figure out a way to
> > >> > divide
> > >> > them up among you, me, Nathan, and Abdelatif?
> > >> >
> > >> > -adam
> > >> >
> > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis <
> > >> acas...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Hi guys,
> > >> >>
> > >> >> I finished including the apps/ improvements and bugfixes.
> > >> >>
> > >> >> Is there anything else we need to take care?
> > >> >>
> > >> >> BR,
> > >> >>
> > >> >> Alan
> > >> >>
> > >> >> On 4/10/20, Abdelatif Guettouche 
> > >> wrote:
> > >> >> >> Speaking about the branch, Brennan is suggesting to have a
> > >> >> >> different
> > >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY
> > >> >> >> (the
> > >> >> >> reasons behind this are here:
> > >> >> >> https://github.com/apache/incubator-nuttx/pull/757)
> > >> >> >
> > >> >> > Is everyone okay with changing the branches naming convention?
> > >> >> > I personally do not mind.
> > >> >> >
> > >> >> > For that PR, I asked Brennan on how to proceed with signing the
> > >> >> > tarballs.
> > >> >> > The original flow was:
> > >> >> > 1. Generate the tarballs
> > >> >> > 2. Sign the tarballs and create the hashes.
> > >> >> > 3. Then upload everything (tarballs, hashes, signatures)
> > >> >> > Everything was done locally and then uploaded.
> > >> >> > With the PR757 the release tarballs are generated with a push to
> > the
> > >> >> > release branch.
> > >> >> > Do we download them, sign and then upload the signatures?
> > >> >> > We need at least one way to check the downloads before signing,
> > like
> > >> >> > by creating the hashes with the tarballs.
> > >> >> >
> > >> >> >
> > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer 
> > wrote:
> > >> >> >>
> > >> >> >> Xiang,
> > >> >> >>
> > >> >> >> Ok, thanks. It's great that this doesn't block the release!
> > >> >> >>
> > >> >> >> -adam
> > >> >> >>
> > >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao
> > >> >> >>  > >> >
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> > This build error happen for several special config only, and
> > >> already
> > >> >> >> > exist
> > >> >> >> >
> > >> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer 
> > >> wrote:
> > >> >> >> > >
> > >> >> >> > > Xiang,
> > >> >> >> > >
> > >> >> >> > > Do the parallel build failures block our release? If so, what
> > >> >> >> > > can
> > >> >> >> > > we
> > >> >> >> > > do
> > >> >> >> >
> > >> >> >> > Shouldn't, because:
> > >> >> >> > 1.The build error already exist for a long time
> > >> >> >> > 2.Only several seldom used configs(all related to
> > >> >> >> > binfmt/module/so)
> > >> >> >> > hit this issue
> > >> >> >> > 3.The single thread build can always finish successfully
> > >> >> >> >
> > >> >> >> > > temporarily to unblock it? Or is there a fix in the works that
> > >> >> >> > > will
> > >> >> >> > > be
> > >> >> >> > > ready soon?
> > >> >> >> > >
> > >> >> >> >
> > >> >> >> > Masayuki, Haitao

Re: debugging a NuttX linker problem

2020-04-10 Thread Adam Feuer
Thanks Greg.

I found out that this resulted from an error in my Kconfig file. I was
providing those functions, but they weren't getting compiled or linked due
to my config settings. I corrected that Kconfig file, reran 'make
menuconfig' and now my files are being compiled and linked.

There's still problems compiling some stuff that I ported from the imxrt SD
Card driver... working on that now...

-adam

On Thu, Apr 9, 2020 at 11:42 AM Gregory Nutt  wrote:

>
> >> arm-none-eabi-ld:
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_bringup.o):
> >> in function `sam_bringup':
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_bringup.c:149:
> >> undefined reference to `sam_sdmmc_sdio_initialize'
> >> arm-none-eabi-ld:
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_bringup.c:166:
> >> undefined reference to `sam_sdmmc_set_sdio_card_isr'
> >> arm-none-eabi-ld:
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_sdmmc.o):
> >> in function `sam_sdmmc_cardetect':
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:152:
> >> undefined reference to `sdio_mediachange'
> >> arm-none-eabi-ld:
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/arch/arm/src/board/libboard.a(sam_sdmmc.o):
> >> in function `sam_sdmmc_initialize':
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:239:
> >> undefined reference to `sam_sdmmc_sdio_initialize'
> >> arm-none-eabi-ld:
> >>
> /home/adam/src/nuttx/nuttx-sama5d2-xult/nuttx/boards/arm/sama5/sama5d2-xult/src/sam_sdmmc.c:263:
> >> undefined reference to `sdio_mediachange'
>
> These are ALL functions that must be provided in your board-specific
> logic.  Look for example a:
>
> $ cd boards/arm/sama5/
> $ grep -r sdio_mediachange *
> sama5d2-xult/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd);
> sama5d2-xult/src/sam_hsmci.c:  sdio_mediachange(state->hsmci, state->cd);
> sama5d3x-ek/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd);
> sama5d3x-ek/src/sam_hsmci.c:  sdio_mediachange(state->hsmci, state->cd);
> sama5d3-xplained/src/sam_hsmci.c: sdio_mediachange(state->hsmci, cd);
> sama5d3-xplained/src/sam_hsmci.c: sdio_mediachange(state->hsmci,
> state->cd);
> sama5d4-ek/src/sam_hsmci.c:  sdio_mediachange(state->hsmci, cd);
> sama5d4-ek/src/sam_hsmci.c:  sdio_mediachange(state->hsmci, state->cd);
>
>
>

-- 
Adam Feuer 


Build failed in Jenkins: NuttX-Nightly-Build #92

2020-04-10 Thread Apache Jenkins Server
See 

Changes:


--
[...truncated 547.30 KB...]
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

In file included from bas.c:84:0:
bas.c: In function 'bas_interpreter':
bas_error.h:110:37: warning: left-hand operand of comma expression has no 
effect [-Wunused-value]
 #define NOSUCHLINE STATIC+40, _("No such line")
 ^
bas.c:2425:52: note: in expansion of macro 'NOSUCHLINE'
   FS_putChars(STDCHANNEL, (NOSUCHLINE));
^~
bas_fs.c:107:22: warning: 'g_vt100_colormap' defined but not used 
[-Wunused-const-variable=]
 static const uint8_t g_vt100_colormap[8] =
  ^~~~
:4048:16: warning: 'input' defined but not used [-Wunused-function]

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

local/local_connect.c: In function 'psock_local_connect':
local/local_connect.c:292:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

local/local_fifo.c: In function 'local_release_halfduplex':
local/local_fifo.c:449:4: warning: #warning Missing logic [-Wcpp]
 #  warning Missing logic
^~~
local/local_sockif.c: In function 'local_connect':
local/local_sockif.c:550:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
local/local_sockif.c: In function 'local_send':
local/local_sockif.c:695:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
local/local_connect.c: In function 'psock_local_connect':
local/local_connect.c:292:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~

Skipping: sim/rpproxy

Configuration/Tool: sim/vpnkit

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

nsh_netcmds.c: In function 'cmd_ifconfig':
nsh_netcmds.c:885:2: warning: #warning Missing Logic [-Wcpp]
 #warning Missing Logic
  ^~~
local/local_fifo.c: In function 'local_release_halfduplex':
local/local_fifo.c:449:4: warning: #warning Missing logic [-Wcpp]
 #  warning Missing logic
^~~~