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

[Apache Jenkins Server]

See 

Changes:


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


Configuration/Tool: sim/configdata

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


Configuration/Tool: sim/sixlowpan

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

mtd/at24xx.c:139:4: warning: #warning "Assuming MTD driver block size is the 
same as the FLASH page size" [-Wcpp]
 #  warning "Assuming MTD driver block size is the same as the FLASH page size"
^~~

Skipping: sim/cxxtest

Configuration/Tool: sim/nettest

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


Skipping: sim/nxwm

Configuration/Tool: sim/ipforward

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


Configuration/Tool: sim/nx

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


Configuration/Tool: sim/ostest

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


Configuration/Tool: sim/mount

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


Configuration/Tool: sim/minibasic

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


Configuration/Tool: sim/tcpblaster

  Cleaning...
  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...
  Bu

[GitHub] [incubator-nuttx-testing] liuguo09 commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container

[GitBox]

liuguo09 commented on issue #13: docker: initial checkin Dockerfile for nuttx 
github action container
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/13#issuecomment-599307751
 
 
   @btashton thanks, I'll look into it and feedback later. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

[David Sidrane]

Hi Adam,



Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
and submit a PR to upstream or Fork it?



It may be that time spent training Clang-format is better than time spent
on nstyle, as it is a "shorter haul" with a much, much greater return.



David



*From:* Adam Feuer [mailto:a...@starcat.io]
*Sent:* Saturday, March 14, 2020 1:59 PM
*To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
*Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
precheck a little bit?]



I looked at the clang-format source code. It has trouble aligning the = of
a -= or +=. I easily made a change to align on the - or + of a -= or +=,
but some work will be necessary to give an option that aligns the way the
nuttx code does it. Will think more about it.



-adam





On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  wrote:

David, Maciej, Peter,



Thanks for your help!



IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
.clang-format file is this:



IndentPPDirectives: AfterHash



That makes things a lot better. There are a bunch of inconsistent macro
indents under sched/ though— many macros indent ok, but there are a bunch
that don't. Not sure what to do about that... are they really inconsistent?
If so maybe we make a small PR that fixes the inconsistent indents?



What seems to be next:

·  alignment of successive expressions

   reltime.tv_nsec += NSEC_PER_SEC;
-  reltime.tv_sec  -= 1;
+  reltime.tv_sec -= 1;

·  alignment of comment blocks ­— to make sure they line up with the next
comment line in the block

For instance:



-  /* The resulting set is the intersection of the current set and
+/* The resulting set is the intersection of the current set and
* the complement of the signal set pointed to by _set.
*/

·  evaluating inconsistencies in the alignment style... some expressions
and declarations are aligned, others are not... I need to consult the style
guide to see what it says.



I'm using clang-format-9. Here's the command lines I'm running to generate
and look at the changes (in the nutt/ dir):



$ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
-style=file

$ git diff

$ # change .clang-format

$ git stash; git stash drop





Here's my .clang format file as of now:



---
Language:Cpp
AccessModifierOffset: -2
AlignAfterOpenBracket: Align
AlignConsecutiveMacros: true
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: true
AlignEscapedNewlines: DontAlign
AlignOperands:   true
AlignTrailingComments: true
AllowAllArgumentsOnNextLine: true
AllowAllConstructorInitializersOnNextLine: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: All
AllowShortLambdasOnASingleLine: All
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: MultiLine
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
  AfterCaseLabel:  false
  AfterClass:  false
  AfterControlStatement: true
  AfterEnum:   true
  AfterFunction:   true
  AfterNamespace:  false
  AfterObjCDeclaration: false
  AfterStruct: true
  AfterUnion:  true
  AfterExternBlock: false
  BeforeCatch: false
  BeforeElse:  true
  IndentBraces:true
  SplitEmptyFunction: true
  SplitEmptyRecord: true
  SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Custom
BreakBeforeInheritanceComma: false
BreakInheritanceList: BeforeColon
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: false
BreakConstructorInitializers: BeforeColon
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: true
ColumnLimit: 0
CommentPragmas:  '^ IWYU pragma:'
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: false
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 0
Cpp11BracedListStyle: false
DerivePointerAlignment: false
DisableFormat:   false
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: false
ForEachMacros:
  - foreach
  - Q_FOREACH
  - BOOST_FOREACH
IncludeBlocks:   Preserve
IncludeCategories:
  - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
Priority:2
  - Regex:   '^(<|"(gtest|gmock|isl|json)/)'
Priority:3
  - Regex:   '.*'
Priority:1
IncludeIsMainRegex: '(Test)?$'
IndentCaseLabels: true
IndentPPDirectives: AfterHash
IndentWidth: 2
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
JavaScriptWrapImports: true
KeepEmptyLinesAtTheStartOfBlocks: true
MacroBlockBegin: ''
MacroBlockEnd:   ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
ObjCBinPackProtocolList: Auto
ObjCBlockIndentWidth: 2
ObjCSpaceAfterProperty: false
ObjCSpaceBefore

Re: Should we relax precheck a little bit?

[Gregory Nutt]

Yeah I thought about the too

But think of the can of worm on the commit history: Every PR touches the cfg
file.


I don't see that.  Modifications to the white list file, whatever it is 
called, would be very rare.  Only when a new non-compliant name is added 
which should be never.


We should not permit people to create new non-compliant names. The 
existing non-compliant names are a consequence of names defined in other 
standards and by chip manufacturers.  If POSIX changes or if we add 
support for new chips, then and only then would the whitelists change.


I see no can.  I see no worms.

Re: Should we relax precheck a little bit?

[Gregory Nutt]

How about we put this special treatment to another file(e.g.
nxstyle.cfg)? So we don't pollute the source code.


+1 I like it.  I just suggested basically the same think in the PR.  I 
suggested the name .nxignore.


If a .nxignore file exists in the same directory as the file under test, 
then it could be read to get the white list.  Perhaps there would be a 
global .nxignore file at the top level, or under tools/?


Greg

RE: Should we relax precheck a little bit?

[David Sidrane]

Yeah I thought about the too

But think of the can of worm on the commit history: Every PR touches the cfg
file.

Rebase HELL! Yuch!

Fix or replace the tool!

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Sunday, March 15, 2020 6:08 AM
To: dev@nuttx.apache.org
Subject: Re: Should we relax precheck a little bit?

How about we put this special treatment to another file(e.g.
nxstyle.cfg)? So we don't pollute the source code.


On Sun, Mar 15, 2020 at 7:47 PM Schock, Johannes - NIVUS GmbH
 wrote:
>
> Hello,
> I filed a pull request that introduces an idea of controlling the
> behaviour of nxstyle from inside the file under test.
> https://github.com/apache/incubator-nuttx/pull/569
> This would allow to address some special requirements that are needed in
> cornercases (e.g. whitelisting), and, by using the ignore feature, to
> switch of testing for ranges of the file that are correct but nxstyle
> isn't happy about it (yet unaddressed cornercases).
> This would give a contributor/commiter the possibility to explicitly pass
> the PR through the style check, and perhaps file an nxstyle issue.
> From time to time we could grep for the ignore command and remove it if
> the issue had been resolved.
> Please share your thoughts.
> Johannes
>
> P.S.: if some aren't happy with the xml-like syntax, we can change this
> for sure

RE: Question of PR Etiquette

[David Sidrane]

Helping someone is not a bad thing.

Consider the effect on the community and the code.

What use to happen with patches: patches were emailed, ***modified*** and
committed.

Submitted != Committed - Was that BAD Etiquette?

What use to happen with a PR: PR were submitted, 1-N more commits were made
AFTER merging the PR therefore modifying the code. This created risk, build
breakage and major commit spaghetti. Was that BAD Etiquette?

The **net** result was the correct thing was done from the code
perspective. - That was good, but not done right.

Well we could argue that while it was or was not bad etiquette, what it
really was, was bad workflow. That work should have been done on a branch,
reviewed, tested then merged.

This is what we are doing now.

The git hub tools allow us to collaborate, use a PR development effort to
educate, and get to a quality submission.

When with permission, a committer pushes to a contributor's PR the key
difference: The squashed commits of that PR are now atomic and not commit
spaghetti. Attribution is preserved. This is a WIN-WIN.

>From the community perspective we can help the contributor using things like
"Suggested Changes" and with giving them advice on how to proceed with
process (or an nxstyle flaw). We do not help them by criticizing them or
telling them things they can get from Nxstyle output.

For the push to PR option to be used, we have to give the contributor a
choice to:
 a) Fix the code themselves
 b) Offer to do it with or for them.

When you let them decide.  Then it is not BAD Etiquette.

If it becomes a "Drive-by" PR and it has value to the project. Do a
continuation PR in the repo - attribute the work to them and fix it, test it
and commit it.

Things to consider:

We have to be patient: PR can run for a while.

We have to be respectful of people's time:

We need to provide working tooling and work flow.
Nxstyle needs to be fixed or replaced ASAP.
We cannot expect them to run bad the tools, and hold them 
accountable the
Known issues.

A contribution is a solution that is shared by someone who may have done
the work for a day job. You cannot expect them to fix a coding style issues
immediately.  The same goes for committers.


I will vote NO on limiting this feature. If it get rolled into the workflow
(Let’s call it: pork barreled) I will vote no on it as well.

David



-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Saturday, March 14, 2020 2:31 PM
To: dev@nuttx.apache.org
Subject: Question of PR Etiquette

Question:  Github permits committer to modify the content of
contributors PRs through this mechanism:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork

I appreciate that this may be expeditious, but it feels like bad
etiquette to me.  It seems like we should accept what the contributor
has offered, accept the changes, or allow them to modify the changes.

I can also appreciate that there may be cases where a committer requires
help to get things right, but that would be a special case.

Do we really want to encourage this as standard practice.  My gut says
no, but I can also change my gut to match the consensus of the PPMC.

Whatever should be decided, the conclusion should be included in the
workflow document:
https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow.
If it is not permitted by the workflow, then it is forbidden, right?

I don't think we need to vote on this here.  The proper text needs to be
included in the workflow document which we will, eventually approve by vote.

Greg

Re: Should we relax precheck a little bit?

[Xiang Xiao]

How about we put this special treatment to another file(e.g.
nxstyle.cfg)? So we don't pollute the source code.


On Sun, Mar 15, 2020 at 7:47 PM Schock, Johannes - NIVUS GmbH
 wrote:
>
> Hello,
> I filed a pull request that introduces an idea of controlling the behaviour 
> of nxstyle from inside the file under test.
> https://github.com/apache/incubator-nuttx/pull/569
> This would allow to address some special requirements that are needed in 
> cornercases (e.g. whitelisting), and, by using the ignore feature, to switch 
> of testing for ranges of the file that are correct but nxstyle isn't happy 
> about it (yet unaddressed cornercases).
> This would give a contributor/commiter the possibility to explicitly pass the 
> PR through the style check, and perhaps file an nxstyle issue.
> From time to time we could grep for the ignore command and remove it if the 
> issue had been resolved.
> Please share your thoughts.
> Johannes
>
> P.S.: if some aren't happy with the xml-like syntax, we can change this for 
> sure

Re: Should we relax precheck a little bit?

[spudaneco]

I am oppose to modyfing source files to support the tool.  I don't think we 
should go that direction.Sent from Samsung tablet.
 Original message From: "Schock, Johannes - NIVUS GmbH" 
 Date: 3/15/20  5:47 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Should we relax precheck a little bit? 
Hello,I filed a pull request that introduces an idea of controlling the 
behaviour of nxstyle from inside the file under 
test.https://github.com/apache/incubator-nuttx/pull/569This would allow to 
address some special requirements that are needed in cornercases (e.g. 
whitelisting), and, by using the ignore feature, to switch of testing for 
ranges of the file that are correct but nxstyle isn't happy about it (yet 
unaddressed cornercases).This would give a contributor/commiter the possibility 
to explicitly pass the PR through the style check, and perhaps file an nxstyle 
issue.From time to time we could grep for the ignore command and remove it if 
the issue had been resolved.Please share your thoughts.JohannesP.S.: if some 
aren't happy with the xml-like syntax, we can change this for sure

Re: Should we relax precheck a little bit?

[Schock, Johannes - NIVUS GmbH]

Hello,
I filed a pull request that introduces an idea of controlling the behaviour of 
nxstyle from inside the file under test.
https://github.com/apache/incubator-nuttx/pull/569
This would allow to address some special requirements that are needed in 
cornercases (e.g. whitelisting), and, by using the ignore feature, to switch of 
testing for ranges of the file that are correct but nxstyle isn't happy about 
it (yet unaddressed cornercases).
This would give a contributor/commiter the possibility to explicitly pass the 
PR through the style check, and perhaps file an nxstyle issue.
>From time to time we could grep for the ignore command and remove it if the 
>issue had been resolved.
Please share your thoughts.
Johannes

P.S.: if some aren't happy with the xml-like syntax, we can change this for sure

Re: Question of PR Etiquette

[Abdelatif Guettouche]

Completely forbidding this functionality will deprive us from a useful feature.
We may need it now to help with overwhelming style complaints that
were not introduced by the PR or in the future if the contributor asks
for some sort of help.
We just need some moderation and resort to this only after a
discussion with the author.

On Sun, Mar 15, 2020 at 8:09 AM Justin Mclean  wrote:
>
> Hi,
>
> > So what you suggest it that we as committer don't need disscuss
> > anything with the contributor, we just need take his PR and do what we
> > think the right modification then merge directly.
>
> You could either discuss it with them or accept the PR and improve it. What 
> you do may be decided on a case by case basis and how much work it needs, it 
> it’s just a minor fix I would suggest accepting it and fixing the issue right 
> away. If it requires a lot of changes have a discussion with them so their 
> next PR is better.
>
> > I talk this example just because I saw some people send a PR and then
> > forget it in other github project, the contributor has to correct the
> > issue in PR by self sometime.
>
> It’s not the responsibility of the contributor to correct all issues, it up 
> the the PPMC as their primary goal is to grow the community and make their 
> project welcoming not work on the code. All contribution are generally 
> valuable even if they need some minor tweaks and you want to encourage people 
> to contribute. Apache often says "community over code”.
>
> Thanks,
> Justin

[GitHub] [incubator-nuttx-testing] btashton commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container

[GitBox]

btashton commented on issue #13: docker: initial checkin Dockerfile for nuttx 
github action container
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/13#issuecomment-599183244
 
 
   @liuguo09  Sorry this took me so long.   Have a look at what I have done 
over here:
   https://github.com/btashton/nuttx-build-containers
   
   The docker file is split into a bunch of stages which makes it a lot faster 
to rebuild and keeps the build time dependencies isolated from the rest of the 
image.  Note that I am not downloading all of the toolchains now instead of 
copying local ones in.
   
   I also have a github action wired up to that to create the docker image and 
place it in the github project package registry. 
   
   On thing I think we should consider is using that structure to create images 
that each have the needed toolchains they are very large and the ARM builds 
should not be paying the cost of the RISCV, but I think this is a later 
improvement that can be made.
   
   You can see this integrated and running here:
   https://github.com/btashton/incubator-nuttx/runs/508883969
   
   Let me know how you think and we can look at moving it forward. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Question of PR Etiquette

[Justin Mclean]

Hi,

> So what you suggest it that we as committer don't need disscuss
> anything with the contributor, we just need take his PR and do what we
> think the right modification then merge directly.

You could either discuss it with them or accept the PR and improve it. What you 
do may be decided on a case by case basis and how much work it needs, it it’s 
just a minor fix I would suggest accepting it and fixing the issue right away. 
If it requires a lot of changes have a discussion with them so their next PR is 
better.

> I talk this example just because I saw some people send a PR and then
> forget it in other github project, the contributor has to correct the
> issue in PR by self sometime.

It’s not the responsibility of the contributor to correct all issues, it up the 
the PPMC as their primary goal is to grow the community and make their project 
welcoming not work on the code. All contribution are generally valuable even if 
they need some minor tweaks and you want to encourage people to contribute. 
Apache often says "community over code”.

Thanks,
Justin

Re: Question of PR Etiquette

[Xiang Xiao]

On Sun, Mar 15, 2020 at 12:59 PM Justin Mclean  wrote:
>
> Hi,
>
> > Yes, this is last resort. It's better to discuss PR in the github and
> > let the contributor fix the problem by self. The collaboration model
> > can decrease the divergence and improve the community health.
>
> In my experience this has the opposite effect, it discourages newcomers from 
> contributing. You want to help contributors out so that they become 
> committers over time. But as they say you milage may vary. You want a low bar 
> for new people to be able to become contributors and to become committers.

So what you suggest it that we as committer don't need disscuss
anything with the contributor, we just need take his PR and do what we
think the right modification then merge directly.

>
> > It's better to limit this direct modification in some special case,
> > for example the owner don't response PR for a long time.
>
> If they don’t respond it mean you have driven them away, and that teh best 
> time to ask yourself what could you have done differently to keep them 
> involved?

I talk this example just because I saw some people send a PR and then
forget it in other github project, the contributor has to correct the
issue in PR by self sometime.
>From the recent PR, most contributor will like to dissuss his PR and improve 
>it:
https://github.com/apache/incubator-nuttx/pull/556
https://github.com/apache/incubator-nuttx/pull/550
https://github.com/apache/incubator-nuttx/pull/503
The aboved PR has many constructive dissussion between the contributor
and commiter before they get the final consensus.

>
> Thanks,
> Justin