Sv: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Jerpelea, Alin
+1,

I checked
- Signature and hash OK
- LICENSE, DISCLAIMER and NOTICE exist
- Build from source.Spresense board

Från: Brennan Ashton 
Skickat: den 24 juni 2020 07:52
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

Greg and Alan,
Started looking and there are some changes in the diff in the
generated config.h as can be seen here
One change is the date command is no longer disabled by default.  This
accounts for 2304 bytes, leaving only 800 byte change.
I'm not sure if changing the default was expected, but I dont think
this should block the release.
The TLS changes are harder for me to judge and the netdb change I
think just changes ram usage.  I can dig more, if you think it is
necessary, I agree that we should keep and eye on the size though. I
had some thoughts on keeping the build artifacts around so we could
track and test things easier (hard to go back in time with both repos
changing).

9.1.0
   text   databssdechexfilename
  71731104   2476  74311  12247./9.1/nuttx

9.1.0 (with date disabled)
   text   databssdechexfilename
  69427104   2476  72007  11947nuttx


--- /home/bashton/nuttx/apache/sizetest/9.0/config.h
+++ /home/bashton/nuttx/apache/sizetest/9.1/config.h
@@ -135,7 +135,6 @@
 #define CONFIG_TASK_NAME_SIZE 31
 #define CONFIG_MAX_TASKS 16
 #define CONFIG_SCHED_WAITPID 1
-#define CONFIG_NPTHREAD_KEYS 4
 #define CONFIG_PTHREAD_MUTEX_ROBUST 1
 #define CONFIG_DEV_CONSOLE 1
 #define CONFIG_SDCLONE_DISABLE 1
@@ -196,15 +195,14 @@
 #define CONFIG_POSIX_SPAWN_PROXY_STACKSIZE 1024
 #define CONFIG_TASK_SPAWN_DEFAULT_STACKSIZE 2048
 #define CONFIG_LIB_HOSTNAME ""
-#define CONFIG_ARCH_HAVE_TLS 1
-#define CONFIG_NETDB_BUFSIZE 128
+#define CONFIG_TLS_NELEM 4
+#define CONFIG_NETDB_BUFSIZE 256
 #define CONFIG_NETDB_MAX_IPADDR 1
-#define CONFIG_LIBC_IOCTL_VARIADIC 1
 #define CONFIG_LIB_SENDFILE_BUFSIZE 512
 #define CONFIG_BUILTIN 1
 #define CONFIG_HAVE_CXX 1
 #define CONFIG_EXAMPLES_HELLO 1
-#define CONFIG_EXAMPLES_HELLO_PROGNAME hello
+#define CONFIG_EXAMPLES_HELLO_PROGNAME "hello"
 #define CONFIG_EXAMPLES_HELLO_PRIORITY 100
 #define CONFIG_EXAMPLES_HELLO_STACKSIZE 2048
 #define CONFIG_NSH_LIBRARY 1
@@ -214,7 +212,6 @@
 #define CONFIG_NSH_MAXARGUMENTS 7
 #define CONFIG_NSH_NESTDEPTH 3
 #define CONFIG_NSH_BUILTIN_APPS 1
-#define CONFIG_NSH_DISABLE_DATE 1
 #define CONFIG_NSH_DISABLE_LOSMART 1
 #define CONFIG_NSH_DISABLE_PRINTF 1
 #define CONFIG_NSH_DISABLE_TRUNCATE 1
@@ -227,7 +224,7 @@
 #define CONFIG_SYSTEM_NSH 1
 #define CONFIG_SYSTEM_NSH_PRIORITY 100
 #define CONFIG_SYSTEM_NSH_STACKSIZE 2048
-#define CONFIG_SYSTEM_NSH_PROGNAME nsh
+#define CONFIG_SYSTEM_NSH_PROGNAME "nsh"
 #define CONFIG_SYSTEM_NSH_CXXINITIALIZE 1
 #define CONFIG_READLINE_HAVE_EXTMATCH 1
 #define CONFIG_SYSTEM_READLINE 1

On Tue, Jun 23, 2020 at 6:17 PM Gregory Nutt  wrote:
>
> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
> >
> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
> >> Flash usage, but I didn't check further to see what happened.
> >>
> >> NuttX 9.0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>68624104   2496  71224  11638nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.0.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192976   7536 185440 125248
> >> nsh>
> >>
> >>
> >> NuttX 9.1 RC0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>71732104   2476  74312  12248nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.1.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192992   7536 185456 125264
> >> nsh>
> >
> > This might indicate a significant problem.  One possible explanation
> > might be that a new configuration option enables logic by default that
> > it should not.  Almost any explanation you can think of suggests a
> > problem.
>
> Can you look into this Alan?  I would think that an unexplained 3Kb size
> increase in such a trivial configuration would warrant a -1 vote.
>
>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
Greg and Alan,
Started looking and there are some changes in the diff in the
generated config.h as can be seen here
One change is the date command is no longer disabled by default.  This
accounts for 2304 bytes, leaving only 800 byte change.
I'm not sure if changing the default was expected, but I dont think
this should block the release.
The TLS changes are harder for me to judge and the netdb change I
think just changes ram usage.  I can dig more, if you think it is
necessary, I agree that we should keep and eye on the size though. I
had some thoughts on keeping the build artifacts around so we could
track and test things easier (hard to go back in time with both repos
changing).

9.1.0
   text   databssdechexfilename
  71731104   2476  74311  12247./9.1/nuttx

9.1.0 (with date disabled)
   text   databssdechexfilename
  69427104   2476  72007  11947nuttx


--- /home/bashton/nuttx/apache/sizetest/9.0/config.h
+++ /home/bashton/nuttx/apache/sizetest/9.1/config.h
@@ -135,7 +135,6 @@
 #define CONFIG_TASK_NAME_SIZE 31
 #define CONFIG_MAX_TASKS 16
 #define CONFIG_SCHED_WAITPID 1
-#define CONFIG_NPTHREAD_KEYS 4
 #define CONFIG_PTHREAD_MUTEX_ROBUST 1
 #define CONFIG_DEV_CONSOLE 1
 #define CONFIG_SDCLONE_DISABLE 1
@@ -196,15 +195,14 @@
 #define CONFIG_POSIX_SPAWN_PROXY_STACKSIZE 1024
 #define CONFIG_TASK_SPAWN_DEFAULT_STACKSIZE 2048
 #define CONFIG_LIB_HOSTNAME ""
-#define CONFIG_ARCH_HAVE_TLS 1
-#define CONFIG_NETDB_BUFSIZE 128
+#define CONFIG_TLS_NELEM 4
+#define CONFIG_NETDB_BUFSIZE 256
 #define CONFIG_NETDB_MAX_IPADDR 1
-#define CONFIG_LIBC_IOCTL_VARIADIC 1
 #define CONFIG_LIB_SENDFILE_BUFSIZE 512
 #define CONFIG_BUILTIN 1
 #define CONFIG_HAVE_CXX 1
 #define CONFIG_EXAMPLES_HELLO 1
-#define CONFIG_EXAMPLES_HELLO_PROGNAME hello
+#define CONFIG_EXAMPLES_HELLO_PROGNAME "hello"
 #define CONFIG_EXAMPLES_HELLO_PRIORITY 100
 #define CONFIG_EXAMPLES_HELLO_STACKSIZE 2048
 #define CONFIG_NSH_LIBRARY 1
@@ -214,7 +212,6 @@
 #define CONFIG_NSH_MAXARGUMENTS 7
 #define CONFIG_NSH_NESTDEPTH 3
 #define CONFIG_NSH_BUILTIN_APPS 1
-#define CONFIG_NSH_DISABLE_DATE 1
 #define CONFIG_NSH_DISABLE_LOSMART 1
 #define CONFIG_NSH_DISABLE_PRINTF 1
 #define CONFIG_NSH_DISABLE_TRUNCATE 1
@@ -227,7 +224,7 @@
 #define CONFIG_SYSTEM_NSH 1
 #define CONFIG_SYSTEM_NSH_PRIORITY 100
 #define CONFIG_SYSTEM_NSH_STACKSIZE 2048
-#define CONFIG_SYSTEM_NSH_PROGNAME nsh
+#define CONFIG_SYSTEM_NSH_PROGNAME "nsh"
 #define CONFIG_SYSTEM_NSH_CXXINITIALIZE 1
 #define CONFIG_READLINE_HAVE_EXTMATCH 1
 #define CONFIG_SYSTEM_READLINE 1

On Tue, Jun 23, 2020 at 6:17 PM Gregory Nutt  wrote:
>
> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
> >
> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
> >> Flash usage, but I didn't check further to see what happened.
> >>
> >> NuttX 9.0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>68624104   2496  71224  11638nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.0.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192976   7536 185440 125248
> >> nsh>
> >>
> >>
> >> NuttX 9.1 RC0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>71732104   2476  74312  12248nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.1.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192992   7536 185456 125264
> >> nsh>
> >
> > This might indicate a significant problem.  One possible explanation
> > might be that a new configuration option enables logic by default that
> > it should not.  Almost any explanation you can think of suggests a
> > problem.
>
> Can you look into this Alan?  I would think that an unexplained 3Kb size
> increase in such a trivial configuration would warrant a -1 vote.
>
>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Alin Jerpelea
those are the bin and config diffs between 9.0 and 9.1 for Spresense board
(nsh defconfig)

file size
2232796 Jun 24 07:34 nuttx-9.0
2274908 Jun 24 07:31 nuttx-9.1

--- conf-9.02020-06-24 07:34:00.244923392 +0200
+++ conf-9.12020-06-24 07:30:35.748476384 +0200
@@ -129,10 +129,8 @@
 # CONFIG_ARCH_ARM1156T2 is not set
 # CONFIG_ARCH_ARM1176JZ is not set
 # CONFIG_ARCH_CORTEXM0 is not set
-# CONFIG_ARCH_CORTEXM23 is not set
 CONFIG_ARCH_ARMV7M=y
 # CONFIG_ARCH_CORTEXM3 is not set
-# CONFIG_ARCH_CORTEXM33 is not set
 CONFIG_ARCH_CORTEXM4=y
 # CONFIG_ARCH_CORTEXM7 is not set
 # CONFIG_ARCH_ARMV7A is not set
@@ -144,6 +142,10 @@
 # CONFIG_ARCH_CORTEXR4 is not set
 # CONFIG_ARCH_CORTEXR5 is not set
 # CONFIG_ARCH_CORTEXR7 is not set
+# CONFIG_ARCH_ARMV8M is not set
+# CONFIG_ARCH_CORTEXM23 is not set
+# CONFIG_ARCH_CORTEXM33 is not set
+# CONFIG_ARCH_CORTEXM35P is not set
 CONFIG_ARCH_FAMILY="armv7-m"
 CONFIG_ARCH_CHIP="cxd56xx"
 # CONFIG_ARCH_HAVE_TRUSTZONE is not set
@@ -165,8 +167,6 @@
 # CONFIG_ARMV7M_HAVE_DTCM is not set
 # CONFIG_ARMV7M_TOOLCHAIN_IARL is not set
 # CONFIG_ARMV7M_TOOLCHAIN_BUILDROOT is not set
-# CONFIG_ARMV7M_TOOLCHAIN_CODEREDL is not set
-# CONFIG_ARMV7M_TOOLCHAIN_CODESOURCERYL is not set
 CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL=y
 # CONFIG_ARMV7M_TOOLCHAIN_CLANGL is not set
 # CONFIG_ARMV7M_HAVE_STACKCHECK is not set
@@ -387,8 +387,12 @@
 # Board-Specific Options
 #
 CONFIG_CXD56_SPIFLASHSIZE=0x40
-# CONFIG_SPRESENSE_EXTENSION is not set
+
+#
+# Audio Options
+#
 # CONFIG_CXD56_IMAGEPROC is not set
+# CONFIG_SPRESENSE_EXTENSION is not set

 #
 # LTE Options
@@ -457,7 +461,6 @@
 #
 # Pthread Options
 #
-CONFIG_NPTHREAD_KEYS=4
 # CONFIG_PTHREAD_MUTEX_TYPES is not set
 CONFIG_PTHREAD_MUTEX_ROBUST=y
 # CONFIG_PTHREAD_MUTEX_UNSAFE is not set
@@ -945,7 +948,6 @@
 # CONFIG_EOL_IS_LF is not set
 # CONFIG_EOL_IS_BOTH_CRLF is not set
 CONFIG_EOL_IS_EITHER_CRLF=y
-# CONFIG_MEMCPY_VIK is not set
 # CONFIG_LIBM is not set

 #
@@ -994,6 +996,7 @@
 #
 # memcpy/memset Options
 #
+# CONFIG_MEMCPY_VIK is not set
 # CONFIG_MEMSET_OPTSPEED is not set

 #
@@ -1011,12 +1014,12 @@
 # Time/Time Zone Support
 #
 # CONFIG_LIBC_LOCALTIME is not set
-CONFIG_ARCH_HAVE_TLS=y

 #
 # Thread Local Storage (TLS)
 #
-# CONFIG_TLS is not set
+# CONFIG_TLS_ALIGNED is not set
+CONFIG_TLS_NELEM=4

 #
 # Network-Related Options
@@ -1029,10 +1032,9 @@
 # NETDB Support
 #
 # CONFIG_LIBC_GAISTRERROR is not set
-CONFIG_NETDB_BUFSIZE=128
+CONFIG_NETDB_BUFSIZE=256
 CONFIG_NETDB_MAX_IPADDR=1
 # CONFIG_NETDB_HOSTFILE is not set
-CONFIG_LIBC_IOCTL_VARIADIC=y
 CONFIG_LIB_SENDFILE_BUFSIZE=512

 #
@@ -1084,7 +1086,6 @@
 # CONFIG_EXAMPLES_AUDIO_SOUND is not set
 # CONFIG_EXAMPLES_BATTERY is not set
 # CONFIG_EXAMPLES_SIXAXIS is not set
-# CONFIG_EXAMPLES_BUTTONS is not set
 # CONFIG_EXAMPLES_CALIB_UDELAY is not set
 # CONFIG_EXAMPLES_CCTYPE is not set
 # CONFIG_EXAMPLES_CHARGER is not set
@@ -1097,6 +1098,7 @@
 # CONFIG_EXAMPLES_FTPC is not set
 # CONFIG_EXAMPLES_FTPD is not set
 # CONFIG_EXAMPLES_GPS is not set
+# CONFIG_EXAMPLES_HDC1008 is not set
 # CONFIG_EXAMPLES_HELLO is not set
 # CONFIG_EXAMPLES_HELLOXX is not set
 # CONFIG_EXAMPLES_HIDKBD is not set
@@ -1257,7 +1259,7 @@
 # CONFIG_NSH_DISABLE_RM is not set
 # CONFIG_NSH_DISABLE_RMDIR is not set
 # CONFIG_NSH_DISABLE_SET is not set
-# CONFIG_NSH_DISABLE_SH is not set
+# CONFIG_NSH_DISABLE_SOURCE is not set
 # CONFIG_NSH_DISABLE_SLEEP is not set
 # CONFIG_NSH_DISABLE_TIME is not set
 # CONFIG_NSH_DISABLE_TEST is not set

On Wed, Jun 24, 2020 at 3:17 AM Gregory Nutt  wrote:

> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
> >
> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
> >> Flash usage, but I didn't check further to see what happened.
> >>
> >> NuttX 9.0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>68624104   2496  71224  11638nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.0.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192976   7536 185440 125248
> >> nsh>
> >>
> >>
> >> NuttX 9.1 RC0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>71732104   2476  74312  12248nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.1.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192992   7536 185456 125264
> >> nsh>
> >
> > This might indicate a significant problem.  One possible explanation
> > might be that a new configuration option enables logic by default that
> > it should not.  Almost any explanation you can think of suggests a
> > problem.
>
> Can you look into this Alan?  I would think that an unexplained 3Kb size
> increase in such a trivial configuration would warrant a -1 vote.
>
>
>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Alin Jerpelea
 +1,

I checked
- Signature and hash OK
- LICENSE, DISCLAIMER and NOTICE exist
- Build from source.Spresense board

On Wed, Jun 24, 2020 at 3:17 AM Gregory Nutt  wrote:

> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
> >
> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
> >> Flash usage, but I didn't check further to see what happened.
> >>
> >> NuttX 9.0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>68624104   2496  71224  11638nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.0.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192976   7536 185440 125248
> >> nsh>
> >>
> >>
> >> NuttX 9.1 RC0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text   databssdechexfilename
> >>71732104   2476  74312  12248nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.1.0
> >> nsh> free
> >>   total   used   freelargest
> >> Umem:   192992   7536 185456 125264
> >> nsh>
> >
> > This might indicate a significant problem.  One possible explanation
> > might be that a new configuration option enables logic by default that
> > it should not.  Almost any explanation you can think of suggests a
> > problem.
>
> Can you look into this Alan?  I would think that an unexplained 3Kb size
> increase in such a trivial configuration would warrant a -1 vote.
>
>
>


Jenkins build is back to normal : NuttX-Nightly-Build #200

2020-06-23 Thread Apache Jenkins Server
See 



Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Gregory Nutt

On 6/23/2020 6:59 PM, Gregory Nutt wrote:



I compared it to release 9.0 and noticed it increased about 3 KiB of
Flash usage, but I didn't check further to see what happened.

NuttX 9.0

$ arm-none-eabi-size nuttx
    text   data    bss    dec    hex    filename
   68624    104   2496  71224  11638    nuttx


NuttShell (NSH) NuttX-9.0.0
nsh> free
  total   used   free    largest
Umem:   192976   7536 185440 125248
nsh>


NuttX 9.1 RC0

$ arm-none-eabi-size nuttx
    text   data    bss    dec    hex    filename
   71732    104   2476  74312  12248    nuttx


NuttShell (NSH) NuttX-9.1.0
nsh> free
  total   used   free    largest
Umem:   192992   7536 185456 125264
nsh>


This might indicate a significant problem.  One possible explanation 
might be that a new configuration option enables logic by default that 
it should not.  Almost any explanation you can think of suggests a 
problem.


Can you look into this Alan?  I would think that an unexplained 3Kb size 
increase in such a trivial configuration would warrant a -1 vote.





Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Gregory Nutt




I compared it to release 9.0 and noticed it increased about 3 KiB of
Flash usage, but I didn't check further to see what happened.

NuttX 9.0

$ arm-none-eabi-size nuttx
text   data bss dec hex filename
   686241042496   71224   11638 nuttx


NuttShell (NSH) NuttX-9.0.0
nsh> free
  total   used   freelargest
Umem:   192976   7536 185440 125248
nsh>


NuttX 9.1 RC0

$ arm-none-eabi-size nuttx
text   data bss dec hex filename
   717321042476   74312   12248 nuttx


NuttShell (NSH) NuttX-9.1.0
nsh> free
  total   used   freelargest
Umem:   192992   7536 185456 125264
nsh>
  


This might indicate a significant problem.  One possible explanation 
might be that a new configuration option enables logic by default that 
it should not.  Almost any explanation you can think of suggests a problem.





Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Justin Mclean
Hi,

> This key is not expired and has been signed by my apache.org email address as 
> well

Thanks for that I must of had an old cached key.

Setting your expiry dates to the near future may not be a good idea as I seem 
to recall releases with expired key were removed from the mirrors at one point. 
I ‘m not sure how often it checks or if that is still the case.


Thanks,
Justin

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
On Tue, Jun 23, 2020 at 5:36 PM Brennan Ashton
 wrote:
>
> On Tue, Jun 23, 2020 at 5:35 PM Brennan Ashton
>  wrote:
> >
> > On Tue, Jun 23, 2020 at 5:31 PM Justin Mclean  
> > wrote:
> > >
> > > Hi,
> > >
> > > I’ve not done a full check (which I will do) but I would be -1 on this 
> > > release as it looks like it’s been signed with an expired key:
> > >
> > > gpg: Good signature from "Brennan Ashton " 
> > > [expired]
> > > gpg: Note: This key has expired!
> > >
> > > It's also a good idea to sign with an “@apache.org” email address.
> > This key is not expired and has been signed by my apache.org email
> > address as well:
> > https://keyserver.ubuntu.com/pks/lookup?search=0x3554D78458CEB6954B020E12E1B6E30DB05D6280=on=index
> > This is also indicated here:
> > https://dist.apache.org/repos/dist/release/incubator/nuttx/KEYS
> >
> > --Brennan
>
> Hmm I take that back about the KEYS file.  I must have messed up my
> SVN foo, because I certainly updated my local copy of that file...

Sorry for all the emails... Wrong link, the KEYS file in dev is correct.
https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS
If you can let me know what is wrong here I will be happy to fix it,
but this seems correct to me.

--Brennan


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
On Tue, Jun 23, 2020 at 5:35 PM Brennan Ashton
 wrote:
>
> On Tue, Jun 23, 2020 at 5:31 PM Justin Mclean  
> wrote:
> >
> > Hi,
> >
> > I’ve not done a full check (which I will do) but I would be -1 on this 
> > release as it looks like it’s been signed with an expired key:
> >
> > gpg: Good signature from "Brennan Ashton " 
> > [expired]
> > gpg: Note: This key has expired!
> >
> > It's also a good idea to sign with an “@apache.org” email address.
> This key is not expired and has been signed by my apache.org email
> address as well:
> https://keyserver.ubuntu.com/pks/lookup?search=0x3554D78458CEB6954B020E12E1B6E30DB05D6280=on=index
> This is also indicated here:
> https://dist.apache.org/repos/dist/release/incubator/nuttx/KEYS
>
> --Brennan

Hmm I take that back about the KEYS file.  I must have messed up my
SVN foo, because I certainly updated my local copy of that file...


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
On Tue, Jun 23, 2020 at 5:31 PM Justin Mclean  wrote:
>
> Hi,
>
> I’ve not done a full check (which I will do) but I would be -1 on this 
> release as it looks like it’s been signed with an expired key:
>
> gpg: Good signature from "Brennan Ashton " 
> [expired]
> gpg: Note: This key has expired!
>
> It's also a good idea to sign with an “@apache.org” email address.
This key is not expired and has been signed by my apache.org email
address as well:
https://keyserver.ubuntu.com/pks/lookup?search=0x3554D78458CEB6954B020E12E1B6E30DB05D6280=on=index
This is also indicated here:
https://dist.apache.org/repos/dist/release/incubator/nuttx/KEYS

--Brennan


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Justin Mclean
Hi,

I’ve not done a full check (which I will do) but I would be -1 on this release 
as it looks like it’s been signed with an expired key:

gpg: Good signature from "Brennan Ashton " [expired]
gpg: Note: This key has expired!

It's also a good idea to sign with an “@apache.org” email address.

Thanks,
Justin

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Justin Mclean
Hi,

> Does this mean that if you do not validate anything, you lose your right as a 
> PPMC member to vote?

No, merit once gained isn’t lost, but it could be a little embarrassing if a 
critical issue is found after the release has been made. In that case another 
release is needed to correct it, it may not be a big deal, but it may cause 
some users inconvenience. The aim if for each release to be better than the 
last one. I would recommend that everyone voting does a complete check.

Re [DISCUSS] it’s a good idea to have one but it’s not required by ASF policy. 
Having a discuss thread may just means there’s a few less RC’s and less 
conversation in the VOTE thread.

Thanks,
Justin



Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Alan Carvalho de Assis
Hi Brennan,

I did a basic test on STM32F4Discovery board compiling the "nsh" and
everything worked fine (see below).

My VOTE: +1


I compared it to release 9.0 and noticed it increased about 3 KiB of
Flash usage, but I didn't check further to see what happened.

NuttX 9.0

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
  68624 1042496   71224   11638 nuttx


NuttShell (NSH) NuttX-9.0.0
nsh> free
 total   used   freelargest
Umem:   192976   7536 185440 125248
nsh>


NuttX 9.1 RC0

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
  71732 1042476   74312   12248 nuttx


NuttShell (NSH) NuttX-9.1.0
nsh> free
 total   used   freelargest
Umem:   192992   7536 185456 125264
nsh>


Good work guys!

BR,

Alan

On 6/23/20, Brennan Ashton  wrote:
> Hello all,
> Apache NuttX (Incubating) 9.1.0 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.
>
> Because this project targets embedded systems there is more complexity
> involved
> in the build process.  We have tried to make some improvements around this
> for
> new people to the project and are in the process of updating our sites and
> wiki
> to simplify the getting started process.
> Two starting points:
>  * README.txt -- This is found in the Apache NuttX source and is extensive.
>  * Unofficial NuttX Companion -- Located at [3], this is a currently
> unofficial
>opinionated guide maintained by some of the project committers.
>
>
> 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 [4]
> "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 [5].  I did try to walk through this document,
> but please comment
> if you find anything not clear.
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [5])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Brennan Ashton
>
> SCM Information:
>   Release tag: releases/9.1.0-RC0
>   Hash for the release incubating-nuttx tag:
> 5d5e6f7192d24a6241aa3e22c729a85eda7afe2d
>   Hash for the release incubating-nuttx-apps tag:
> 6fd57ba0712a78b20bd3ce49022924810a5552c7
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC0/
> [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC0/ReleaseNotes
> [3] https://nuttx-companion.readthedocs.io/en/latest/
> [4] https://www.apache.org/dev/release.html#approving-a-release
> [5]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
>
> In the past, I thought we decided that any [VOTE] phase must be preceded
> by a [DISCUSS] phase?
>

This email is basically boiler plate that is following the process that
Apache defines for the podling release process and is the same as what we
did for the last release. There is no obligation to vote, but if you do you
are certifying that you did the checks you said you did.

As for the discuss bit, I outlined a release timeline there were no
objections even in a follow-up reminder.bIf anyone objects to the release
they are welcome to -1 and we can cancel the vote. We kind of did that last
time which is why RC1 not RC0 passed and went to the IPMC for voting. I
don't see any reason for an additional discussion phase if we agreed to a
timeline, this process is already painfully slow and has ample time to halt
the process in the case of bugs.

--Brennan

>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Gregory Nutt

On 6/23/2020 12:36 AM, Brennan Ashton wrote:

Hello all,
Apache NuttX (Incubating) 9.1.0 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.

Because this project targets embedded systems there is more complexity involved
in the build process.  We have tried to make some improvements around this for
new people to the project and are in the process of updating our sites and wiki
to simplify the getting started process.
Two starting points:
  * README.txt -- This is found in the Apache NuttX source and is extensive.
  * Unofficial NuttX Companion -- Located at [3], this is a currently unofficial
opinionated guide maintained by some of the project committers.


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 [4]
"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 [5].  I did try to walk through this document,
but please comment
if you find anything not clear.

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [5])
[ ] -1 reject (explanation required)

Thank you all,
Brennan Ashton

SCM Information:
   Release tag: releases/9.1.0-RC0
   Hash for the release incubating-nuttx tag:
5d5e6f7192d24a6241aa3e22c729a85eda7afe2d
   Hash for the release incubating-nuttx-apps tag:
6fd57ba0712a78b20bd3ce49022924810a5552c7

[1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC0/
[2] 
https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC0/ReleaseNotes
[3] https://nuttx-companion.readthedocs.io/en/latest/
[4] https://www.apache.org/dev/release.html#approving-a-release
[5] 
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release


In the past, I thought we decided that any [VOTE] phase must be preceded 
by a [DISCUSS] phase?




Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Gregory Nutt

On 6/23/2020 12:36 AM, Brennan Ashton wrote:

Hello all,
Apache NuttX (Incubating) 9.1.0 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.

Because this project targets embedded systems there is more complexity involved
in the build process.  We have tried to make some improvements around this for
new people to the project and are in the process of updating our sites and wiki
to simplify the getting started process.
Two starting points:
  * README.txt -- This is found in the Apache NuttX source and is extensive.
  * Unofficial NuttX Companion -- Located at [3], this is a currently unofficial
opinionated guide maintained by some of the project committers.


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 [4]
"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 [5].  I did try to walk through this document,
but please comment
if you find anything not clear.

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [5])
[ ] -1 reject (explanation required)

Thank you all,
Brennan Ashton

SCM Information:
   Release tag: releases/9.1.0-RC0
   Hash for the release incubating-nuttx tag:
5d5e6f7192d24a6241aa3e22c729a85eda7afe2d
   Hash for the release incubating-nuttx-apps tag:
6fd57ba0712a78b20bd3ce49022924810a5552c7

[1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC0/
[2] 
https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC0/ReleaseNotes
[3] https://nuttx-companion.readthedocs.io/en/latest/
[4] https://www.apache.org/dev/release.html#approving-a-release
[5] 
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release


Does this mean that if you do not validate anything, you lose your right 
as a PPMC member to vote?





Re: ftw/fts

2020-06-23 Thread Gregory Nutt





The core of these functions should be the same as the logic in 
apps/insulin in cmd_ls() that handles the 'lsd _R' command.


Of course, I meant 'ls -R'.  I don't know what I was on.

I am referring specifically to the function nsh_foreach_direntry() 
which is actually in nsh_fsutils.c.  It is used in several places in NSH.


I will implement these functions if no one else is doing them. If 
someone else is working on them, then let me know so that we do not 
duplicate effort.






Re: ftw/fts

2020-06-23 Thread Gregory Nutt



The core of these functions should be the same as the logic in 
apps/insulin in cmd_ls() that handles the 'lsd _R' command.


Of course, I meant 'ls -R'.  I don't know what I was on.

I am referring specifically to the function nsh_foreach_direntry() which 
is actually in nsh_fsutils.c.  It is used in several places in NSH.





Re: ftw/fts

2020-06-23 Thread spudaneco
The core of these functions should be the same as the logic in apps/insulin in 
cmd_ls() that handles the 'lsd _R' command.Sent from Samsung tablet.
 Original message From: Alan Carvalho de Assis 
 Date: 6/23/20  5:22 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: ftw/fts Hi Yamamoto-san,I didn't find an 
implementation for NuttX, but it should be nice tohave it because it is part of 
POSIX standard.BR,AlanOn 6/23/20, Takashi Yamamoto 
 wrote:> hi,>> does anyone know ftw/nftw, fts, 
or similar libraries for nuttx?> 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/nftw.html> 
https://netbsd.gw.com/cgi-bin/man-cgi?fts++NetBSD-current>

Re: ftw/fts

2020-06-23 Thread Alan Carvalho de Assis
Hi Yamamoto-san,

I didn't find an implementation for NuttX, but it should be nice to
have it because it is part of POSIX standard.

BR,

Alan

On 6/23/20, Takashi Yamamoto  wrote:
> hi,
>
> does anyone know ftw/nftw, fts, or similar libraries for nuttx?
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/nftw.html
> https://netbsd.gw.com/cgi-bin/man-cgi?fts++NetBSD-current
>


Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Abdelatif Guettouche
Hi,
+1, I checked:
- Incubating in name
- Signature and hash OK
- LICENSE, DISCLAIMER and NOTICE exist
- Build from source.


On Tue, Jun 23, 2020 at 7:37 AM Brennan Ashton
 wrote:
>
> Hello all,
> Apache NuttX (Incubating) 9.1.0 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.
>
> Because this project targets embedded systems there is more complexity 
> involved
> in the build process.  We have tried to make some improvements around this for
> new people to the project and are in the process of updating our sites and 
> wiki
> to simplify the getting started process.
> Two starting points:
>  * README.txt -- This is found in the Apache NuttX source and is extensive.
>  * Unofficial NuttX Companion -- Located at [3], this is a currently 
> unofficial
>opinionated guide maintained by some of the project committers.
>
>
> 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 [4]
> "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 [5].  I did try to walk through this document,
> but please comment
> if you find anything not clear.
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [5])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Brennan Ashton
>
> SCM Information:
>   Release tag: releases/9.1.0-RC0
>   Hash for the release incubating-nuttx tag:
> 5d5e6f7192d24a6241aa3e22c729a85eda7afe2d
>   Hash for the release incubating-nuttx-apps tag:
> 6fd57ba0712a78b20bd3ce49022924810a5552c7
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC0/
> [2] 
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC0/ReleaseNotes
> [3] https://nuttx-companion.readthedocs.io/en/latest/
> [4] https://www.apache.org/dev/release.html#approving-a-release
> [5] 
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release


Re: Creating 9.1.0-RC0

2020-06-23 Thread Abdelatif Guettouche
> Hmmm... I believe that the whole point of Release Notes is to point
> out things like Compatibility Concerns that our downstream users and
> developers will want to know about before they attempt to update and
> learn the hard way that their code doesn't build or doesn't run
> correctly. But that's just my opinion. Let's see what others think.

I agree that it's important to highlight compatibility concerns and
guide downstream users, it just didn't fit in that file.  Sorry I
wasn't too clear, it was a suggestion and I should have mentioned that
anyone could push to the PR and change it if need be.

> Perhaps we could consider an alternate solution: Instead of one huge
> ReleaseNotes file that will only continue growing without bounds,
> perhaps the ReleaseNotes file should document the latest release only,
> and all prior release notes could be moved to separate files in a
> subdirectory? Each time we make a release, move ReleaseNotes into that
> subdirectory (and rename it, e.g., ReleaseNotes-9.1) and create a new
> ReleaseNotes file in its place?

It has been suggested before to keep only the latest release notes in
the top level file. The downside was that we didn't want users to
juggle with GIT to retrieve earlier release notes.  Having a subdir
with the old release notes could actually solve both issues.
Another point is the template format.  What are your thoughts on using
Markdown?  Both in the Wiki and in ReleaseNote.
Using it in the Wiki will ease copy pasting without being concerned
about formatting (Thanks Brennan for fixing the PR!) and in the
ReleaseNote we will still have a readable text file but also one that
can be auto formatted by any Markdown-aware tool/website.


On Tue, Jun 23, 2020 at 4:36 AM Nathan Hartman  wrote:
>
> On Mon, Jun 22, 2020 at 10:13 PM Brennan Ashton 
> wrote:
>
> > On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman 
> > wrote:
> >
> > > On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche
> > >  wrote:
> > > > I created a PR copying the release notes from Confluence to ReleaseNote
> > > file.
> > > > I did not copy the "Compatibility Concerns" part, that's valuable
> > > > information but I don't think it belongs to that file, just because
> > > > there is a lot of explanation and code snippets which are not well
> > > > suited for the template of that file.
> > > > Speaking of which, I believe we should reconsider the ReleaseNote file
> > > > and its content.  It's hard to navigate a 27K+ file.   That's a
> > > > discussion for another thread, just put it here as a reminder for
> > > > myself.
> > >
> > > Hmmm... I believe that the whole point of Release Notes is to point
> > > out things like Compatibility Concerns that our downstream users and
> > > developers will want to know about before they attempt to update and
> > > learn the hard way that their code doesn't build or doesn't run
> > > correctly. But that's just my opinion. Let's see what others think.
> > >
> >
> > Nathan,
> > Do you want to make any of these changes for this release? I would like to
> > bring the Release Notes in the to release branch to cut a release in the
> > next few hours.
> >
> > I agree that we should probably have some discussion about release notes
> > and documentation going forward.
>
>
>
> I think it's best to proceed with the release candidate as-is.
>
> I agree with Abdelatif that the release notes file is beginning to grow too
> large to add so much new information to it, so I think that we should as a
> community discuss how to deal with this moving forward. For now, the
> information is  documented at the wiki.
>
> Thanks,
> Nathan


[VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

2020-06-23 Thread Brennan Ashton
Hello all,
Apache NuttX (Incubating) 9.1.0 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.

Because this project targets embedded systems there is more complexity involved
in the build process.  We have tried to make some improvements around this for
new people to the project and are in the process of updating our sites and wiki
to simplify the getting started process.
Two starting points:
 * README.txt -- This is found in the Apache NuttX source and is extensive.
 * Unofficial NuttX Companion -- Located at [3], this is a currently unofficial
   opinionated guide maintained by some of the project committers.


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 [4]
"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 [5].  I did try to walk through this document,
but please comment
if you find anything not clear.

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [5])
[ ] -1 reject (explanation required)

Thank you all,
Brennan Ashton

SCM Information:
  Release tag: releases/9.1.0-RC0
  Hash for the release incubating-nuttx tag:
5d5e6f7192d24a6241aa3e22c729a85eda7afe2d
  Hash for the release incubating-nuttx-apps tag:
6fd57ba0712a78b20bd3ce49022924810a5552c7

[1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC0/
[2] 
https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC0/ReleaseNotes
[3] https://nuttx-companion.readthedocs.io/en/latest/
[4] https://www.apache.org/dev/release.html#approving-a-release
[5] 
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release