> -Original Message-
> From: Gregory Nutt
> Sent: Tuesday, May 26, 2020 2:13 AM
> To: dev@nuttx.apache.org
> Subject: Re: kconfig (Re: mbedtls)
>
>
> > I agree, and all the more reason we should ensure that our project has
> > a controlled snapshot
ifferent opinions.
> Original message From: Takashi Yamamoto
> Date: 5/25/20 6:41 PM (GMT-06:00) To:
> dev@nuttx.apache.org Subject: Re: kconfig (Re: mbedtls) On Tue, May 26, 2020
> at 12:48 AM Gregory Nutt wrote:>> We should all be
> using a consistent, common vers
On Tue, May 26, 2020 at 10:11 AM Nathan Hartman
wrote:
>
> On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto
> wrote:
>
> > On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote:
> > >
> > > We should all be using a consistent, common version of
> > > kconfig-frontends. A snapshot was taken and ha
t: Re: kconfig (Re: mbedtls) On Tue, May 26, 2020 at
12:48 AM Gregory Nutt wrote:>> We should all be using a
consistent, common version of> kconfig-frontends. A snapshot was taken and has
never disappeared from> internet contrary to other statements it is always been
here and wil
On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto
wrote:
> On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote:
> >
> > We should all be using a consistent, common version of
> > kconfig-frontends. A snapshot was taken and has never disappeared from
> > internet contrary to other statements it i
On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote:
>
> We should all be using a consistent, common version of
> kconfig-frontends. A snapshot was taken and has never disappeared from
> internet contrary to other statements it is always been here and will
> always be here: https://bitbucket.org/
I agree, and all the more reason we should ensure that our project has
a controlled snapshot of this tool -- and to ensure the longevity of
that snapshot so that it will not be lost suddenly!
There is also a snapshot of genromfs in the tools repository. This is a
snapshot of the tool from th
On Mon, May 25, 2020 at 12:28 PM Gregory Nutt wrote:
> Most projects that use kconfig-frontends use a snapshot version that is
> built into the codebase. We cannot do that because kconfig-frontends is
> GPL. However, I still argue that we should use a fixed, common version
> of kconfig-frontends
On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote:
A snapshot was taken and has never disappeared from
internet contrary to other statements it is always been here and will
always be here: https://bitbucket.org/nuttx/tools/src/master/
Correct. I meant that the original (from Yann Morin) di
On 5/25/2020 10:03 AM, Nathan Hartman wrote:
On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote:
A snapshot was taken and has never disappeared from
internet contrary to other statements it is always been here and will
always be here: https://bitbucket.org/nuttx/tools/src/master/
Correct. I m
On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote:
> A snapshot was taken and has never disappeared from
> internet contrary to other statements it is always been here and will
> always be here: https://bitbucket.org/nuttx/tools/src/master/
Correct. I meant that the original (from Yann Morin) d
We should all be using a consistent, common version of
kconfig-frontends. A snapshot was taken and has never disappeared
from internet contrary to other statements it is always been here and
will always be here: https://bitbucket.org/nuttx/tools/src/master/
Since the kconfig-frontends pro
We should all be using a consistent, common version of
kconfig-frontends. A snapshot was taken and has never disappeared from
internet contrary to other statements it is always been here and will
always be here: https://bitbucket.org/nuttx/tools/src/master/
We do not accept any Python-based
On Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto
wrote:
> On Mon, May 25, 2020 at 1:00 AM Nathan Hartman
> wrote:
> > We do have to solve the issue of Kconfig. That has disappeared from
> > the Internet and we depend on it. We were told, before we joined
>
> do we have some reasons not to switc
On Mon, May 25, 2020 at 10:51 AM Gregory Nutt wrote:
> I would say that it is an absolute requirement that nothing depend on
> GIT in anyway from the standpoint of the end user.
I agree
Nathan
Yes, we can reuse github.com/nuttx to host the 3rd party library which stop the
active development. But It's better to host the library by the different git to
keep the full history for each project.
I think it could be used in projects in active development too. I have
seen people take a
Yes, I think it could live at github.com/nuttx/apps-externals
I'm not a big fun of git submodules but it could be a way to integrate
the a copy of external projects that could live as forks there.
Please ... no submodules in the git repositories! The don't work for
people who don't use G
Yes, I think it could live at github.com/nuttx/apps-externals
I'm not a big fun of git submodules but it could be a way to integrate
the a copy of external projects that could live as forks there.
Please ... no submodules in the git repositories! The don't work for
people who don't use GIT
2020 8:01 PM
>> To: dev@nuttx.apache.org
>> Subject: Re: mbedtls
>>
>> I completely agree on that!
>>
>> Also I think it is important to have a copy of each thirdparty project at
>> nuttx-apps-external to avoid they disappear from the Internet.
>>
>> B
25, 2020 8:01 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
> I completely agree on that!
>
> Also I think it is important to have a copy of each thirdparty project at
> nuttx-apps-external to avoid they disappear from the Internet.
>
> BR,
>
> Al
4 is also good enough. To reduce the git repo number and
>> simplify the finding, I think that item 1 and 4 is better than other.
>>
>> > -Original Message-
>> > From: Takashi Yamamoto
>> > Sent: Monday, May 25, 2020 2:55 PM
>> > To: dev@
8:23 Xiang Xiao wrote:
> Yes, item 4 is also good enough. To reduce the git repo number and
> simplify the finding, I think that item 1 and 4 is better than other.
>
> > -Original Message-
> > From: Takashi Yamamoto
> > Sent: Monday, May 25, 2020 2:55 PM
> &g
Yes, item 4 is also good enough. To reduce the git repo number and simplify the
finding, I think that item 1 and 4 is better than other.
> -Original Message-
> From: Takashi Yamamoto
> Sent: Monday, May 25, 2020 2:55 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
&
On Mon, May 25, 2020 at 3:41 PM Xiang Xiao wrote:
>
>
>
> > -Original Message-
> > From: Nathan Hartman
> > Sent: Monday, May 25, 2020 12:00 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: mbedtls
> >
> > On Sun, May 24, 2020 at 7:5
> -Original Message-
> From: Nathan Hartman
> Sent: Monday, May 25, 2020 12:00 AM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
> On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
> wrote:
> > Some months ago I suggested that NuttX could fo
On Mon, May 25, 2020 at 1:00 AM Nathan Hartman wrote:
>
> On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
> wrote:
> > Some months ago I suggested that NuttX could focus only in the kernel
> > and we could create an external distribution using some build system
> > like buildroot, yocto, e
On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
wrote:
> Some months ago I suggested that NuttX could focus only in the kernel
> and we could create an external distribution using some build system
> like buildroot, yocto, etc. But as some people pointed, maybe a great
> strength of NuttX i
I’m concerned that you are discussion doing work outside of the Apache
repositories. Why is the main issue here?
I think Alan summarized this well. We are already doing work outside of
the Apache repositories here:
https://bitbucket.org/nuttx/?repo_name=apps-old . We have discussed
this
Hi Justin,
The point we are discussing is how to integrate external/third-party
projects on NuttX apps repository. The licensing it only one of many
issues we have.
Some months ago I suggested that NuttX could focus only in the kernel
and we could create an external distribution using some build
Hi,
I’m concerned that you are discussion doing work outside of the Apache
repositories. Why is the main issue here?
Greg mentions that the apache report are not properly controlled and verified
but I’m not 100% sure what he means by that. The PMC has control of them and
only verified committe
I propose that we reuse the same process(Apache Way) for github.com/nuttx(e.g.
review/merge, select new committer/PMC). The only difference is that
github.com/nuttx isn't an Apache project and is an optional component.
I think other than the repository location, it can piggyback completely
> -Original Message-
> From: Gregory Nutt
> Sent: Saturday, May 23, 2020 2:04 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
>
> > i guess a user often want to use apache-nuttx-external AND his own version.
> > while you can always workaround
> -Original Message-
> From: Takashi Yamamoto
> Sent: Friday, May 22, 2020 11:18 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
> On Fri, May 22, 2020 at 10:14 PM Xiang Xiao wrote:
> >
> > On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
On Fri, May 22, 2020 at 9:18 AM Alan Carvalho de Assis
wrote:
> Hi Daniel,
>
> Yes, I think an option is to create an apps/thirdparty folder to
> follow with Xiang idea.
I like the idea of glue code.
There are many libraries out there which people may want to use with NuttX,
and we can't/shoul
i guess a user often want to use apache-nuttx-external AND his own version.
while you can always workaround it with symbolic links, i wonder if it could
be more straightforward to use multiple "external" repos.
People have talked about this on and off for some time in various way.
There rea
On Fri, May 22, 2020 at 10:14 PM Xiang Xiao wrote:
>
> On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
> wrote:
> >
> > Hi Xiang,
> >
> > On 5/22/20, Xiang Xiao wrote:
> > sic
> > >
> > > But mbedtls can be used in more context than HTTPS/TLS like security
> > > boot, OTA and TEE, it does
Le 22/05/2020 à 17:00, Takashi Yamamoto a écrit :
On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet wrote:
Hello
Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :
can you explain what's "real nuttx code"?
For me, code specifically written for NuttX with good integration and
performance. Di
On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet wrote:
>
> Hello
>
> Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :
> > can you explain what's "real nuttx code"?
>
> For me, code specifically written for NuttX with good integration and
> performance. Different from a third-party library.
i'm
Hi Daniel,
Yes, I think an option is to create an apps/thirdparty folder to
follow with Xiang idea.
BR,
Alan
On 5/22/20, Daniel Pereira Carvalho wrote:
> What about a new 3rd party folder?
>
> Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis
> escreveu:
>
>> Hi Xiang,
>>
>> On 5/22/20,
On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
wrote:
>
> Hi Xiang,
>
> On 5/22/20, Xiang Xiao wrote:
> sic
> >
> > But mbedtls can be used in more context than HTTPS/TLS like security
> > boot, OTA and TEE, it doesn't make sense to put into netutils. A
> > central folder(e.g. external) f
Hi Greg,
On 5/22/20, Gregory Nutt wrote:
>
>>> 2. if yes, which repository is appropriate? apps?
>> Yes, apps of course.
>>
>>> 3. if apps, in which directory? netutils? crypto?
>> Although crypto could be an option (but it doesn't exist inside apps/
>> yet), I think netutils/ is a better option.
What about a new 3rd party folder?
Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis
escreveu:
> Hi Xiang,
>
> On 5/22/20, Xiang Xiao wrote:
> sic
> >
> > But mbedtls can be used in more context than HTTPS/TLS like security
> > boot, OTA and TEE, it doesn't make sense to put into netutils
Hi Xiang,
On 5/22/20, Xiang Xiao wrote:
sic
>
> But mbedtls can be used in more context than HTTPS/TLS like security
> boot, OTA and TEE, it doesn't make sense to put into netutils. A
> central folder(e.g. external) for 3rd party is a better choice
> because:
The external folder is used for othe
On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis
wrote:
>
> Hi Takashi-san,
>
> On 5/22/20, Takashi Yamamoto wrote:
> > hi,
> >
> > i'm working on mbedtls Makefile/Kconfig glue for NuttX.
> > right now, it downloads and uses the mbedtls source code from
> > the upstream as it is. (similarly
BTW, Xiaomi already port many 3rd party library(include mbedtls) and
can share the result to community to avoid the duplicated work.
On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis
wrote:
>
> Hi Takashi-san,
>
> On 5/22/20, Takashi Yamamoto wrote:
> > hi,
> >
> > i'm working on mbedtls Ma
Hi Takashi-san,
On 5/22/20, Takashi Yamamoto wrote:
> hi,
>
> i'm working on mbedtls Makefile/Kconfig glue for NuttX.
> right now, it downloads and uses the mbedtls source code from
> the upstream as it is. (similarly to what netutils/cjson does)
>
> questions:
>
> 1. if we decide to contribute i
Hello
Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :
can you explain what's "real nuttx code"?
For me, code specifically written for NuttX with good integration and
performance. Different from a third-party library.
The makefile glue is OK for NuttX contribution.
Crypto is a directory t
On Fri, May 22, 2020 at 4:12 PM Takashi Yamamoto
wrote:
>
> On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet
> wrote:
> >
> > Hello,
> >
> > I have seriously slowed down my nuttx contributions because of the
> > apache turmoil but I am still reading this list and will have to work on
> > this t
On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet wrote:
>
> Hello,
>
> I have seriously slowed down my nuttx contributions because of the
> apache turmoil but I am still reading this list and will have to work on
> this topic at one point.
>
> See my opinions below.
>
> Sebastien
>
> Le 22/05/202
Hello,
I have seriously slowed down my nuttx contributions because of the
apache turmoil but I am still reading this list and will have to work on
this topic at one point.
See my opinions below.
Sebastien
Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit :
hi,
i'm working on mbedtls Makefil
50 matches
Mail list logo
