Hello All,
I am trying to build SMTP send mail example in NuttX 8.2 but getting compiler
error as shown in attachment.
1. Nuttx/configure->Application configure->Network Utilities->smtp
2. Nuttx/configure->Application configure->example->send mail example
I have analyze error and
Hello All,
Please find Kconfig attachment which was missed in last mail.
Regards,
Surya
From: Surya prakash Verma [mailto:surya.prak...@tataelxsi.co.in.INVALID]
Sent: Tuesday, January 14, 2020 3:50 PM
To: dev@nuttx.apache.org
Subject: SMTP send mail example build failure
surya.prak...@tataelxsi
Hi Anjana,
Your patch was generated incorrectly, it doesn't apply.
You can test it yourself to confirm it doesn't work:
Clone a pristine incubator-nuttx from github, enter inside it and run:
$ patch -p1 --dry-run < /tmp/RX65N_arch.txt
You will see many Hunk #xxx FAILED ...:
172 out of 172 hun
The NuttX project is still misusing the tools.
It is not the PR. It is the process (or lack of one)
To solve this problem:
Build the PR on top of master BEFORE merging.
Do not MERGE until PR on master builds.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent:
Just a small checklist before pushing.!
1 *pull master*
2. add your patch(es)
3.* compile*
4 make distclean
5.* PUSH*
Let's hope that we avoid having it broken again
On our side as commiters, before the automation is ready, we should
cherry-pick and build before pressing the merge button
Can
Since NuttX use Kconfig system, the simple pull/apply/compile cycle
isn't enough to catch all possible error. Actually, all my commits
pass our local automation build(four config: sim, armv7-m, armv8-m and
armv7-a) before PR sent out.
Haitao is preparing the jenkins job to run all possible config,
On Mon, Jan 13, 2020 at 8:32 AM Gregory Nutt wrote:
>
>
> >
> >> So I guess our choices are:
> >>
> >> 1. Reinstate (void) only where the warning occurs.
> >>
> >> 2. Reinstate (void) everywhere return values aren't checked. What a
> >> nightmare.
> >>
> >> 3. Change defines such as the above to s
Xiang,
How about just collecting a bunch of commonly used configurations from
users? Maybe using the example configs that are in the repo now, but
adapting them to be run on the version that is being run in Jenkins...?
That is not perfect, but even having 10-20 example configs would be better
than
How about just collecting a bunch of commonly used configurations from
users? Maybe using the example configs that are in the repo now, but
adapting them to be run on the version that is being run in Jenkins...?
That is not perfect, but even having 10-20 example configs would be better
than 1.
Hi, Xiang,
Since NuttX use Kconfig system, the simple pull/apply/compile cycle
isn't enough to catch all possible error. Actually, all my commits
pass our local automation build(four config: sim, armv7-m, armv8-m and
armv7-a) before PR sent out.
It is hard to imagine how they could have passed
Anjana,
Please remove the Disclaimer from your email, it's incorrect -- you're
sending files containing source code to an open-source project and claiming
confidentiality and intended use by an individual...
Regards,
-david
On Mon, Jan 13, 2020 at 10:02 PM Anjana
wrote:
> Hi All,
>
> We have u
Haitao is preparing the jenkins job to run all possible config, but
the config number is huge, we need to donate several powerful severs
to ensure the precheck can finish in half hour.
I am repeating myself, but it is worth remembering.
There might not be any configuration in the repository
On Tue, Jan 14, 2020 at 2:01 PM Gregory Nutt wrote:
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth rem
On Wed, Jan 15, 2020 at 2:21 AM Gregory Nutt wrote:
>
> Hi, Xiang,
> > Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> > isn't enough to catch all possible error. Actually, all my commits
> > pass our local automation build(four config: sim, armv7-m, armv8-m and
> > armv7-a)
Hi,
> Speaking of LINT, another avenue might be static analysis, which finds all
> kinds of common errors. That is imperfect and comes with false negatives
> but is useful nonetheless.
Apache projects have access to this [1]. I used it in the past to good effect.
It does support C projects. e.g
Hi,
> The report from Haitao show that all arm 400 config can build within
> 94min with his machine
What report? Where can I find this?
> We are discussing internally to donate several build machines to
> ensure all build could finish within half hour.
Why is this conversation not happing on th
On Wed, Jan 15, 2020 at 5:54 AM Justin Mclean wrote:
>
> Hi,
>
> > The report from Haitao show that all arm 400 config can build within
> > 94min with his machine
>
> What report? Where can I find this?
>
This just our internal test,and share in Wechat, not the final report.
I shared this informa
Hi,
> This just our internal test,and share in Wechat, not the final report.
What is this conversation happening in WeChat? It needs to be on the mailing
list. It’s fine to use WeCat for casual conversation but anything that affects
the project needs to be brought back to this mailing list.
>
Hi,
> We need get the manager approve before we can send the official announcement.
Also this is something the whole PPMC need to be involved in and make a
decision on before any announcement is made.
I’m a little unclear what context you mean as an announcement there, incubating
project need
Hi,
If the PPMC want to get started making a release I suggest they do the
following:
1. Someone puts up their hand up to be the release manager. Do we have any
takers?
2. Add LICENSE and NOTICE and DISCLAIMER to the repo. COPYING may need to be
modified/removed.
3. Decide on approach to take w
We started a discussion about bug tracking and never really came to a
consensus. I notice that the ASF also provides Bugzilla:
https://bz.apache.org/bugzilla/
That is an older, simpler tool than Jira but probably also should be
considered.
I haven't used Bugzilla for years and I can't reall
On Wed, Jan 15, 2020 at 3:01 AM Gregory Nutt wrote:
>
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth re
Hi,
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
I don’t think there’s an ideal solutio
Yes, it's great that we develop a tool to generate all possible
combination of affected options smartly.
It would be difficult to cover them all due to things like mutually
exclusive "choice" and dependencies. But if we could generate a tool
that generated all possible configurations (assu
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
I don’t think there’s an ideal solution
Well, we still don't have a clean build yet 8( I got to configuration
342 out of the 420 then it failed on a THTTP + binfs build what has
worked for years (olimex-lpc1766stk:thttpd-binfs). No idea while. I
will look into that tomorrow.
Greg
On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean
wrote:
> Hi,
>
> Part of the issues to consider is that If you use GitHub issues, having
> multiple repos you may need to enable issues in multiple places. This means
> more to manage and track. Having all issues for multiple repos on a single
> githu
I am fine with either of the following two options (not in any order of
preference):
(1) GitHub issues with separate issues for each repository, i.e., issues
with "apps" are reported against "apps," *not* against NuttX.
Pros: Convenience and widespread familiarity across the FOSS world.
Can people also respond on the Projects feature of GitHub?
I imagined it would be used for thinks like new ports, releases, and large
features. Most of these would have tasks spanning two repos.
Take crypto. There is an OS interface component, at least a demo app, and
likely a configuration to be
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote:
> The implication is the you would be opposed to Bugzilla. Bugzilla is
> more primitive but is has the advantage of being lightweight and fast.
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does mu
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote:
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does much more than just track issues).
When you say that Jira is a heavyweight solution, do you mean in terms
of the infrastructure required to run i
I don't believe it has great integration with GitHub (I did not see any
mention in infra) and when I used it at RedHat it was really heavy and
clunky, and designed to manage all the software under some enterprise
organization. The only thing I think it has going for it is that it's
opensource unlik
Hi,
> I don't believe it has great integration with GitHub (I did not see any
> mention in infra)
It has some integration e.g. mention a JIRA in a commit message (or PR) and it
automatically get linked up to that JIRA.
At the ASF Infra manages JIRA so that reduces a little of the load in regard
Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.
On Tue, Jan 14, 2020, 4:43 PM Justin Mclean
wrote:
> Hi,
>
> > I don't believe it has great integration with GitHub (I did not see any
> > mention in infra)
>
> It has some integration
Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.
I didn't perceive things that way. I recall only Alin having a strong
position to use github issues.
Not apposed to any solution.
However, the argument that people not having access to Github is still
out there.
Why can't we use both JIRA and Github, since they are linked?
On Wed, Jan 15, 2020 at 12:50 AM Gregory Nutt wrote:
>
>
> > Speaking about bugzilla. I know JIRA is linked which is what I
Hi,
> Why can't we use both JIRA and Github, since they are linked?
The downside would be multiple places to look for issues, They are not closely
linked if you raise an issue in GitHub one doesn’t get raised in JIRA.
My understanding is that most patch will come via the mailing list anyway and
My understanding is that most patch will come via the mailing list anyway and
it will be mostly up o the PPMX to create and manage the issues for the users.
That is true. There was one this morning (my time): "SMTP send mail
example build failure"
I presume that there will be vote coming in the next few days for the
Bug Tracking solution. This thread, then, is really the [DISCUSS]
thread prior to the vote, right? I have no idea what the voting options
will be, but we should probably label this as [DISCUSS] so people will
appreciate tha
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
There would certainly be some scalabil
The Mynewt project, for example, has many repositories. I can
find the page but I recall that it is on the order of a dozen or so
repositories. ...
17
See https://gitbox.apache.org/repos/asf
41 matches
Mail list logo
