Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Abdelatif Guettouche]

We have addressed the concerns raised here.
Brennan, could you give it another go? This time it should be RC1, right?

BTW; as you can see in Github we have merged some of the apps'
backported PRs with failing tests.  Those PRs were low risk since they
changed only text files. It seems that they are failing because PRs
made against apps/ releases/9.0 pull nuttx/ master instead of
releases/9.0.

On Sat, Apr 25, 2020 at 4:33 AM Gregory Nutt  wrote:
>
>
> > I took a look at the STM32F4DISCOVERY guide in the wiki and a lot of the
> > links are now wrong or broken.
> >
> > https://cwiki.apache.org/confluence/display/NUTTX/STM32F4DISCOVERY+Unix
> Yes, the wiki is not being well maintained.

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Brennan Ashton]

On Sat, Apr 25, 2020, 3:01 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> We have addressed the concerns raised here.
> Brennan, could you give it another go? This time it should be RC1, right?
>

Happy to cut another release, although I think this next one should be sent
directly for the 72hr vote.
if people are OK with it.

The one concern I have is we did not do much to send someone totally new
in the right direction with regards to building the code.  I know some of
it can be addressed outside
of the release code, but do we need to have a really short guide to send
someone on the right track to
build the SIM or something like the STM32DISCOVERY4?  Something that gets
you to shell from 0 in 10min.


> BTW; as you can see in Github we have merged some of the apps'
> backported PRs with failing tests.  Those PRs were low risk since they
> changed only text files. It seems that they are failing because PRs
> made against apps/ releases/9.0 pull nuttx/ master instead of
> releases/9.0.

The CI changes I made only made it to the OS repo and not to the Apps
repo.  I just opened two PR and tagged
you that include the change for master and the release branch.  I think
with those the app CI should be green.

--Brennan

>

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Abdelatif Guettouche]

> Happy to cut another release, although I think this next one should be sent
> directly for the 72hr vote.
> if people are OK with it.

Yes, we can still discuss there if there something to add.

> The one concern I have is we did not do much to send someone totally new
> in the right direction with regards to building the code.  I know some of
> it can be addressed outside
> of the release code, but do we need to have a really short guide to send
> someone on the right track to
> build the SIM or something like the STM32DISCOVERY4?  Something that gets
> you to shell from 0 in 10min.

I think Adam's companion does a pretty good job and is up to date with
all the changes we had recently.
It's linked in the getting started article in our wiki.

> The CI changes I made only made it to the OS repo and not to the Apps
> repo.  I just opened two PR and tagged
> you that include the change for master and the release branch.  I think
> with those the app CI should be green.

Thanks, I merged both.


On Sun, Apr 26, 2020 at 12:18 AM Brennan Ashton
 wrote:
>
> On Sat, Apr 25, 2020, 3:01 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > We have addressed the concerns raised here.
> > Brennan, could you give it another go? This time it should be RC1, right?
> >
>
> Happy to cut another release, although I think this next one should be sent
> directly for the 72hr vote.
> if people are OK with it.
>
> The one concern I have is we did not do much to send someone totally new
> in the right direction with regards to building the code.  I know some of
> it can be addressed outside
> of the release code, but do we need to have a really short guide to send
> someone on the right track to
> build the SIM or something like the STM32DISCOVERY4?  Something that gets
> you to shell from 0 in 10min.
>
>
> > BTW; as you can see in Github we have merged some of the apps'
> > backported PRs with failing tests.  Those PRs were low risk since they
> > changed only text files. It seems that they are failing because PRs
> > made against apps/ releases/9.0 pull nuttx/ master instead of
> > releases/9.0.
>
> The CI changes I made only made it to the OS repo and not to the Apps
> repo.  I just opened two PR and tagged
> you that include the change for master and the release branch.  I think
> with those the app CI should be green.
>
> --Brennan
>
> >

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Nathan Hartman]

On Sat, Apr 25, 2020 at 7:18 PM Brennan Ashton 
wrote:

> The one concern I have is we did not do much to send someone totally new
> in the right direction with regards to building the code.  I know some of
> it can be addressed outside
> of the release code, but do we need to have a really short guide to send
> someone on the right track to
> build the SIM or something like the STM32DISCOVERY4?  Something that gets
> you to shell from 0 in 10min.


Maybe a "quickstart for the impatient" section at the top of the top level
README, after "introduction" and "community" and before "environments?"

The only bad thing is that such a quickstart might have to assume a
particular development system and a particular target board, otherwise the
number of permutations gets out of hand and it's no longer a short
quickstart.

Hmmm...

Maybe three quickstart examples, on macOS, Linux, Windows, and choose a
board for each of those that demonstrates some customization or something
instructive?

Just thinking out loud here

Nathan

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Nathan Hartman]

On Fri, Apr 24, 2020 at 11:24 PM Gregory Nutt  wrote:
> There are a lot of people using macOS.  We do PR checks and nightly
> builds on macOS.  Any references in documents or README's to OSX should
> be changed to macOS.

I have created PR #878: "Docs and comments: Change OSX -> macOS" to
make this change.

There actually weren't that many references to "OSX," "OS X," etc.,
only about 30 or so.

Cheers,
Nathan

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Xiang Xiao]

On Sun, Apr 26, 2020 at 10:20 AM Nathan Hartman
 wrote:
>
> On Sat, Apr 25, 2020 at 7:18 PM Brennan Ashton 
> wrote:
>
> > The one concern I have is we did not do much to send someone totally new
> > in the right direction with regards to building the code.  I know some of
> > it can be addressed outside
> > of the release code, but do we need to have a really short guide to send
> > someone on the right track to
> > build the SIM or something like the STM32DISCOVERY4?  Something that gets
> > you to shell from 0 in 10min.
>
>
> Maybe a "quickstart for the impatient" section at the top of the top level
> README, after "introduction" and "community" and before "environments?"
>
> The only bad thing is that such a quickstart might have to assume a
> particular development system and a particular target board, otherwise the
> number of permutations gets out of hand and it's no longer a short
> quickstart.
>

For the beginner, it may be better to select the platform supported by
sim or qemu, so he/she can try imediately without the real hardware
and complex setup.

> Hmmm...
>
> Maybe three quickstart examples, on macOS, Linux, Windows, and choose a
> board for each of those that demonstrates some customization or something
> instructive?
>

Windows have many atlernative: Cygwin, MSYS2, WSL and Native. We need
select one(less setup, more stable and community favor) to avoid the
user lose the focus. It will be great if the selected platform can
build and test on Linux/macOS/WIndows.

> Just thinking out loud here
>
> Nathan

Re: [ANNOUNCEMENT] Call for Validation of Apache NuttX 9.0.0 (incubating) RC0

[Nathan Hartman]

On Sat, Apr 25, 2020 at 11:27 PM Xiang Xiao  wrote:
>
> On Sun, Apr 26, 2020 at 10:20 AM Nathan Hartman
>  wrote:
> >
> > On Sat, Apr 25, 2020 at 7:18 PM Brennan Ashton 
> > wrote:
> >
> > > The one concern I have is we did not do much to send someone totally new
> > > in the right direction with regards to building the code.  I know some of
> > > it can be addressed outside
> > > of the release code, but do we need to have a really short guide to send
> > > someone on the right track to
> > > build the SIM or something like the STM32DISCOVERY4?  Something that gets
> > > you to shell from 0 in 10min.
> >
> > Maybe a "quickstart for the impatient" section at the top of the top level
> > README, after "introduction" and "community" and before "environments?"
> >
> > The only bad thing is that such a quickstart might have to assume a
> > particular development system and a particular target board, otherwise the
> > number of permutations gets out of hand and it's no longer a short
> > quickstart.
>
> For the beginner, it may be better to select the platform supported by
> sim or qemu, so he/she can try imediately without the real hardware
> and complex setup.

This is a good idea! I like this idea.

> > Maybe three quickstart examples, on macOS, Linux, Windows, and choose a
> > board for each of those that demonstrates some customization or something
> > instructive?
> >
>
> Windows have many atlernative: Cygwin, MSYS2, WSL and Native. We need
> select one(less setup, more stable and community favor) to avoid the
> user lose the focus. It will be great if the selected platform can
> build and test on Linux/macOS/WIndows.

Regarding Windows, I think Native is the best for a 10-minute
quickstart, because it does not require installing a big
UNIX-compatibility layer? I don't know the details because I build on
Linux.

Nathan

Broken link? Windows Native kconfig-frontends

[Nathan Hartman]

In several places, the top-level README.txt mentions a specially
modified version of the kconfig-frontends tool that can be used on
Native Windows and provides a link:

http://uvc.de/posts/linux-kernel-configuration-tool-mconf-under-windows.html

Unfortunately, at this time, that page is giving a "404 - Seite nicht
gefunden" error.

Does anyone know of an alternate download location?

Do we happen to have a backup, like we did for Yann Morin's kconfig-frontends?

Thanks,
Nathan

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

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 4.52 MB...]
sched/pthread_setaffinity.d
sched/pthread_setschedparam.d
sched/pthread_setschedprio.d
sched/pthread_setspecific.d
sched/pthread_sigmask.d
sched/sched_addblocked.d
sched/sched_addprioritized.d
sched/sched_addreadytorun.d
sched/sched_cpupause.d
sched/sched_cpuselect.d
sched/sched_foreach.d
sched/sched_getaffinity.d
sched/sched_getcpu.d
sched/sched_getfiles.d
sched/sched_getparam.d
sched/sched_getscheduler.d
sched/sched_getsockets.d
sched/sched_getstreams.d
sched/sched_gettcb.d
sched/sched_idletask.d
sched/sched_lock.d
sched/sched_lockcount.d
sched/sched_mergepending.d
sched/sched_mergeprioritized.d
sched/sched_note.d
sched/sched_processtimer.d
sched/sched_releasetcb.d
sched/sched_removeblocked.d
sched/sched_removereadytorun.d
sched/sched_resumescheduler.d
sched/sched_roundrobin.d
sched/sched_rrgetinterval.d
sched/sched_self.d
sched/sched_setaffinity.d
sched/sched_setparam.d
sched/sched_setpriority.d
sched/sched_setscheduler.d
sched/sched_suspendscheduler.d
sched/sched_tasklistlock.d
sched/sched_thistask.d
sched/sched_unlock.d
sched/sched_verifytcb.d
sched/sched_waitpid.d
sched/sched_yield.d
sched/sem_destroy.d
sched/sem_post.d
sched/sem_recover.d
sched/sem_reset.d
sched/sem_tickwait.d
sched/sem_timedwait.d
sched/sem_timeout.d
sched/sem_trywait.d
sched/sem_wait.d
sched/sem_waitirq.d
sched/sig_action.d
sched/sig_allocpendingsigaction.d
sched/sig_cleanup.d
sched/sig_deliver.d
sched/sig_dispatch.d
sched/sig_findaction.d
sched/sig_initialize.d
sched/sig_kill.d
sched/sig_lowest.d
sched/sig_nanosleep.d
sched/sig_notification.d
sched/sig_pause.d
sched/sig_pending.d
sched/sig_ppoll.d
sched/sig_procmask.d
sched/sig_pselect.d
sched/sig_queue.d
sched/sig_releasependingsigaction.d
sched/sig_releasependingsignal.d
sched/sig_removependingsignal.d
sched/sig_sleep.d
sched/sig_suspend.d
sched/sig_timedwait.d
sched/sig_unmaskpendingsignal.d
sched/sig_usleep.d
sched/sig_waitinfo.d
sched/spinlock.d
sched/task_activate.d
sched/task_create.d
sched/task_delete.d
sched/task_exit.d
sched/task_exithook.d
sched/task_getgroup.d
sched/task_getpid.d
sched/task_init.d
sched/task_prctl.d
sched/task_recover.d
sched/task_restart.d
sched/task_setcancelstate.d
sched/task_setup.d
sched/task_spawn.d
sched/task_spawnparms.d
sched/task_start.d
sched/task_terminate.d
sched/timer_create.d
sched/timer_delete.d
sched/timer_getitimer.d
sched/timer_getoverrun.d
sched/timer_gettime.d
sched/timer_initialize.d
sched/timer_release.d
sched/timer_setitimer.d
sched/timer_settime.d
sched/wd_cancel.d
sched/wd_create.d
sched/wd_delete.d
sched/wd_gettime.d
sched/wd_initialize.d
sched/wd_recover.d
sched/wd_start.d
tools/pic32/mkpichex
uImage

nothing to commit, working tree clean
On branch master
Your branch is up to date with 'origin/master'.

Ignored files:
  (use "git add -f ..." to include in what will be committed)

builtin/builtin_list.d

builtin/builtin_list.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.builtin.d
builtin/exec_builtin.d

builtin/exec_builtin.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.builtin.d
examples/hello/hello_main.d

examples/hello/hello_main.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.examples.hello.d
examples/romfs/testdir/
examples/unionfs/romfs_atestdir.h
examples/unionfs/romfs_btestdir.h
nshlib/nsh_builtin.d

nshlib/nsh_builtin.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.nshlib.d
nshlib/nsh_command.d

nshlib/nsh_command.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.nshlib.d
nshlib/nsh_console.d

nshlib/nsh_console.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.nshlib.d
nshlib/nsh_consolemain.d

nshlib/nsh_consolemain.home.jenkins.jenkins-slave.workspace.NuttX-Nightly-Build.apps.nshlib.d
nshlib/nsh_dbgcmds.d

nshlib/nsh