Re: PR and issue Templates

It's a nice feature, who can create a PR? so we can review and merge it. Thanks Xiang On Sat, Mar 21, 2020 at 4:42 AM David Sidrane wrote: > > Here are some that work well for issues. > > https://github.com/PX4/Firmware/tree/master/.github/ISSUE_TEMPLATE > > For PR's > We could add the

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

See Changes: -- [...truncated 561.55 KB...] Building NuttX...

Re: Build errors with inline functions

On Sat, Mar 21, 2020 at 5:15 AM John Rippetoe wrote: > > > > > > You can try removing the static from the inline function definitions > > in the header file. The code should then compile, however, you could > > also get multiply defined functions at link time... Or maybe the > > linker is smart

Re: Build errors with inline functions

Another example, we use MPU to protect the code section for NOXIP case in the flat mode. On Sat, Mar 21, 2020 at 5:41 AM David Sidrane wrote: > > > the error will crop back up if MPU support is enabled without also > > performing a protected build since up_mpu.c is only included in a > >

Re: Apache 2.0 License headers in source files

Thanks Justin. I think Brennan is volunteering to be release manager and get the next one out, as long as we can start a license clearing process and make things a little better (become more Apache-like :) ) each release. Here's what Brennan and I are planning for this weekend: 1. We're going

Re: Apache 2.0 License headers in source files

Hi, INAL but the copyright notice in the header is just a claim and may not reflect who actually has copyright. It doesn’t mean that that person or company owns the copyright on the entire file. With a company it’s usually easier as employment contracts say the company owns the copyright of

RE: Build errors with inline functions

> the error will crop back up if MPU support is enabled without also > performing a protected build since up_mpu.c is only included in a > protected build. Just a heads up there are some case on some HW (imxrt, maybe the K66 for the DMA) were the MPU is needed to enable the proper access but not

Re: Build errors with inline functions

You can try removing the static from the inline function definitions in the header file.  The code should then compile, however, you could also get multiply defined functions at link time... Or maybe the linker is smart enough to allow multiples??? Putting inline functions in header

Re: Build errors with inline functions

I think at a minimum, we need to conditionally include mpu.h only when the MPU support is actually needed. Options for that are CONFIG_ARM_MPU, CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the first two, the error will crop back up if MPU support is enabled without also

RE: PR and issue Templates

Here are some that work well for issues. https://github.com/PX4/Firmware/tree/master/.github/ISSUE_TEMPLATE For PR's We could add the requirement for License on new files with links to Our template. We could add the requirement for {I|C}CLA with links to

Re: Podling Nuttx Report Reminder - April 2020

> Sounds good to me, can't go anywhere anyway this weekend. > Yeah neither can I. Ok, let's coordinate off-list. -adam -- Adam Feuer

Re: Podling Nuttx Report Reminder - April 2020

On Fri, Mar 20, 2020, 12:34 PM Adam Feuer wrote: > Brennan, > > I'm willing to put a couple hours this weekend into Fossology, updating > license headers for the files we clear, and making a PR to revidew. Are you > willing to spend a couple of hours this weekend with me to help? I think if > we

Re: Podling Nuttx Report Reminder - April 2020

Brennan, I'm willing to put a couple hours this weekend into Fossology, updating license headers for the files we clear, and making a PR to revidew. Are you willing to spend a couple of hours this weekend with me to help? I think if we coordinate our work, it doesn't have to be at the same time.

Re: Podling Nuttx Report Reminder - April 2020

On Fri, Mar 20, 2020, 12:21 PM Gregory Nutt wrote: > > > What blocks us from doing a release right now? I've heard a few things: > > > > - parallel build is broken > > - no progress on license clearing > > Single biggest reason: No release manager to manage the release process > I have

Re: Podling Nuttx Report Reminder - April 2020

What blocks us from doing a release right now? I've heard a few things: - parallel build is broken - no progress on license clearing Single biggest reason:  No release manager to manage the release process

Re: Podling Nuttx Report Reminder - April 2020

What blocks us from doing a release right now? I've heard a few things: - parallel build is broken - no progress on license clearing Are these correct? If not, what do we need to add or change to get a release out? If people reply to this thread, I will summarize and create a checklist in

Re: PR and issue Templates

Here's the template I've used before in PRs on other projects, I found it helps to encourage people submitting PRs to fill out all relevant sections: ### Summary * bullet point form * is easier to read ### Impact ### Limitations / TODO ### Detail ### Testing ### How To Verify Here's the process

Re: PR and issue Templates

> > @mentors Do we have the ability to add a Git hub PR and Issue template? > There at least one project using this: https://github.com/apache/incubator-tvm/blob/master/.github/PULL_REQUEST_TEMPLATE.md I didn't go through all the Apache projects, maybe there are others. What do you think should

Re: Breakout apps/ ?

Hi Greg, I agree with this idea! A NuttX distribution makes sense and will avoid licensing issues, we could let the user to select which licenses he accept to use. BR, Alan On 3/20/20, Gregory Nutt wrote: > Hi, group, > > There has been talk for years about the idea of creating a separate >

Breakout apps/ ?

Hi, group, There has been talk for years about the idea of creating a separate project out of apps/, extending it so that it is a real NuttX "Distribution," basically like OpenEmbedded, Buildroot, or Yocto for NuttX.  It would: *  Download and install the NuttX *  Select and build the

Re: Apache 2.0 License headers in source files

For the license clearing part, I think the next piece of work to do is license clearing for all the files under sched/ as a test of this process: https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing As noted in a previous email, there are: - 285 total files - 114 files have

Re: Apache 2.0 License headers in source files

On Fri, Mar 20, 2020, 8:19 AM Gregory Nutt wrote: > > We CANNOT just go and update the headers on files unless Greg is the > >> only > author and all other non trivial contributors have signed some form of > CLA. I would feel very uncomfortable signing off on a release > without

Re: Build errors with inline functions

If we want to support the compiler which don't support inline, it's better that: 1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h 2.Convert inline fucntion to macro to normal function It isn't hard to fix because grep just can find inline about 100 times. There are inline functions in

Re: Apache 2.0 License headers in source files

We CANNOT just go and update the headers on files unless Greg is the only author and all other non trivial contributors have signed some form of CLA. I would feel very uncomfortable signing off on a release without a review of these files that got changed, disclaimer or not. Is it enough

Re: Build errors with inline functions

On Fri, Mar 20, 2020 at 11:07 PM Gregory Nutt wrote: > > > > In C, if placing a function in a header, "static inline" is needed to avoid > > a "multiple definitions" problem, but means that if the compiler decides > > *not* to inline the function, and if the function is used from multiple C > >

Re: Apache 2.0 License headers in source files

On Fri, Mar 20, 2020 at 10:37 AM Brennan Ashton wrote: > On Fri, Mar 20, 2020, 7:29 AM Nathan Hartman > wrote: > > I'd like to nudge (or pehaps push and shove) Apache NuttX toward > > making our first release as an Apache podling. Along those lines I'd > > like to revive this conversation... > >

Re: Apache 2.0 License headers in source files

On Fri, Mar 20, 2020, 8:01 AM Gregory Nutt wrote: > > >> We CANNOT just go and update the headers on files unless Greg is the > only > >> author and all other non trivial contributors have signed some form of > >> CLA. I would feel very uncomfortable signing off on a release without a > >>

Re: Build errors with inline functions

In C, if placing a function in a header, "static inline" is needed to avoid a "multiple definitions" problem, but means that if the compiler decides *not* to inline the function, and if the function is used from multiple C modules, then some code bloat results because you could end up with

Re: Apache 2.0 License headers in source files

We CANNOT just go and update the headers on files unless Greg is the only author and all other non trivial contributors have signed some form of CLA. I would feel very uncomfortable signing off on a release without a review of these files that got changed, disclaimer or not. Is it enough

Re: Apache 2.0 License headers in source files

On Fri, Mar 20, 2020 at 10:46 PM Gregory Nutt wrote: > > > > I'd like to nudge (or pehaps push and shove) Apache NuttX toward > > making our first release as an Apache podling. > The last release, 8.2, was from mid-November 2019. Releases had been > been made religiously every two months for

Re: Apache 2.0 License headers in source files

On Fri, Mar 20, 2020 at 10:37 PM Brennan Ashton wrote: > > On Fri, Mar 20, 2020, 7:29 AM Nathan Hartman > wrote: > > > On Sat, Mar 7, 2020 at 9:45 PM Brennan Ashton > > wrote: > > > Adam if you look back I have a hosted instance of it running for the > > > project, no sense in duplicating the

Re: Build errors with inline functions

On Thu, Mar 19, 2020 at 6:38 PM Gregory Nutt wrote: > > > More likely is the fact that inlining is disabled at -O0 and now the > > functions really are implemented as static functions and generate > > static functions. Now you really do have unreferenced static > > functions. Try removing the

Re: Apache 2.0 License headers in source files

I'd like to nudge (or pehaps push and shove) Apache NuttX toward making our first release as an Apache podling. The last release, 8.2, was from mid-November 2019.  Releases had been been made religiously every two months for years up until 8.2. We are approaching 6 months with no releases. 

Re: Apache 2.0 License headers in source files

On Sat, Mar 7, 2020 at 9:45 PM Brennan Ashton wrote: > Adam if you look back I have a hosted instance of it running for the > project, no sense in duplicating the work. I'm happy to provide you an > account. The nice thing about using this is that the reports can be shared > publicly and we can

Re: problem with nxsig_timeout (sig_timedwait.c)

Looking at the declarations of nxsig_timeout and wdentry_t: static void nxsig_timeout(int argc, wdparm_t itcb) typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...); A sidenote:  You must be looking at a very old code base.  The current type for wdentry_t is: 133 typedef CODE

PR and issue Templates

Hi, We spend a lot of time on PRs repeating ourselves on format, license. Giving directed links and examples will not challenge contributors with having to ferret this out on their own. @mentors Do we have the ability to add a Git hub PR and Issue template? David *From:*

Re: Podling Nuttx Report Reminder - April 2020

Hi, > Will this help us make progress? If you don’t want to report then that’s up to you. > We've been more or less repeating the same thing for the past two reports. Which is a concern. > Technically the project is making progress Which the ASF is not so concerned about, what you need to

Re: Podling Nuttx Report Reminder - April 2020

> > but given this podlings lack of progress I think it might be good for it > to report again this month. Will this help us make progress? The report would be similar to the old one. We've been more or less repeating the same thing for the past two reports. Technically the project is making

Re: Podling Nuttx Report Reminder - April 2020

Hi, > My understanding is that new podlings report monthly for the first 3 months > then quarterly after that. That’s correct it looks like the group attribute may of been set incorrectly in podlings.xml I’ll double check and fix it, but given this podlings lack of progress I think it might be

Re: Podling Nuttx Report Reminder - April 2020

Do we have to report? We reported every month for the last 3 months. My understanding is that new podlings report monthly for the first 3 months then quarterly after that. On Fri, Mar 20, 2020, 04:18 wrote: > Dear podling, > > This email was sent by an automated system on behalf of the Apache >