10.3 merge issues
Hi All,
My project has been in hibernation for 6 months for personal reasons but
today was the day I fired the custom board up again to restart porting work.
My 10.2-based "in progress" work behaves as before (which was a relief) so I
decided I would merge in 10.3 to make sure I restarted with the latest
release (not withstanding that 10.4 is close!).
Most issues were easily solved by referring to release notes or good ol'
Google but I am left with one major and 1 minor problem.
1. Final change that allowed a compile was when I changed the defconfig
to have the new:
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INIT_ENTRYNAME="nsh"
It all boots and I get the nsh prompt but I get continuous:
nsh_session: cle failed: 22
I'm assuming that's EINVAL, but I can't work out why?
2. my board Make.defs file is an edited clone of another from the same
device (SAMA5D2) and is virtually identical to many other similar files for
other chips of course. I am running "Ubuntu 20.04.3 TLS"
This is included in virtually all these files for any chip/arch:
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
ARCHSCRIPT = -T "${shell cygpath -w
$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
But the compiler complains that there's:
no rule to make target '-T/home/{rest of the path}'
If I remove the -T it is fine.
Linux/Ubuntu is including the -T in the path I assume? Seems very odd that
10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume? Linux
skills are definitely lacking, so any suggestions welcomed!
Re: 10.3 merge issues
Hi Tim,
Try to compile with verbose enabled:
$ make V=1
Probably your board is bringing some older definition that is causing a
variable to be created incorrectly, because "-T/something" doesn't appear a
valid target.
BR,
Alan
On Wednesday, August 17, 2022, TimH wrote:
> Hi All,
>
>
>
> My project has been in hibernation for 6 months for personal reasons but
> today was the day I fired the custom board up again to restart porting
> work.
>
>
>
> My 10.2-based "in progress" work behaves as before (which was a relief) so
> I
> decided I would merge in 10.3 to make sure I restarted with the latest
> release (not withstanding that 10.4 is close!).
>
>
>
> Most issues were easily solved by referring to release notes or good ol'
> Google but I am left with one major and 1 minor problem.
>
>
>
> 1. Final change that allowed a compile was when I changed the
> defconfig
> to have the new:
>
>
>
> CONFIG_INIT_ENTRYPOINT="nsh_main"
>
> CONFIG_INIT_ENTRYNAME="nsh"
>
>
>
> It all boots and I get the nsh prompt but I get continuous:
>
>
>
> nsh_session: cle failed: 22
>
>
>
> I'm assuming that's EINVAL, but I can't work out why?
>
>
>
> 2. my board Make.defs file is an edited clone of another from the same
> device (SAMA5D2) and is virtually identical to many other similar files for
> other chips of course. I am running "Ubuntu 20.04.3 TLS"
>
>
>
> This is included in virtually all these files for any chip/arch:
>
>
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>
> else
>
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> endif
>
>
>
> But the compiler complains that there's:
>
>
>
> no rule to make target '-T/home/{rest of the path}'
>
>
>
> If I remove the -T it is fine.
>
>
>
> Linux/Ubuntu is including the -T in the path I assume? Seems very odd that
> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume? Linux
> skills are definitely lacking, so any suggestions welcomed!
>
>
Re: 10.3 merge issues
On Wed, Aug 17, 2022 at 12:56 PM TimH wrote:
> 1. Final change that allowed a compile was when I changed the defconfig
> to have the new:
>
>
>
> CONFIG_INIT_ENTRYPOINT="nsh_main"
>
> CONFIG_INIT_ENTRYNAME="nsh"
>
>
>
> It all boots and I get the nsh prompt but I get continuous:
>
>
>
> nsh_session: cle failed: 22
>
>
>
> I'm assuming that's EINVAL, but I can't work out why?
Looks to me like this message is probably printed from nsh_stdlogin(),
but I cannot understand where the "nsh_session" part of that printout
is coming from. Do you have CONFIG_NSH_CLE defined? (NSH_CLE in
Kconfig).
More below...
> 2. my board Make.defs file is an edited clone of another from the same
> device (SAMA5D2) and is virtually identical to many other similar files for
> other chips of course. I am running "Ubuntu 20.04.3 TLS"
>
> This is included in virtually all these files for any chip/arch:
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>
> else
>
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> endif
>
> But the compiler complains that there's:
>
> no rule to make target '-T/home/{rest of the path}'
>
> If I remove the -T it is fine.
>
> Linux/Ubuntu is including the -T in the path I assume? Seems very odd that
> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume? Linux
> skills are definitely lacking, so any suggestions welcomed!
Regarding question #2:
Dumb question, but after 'make clean' or 'make distclean' could you
verify there are no stale object files (*.o) anywhere in the nuttx or
apps trees? I'm asking because I've run into this problem in the past
where some obscure error in the makefiles caused some stale objects to
stay around.
Cheers,
Nathan
Re: 10.3 merge issues
1. Final change that allowed a compile was when I changed the defconfig to have the new: CONFIG_INIT_ENTRYPOINT="nsh_main" CONFIG_INIT_ENTRYNAME="nsh" It all boots and I get the nsh prompt but I get continuous: nsh_session: cle failed: 22 I'm assuming that's EINVAL, but I can't work out why? What kind of terminal do you use? CLE only works with a VT100-compatible terminal and will return -EINVAL to nsh_session if the terminal does not respond correctly to a VT100 request for the current cursor position.
RE: 10.3 merge issues
>-Original Message- >From: Gregory Nutt >Sent: 17 August 2022 19:16 >Subject: Re: 10.3 merge issues > > >> 1. Final change that allowed a compile was when I changed the defconfig >> to have the new: >> >> >> >> CONFIG_INIT_ENTRYPOINT="nsh_main" >> >> CONFIG_INIT_ENTRYNAME="nsh" >> >> >> >> It all boots and I get the nsh prompt but I get continuous: >> >> >> >> nsh_session: cle failed: 22 >> >> >> >> I'm assuming that's EINVAL, but I can't work out why? >> >> > >What kind of terminal do you use? CLE only works with a VT100-compatible >terminal and will return -EINVAL to nsh_session if the terminal does not >respond correctly to a VT100 request for the current cursor position. > [Tim] Minicom (via serial->USB) under WSL (main build/dev environment is a "proper" Linux machine, but run Minicom via WSL for historic reasons) It has a choice of VT102 or ANSI - both behave the same.
RE: 10.3 merge issues
Yes - I have CONFIG_NSH_CLE defined.
There are no .o files after a make clean
>-Original Message-
>From: Nathan Hartman
>Sent: 17 August 2022 19:10
>To: dev@nuttx.apache.org
>Subject: Re: 10.3 merge issues
>
>On Wed, Aug 17, 2022 at 12:56 PM TimH wrote:
>> 1. Final change that allowed a compile was when I changed the defconfig
>> to have the new:
>>
>>
>>
>> CONFIG_INIT_ENTRYPOINT="nsh_main"
>>
>> CONFIG_INIT_ENTRYNAME="nsh"
>>
>>
>>
>> It all boots and I get the nsh prompt but I get continuous:
>>
>>
>>
>> nsh_session: cle failed: 22
>>
>>
>>
>> I'm assuming that's EINVAL, but I can't work out why?
>
>
>Looks to me like this message is probably printed from nsh_stdlogin(), but I
>cannot understand where the "nsh_session" part of that printout is coming
>from. Do you have CONFIG_NSH_CLE defined? (NSH_CLE in Kconfig).
>
>More below...
>
>
>> 2. my board Make.defs file is an edited clone of another from the same
>> device (SAMA5D2) and is virtually identical to many other similar
>> files for other chips of course. I am running "Ubuntu 20.04.3 TLS"
>>
>> This is included in virtually all these files for any chip/arch:
>>
>> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>>
>> ARCHSCRIPT = -T "${shell cygpath -w
>> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>>
>> else
>>
>> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>>
>> endif
>>
>> But the compiler complains that there's:
>>
>> no rule to make target '-T/home/{rest of the path}'
>>
>> If I remove the -T it is fine.
>>
>> Linux/Ubuntu is including the -T in the path I assume? Seems very odd
>> that
>> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume?
>> Linux skills are definitely lacking, so any suggestions welcomed!
>
>
>Regarding question #2:
>
>Dumb question, but after 'make clean' or 'make distclean' could you verify
>there are no stale object files (*.o) anywhere in the nuttx or apps trees? I'm
>asking because I've run into this problem in the past where some obscure
>error in the makefiles caused some stale objects to stay around.
>
>Cheers,
>Nathan
RE: 10.3 merge issues
Thanks for the useful tip "V=1" = didn't know that Alan :)
But nothing additional reported, just the same " no rule to make" error
>-Original Message-
>From: Alan Carvalho de Assis
>Sent: 17 August 2022 18:14
>To: dev@nuttx.apache.org
>Subject: Re: 10.3 merge issues
>
>Hi Tim,
>
>Try to compile with verbose enabled:
>
>$ make V=1
>
>Probably your board is bringing some older definition that is causing a
>variable
>to be created incorrectly, because "-T/something" doesn't appear a valid
>target.
>
>BR,
>
>Alan
>
>On Wednesday, August 17, 2022, TimH wrote:
>
>> Hi All,
>>
>>
>>
>> My project has been in hibernation for 6 months for personal reasons
>> but today was the day I fired the custom board up again to restart
>> porting work.
>>
>>
>>
>> My 10.2-based "in progress" work behaves as before (which was a
>> relief) so I decided I would merge in 10.3 to make sure I restarted
>> with the latest release (not withstanding that 10.4 is close!).
>>
>>
>>
>> Most issues were easily solved by referring to release notes or good ol'
>> Google but I am left with one major and 1 minor problem.
>>
>>
>>
>> 1. Final change that allowed a compile was when I changed the
>> defconfig
>> to have the new:
>>
>>
>>
>> CONFIG_INIT_ENTRYPOINT="nsh_main"
>>
>> CONFIG_INIT_ENTRYNAME="nsh"
>>
>>
>>
>> It all boots and I get the nsh prompt but I get continuous:
>>
>>
>>
>> nsh_session: cle failed: 22
>>
>>
>>
>> I'm assuming that's EINVAL, but I can't work out why?
>>
>>
>>
>> 2. my board Make.defs file is an edited clone of another from the same
>> device (SAMA5D2) and is virtually identical to many other similar
>> files for other chips of course. I am running "Ubuntu 20.04.3 TLS"
>>
>>
>>
>> This is included in virtually all these files for any chip/arch:
>>
>>
>>
>> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>>
>> ARCHSCRIPT = -T "${shell cygpath -w
>> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>>
>> else
>>
>> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>>
>> endif
>>
>>
>>
>> But the compiler complains that there's:
>>
>>
>>
>> no rule to make target '-T/home/{rest of the path}'
>>
>>
>>
>> If I remove the -T it is fine.
>>
>>
>>
>> Linux/Ubuntu is including the -T in the path I assume? Seems very odd
>> that
>> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume?
>> Linux skills are definitely lacking, so any suggestions welcomed!
>>
>>
Re: 10.3 merge issues
On Wed, Aug 17, 2022 at 2:38 PM TimH wrote:
> >> no rule to make target '-T/home/{rest of the path}'
See commit:
https://github.com/apache/incubator-nuttx/commit/8defb843aa2e1d49b08b1cb7155aea97e1721b6c
There have been some refactorings in the build system to reduce code
duplication.
So instead of writing all this:
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
ARCHSCRIPT = -T "${shell cygpath -w
$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
Now you only have to write:
ARCHSCRIPT += $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
I recommend to compare your Make.defs with that of the board you
cloned and bring over all changes.
Cheers,
Nathan
Re: 10.3 merge issues
On Wed, Aug 17, 2022 at 3:15 PM Nathan Hartman wrote:
>
> On Wed, Aug 17, 2022 at 2:38 PM TimH wrote:
> > >> no rule to make target '-T/home/{rest of the path}'
>
> See commit:
> https://github.com/apache/incubator-nuttx/commit/8defb843aa2e1d49b08b1cb7155aea97e1721b6c
>
> There have been some refactorings in the build system to reduce code
> duplication.
>
> So instead of writing all this:
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
> else
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
> endif
>
> Now you only have to write:
> ARCHSCRIPT += $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> I recommend to compare your Make.defs with that of the board you
> cloned and bring over all changes.
This is the PR: https://github.com/apache/incubator-nuttx/pull/5496
Cheers,
Nathan
Re: 10.3 merge issues
I realise, now, I compared mine against 10.2 variants not 10.3...not sure why,
but there you go. I'll give that a try tomorrow - thanks!
On 17/08/2022, 20:19, "Nathan Hartman" wrote:
On Wed, Aug 17, 2022 at 3:15 PM Nathan Hartman
wrote:
>
> On Wed, Aug 17, 2022 at 2:38 PM TimH wrote:
> > >> no rule to make target '-T/home/{rest of the path}'
>
> See commit:
https://github.com/apache/incubator-nuttx/commit/8defb843aa2e1d49b08b1cb7155aea97e1721b6c
>
> There have been some refactorings in the build system to reduce code
> duplication.
>
> So instead of writing all this:
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
> else
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
> endif
>
> Now you only have to write:
> ARCHSCRIPT += $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> I recommend to compare your Make.defs with that of the board you
> cloned and bring over all changes.
This is the PR: https://github.com/apache/incubator-nuttx/pull/5496
Cheers,
Nathan
Quectel BG770A support on NuttX
Hi Everyone, By the chance, did you know if someone already added support to this modem on NuttX? A friend of mine from a USA company is willing to use this modem and they are interested to contract someone from community to do the port, case this modem is not support yet. At the end of the day this support will be integrated back to NuttX mainline. So, if you are interested to work on that, please let me know. BR, Alan
Re: 10.3 merge issues
On Wed, Aug 17, 2022 at 3:27 PM Tim Hardisty wrote: > I realise, now, I compared mine against 10.2 variants not 10.3...not sure > why, but there you go. I'll give that a try tomorrow - thanks! Sure thing! Let us know if that fixes it. I'm pretty sure that change in your board's Make.defs (and there might be a couple of others, that's why I suggest to compare it to the up-to-date Make.defs of the board you cloned) should fix the compile issues... Cheers, Nathan
Article: Visual Programming with Zig and NuttX Sensors
What if we could drag-and-drop NuttX Sensors to create IoT Apps? This article explains how... https://lupyuen.github.io/articles/visual Thanks to Alan C. Assis for the brilliant idea on "Visual Arduino"! Lup
Re: Quectel BG770A support on NuttX
Hi Alan, I am interested in this work. I am an embedded engineer and have worked with nuttx for several years porting to a couple of nordic mcus . At zGlue I was heavily involved porting nimBLE to nuttx, precision ring gyros, and more mundane sensors. None of the code made it out of legal review so no opportunity to upstream arose Bill Rees > > On Aug 17, 2022 at 1:03 PM, (mailto:acas...@gmail.com)> wrote: > > > > Hi Everyone, By the chance, did you know if someone already added support to > this modem on NuttX? A friend of mine from a USA company is willing to use > this modem and they are interested to contract someone from community to do > the port, case this modem is not support yet. At the end of the day this > support will be integrated back to NuttX mainline. So, if you are interested > to work on that, please let me know. BR, Alan > >
[VOTE] Apache NuttX 11.0.0 (incubating) RC0 release
Hello all, Apache NuttX (Incubating) 11.0.0 RC0 has been staged under [1] and it's time to vote on accepting it for release. If approved we will seek final release approval from the IPMC. Voting will be open for 72hr. A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. The Apache requirements for approving a release can be found here [3] "Before voting +1 [P]PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases." A document to walk through some of this process has been published on our project wiki and can be found here [4]. [ ] +1 accept (indicate what you validated - e.g. performed the non-RM items in [4]) [ ] -1 reject (explanation required) Thank you all, SCM Information: Release tag: nuttx-11.0.0-RC0 Hash for the release incubating-nuttx tag: 53800a86574b3d8b144bd3b6630cb16b8e1d0f92 Hash for the release incubating-nuttx-apps tag: 8b43f9f9ca30f44c1cccae9a9078d5d45b776d35 [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/11.0.0-RC0/ [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-11.0.0-RC0/ReleaseNotes [3] https://www.apache.org/dev/release.html#approving-a-release [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
RE: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release
Hi all, The voting is canceled and I restarted the vote process for 11.0.0-RC0 Thanks for testing the release and providing feedback Best regards Alin Jerpelea -Original Message- From: alin.jerpe...@sony.com Sent: den 12 augusti 2022 08:49 To: dev@nuttx.apache.org Subject: RE: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release Hi Alan, Thanks for investigating the issue. Did you fix the hash ? Do you retract your -1 ? @Petro Thanks for providing a explanation for the issue Best regards Alin -Original Message- From: Alan Carvalho de Assis Sent: den 12 augusti 2022 02:38 To: dev@nuttx.apache.org Subject: Re: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release The most important I forgot to say: Alin: reverting Petro's commit solves the issue, but is not the solution. He fixed the issue, it is just incompatible with old hash. The solution is to fix the hash. BR, Alan On 8/11/22, Alan Carvalho de Assis wrote: > Hi Petro, > > I think we don't want to be compatible with it if it was in fact faulty. > > The TEA algorithm by itself has some weakness as people can see here: > > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Tiny_Encrypt > ion_Algorithm__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U6G89QqC7-aO > 7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_su8CI-UD$ > > "TEA has a few weaknesses. Most notably, it suffers from equivalent > keys—each key is equivalent to three others, which means that the > effective key size is only 126 bits.[5] As a result, TEA is especially > bad as a cryptographic hash function. This weakness led to a method > for hacking Microsoft's Xbox game console, where the cipher was used > as a hash function." > > We could keep TEA support as an option (maybe for devices that don't > need strong security) but the default algo could be XTEA or some other > without known weakness. > > Just my 2 cents. > > BR, > > Alan > > On 8/11/22, Petro Karashchenko wrote: >> The code had an obvious bug when memory was accessed out of bounds. >> >> In some of the cases it was accessing zeroes and producing some >> output, but after my changes it started to work "as designed" and use >> "space" (not >> zero) as padding. >> >> I'm not sure what is the best way to fix this. Changing padding >> symbol from "space" to zero should also make decryption working. I >> really do not know what is the best solution and what is better "to >> be right" or "to be backward compatible". >> >> Best regards, >> Petro >> >> On Thu, Aug 11, 2022, 10:10 PM Alan Carvalho de Assis >> >> wrote: >> >>> ACK >>> >>> Strange, the previous email went only to you! >>> >>> On 8/11/22, Alin Jerpelea wrote: >>> > @Alan Carvalho de Assis please confirm that >>> > works after revert >>> > >>> > On Thu, 11 Aug 2022, 20:22 Petro Karashchenko, >>> > >>> > wrote: >>> > >>> >> Hello Alan, >>> >> >>> >> Seems that the root cause is my change >>> >> https://urldefense.com/v3/__https://github.com/apache/incubator-n >>> >> uttx-apps/pull/1097__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U >>> >> 6G89QqC7-aO7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_ss9mT39r$ >>> >> >>> >> I think that all previously generated passwords need to be >>> >> re-generated. >>> >> >>> >> Best regards, >>> >> Petro >>> >> >>> >> On Thu, Aug 11, 2022, 8:49 PM Alan Carvalho de Assis >>> >> >> > >>> >> wrote: >>> >> >>> >> > Alin, >>> >> > >>> >> > I want to redraw my vote, I found the first regression, so my >>> >> > vote >>> >> > is: >>> >> > >>> >> > -1 >>> >> > >>> >> > Seems like the console login is not working, I'm using user: >>> >> > admin and >>> >> > password: Administrator >>> >> > >>> >> > $ ./tools/configure.sh sim:nsh >>> >> > >>> >> > $ make -j >>> >> > >>> >> > $ ./nuttx >>> >> > login: admin >>> >> > password: >>> >> > Invalid username or password >>> >> > login: admin >>> >> > password: >>> >> > Invalid username or password >>> >> > login: admin >>> >> > password: >>> >> > Invalid username or password >>> >> > Login failed! >>> >> > >>> >> > I double checked the /etc/passwd file and it is correct: >>> >> > >>> >> > nsh> cat /etc/passwd >>> >> > admin:8Tv+Hbmr3pLddSjtzL0kwC:0:0:/ >>> >> > >>> >> > Please help me to find the offending commit. >>> >> > >>> >> > BR, >>> >> > >>> >> > Alan >>> >> > >>> >> > On 8/8/22, Alin Jerpelea wrote: >>> >> > > Hello all, >>> >> > > Apache NuttX (Incubating) 10.4.0 RC0 has been staged under >>> >> > > [1] and it's time to vote on accepting it for release. If >>> >> > > approved we will seek final release approval from the IPMC. >>> >> > > Voting will be open for 72hr. >>> >> > > >>> >> > > A minimum of 3 binding +1 votes and more binding +1 than >>> >> > > binding >>> >> > > -1 >>> >> > > are >>> >> > > required to pass. >>> >> > > >>> >> > > The Apache requirements for approving a release can be found >>> >> > > here >>> [3] >>> >> > > "Before voting +1 [P]PMC members are required to download the >>> >> > > signed source code package, compile it as provided, a
