Re: Arduino zero Blinky : build bootloader error

[Christopher Collins]

Hi Pradeep,

On Sun, May 15, 2016 at 06:47:29PM +0530, Pradeep Sanjeewa wrote:
> But when I try to download the bootloader (newt load arduino_boot) , it
> gives an error.
> 
> line 61: openocd: command not found
> Error: exit status 127

Did you see the documentation for getting started in Linux?
http://mynewt.apache.org/os/get_started/cross_tools/#install-arm-cross-arm-tools-for-linux

I think the "Install OpenOCD" step should solve this problem.

Thanks,
Chris

Re: Mynewt Local BSP Instance Location

[Christopher Collins]

Hi Kevin,

On Wed, May 11, 2016 at 01:32:14PM +0200, Kevin Townsend wrote:
> I'm trying to document the process of creating a custom BSP based on an 
> existing model from apache-newt-core, and copied the model into the 
> local `projectroot/hw/bsp/boardname` folder, updated the `pkg.yml` file, 
> and modified the filenames/content accordingly. I then referenced this 
> BSP in the bootloader and main application target via newt.
> 
> When I reference the local `hw/bsp/boardname` instance and then try to 
> build I get the following error, though:
> 
> $ newt -v build nrf51_boot
> Building target targets/nrf51_boot
> panic: interface conversion: interfaces.PackageInterface is nil, not
> *pkg.LocalPackage
[...]

Ouch... there is clearly a bug in the newt tool.  There should be no
problem with creating a BSP package in the local repo.  Could you send
the output of 'newt target show'?  I would like to see what specifically
triggered this crash.  I'll also look see if I have the same issues with
local BSPs.

Thanks,
Chris

Re: callout and callout_func

[Christopher Collins]

I also prefer #2.

Chris

On Fri, May 06, 2016 at 11:31:03AM -0700, will sanfilippo wrote:
> My vote would be #2 as well.
> 
> 
> > On May 6, 2016, at 11:29 AM, marko kiiskila  wrote:
> > 
> > Hi,
> > 
> >> On May 5, 2016, at 10:47 AM, Sterling Hughes  wrote:
> >> 
> >> Salutations,
> >> 
> >> As I've been going through the callout implementation, one thing I've 
> >> noticed is that callouts and callout_funcs can't be interleaved.
> >> 
> >> The implementation of a callout, is that it has an event as the first 
> >> element of the structure.  When that event is posted to an event queue, it 
> >> is posted with the event type EVENT_T_TIMER, which is reserved for 
> >> callouts.  However, you must know a priori what type of callout it is, a 
> >> callout, or a callout_func.
> >> 
> >> I don't think this behavior is ideal, and there are a couple of options 
> >> for fixing it:
> >> 
> >> 1- Break out EVENT_T_TIMER into EVENT_T_TIMER (callout) and 
> >> EVENT_T_TIMER_FUNC (callout_func).
> >> 
> >> 2- Remove the concept of callout, and just have callout_func. callout_func 
> >> is by far the more useful of the two.
> >> 
> >> 3- Add a flags field to callout, which will tell you whether its a callout 
> >> or a callout_func.
> >> 
> >> I'm leaning towards either #2 or #3 here, because I think the first one 
> >> will end up being confusing when debugging things.  "Oh no, I put TIMER 
> >> instead of TIMER_FUNC. GRR."  My personal preference is #2, but I'm not 
> >> sure everyone wants to be forced to have a function per-timer in their 
> >> task context.
> >> 
> >> Thoughts?
> > 
> > I would prefer #2, as that would simplify the concept.
> > 
> > Also, while you have that file cracked open, cf_arg from within 
> > os_callout_func could be removed.
> > os_callout includes os_event, and that structure already has a void * which 
> > could be used as callout_func
> > argument.
> > —
> > M
> 

Re: Blinky on nrf52DK needs repos/apache-mynewt-core to be on master

[Christopher Collins]

On Thu, May 05, 2016 at 05:13:25PM +0530, Anuj Deshpande wrote:
> Hi all
> 
> I followed the instructions on how to setup newt tool and then blinky on
> the nrf52 DK.
> 
> http://mynewt.apache.org/os/tutorials/nRF52/
[...]
> I had to change the branch of the repos/apache-mynewt-core repo which was
> cloned for me using the newt tool. This isn't reflected in the docs (and I
> don't think it should be). Is there something amiss with the newt tool ?

Hi Anuj,

As you suspected, you should not need to change the branch using git.
The problem here is that nrf52dk support is a new feature that is going
into the upcoming release.  If all goes well, this release will be out
in a day or two.  Until the release is out, the apache-mynewt-core
repository points to the old tag (mynewt_0_8_0_b2_tag) which lacks this
feature.

Manually pointing the repo to a different branch with git solves the
problem in the short term, but it might cause trouble for you the next
time you try to upgrade the core repo.  I don't believe we have
documented the correct way to use developmental features, so I am
certainly not criticizing you for doing what you did!

The preferred way to use developmental features is to change your
project.yml as follows:

FROM:

repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core

TO:

repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core

(change the "vers" field).

Then upgrade your packages with "newt upgrade", e.g.,

[ccollins@iori:~/tmp/myproj]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 
0.0.0-none ? [Yn] y

Naturally, this branch is quite unstable.

Chris

On Thu, May 05, 2016 at 05:13:25PM +0530, Anuj Deshpande wrote:
> Hi all
> 
> I followed the instructions on how to setup newt tool and then blinky on
> the nrf52 DK.
> 
> http://mynewt.apache.org/os/tutorials/nRF52/
> 
> ➜  apache-mynewt-core git:(2bec33d) ls hw/bsp
> native  nrf51dk  nrf51dk-16kbram  nrf52pdk  olimex_stm32-e407_devboard
> ➜  apache-mynewt-core git:(2bec33d) git checkout master
> Previous HEAD position was 2bec33d... Merge branch 'develop'
> Switched to branch 'master'
> Your branch is up-to-date with 'origin/master'.
> ➜  apache-mynewt-core git:(master) git pull origin master
> From https://github.com/apache/incubator-mynewt-core
>  * branchmaster -> FETCH_HEAD
> Already up-to-date.
> ➜  apache-mynewt-core git:(master) ls hw/bsp -l
> total 28
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 bmd300eval
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 native
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 nrf51dk
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 nrf51dk-16kbram
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 nrf52dk
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 nrf52pdk
> drwxrwxr-x 4 anuj anuj 4096 May  5 16:55 olimex_stm32-e407_devboard
> ➜  apach
> 
> I had to change the branch of the repos/apache-mynewt-core repo which was
> cloned for me using the newt tool. This isn't reflected in the docs (and I
> don't think it should be). Is there something amiss with the newt tool ?
> 
> I was able to build and load by following the other instructions to the T.
> 
> PS: new to the project, looks cool ! Looking forward to contribute !
> 
> Cheers,
> 
> Anuj
> ​

Re: Setting cflags correctly in bletiny

[Christopher Collins]

On Thu, May 05, 2016 at 06:28:19PM +0530, Anuj Deshpande wrote:
> Hi all,
> 
> I am on 64 bit 16.04 Ubuntu with a manually installed toolchain which has
> been added to my path.
> 
> Before building the app, while setting the cflags for the target, the
> documentation says that one should not give the - symbol.
> 
> http://mynewt.incubator.apache.org/os/tutorials/bletiny_project/
> 
> I had to give that to get it to build.
[...]

Good catch, Anuj.  The documentation is wrong.  I'll submit a pull
request to fix that typo.

Thanks,
Chris

[jira] [Created] (MYNEWT-292) Don't allow two tasks to have the same priority

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-292:
--

 Summary: Don't allow two tasks to have the same priority
 Key: MYNEWT-292
 URL: https://issues.apache.org/jira/browse/MYNEWT-292
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: legacy pairing for nimble

[Christopher Collins]

On Mon, May 02, 2016 at 09:27:12PM +, p...@wrada.com wrote:
> 
> All,
> 
> This pull request contains legacy pairing implementation for nimble.  It also 
> contains a change from Chris which is not yet committed that I needed to 
> ensure atomic access to the l2cap state machine in multi-threaded 
> applications.
> 
> Please review if you are interested and get a chance.
> 

Thanks, Paul.  It looks great.  I have merged the pull request.

Chris

[jira] [Updated] (MYNEWT-291) BLE Host - Split GATT attribute access function into more specific events

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-291:
---
Description: 
Nimble notifies the app that a characteristic or descriptor is being accessed 
via an access callback.  The access callback takes a context parameter which 
points to an instance of the following union:

{noformat}
union ble_gatt_access_ctxt {
struct {
const struct ble_gatt_chr_def *chr;
void *data;
int len;
} chr_access;

struct {
const struct ble_gatt_dsc_def *dsc;
void *data;
int len;
} dsc_access;
};
{noformat}

This is problematic because the user may wish to point the _data_ fields to 
read-only data, requiring them to "cast away const."  This looks questionable 
in code, and is difficult to document in the user guide with a straight face.

Instead, we should change the union to the following:

{noformat}
union ble_gatt_access_ctxt {
struct {
const struct ble_gatt_chr_def *chr;
const void *data;
int len;
} chr_read;

struct {
const struct ble_gatt_chr_def *chr;
void *data;
int len;
} chr_write;

struct {
const struct ble_gatt_dsc_def *dsc;
const void *data;
int len;
} dsc_read;

struct {
const struct ble_gatt_dsc_def *dsc;
void *data;
int len;
} dsc_write;
};
{noformat}

  was:
Nimble notifies the app that a characteristic or descriptor is being accessed 
via an access callback.  The access callback takes a context parameter which 
points to an instance of the following union:

{noformat}
union ble_gatt_access_ctxt {
struct {
const struct ble_gatt_chr_def *chr;
void *data;
int len;
} chr_access;

struct {
const struct ble_gatt_dsc_def *dsc;
void *data;
int len;
} dsc_access;
};
{noformat}

This is problematic because the user may wish to point the _data_ fields to 
read-only data, requiring them to "cast away const."  This looks questionable 
in code, and is difficult to document in the user guide with a straight face.

Instead, we should change the union to the following:
union ble_gatt_access_ctxt {
struct {
const struct ble_gatt_chr_def *chr;
const void *data;
int len;
} chr_read;

struct {
const struct ble_gatt_chr_def *chr;
void *data;
int len;
} chr_write;

struct {
const struct ble_gatt_dsc_def *dsc;
const void *data;
int len;
} dsc_read;

struct {
const struct ble_gatt_dsc_def *dsc;
void *data;
int len;
} dsc_write;
};


> BLE Host - Split GATT attribute access function into more specific events
> -
>
> Key: MYNEWT-291
> URL: https://issues.apache.org/jira/browse/MYNEWT-291
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: 0.9.0
>
>
> Nimble notifies the app that a characteristic or descriptor is being accessed 
> via an access callback.  The access callback takes a context parameter which 
> points to an instance of the following union:
> {noformat}
> union ble_gatt_access_ctxt {
> struct {
> const struct ble_gatt_chr_def *chr;
> void *data;
> int len;
> } chr_access;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> void *data;
> int len;
> } dsc_access;
> };
> {noformat}
> This is problematic because the user may wish to point the _data_ fields to 
> read-only data, requiring them to "cast away const."  This looks questionable 
> in code, and is difficult to document in the user guide with a straight face.
> Instead, we should change the union to the following:
> {noformat}
> union ble_gatt_access_ctxt {
> struct {
> const struct ble_gatt_chr_def *chr;
> const void *data;
> int len;
> } chr_read;
> struct {
> const struct ble_gatt_chr_def *chr;
> void *data;
> int len;
> } chr_write;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> const void *data;
> int len;
> } dsc_read;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> void *data;
> int len;
> } dsc_write;
> };
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Mynewt 0.8.0-incubating-rc1

[Christopher Collins]

On Thu, Apr 28, 2016 at 01:09:45PM -0700, marko kiiskila wrote:
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC votes are cast.
> 
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

Chris

[jira] [Resolved] (MYNEWT-75) NFFS - Perform garbage collection when hash entry pool or data block pool exhausted

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-75.
---
Resolution: Fixed

> NFFS - Perform garbage collection when hash entry pool or data block pool 
> exhausted
> ---
>
> Key: MYNEWT-75
> URL: https://issues.apache.org/jira/browse/MYNEWT-75
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v0_9_0_beta1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: First draft of Coding standards in develop branch

[Christopher Collins]

I am not sure I would put it that way.  The POSIX headers are part of
the "implementation," so they are permitted to use the reserved
namespace.  Since mynewt code needs to build in sim (POSIX) and also
freestanding implementations, it is probably best to respect both
standards in our code.

Chris

On Tue, Apr 26, 2016 at 09:31:55AM -0700, Sterling Hughes wrote:
> 
> 
> On 4/26/16 9:22 AM, Christopher Collins wrote:
> > On Tue, Apr 26, 2016 at 09:06:37AM -0700, Sterling Hughes wrote:
> >> I think we do need a naming convention here - I'm fine adopting H_*.
> >> I'll point out that almost every POSIX or LIBC header I've ever seen
> >> uses underscore, and I believe this is only reserved in C++ -- that
> >> said, we need to be friendly to C++, and as you point out, we should
> >> follow a defined behavior.
> >
> > These identifiers are reserved in C as well.  From 7.1.3 of n1570:
> >
> >  All identifiers that begin with an underscore and either an
> >  uppercase letter or another underscore are always reserved for for
> >  any use.
> >
> > (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf)
> >
> 
> Hrm, you're right.  There are a lot of POSIX headers that have undefined 
> behavior. :-)
> 
> Sterling

Re: First draft of Coding standards in develop branch

[Christopher Collins]

On Tue, Apr 26, 2016 at 09:06:37AM -0700, Sterling Hughes wrote:
> I think we do need a naming convention here - I'm fine adopting H_*. 
> I'll point out that almost every POSIX or LIBC header I've ever seen 
> uses underscore, and I believe this is only reserved in C++ -- that 
> said, we need to be friendly to C++, and as you point out, we should 
> follow a defined behavior.

These identifiers are reserved in C as well.  From 7.1.3 of n1570:

All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for for
any use.

(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf)

Chris

Re: First draft of Coding standards in develop branch

[Christopher Collins]

On Sun, Apr 24, 2016 at 10:08:09AM -0700, Sterling Hughes wrote:
> Hi,
> 
> As we start to bring on new contributors, and operate as a project, its 
> increasingly important that we document and agree upon coding standards. 
>   I think we've done a good job of maintaining this consistency 
> informally, but, now we need to vote and agree on project standards.
> 
> I've taken a first stab at this and committed it to the develop branch, 
> folks can see it here:
> 
> https://github.com/apache/incubator-mynewt-core/blob/develop/CODING_STANDARDS.md

Thanks for putting this together Sterling.  I think it looks great.  My
opinion is that a coding standards document should not be overly
prescriptive.  Everyone has his own set of coding pet peeves; I suggest
we try to keep those out of this document and keep it as short as
possible.  Otherwise, people won't adhere to the document, or they will
just hate writing code and they won't contribute as much.

For me, the important rules are:
* Maximum line length
* Brace placement
* Typedefs
* All-caps macros
* Compiler extensions (e.g., packed structs).

The first three are already captured; I think the others should be
addressed.  I think macros should always be in all-caps for reasons that
everyone is probably familiar with. Unfortunately, I don't have a good
rule for when extensions are acceptable.

I would also like to see a note about when it is OK to stray from the
conventions.  There will be times (rarely) when adhering to the
standards document just doesn't make sense.  "Zero-tolerance" rules
always seem to pave the road to hell :).

Finally, there is one point in particular that I wanted to address:
include guards in header files.  From the document:

* ```#ifdef``` aliasing, shall be in the following format, where
the package name is "os" and the file name is "callout.h":

```no-highlight
#ifndef _OS_CALLOUT_H
#define _OS_CALLOUT_H

I am not sure I like this rule for the following two reasons:
* A lot of the code base doesn't follow this particular naming
  convention.
* Identifiers starting with underscore and capital letter are
  reserved to the implementation, so technically this opens the door
  to undefined behavior.  

A leading capital E is also reserved by POSIX (e.g., EINVAL).  The
naming convention I use is:

H_CALLOUT_

I would not consider this something to worry about, and I don't think we
need to include a specific naming convention in the document.  However,
insofar as we prescribe a naming convention, it should be one which
avoids undefined behavior.

Thanks,
Chris

[jira] [Commented] (MYNEWT-286) nRF51 crashes when receiving large(ish) ACL packet

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15254676#comment-15254676
 ] 

Christopher Collins commented on MYNEWT-286:


Thanks, Johan.  I haven't had any luck in reproducing this crash.  Details of 
my setup are below.  Could you please point me the specific nimble commit which 
you were using when you produced this crash?

*Test setup 1*
* Master: bmd300 running blehci app, controlled by bluetoothctl 
* Slave: nrf52pdk preview running blehci app, controlled by btmgmt
* Both boards running code built from commit 
4d0a38707bdeeb2061b3089d627fc2cee13f1f6c

*Test setup 2*
* Master: nrf52pdk running blehci app, controlled by bluetoothctl 
* Slave: nrf51dk preview running blehci app, controlled by btmgmt
* Both boards running code built from commit 
4d0a38707bdeeb2061b3089d627fc2cee13f1f6c

*btmon log from Test setup 1 (hci1=master; hci0=slave)*
{noformat}
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7  
 [hci1] 1771.171413
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 
>  [hci1] 1771.174704
  LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2  
 [hci1] 1771.174736
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 
>  [hci1] 1771.178689
  LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 18   
>  [hci1] 1771.480724
  LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: 0A:0B:0C:0D:0E:0F (OUI 0A-0B-0C)
Data length: 6
Flags: 0x06
  LE General Discoverable Mode
  BR/EDR Not Supported
TX power: 0 dBm
RSSI: -52 dBm (0xcc)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2  
 [hci1] 1771.480907
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 
>  [hci1] 1771.484717
  LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25   
 [hci1] 1771.484746
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 0A:0B:0C:0D:0E:0F (OUI 0A-0B-0C)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x)
Max connection length: 0.000 msec (0x)
> HCI Event: Command Status (0x0f) plen 4   
>  [hci1] 1771.490698
  LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19   
>  [hci1] 1772.765700
  LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 1
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: 0A:0B:0C:0D:0E:0F (OUI 0A-0B-0C)
Connection interval: 70.00 msec (0x0038)
Connection latency: 0.00 msec (0x)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x04
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
 [hci1] 1772.765816
Handle: 1
@ Device Connected: 0A:0B:0C:0D:0E:0F (1) flags 0x
02 01 06 02 0a 00 

Re: MYNEWT-262 Log module needs split in logging and reporting

[Christopher Collins]

Hi Vipul,

On Mon, Apr 18, 2016 at 11:53:28PM -0700, Vipul Rahane wrote:
> - Make changes to the log_register() function to take LOG_MODULE_X as
> an argument. This module ID is present as a field in the log structure
> and can be used anytime an entry is logged in the specific log. There
> was a disconnect earlier as the log itself did not quite have a module
> ID of it’s own. If we want to be able to filter logs the module ID
> needs to be used as a filtering criteria to pick the right log node
> from the queue.

Sounds good to me.  Currently, a log has a name but not a module ID, and
there is no way to determine which log created a particular log entry.

[...]

> - When newtmgr requests to read all the logs using “logs show”
> command, the response would contain a module ID as well. If the
> response does not contain any entries, no response would be sent for
> that log. Module ID also helps in filtering the log entries while
> sending the response.
> 
> JSON Response:
> 
> {
>   "rc": 0,
>   "logs": [{
>   "name": "log",
>   "module": 0,
>   "type": 1,
>   "entries": [{
>   "msg": "GPIO toggle from 1 to 0",
>   "ts": 1007000,
>   "level": 2,
>   "index": 1
>   }, {
>   "msg": "GPIO toggle from 0 to 1",
>   "ts": 2015000,
>   "level": 2,
>   "index": 2
>   }, {
>   "msg": "GPIO toggle from 1 to 0",
>   "ts": 3019000,
>   "level": 2,
>   "index": 3
>   }, {
>   "msg": "GPIO toggle from 0 to 1",
>   "ts": 4024000,
>   "level": 2,
>   "index": 4
>   }]
>   }]
> }

I don't necessarily disagree, but I am wondering why the newtmgr user
needs to know about module IDs at all.  I was thinking module IDs were
only used internally to keep track of which log a particular entry
belongs to.  It seems like the newtmgr user would rather just deal with
log names than module IDs.

That said, I am not against providing extra information to the user if
it might be helpful.

> When the log_set_handler() function is called in the app, it makes all
> the function pointers if any nodes exist in the TAILQ to point to the
> same log handlers. One problem with this approach is that since the
> log_set_handler() function needs to be called after all the modules
> are initialized, logging to the same log during initialization is not
> possible as the logs are not created at that point.
> 
> Ways to solve this:
> 1. Passing the log handler as an argument to all the init functions
> which I don’t like personally as it is not too clean.
> 
> 2. Having a global default log handler which gets set by calling
> log_set_handler() which would take precedence over other logs as
> log_register() would also look at this default handler and if the
> default handler is present, the log infrastructure decides to use that
> instead of whats specified in the modules. As a result everything that
> gets logged would go to the log defined by the app including
> initialization logs.
> 
> Thoughts ?

As background for other readers: libraries are responsible for fully
configuring their own logs, including specifying where the log writes to
(e.g., console, a particular flash circular buffer, etc.).  This is
problematic because the library doesn't know the app's capabilities and
requirements; it is the app which should have the final say regarding
where each log gets written.

I think we need to make sure the following requirements are met (this is
off the top of my head, so feel free to call me out if I'm saying
something absurd!):

A. An app can easily arrange for all logs to be written to the same
place.

B. An app can specify where a particular library's log(s) get written
to.

Requirement A allows for easy bringup and debugging.  Requirement B is
necessary for production firmware where each log is expected to use a
particular handler.  I think your solution 2 addresses requirement A,
but it does not give an app sufficient control to implement requirement
B.

To give a hypothetical example: an app wants to log all bluetooth
activity to flash circular buffer x, and all application activity to
flash circular buffer y.  The app is not interested in logs from any
other libraries, so it has not reserved any RAM or flash to hold these
other logs.  A default handler won't meet this app's requirements
for two reasons: 1) only a single circular buffer gets used, but the app
wants to use two, and 2) logs from all libraries get written to flash,
but the app wants to save the flash space for the logs that it actually
cares about.

I can't think of any way to give an app the control it needs, except by
implementing your first solution (library 

Re: Mynewt for arduino_101 board

[Christopher Collins]

Hi Andre,

On Mon, Apr 18, 2016 at 10:55:49AM +0300, Andrei Emeltchenko wrote:
> Hi,
> 
> I am working on arduino_101 development board.
> https://www.arduino.cc/en/Main/ArduinoBoard101
> 
> It has nrf51 BLE chip, Basically the configuration is the same as for
> the nrf51dk-16kbram with the only difference:
> 
> --- a/hw/bsp/nrf51dk-16kbram/src/hal_bsp.c
> +++ b/hw/bsp/nrf51dk-16kbram/src/hal_bsp.c
> @@ -24,7 +24,7 @@
>  static const struct nrf51_uart_cfg uart_cfg = {
>  .suc_pin_tx = 9,
>  .suc_pin_rx = 11,
> -.suc_pin_rts = 8,
> +.suc_pin_rts = 12,
>  .suc_pin_cts = 10
>  };
> 
> 
> What is the best way of keeping the change? Making special BSP would be
> too expensive for this one line change.

This is indeed an annoying situation.  There is a nearly identical
dilemma with the Arduino Zero and the Arduino Zero Pro; the only
difference among these two boards is a single pin.

The solution for the Arduino Zero is to use a single BSP, but to select
the proper pin at compile time via an #ifdef:

#ifdef ARDUINO_ZERO_PRO
 ARDUINO_ZERO_D2 = (8),
 ARDUINO_ZERO_D4 = (14),
#endif

#ifdef ARDUINO_ZERO
 ARDUINO_ZERO_D2 = (14),
 ARDUINO_ZERO_D4 = (8),
#endif

The appropriate preprocessor symbol is defined by the use of a target
feature, as described in the arduino zero tutorial:
http://mynewt.apache.org/os/tutorials/arduino_zero/

That said, I am not sure this is the right approach.  I will certainly
let others weight in, but my feeling is that it is better to just bite
the bullet and create a new BSP.  Both solutions pose maintenance
headaches, but I think separate BSPs is simpler and more maintainable.
An additional benefit of separate BSPs is that it simplifies target
creation for the application developer (just specify BSP, rather than
BSP plus feature).

Thanks,
Chris

Re: Proposed changes to Nimble host

[Christopher Collins]

On Mon, Apr 18, 2016 at 09:18:16AM -0700, will sanfilippo wrote:
> For #2, my only “concerns” (if you could call them such) are:
> * Using OS_EVENT_TIMER as opposed to some other event. Should all
> OS_EVENT_TIMER events be caused by a timer? Probably no big deal… What
> events are going to be processed here? Do you envision many host
> events?

Yes, I agree.  I think a more appropriate event type would be
OS_EVENT_CALLBACK or similar.  I am a bit leery about adding a new OS
event type for this case, because it would require all applications to
handle an extra event type without any practical benefit.  Perhaps
mynewt could relieve this burden with an "os_handle_event()" function
which processes these generic events.  My concern there is that
applications may want to add special handling for certain event types,
so they wouldn't want to call the helper function anyway.

The OS events that the host would generate are:
* Incoming ACL data packets.
* Incoming HCI events.
* Expired timers.

> * I wonder about the complexity of this from an application developers
> standpoint. Not saying that what you propose would be more or less
> complex; just something we should consider when making these changes.

I think the taskless design reduces complexity for the application
developer.  If there is no host task, the developer can worry less about
task priorities and stack sizes.  

> On a side note (I guess it is related), we should consider how
> applications are going to initialize the host and/or the controller in
> regards to system memory requirements (i.e. mbufs). While our current
> methodology to create a BLE app is not rocket science, I think we
> could make it a bit simpler.

Yes, definitely.  As you say, the setup is not terribly complicated, but
it does involve a fair number of steps, so it will seem complicated to
someone not familiar with Mynewt.

Chris

Proposed changes to Nimble host

[Christopher Collins]

Hello all,

The Mynewt BLE stack is called Nimble.  Nimble consists of two packages:
* Controller (link-layer) [net/nimble/controller]
* Host (upper layers) [net/nimble/host]

This email concerns the Nimble host.  

As I indicated in an email a few weeks ago, the code size of the Nimble
host had increased beyond what I considered a reasonable level.  When
built for the ARM cortex-M4, with security enabled and the log level set
to INFO, the host code size was about 48 kB.  In recent days, I came up
with a few ideas for reducing the host code size.  As I explored these
ideas, I realized that they open the door for some major improvements in
the fundamental design of the host.  Making these changes would
introduce some backwards-compatibility issues, but I believe it is
absolutely the right thing to do.  If we do this, it needs to be done
now while Mynewt is still in its beta phase.  I have convinced myself
that this is the right way forward; now I would like to see what the
community thinks.  As always, all feedback is greatly appreciated.

There are two major changes that I am proposing:

1. All HCI command/acknowledgement exchanges are blocking.

Background: The host and controller communicate with one another via the
host-controller-interface (HCI) protocol.  The host sends _commands_ to
the controller; the controller sends _events_ to the host.  Whenever the
controller receives a command from the host, it immediately responds
with an acknowledgement event.  In addition, the controller also sends
unsolicited events to the host to indicate state changes or to request
information in a subsequent command.

In the current host, all HCI commands are sent asynchronously
(non-blocking).  When the host wants to send an HCI command, it
schedules a transmit operation by putting an OS event on its own event
queue.  The event points to a callback which does the actual HCI
transmission.  The callback also configures a second callback to be
executed when the expected acknowledgement is received from the
controller.  Each time the host receives an HCI event from the
controller, an OS event is put on the host's event queue.  Processing of
this OS event ultimately calls the configured callback (if it is an
acknowledgement), or a hardcoded callback (if it is an unsolicited HCI
event).

This design works, but it introduces a number of problems.  First, it
requires the host code to maintain some quite complex state machines for
what seem like simple HCI exchanges.  This FSM machinery translates into
a lot of extra code.  There is also a lot of ugliness involved in
canceling scheduled HCI transmits.

Another complication with non-blocking HCI commands is that they require
the host to jump through a lot of hoops to provide feedback to the
application.  Since all the work is done in parallel by the host task,
the host has to notify the application of failures by executing
callbacks configured by the application.  I did not want to place any
restrictions on what the application is allowed to do during these
callbacks, which means the host has to ensure that it is in a valid
state whenever a callback gets executed (no mutexes are locked, for
example).  This requires the code to use a large number of mutexes and
temporary copies of host data structures, resulting in a lot of
complicated code.

Finally, non-blocking HCI operations complicates the API presented to
the application.  A single return code from a blocking operation is
easier to manage than a return code plus the possibility of a callback
being executed sometime in the future from a different task.  A blocking
operation collapses several failure scenarios into a single function
return.

Making HCI command/acknowledgement exchanges blocking addresses all of
the above issues:
* FSM machinery goes away; controller response is indicated in the
  return code of the HCI send function.
* Nearly all HCI failures are indicated to the application
  immediately, so there is no need for lots of mutexes and temporary
  copies of data structures.
* API is simplified; operation results are indicated via a simple
  function return code.

2. The Nimble host is "taskless"

Currently the Nimble host runs in its own OS task.  This is not
necessarily a bad thing, but in the case of the host, I think the costs
outweigh the benefits.  I can think of three benefits to running a
library in its own task:
* Guarantee that timing requirements are met; just configure the
  task with an appropriate priority.
* (related to the above point) The library task can continue to work
  while the application task is blocked.
* Facilitates stack sizing. Since the library performs its
  operations in its own stack, it is easier to predict stack usage
  of both the library task and the application task.

I don't think any of these benefits are very compelling in the case of
the Nimble host for the following reasons:
* The host has nothing 

Re: Problem Loading arduino_boot

[Christopher Collins]

Hi Nges,

On Thu, Apr 14, 2016 at 03:02:49AM +0100, Nges B wrote:
> Ok thanks.
> I will be waiting for your response.

Unfortunately, I can't reproduce the problem over here.  I was able to
load the arduino boot loader in Ubuntu 14.10 without any problems.

[ccollins@ccollins-VirtualBox:~/tmp/myproj]$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.10
Release:14.10
Codename:   utopic
[ccollins@ccollins-VirtualBox:~/tmp/myproj]$ newt target show
targets/arduino_boot
app=@apache-mynewt-core/apps/boot
bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
build_profile=optimized
features=arduino_zero 
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
[ccollins@ccollins-VirtualBox:~/tmp/myproj]$ newt load arduino_boot
Loading image
[ccollins@ccollins-VirtualBox:~/tmp/myproj]$ 

Sorry I can't provide more help here.

Chris

Re: Problem Loading arduino_boot

[Christopher Collins]

Hi Nges,

On Thu, Apr 14, 2016 at 02:44:10AM +0100, Nges B wrote:
> hello Chris sorry for my late reply,
> I succeeded in installing the openocd 0.9.0 since yesterday morning.

Not a problem, and sorry for not noticing the "0.9.0" string in your
earlier emails.

You do not need to download CMSIS-DAP - this is something that is
supported by the Arduino board.  It appears there is still a USB issue
somewhere.  Unfortunately, I don't have any ideas at the moment.  I
don't have a Linux machine available at the moment, but tonight I will
try with my home Linux machine and see if I encounter the same issue.

Chris

Re: Using third-party Apache code

[Christopher Collins]

(I meant to send this several days ago, but I just noticed it in my
drafts folder.  Thanks for answering my questions!)

Hi Justin,

On Fri, Apr 08, 2016 at 08:08:56AM +1000, Justin Mclean wrote:
[...]

> IANAL etc etc
> 
> What’s the software in question your thinking of bundling?

I have pulled in some BLE security manager code from the Zephyr
project (www.zephyrproject.org).  It is released under the Apache 2.0
license, but not by the ASF.

Thanks,
Chris

Re: Timestamp for logs

[Christopher Collins]

On Thu, Apr 07, 2016 at 10:33:26PM -0700, Vipul Rahane wrote:
> Hello,
> 
> I agree with your statement. We do not know on what kind of devices
> Mynewt would be ported to. Sleepy devices which are meant to work for
> 20 years running on a single coin cell battery will rollover the time
> stamp in 2038. We want to be able to take care of such a situation.
> While there are other solutions which can be implemented that are more
> efficient, keeping it as simple as possible is better from an end to
> end perspective as these logs would be used by applications to
> understand the state of the devices. 
> 
> I was planning on storing microseconds because the OS currently
> populates OS time in seconds and microseconds. For microseconds we do
> require 32 bits. I agree for milliseconds 16 bits are enough but
> higher resolution is always better. 

I think 12 bytes of time is more than necessary.  A few notes:

* A single 64-bit microsecond counter allows for 584942 years before
  rollover.

* A single 32-bit second counter won't actually roll over until 2106
  (the 2038 issue only applies to signed 32-bit timestamps).

If we want microsecond precision, I would just go with a single 64-bit
counter.  Otherwise, 32 bits of seconds is sufficient in my opinion.

Chris

> 
> Regards,
> Vipul Rahane
> 
> > On Apr 7, 2016, at 10:02 PM, Justin Mclean  wrote:
> > 
> > HI, 
> > 
> >> I am going to change the log structure so that it stores both(UTC 
> >> timestamp in seconds - 64 bit, Microseconds since last second - 32 bit)
> > 
> > NO objection, but just out of interest why 64 bit for seconds (when 32 bit 
> > of seconds = 60+ years and good until 2038) and 32 bits for milliseconds 
> > when 16 bits will do? See also [1]
> > 
> > Thanks,
> > Justin
> > 
> > 1. https://en.wikipedia.org/wiki/Year_2038_problem#Solutions
> > 
> 

Re: choosing between FCB and NFFS

[Christopher Collins]

Upon reflection, this idea has problems of its own.  The app still
needs to initialize the specific flash storage package being used.  So,
sorry for posting before thinking!  The idea could be salvaged with the
use of some #if directives in the app code, but I am not sure this is
any better than duplicating the entire app.

I think the problem you described won't be applicable to most apps.  The
example apps are affected by this because they are meant to be as
generic as possible.

Chris

On Thu, Apr 07, 2016 at 11:03:07AM -0700, Christopher Collins wrote:
> That mostly sounds good to me, though I agree that the need to duplicate
> app code is not ideal.
> 
> Here is an alternative idea:
> * Both fs and fcb export a suitable API (e.g., "bootapi").
> * By default, apps depend on nffs.
> * If a particular feature is set in the target, the app depends on
>   fcb instead.
> 
> Something like:
> 
> pkg.deps.base:
> - libs/os
> - sys/log
> - libs/newtmgr
> - libs/console/full
> - libs/shell
> 
> pkg.deps: [pkg.deps.base, fs/nffs]
> pkg.deps.FCB_BOOT.OVERWRITE: [pkg.deps.base, sys/config, sys/fcb]
> 
> I may have gotten the yaml syntax wrong, but I think the concept works.
> 
> Chris

Re: choosing between FCB and NFFS

[Christopher Collins]

That mostly sounds good to me, though I agree that the need to duplicate
app code is not ideal.

Here is an alternative idea:
* Both fs and fcb export a suitable API (e.g., "bootapi").
* By default, apps depend on nffs.
* If a particular feature is set in the target, the app depends on
  fcb instead.

Something like:

pkg.deps.base:
- libs/os
- sys/log
- libs/newtmgr
- libs/console/full
- libs/shell

pkg.deps: [pkg.deps.base, fs/nffs]
pkg.deps.FCB_BOOT.OVERWRITE: [pkg.deps.base, sys/config, sys/fcb]

I may have gotten the yaml syntax wrong, but I think the concept works.

Chris

On Thu, Apr 07, 2016 at 09:27:37AM -0700, marko kiiskila wrote:
> Hi,
> 
> at the moment bootloader always uses NFFS. App can tell bootloader
> to pick specific image for next boot by creating a file. Bootloader also
> keeps track of image update by writing to another file.
> 
> I want to use sys/config and FCB (flash circular buffer) for
> this instead. Reason for this change is the impact on code size.
> 
> My current idea revolves around creating new versions of apps;
> one version uses NFFS and second version uses FCB. Both would
> go for the same flash map entry for location of their storage.
> 
> And you would pick your target to use either NFFS or FCB depending on
> what platform you’re building for.
> 
> Not too keen on this though, as it would require a bit of code
> duplication (main.c on boot/slinky/blinky).
> 
> Better suggestions?

Rename newtmgr protocol

[Christopher Collins]

Hello all,

There are two things called "newtmgr":

1. A simple command-response protocol used for interfacing with mynewt
   devices (the newtmgr server code is at core:libs/newtmgr).
2. A CLI tool which communicates with mynewt devics via the newtmgr protocol
   (newt:newtmgr).

I have had a hard time discussing both of these entities due to the
overloaded name.  In the interest of preventing an endless series of
"who's on first" fiascos, I propose we rename the name of the protocol.

I suggest we rename the protocol to: nmp.  I don't really care about the
name, though, as long as it is unique :).

Alternatively, the tool could be renamed, but I thought newtmgr sounds
more like a tool than a protocol.

Thanks,
Chris

Re: [VOTE]: Committer status for Paul Dietrich and Neel Natu

[Christopher Collins]

On Tue, Apr 05, 2016 at 10:39:01PM -0700, aditi hilbert wrote:
> This is a call to vote on conferring committer status to the following
> two contributors. They have submitted several patches and entire
> modules via pull requests on Mynewt github mirrors on a variety of
> topics. 
> 
> [+1] Paul Dietrich
> [+1] Neel Natu
> 
> They have submitted the ICLA already. Voting will be open for 72 hours. 

Thanks,
Chris

[jira] [Closed] (MYNEWT-74) NFFS - Make sure RAM is freed when a file gets unlinked

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-74.
-
Resolution: Fixed

I tried uploading a 108kB image five times, and I never encountered any issues. 
 I am closing this ticket, and we can reopen it if this issue reoccurs.

> NFFS - Make sure RAM is freed when a file gets unlinked
> ---
>
> Key: MYNEWT-74
> URL: https://issues.apache.org/jira/browse/MYNEWT-74
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_rel
>
>
> When a file gets deleted (and all open handles closed), the following objects 
> should get freed from RAM:
> * File's inode entry
> * The file's last data block (the only one stored in RAM)
> * Hash entry for the inode entry.
> * Hash entries for each of the file's data blocks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MYNEWT-74) NFFS - Make sure RAM is freed when a file gets unlinked

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-74:
-

Assignee: Christopher Collins  (was: Aditi Hilbert)

> NFFS - Make sure RAM is freed when a file gets unlinked
> ---
>
> Key: MYNEWT-74
> URL: https://issues.apache.org/jira/browse/MYNEWT-74
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_rel
>
>
> When a file gets deleted (and all open handles closed), the following objects 
> should get freed from RAM:
> * File's inode entry
> * The file's last data block (the only one stored in RAM)
> * Hash entry for the inode entry.
> * Hash entries for each of the file's data blocks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: net/nimble/host code size reduction

[Christopher Collins]

On Tue, Apr 05, 2016 at 03:10:40PM -0700, aditi hilbert wrote:
> So how much was the size reduction?

Good question :).  The host size was reduced

from: 48526 bytes
  to: 42257 bytes

I should note that I am building with -DLOG_LEVEL=2, which also reduces
the code size somewhat.  This option sets the log level to info rather
than the default (debug).

Chris

net/nimble/host code size reduction

[Christopher Collins]

Hello all,

Yesterday I made a fairly large commit to the net/nimble/host package in the
core repository (the host-side of the BLE stack).  I wanted to provide the
community with an explanation of these changes and related changes planned for
the future.  This email will probably be long and detailed, so don't
feel bad about skimming it for anything that you find interesting.  That
said, I would love to hear any and all feedback.

First, here is the relevant commit:
Repo: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
Branch: develop
Commit: 2fef21d6a1f9d3d83b88ecf11b825a6e5a354a47

Motivation for this change: the code size of net/nimble/host had grown
quite large over the last few months.  During development of the host,
most focus was put on correctness and maintainability, while speed and
size considerations were placed in the background.  Now that the host is
reasonably complete, it is a good time to start optimizing, with the
hope that the unit tests will protect against any regressions.

The commit consists of two major changes:

1. Use packed structs for over-the-air ATT and L2CAP commands.
2. Compile-out most assertions unless BLE_HS_DEBUG is defined.

Regarding 1:

Prior to this change, the host code was manually
marshalling fields between buffers and properly-aligned structs.  This
had the benefit of being defined behavior according to the C standard,
but at the cost of increased code size.  By using the gcc __packed__
attribute, the compiler is able to take advantage of the Cortex-M's
ability to perform unaligned accesses, resulting in a substantial code
savings.

Regarding 2:

The host code makes liberal use of the assert() macro.
Each invocation of the assert() macro was adding a surprising amount of
code to the resulting binary.  The size increase is not caused by
strings being embedded in the binary; the baselibc assert() does not include
the expression text in its expansion, and gcc collapses duplicate
filename strings.  The size increase is just caused by the comparison
and branch implicit in the assert macro.

The asserts in the host code are plentiful and conservative.  They
caused an unwelcome increase in code size, but I didn't want to remove
them entirely because they are valuable during regression testing.  The
standard assert() macro compiles to nothing if the NDEBUG symbol is
defined, but I wanted more control over which asserts actually get
disabled.  As a compromise, I added a second type of assertion that only
gets compiled in if the BLE_HS_DEBUG symbol is defined.  

I think the concept of multiple assert levels will be useful to other
packages and that it should be added to the core OS.  For this reason, I
intentionally made the new assert macro names ugly, as I hope to replace
them with something that isn't host-specific.

Here are the two macros I added:

#if BLE_HS_DEBUG
#define BLE_HS_DBG_ASSERT(x) assert(x)
#define BLE_HS_DBG_ASSERT_EVAL(x) assert(x)
#else
#define BLE_HS_DBG_ASSERT(x)
#define BLE_HS_DBG_ASSERT_EVAL(x) ((void)(x))
#endif


BLE_HS_DBG_ASSERT(x) is self-explanatory; it asserts if the necessary
debug symbol is defined.

BLE_HS_DBG_ASSERT_EVAL(x) is less obvious.  If the BLE_HS_DEBUG symbol
is defined, this macro has the same effect as the first one.  If the
symbol is not defined, this macro evaluates its argument and throws away
the result.  The reason this macro exists is to prevent gcc from raising
"variable set but not used" warnings in code like the following:

rc = operation_that_should_never_fail();
BLE_HS_DBG_ASSERT_EVAL(rc == SUCCESS);

Note that the BLE_HS_DBG_ASSERT_EVAL() macro differs from the standard
assert() macro in this respect.  The standard assert() macro does not
evalute its argument if NDEBUG is defined, which allows you to write
code like the following:

assert(expensive_sanity_check() == SUCCESS);

Future changes:

There are a number of future changes planned for further reducing the
host code size.

* Pack the HCI command and event structs.
* Rework (or remove / replace) the generic FSM implementation; the
  code has outgrown this facility.

If you have made this far and have any suggestions of your own, they
would be much appreciated, so please feel free to share them.

Thanks,
Chris

Re: Testing rhe libs/shell

[Christopher Collins]

On Mon, Apr 04, 2016 at 11:55:54PM +0100, Nges B wrote:
> in a new created project , the newt test all fails the libs/json .
> the jlibs/json was not corrected on that repository.
> Thanks

It looks like this particular fix was already pushed to the develop
branch on 2016-03-21 (e8a365bd766ac2963ca9c757175889caf5f12461).

The reason you still see the test failure in a newly created project is
that newt's default behavior is to use the mynewt_0_8_0_b2_tag, not the
develop branch.  The json unit test fix will be visible by default in
the next release of the core repository.

If you want to try out the fix, you can configure your project to use
the develop branch of core.  Do this by changing your project.yml file
to use core 0.0.0 as follows:

FROM:

repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core

TO:

repository.apache-mynewt-core:
type: github
vers: 0.0.0
user: apache
repo: incubator-mynewt-core

Note that the develop branch my be broken at any time, so it is only
recommended for testing and development.  Also, it is likely to be
incompatible with non-develop-branches of other repositories (e.g., newt
tool and arduino repo).

Thanks for submitting the pull request.  As this particular fix was
already implemented, I will close the request, but please submit more if
you find other issues

Chris

Re: Master newt does not build released software

[Christopher Collins]

On Sat, Apr 02, 2016 at 02:00:55PM -0700, Sterling Hughes wrote:
> When making changes to a platform as popular as Arduino Zero, that will 
> likely break compat, can people please TEST to make sure the release 
> version still works.

Also, I imagine that compatibility-breaking changes like these will be
tied to changes in version numbers.  That will help to prevent this
particular issue from occurring again.

(btw, I realize I misread your comment about deprecating the old pkg.yml
rather than removing support immediately... sorry about that!).

Chris

Re: Master newt does not build released software

[Christopher Collins]

I agree that that is a compatibility break, but that change was made at
the same time as a host of other backwards-incompatible changes
(0.8.0-b2).  I think this particular problem is a bit more complicated,
so strap yourself in for some mind-numbing post-mortem analysis.

The root of this issue is that the arduino repository.yml file
incorrectly pointed to the develop branch rather than an appropriate tag
on the master branch.  Under these conditions, everything worked for a
while, because the arduino bsp's pkg.yml file on the develop branch does
specify the correct package type ("bsp").  Eventually, a change was made
to the arduino develop branch which was incompatible with the core
master branch [*], which is not surprising.  This incompatible change
exposed the bug in the arduino repository.yml file.  As a consequence,
the arduino repository.yml file was modified to point to the master
branch.  The mistake here was in assuming the repository.yml change
would be sufficient for fixing the arduino build issues.

In my opinion, temporarily removing the package type restrictions is not
the right thing to do here.  We would need to re-release newt for that
fix to have any effect.  Instead, I believe we should create a new tag
on the arduino repo with the pkg.yml fix.  I can make this change and
ensure arduino apps build properly.  However, I don't have an arduino
with me, so I can't actually test image upload or debug.

Chris


[*] - C files were including HAL header files that only existed in the
develop branch of the core repo.


On Sat, Apr 02, 2016 at 12:13:45PM -0700, Sterling Hughes wrote:
> Hey,
> 
> Try:
> 
> $ newt target show
> targets/arduino_boot
>  app=@apache-mynewt-core/apps/boot
>  bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
>  build_profile=optimized
>  features=arduino_zero_pro
> targets/my_blinky_sim
>  app=apps/blinky
>  bsp=@apache-mynewt-core/hw/bsp/native
>  build_profile=debug
> $ newt build arduino_boot
> Error: bsp package (hw/bsp/arduino_zero) is not of type bsp; type is: lib
> $
> 
> I understand that we introduced package types into the new release. 
> What I'm not sure of is why we've broken compatibility here?
> 
> Yes, we're beta, and compatibility breaks are allowed, but:
> 
> A- We should call them out on dev@ _PRIOR_ to breaking compatibility, so 
> things like the docs can be changed.
> 
> B- In this case, was a compatibility break really necessary?  Couldn't 
> we have just accepted the package type if it was lib-- at least for a 
> couple of releases?
> 
> Sterling

[jira] [Closed] (MYNEWT-65) NFFS - Don't allow a parent directory to be moved into a child directory

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-65.
-
Resolution: Fixed

> NFFS - Don't allow a parent directory to be moved into a child directory
> 
>
> Key: MYNEWT-65
> URL: https://issues.apache.org/jira/browse/MYNEWT-65
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_rel
>
>
> This operation will cause a loop in the inode tree.  An attempt to perform 
> this operation should fail with an FS_EINVAL error code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ANNOUNCE] Apache Mynewt Apache Mynewt 0.8.0-b2-incubating released

[Christopher Collins]

Hello all,

The Apache Mynewt team is pleased to announce the release of Apache Mynewt
0.8.0-b2-incubating.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:
http://www.apache.org/dyn/closer.lua/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

For information about bugs fixed in beta 2, please view the Issue
Tracker Summary:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319221=12334805

This is the first source release of the "New" Newt.  More information on
the genesis of Newt, and a description can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C56E21C13.9050303%40apache.org%3E

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at
http://mynewt.incubator.apache.org/

Regards,
The Apache Mynewt team

Disclaimer:
Apache Mynewt is an effort undergoing incubation at The Apache Software
Foundation (ASF) sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

Re: FYI: bletiny is over the nrf51 code size limit

[Christopher Collins]

The culprit is the security code that was recently added to the host.
This new code caused ~10kB of mbedtls code to get pulled in to the
image.

Since security support is incomplete, I have disabled the security
manager by default.  The latest code in the develop branch should fit on
the nRF51 once again.

This is obviously not a long term solution.  I think we will need to
look for ways to reduce the nimble host code size soon.

Chris

On Mon, Mar 28, 2016 at 09:52:09AM -0700, will sanfilippo wrote:
> Hello:
> 
> This is just an FYI: the nrf51 bletiny build is over the code size limit, so 
> if you pull develop and build this project it will not link. This will get 
> fixed today (hopefully).

[RESULT][VOTE] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.8.0-b2-incubating-rc3 is now closed.  The
release has passed.  The vote breakdown is as follows:

+1 Jim Jagielski(binding)
+1 Justin Mclean(binding)
+1 Sterling Hughes  (binding)

Total: +3

Thank you to all who voted.

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Nimble HCI

[Christopher Collins]

On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote:
[...]

To summarize my understanding of your proposal (please let me know if I
got anything wrong!):

1. Create several independent HCI packages in the net/nimble directory.

>   net/nimble/hci_spi
>   net/nimble/hci_combined
>   net/nimble/hci_uart

2. Each HCI package exports the "ble_hci" API in its pkg.yml.

# net/nimble/hci_spi/pkg.yml
pkg.apis: ble_hci

3. Both net/nimble/host and net/nimble/controller require the "ble"hci"
API in their pkg.yml files.

# net/nimble/host/pkg.yml
pkg.req_apis: ble_hci

4. The app specifies the hard dependency on a specific HCI package.

# apps/myapp/pkg.yml
pkg.deps: @apache-mynewt-core/net/nimble/hci_spi

I like it.  There is one annoyance, though: it is too bad that the app
has to depend on a specific HCI package.  Using bletiny as an example,
it would be nice if this app could be HCI-transport-agnostic.  However,
some piece of code has to initialize the specific HCI package being
used, and it makes sense that this would happen in the app, so I am not
sure this is an issue.  It might be worthwhile to think a bit about how
we might solve this issue cleanly.  The only solutions I can think of
add too much complexity to justify, in my opinion.

Thanks,
Chris

[VOTE] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Christopher Collins]

Hello,

The Apache Mynewt Incubator PPMC has approved a proposal to release
Release Apache Mynewt 0.8.0-b2-incubating-rc3.  We now kindly request
that the Incubator PMC members review and vote on this incubator
release.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.  Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

For information about bugs fixed in beta 2, please view the Issue
Tracker Summary:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319221=12334805

This is the first source release of the "New" Newt.  More information on
the genesis of Newt, and a description can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C56E21C13.9050303%40apache.org%3E

The full mynewt test suite for this release was executed via "newt test
all" with no failures.  This testing was performed on the following
platforms:
* OS X 10.10.5
* Linux 3.19.0 (Ubuntu 14.10)

In addition, all other currently-supported platforms were smoke tested.

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/

[VOTE] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C20160319014649.GC26120%40iori.nightmare-heaven.no-ip.biz%3E

[RESULT][VOTE] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C20160322195251.GJ26120%40iori.nightmare-heaven.no-ip.biz%3E

[DISCUSS] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C20160319014750.GD26120%40iori.nightmare-heaven.no-ip.biz%3E

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/

The commits under consideration are as follows:

blinky (formerly tadpole):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky.git
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core (formerly larva):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git
commit: 2bec33d4dba12094f32ca560410b8671c0ce1d22

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git
commit: 58053579210a3541916d3e799b22cc81bc473e47

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/apache-newt-bin-linux-0.8.0-b2-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/apache-newt-bin-osx-0.8.0-b2-incubating.tgz

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT][VOTE] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.8.0-b2-incubating-rc3 is now closed.  The
release has passed this step of the process.  The vote breakdown is as
follows:

+1 Christopher Collins
+1 Sterling Hughes
+1 Justin Mclean
+1 Will san Filippo

Total: +4

We can now call a vote on the general@incubator list.

Thank you to all who voted.

Thanks,
Chris

[VOTE] Release Apache Mynewt 0.8.0-incubating-b2

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of
Apache Mynewt 0.8.0-incubating-b2.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.  Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

For information about bugs fixed in beta 2, please view the Issue
Tracker Summary: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319221=12334805

This is the first source release of the "New" Newt.  More information on
the genesis of Newt, and a description can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C56E21C13.9050303%40apache.org%3E

The full mynewt test suite for this release was executed via "newt test
all" with no failures.  This testing was performed on the following
platforms:
* OS X 10.10.5
* Linux 3.19.0 (Ubuntu 14.10)

In addition, all other currently-supported platforms were smoke tested.

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-incubating-b2/

The commits under consideration are as follows:

blinky (formerly tadpole):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky.git
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core (formerly larva):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git
commit: 62df74fab22302d70a12caff0082d1adb6b5b3b3

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git
commit: 58053579210a3541916d3e799b22cc81bc473e47

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-incubating-b2/apache-newt-bin-linux-0.8.0-incubating-b2.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-incubating-b2/apache-newt-bin-osx-0.8.0-incubating-b2.tgz

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers,
please feel free to try out the release candidate and provide your
votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Chris

Re: [VOTE] Release Apache Mynewt 0.8.0-incubating-b2

[Christopher Collins]

On Thu, Mar 17, 2016 at 10:02:01AM +1100, Justin Mclean wrote:
> > Blinky is a bit unusual in that it is not meant to be compilable nor
> > testable on its own
> 
> Any reason it has unittest as a target then? (as shown by mynewt info)

Well... it's an implementation detail that leaked out :).  The unittest
target is used internally by the "newt test" command.  In the latest
release candidate, the unittest target is hidden from the user in the
output of "newt info" and "newt target show".  The plan is to get rid of
this hack in the next release; then the unittest target won't exist at
all.

> > Are subdirectories generally not considered to be included in such a
> > reference?
> 
> All good I missed that subdirectory reference in LICENSE, so nothing needs to 
> be done there.

Great, thanks!

Chris

[DISCUSS] Release Apache Mynewt 0.8.0-incubating-b2

[Christopher Collins]

Hi all,

This thread is for any and all discussion regarding the release of
Apache Mynewt 0.8.0-incubating-b2.  All feedback is welcome.

Thanks,
Chris

[VOTE] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of
Apache Mynewt 0.8.0-b2-incubating-rc3.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.  Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

For information about bugs fixed in beta 2, please view the Issue
Tracker Summary: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319221=12334805

This is the first source release of the "New" Newt.  More information on
the genesis of Newt, and a description can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C56E21C13.9050303%40apache.org%3E

The full mynewt test suite for this release was executed via "newt test
all" with no failures.  This testing was performed on the following
platforms:
* OS X 10.10.5
* Linux 3.19.0 (Ubuntu 14.10)

In addition, all other currently-supported platforms were smoke tested.

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/

The commits under consideration are as follows:

blinky (formerly tadpole):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky.git
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core (formerly larva):
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git
commit: 2bec33d4dba12094f32ca560410b8671c0ce1d22

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git
commit: 58053579210a3541916d3e799b22cc81bc473e47

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/apache-newt-bin-linux-0.8.0-b2-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating/rc3/apache-newt-bin-osx-0.8.0-b2-incubating.tgz

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers,
please feel free to try out the release candidate and provide your
votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Chris

[DISCUSS] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Christopher Collins]

Hello all,

This thread is for any and all discussion regarding the release of
Apache Mynewt 0.8.0-b2-incubating-rc3.  All feedback is welcome.

Thanks,
Chris

[VOTE][CANCEL] Release Mynewt 0.8.0-incubating-b2

[Christopher Collins]

Hello all,

Voting for the release of 0.8.0-incubating-b2 has been cancelled due to
a bug that was discovered in the bletiny application [*].  A new vote
will be called in the near future.

I apologize for the confusion.  The next release candidate will be
clearly labelled with a candidate number (rc3).

Thanks,
Chris

[*] The bletiny application exhibits a stack overflow while logging
incoming BLE messages.

Re: [DISCUSS] Release Apache Mynewt 0.8.0-incubating-b2

[Christopher Collins]

Hi Justin,

On Sat, Mar 19, 2016 at 08:49:50AM +1100, Justin Mclean wrote:
> Hi,
> 
> I took a look at the binaries and have a question. What exactly is in
> the newt binary? Is any extra 3rd party code bundled into that binary
> that is not in the source release? And if so how is that licensed?

The binary does not contain any code that isn't in the source release.
In this release, newt uses the Go "vendoring" feature, which allows
all the library dependencies to be shipped alongside the application
code.  This is a change from the b1 release, which relied on the user to
download all the dependencies using the go command line tool (b1 was
released this way due to the LGPL yaml dependency that has since been
removed).

Thanks,
Chris

[VOTE][CANCEL] Release Mynewt 0.8.0-incubating-b2

[Christopher Collins]

Hello all,

Voting for the release of 0.8.0-incubating-b2 has been cancelled due to
some compliance issues.  A new vote will be called in the near future.

Thanks,
Chris

Apache Mynewt release process

[Christopher Collins]

Hello all,

I have created a page on the Mynewt wiki detailing the release process:

https://cwiki.apache.org/confluence/display/MYNEWT/Release+Process

If you have time, please take a look and make corrections or post
comments to the list.

Thanks,
Chris

[ANNOUNCE] Apache Mynewt 0.8.0-b1-incubating released

[Christopher Collins]

Hello all,

The Apache Mynewt team is pleased to announce the first release of Apache
Mynewt: 0.8.0-b1-incubating.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:
http://www.apache.org/dyn/closer.lua/incubator/mynewt/apache-mynewt-0.8.0-b1-incubating

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at
http://mynewt.incubator.apache.org/

Regards,
The Apache Mynewt team

Disclaimer:
Apache Mynewt is an effort undergoing incubation at The Apache Software
Foundation (ASF) sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

Re: installing the Newt

[Christopher Collins]

I have committed the changes to the develop branch.  Now all go imports
use the vanity domain.

Unfortunately, this is going cause a bit of pain for the current users
because the newt sources are now in the wrong directory.  To correct
this problem, you will need to move the old newt path to the new one:

$ mkdir -p "$GOPATH"/src/mynewt.apache.org &&
  mv $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt 
"$GOPATH"/src/mynewt.apache.org/newt

If you plan on building older versions of newt, you should link the path
rather than move it:

$ mkdir -p "$GOPATH"/src/mynewt.apache.org &&
  ln -s $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt 
"$GOPATH"/src/mynewt.apache.org/newt

Sorry for the hassle.  Yes, we definitely need to include convenience
binaries in the next release :).

Chris

On Wed, Mar 02, 2016 at 11:21:49PM -0800, Christopher Collins wrote:
> Nice!  That seems to work.  I guess I completely glossed over those
> vanity URL emails.  I will make the necessary changes to the develop
> branch.  Unfortunately, I'm afraid it is too late to fix 0.8.0-b1.
> 
> Chris
> 
> On Wed, Mar 02, 2016 at 10:40:53PM -0800, Sterling Hughes wrote:
> > 
> > >
> > > When pointed at the apache server, on the other hand, "go get" seems to
> > > require the ".git" suffix.  An I mentioned earlier, this results in the
> > > creation of a directory that also has the ".git" suffix.
> > >
> > > The problem is: the behavior of "git clone" is in conflict with the
> > > behavior of "go get", at least with regards to the apache git server.
> > > At one point the installation documentation was accurate, but it seems
> > > we have since opted for git-friendliness rather than
> > > go-get-friendliness.
> > >
> > > We will need to find a simpler workaround.  In the meantime, we should
> > > at least update the documentation.  Also, soon newt binaries will be
> > > available for download which help to alleviate problems with go.
> > >
> > 
> > Weren't Todd & Aditi making "mynewt.apache.org" a valid import path, 
> > that would point to the proper Apache git repository?   I thought this 
> > would solve that problem?
> > 
> > Sterling

[RESULT][VOTE] Release Apache Mynewt 0.8.0-b1-incubating

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.8.0-b1-incubating is now closed.  The release
has passed.  The vote breakdown is as follows:

+1 Jim Jagielski(binding)
+1 Justin Mclean(binding)
+1 Sterling Hughes  (binding)

Total: +3

Thank you to all who voted.

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Resolved] (MYNEWT-137) Replace YAML dependency in Newt tool

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-137.

Resolution: Fixed

The solution was to rewrite the parts of yaml.v2 that we need.  This wasn't as 
bad as it sounds because:
* Most of yaml.v2 is actually MIT-licensed, as it is a direct port from the 
libyaml C library.
* We only need to decode YAML, not encode.

That said, this naive solution is still troubling.  All libraries which depend 
on yaml.v2 need to be forked and changed so that they import our yaml library 
instead.  In our current code base, viper is the only library which depends on 
yaml.v2, so the maintenance cost isn't horrible.

> Replace YAML dependency in Newt tool
> 
>
> Key: MYNEWT-137
> URL: https://issues.apache.org/jira/browse/MYNEWT-137
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newt
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
>Priority: Blocker
> Fix For: v0_8_0_beta2
>
>
> We need to replace the YAML dependency in the newt tool.  Currently this LGPL 
> dependency is causing issues with building and distributing Newt. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RESULT][VOTE] Release Apache Mynewt 0.8.0-b1-incubating

[Christopher Collins]

FYI - here is the vote thread on the general list:
http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C20160227030138.GT14480%40iori.nightmare.heaven%3E

(Yes, I need to change my computer domain!)

Chris

On Fri, Feb 26, 2016 at 06:11:25PM -0800, Christopher Collins wrote:
> Hello all,
> 
> Voting for Apache Mynewt 0.8.0-b1-incubating is now closed.  The release
> has passed this step of the process.  The vote breakdown is as follows:
> 
> +1 Aditi Hilbert
> +1 Justin Mclean
> +1 Marko Kiiskila
> +1 Sterling Hughes
> +1 Will san Filippo
> 
> Total: +5
> 
> We can now call a vote on the general@incubator list.
> 
> Thank you to all who voted.
> 
> Thanks,
> Chris

[VOTE] Release Apache Mynewt 0.8.0-b1-incubating

[Christopher Collins]

Hello,

The Apache Mynewt Incubator PPMC has approved a proposal to release
Apache Mynewt 0.8.0-b1-incubating.  We now kindly request that the
Incubator PMC members review and vote on this incubator release.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.  Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

This would be the first release of Apache Mynewt; what has changed since
the last release is: literally everything :).

[VOTE] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201602.mbox/%3C20160224012927.GC14480%40iori.nightmare.heaven%3E

[VOTE RESULT] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201602.mbox/%3C20160227021125.GO14480%40iori.nightmare.heaven%3E

[DISCUSS] thread:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201602.mbox/%3C20160224013028.GD14480%40iori.nightmare.heaven%3E

All automated tests in the mynewt test project for this release were
executed with no failures.  Testing was performed using the "sim"
architecture on an OS X 10.10.5 machine.

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.8.0-b1-incubating/

The commits under consideration are as follows:

larva:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva
commit: ba1586a4f2cbe47c25cf4d202fd3f999e47e0843

tadpole:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole
commit: a9723f015eb42edcd6e14e9b366d35fb7707fde8

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: a8c2eb68eb1e9bc83e344f13410d4cb92c3fa12b

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT][VOTE] Release Apache Mynewt 0.8.0-b1-incubating

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.8.0-b1-incubating is now closed.  The release
has passed this step of the process.  The vote breakdown is as follows:

+1 Aditi Hilbert
+1 Justin Mclean
+1 Marko Kiiskila
+1 Sterling Hughes
+1 Will san Filippo

Total: +5

We can now call a vote on the general@incubator list.

Thank you to all who voted.

Thanks,
Chris

[jira] [Updated] (MYNEWT-167) Newt sometimes performs unnecessary compiles due to inconsistently ordered cflags

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-167:
---
Fix Version/s: v0_8_0_beta2

> Newt sometimes performs unnecessary compiles due to inconsistently ordered 
> cflags
> -
>
> Key: MYNEWT-167
> URL: https://issues.apache.org/jira/browse/MYNEWT-167
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> The cflags, lflags, and aflags that get passed to the compiler are not always 
> consistently ordered between builds.  If the compiler invocation is different 
> from the previous one, newt forces a recompile.  If the only thing that has 
> changed is the order of the flags, then such a recompile is unnecessary.
> The fix is to sort the flags alphabetically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-125) newt should show available options for different tags like arch

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-125.
--
Resolution: Fixed

The user can get a list of valid settings with the following invocation:

{noformat}
newt target set  
{noformat}

That is, a standard "target set" command, but without the "=" suffix.

Example:
{noformat}
[ccollins@ccollins-mac:~/repos/larva/master/larva]$ newt target set bletest arch
Valid values for target variable "arch":
cortex_m0
cortex_m4
sim
{noformat}

The following target variables are supported:
* arch
* bsp
* compiler
* project

Later we can add bash / zsh tab-completion support.

> newt should show available options for different tags like arch
> ---
>
> Key: MYNEWT-125
> URL: https://issues.apache.org/jira/browse/MYNEWT-125
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Newt
>    Reporter: Paul Dietrich
>Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> It would be nice it I could do something like
> newt target set arch=?
> and see a list of what is possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-39) Fix confusion between egg & project .yml files

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-39.
-
Resolution: Fixed

The contents of all {{.yml}} and {{compiler.yml}} files have been 
migrated to the corresponding {{pkg.yml}} files, and the Newt tool has been 
updated to account for this change.

A few notes:
* Project yml files have been modified to look exactly like any other pkg.yml 
file.  This means:
** The "project" prefix has been converted to "pkg"
** The "pkgs" setting has been renamed to "deps"
* Unlike project files, compiler yml files were not fully transformed into the 
pkg.yml format.  Compiler-specific settings (e.g., "compiler.path.cc", 
"compiler.ld.flags", etc.) retain the "compiler" prefix.

The changes to the Newt tool were of the "quick fix" variety.  While reading a 
project's yml file, the tool simply opens "pkg.yml" when it used to open 
".yml".  The proper fix is to load the project configuration in 
the same way as package configurations, allowing us to remove much of the code 
in project.go.  I did not do this because this would require some major 
restructuring of the newt code, and I would prefer to implement this fix 
incrementally.  In the future, we will likely want to make these major changes.

> Fix confusion between egg & project .yml files
> --
>
> Key: MYNEWT-39
> URL: https://issues.apache.org/jira/browse/MYNEWT-39
> Project: Mynewt
>  Issue Type: Improvement
>Reporter: Sterling Hughes
>Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> Right now the project's need to have egg dependencies in egg.yml for newt egg 
> dependencies, and the newt build system looks for the project's dependencies 
> in the .yml file.  This leads to confusion, and mismatching files.
> This should be unified, by either: 
> a) Removing the .yml file, and just having an egg.yml file.
> b) Only listing project dependencies in either the egg.yml _OR_ the 
> .yml file.
> Personally, I think everything a project does can be encapsulated in an 
> egg.yml file. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-43) Add missing fields to egg.yml files

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-43.
-
Resolution: Fixed

I added these fields to all pkg.yml files in larva.  I made up the description, 
and inferred the author from the package's git log.

> Add missing fields to egg.yml files
> ---
>
> Key: MYNEWT-43
> URL: https://issues.apache.org/jira/browse/MYNEWT-43
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newt
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> Need to add the following fields to newt prior to release: 
> - Description: Description of the egg
> - Keywords: Keywords for package search 
> - Author: Author of the package
> - Homepage: Homepage of the package
> - Repository: package repository information (of current package)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-161) NFFS - Inefficient restoring of large files

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-161:
--

 Summary: NFFS - Inefficient restoring of large files
 Key: MYNEWT-161
 URL: https://issues.apache.org/jira/browse/MYNEWT-161
 Project: Mynewt
  Issue Type: Bug
  Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v0_9_0_rel


The inefficiency was introduced in the fix for MYNEWT-160.  This ticket is for 
replacing that fix with something more efficient.

Details to follow...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-160) NFFS - Files with scattered data blocks can cause restore failures

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-160:
--

 Summary: NFFS - Files with scattered data blocks can cause restore 
failures
 Key: MYNEWT-160
 URL: https://issues.apache.org/jira/browse/MYNEWT-160
 Project: Mynewt
  Issue Type: Bug
  Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v0_8_0_beta2


If a file's data blocks are written to disk in an "unexpected" order, the 
subsequent restore operation can fail in a few ways:

1. The restore fails with an FS_ECORRUPT error code.
2. The file is only partially restored; the end of the file will be 
inaccessible.

This bug is rooted in the inconvenient data structure that NFFS uses for 
chained data blocks (reverse singly-linked list).  The data structure is 
inconvenient, but it is used to minimize RAM and flash usage.

On disk, each data block indicates the ID of the preceding data block in the 
parent file.  In RAM, a file inode provides access to all the constituent data 
blocks by maintaining a pointer to the last data block.

The bug is that the NFFS code does not always ensure that a file inode points 
to its last data block.  The code assumes that data blocks will be restored in 
order of increasing file offset.  If data blocks are restored in any other 
order, this bug occurs.

The correct fix will be quite involved.  I am going to implement a quick fix 
for 0.8.0 which fixes the bug, but introduces some horrible inefficiencies when 
large files are restored.  I will schedule a proper fix for 0.9.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: README.md files

[Christopher Collins]

Just an "fyi" - I am planning on tagging and restarting the release
process at about 3:00 PST today (in one hour).  If you have any
documentation or license changes that need to go into master, please let
me know before then.

Thanks,
Chris

On Tue, Feb 23, 2016 at 11:07:28AM -0800, Christopher Collins wrote:
> Hi all,
> 
> In preparation for the Apache Mynewt 0.8.0 beta 1 (incubating) release,
> I have made some minor changes to the top-level README.md files.  I
> think these files could probably use some more work, and I wanted to
> request a favor: if you have time to take a look, please do so and make
> any improvements as you see fit (or suggest changes).
> 
> Here are the minor edits I have made recently:
> 
> newt:
> * Moved newt/README.md to top-level directory (i.e., it applies to
>   newt, newtmgr, and newtvm, rather than just newt).
> * Added basic steps for building the newt tool.
> * Added link to the getting started page
>   (http://mynewt.apache.org/os/get_started/project1/)
> 
> larva:
> * added link to the getting started page
>   (http://mynewt.apache.org/os/get_started/project1/)
> 
> tadpole:
> * I didn't really change anything here; the readme looked decently
>   thorough.
> 
> Thanks,
> Chris

[jira] [Closed] (MYNEWT-127) BLE Host - Allow application to set advertise response data

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-127.
--
Resolution: Fixed

> BLE Host - Allow application to set advertise response data
> ---
>
> Key: MYNEWT-127
> URL: https://issues.apache.org/jira/browse/MYNEWT-127
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MYNEWT-43) Add missing fields to egg.yml files

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-43:
-

Assignee: Christopher Collins  (was: Sterling Hughes)

> Add missing fields to egg.yml files
> ---
>
> Key: MYNEWT-43
> URL: https://issues.apache.org/jira/browse/MYNEWT-43
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newt
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> Need to add the following fields to newt prior to release: 
> - Description: Description of the egg
> - Keywords: Keywords for package search 
> - Author: Author of the package
> - Homepage: Homepage of the package
> - Repository: package repository information (of current package)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MYNEWT-125) newt should show available options for different tags like arch

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-125:
--

Assignee: Christopher Collins  (was: Sterling Hughes)

> newt should show available options for different tags like arch
> ---
>
> Key: MYNEWT-125
> URL: https://issues.apache.org/jira/browse/MYNEWT-125
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Newt
>Reporter: Paul Dietrich
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> It would be nice it I could do something like
> newt target set arch=?
> and see a list of what is possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-96) Nimble stack configuration

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-96:
--
Fix Version/s: (was: v0_8_0_beta2)
   v0_9_0_rel

> Nimble stack configuration
> --
>
> Key: MYNEWT-96
> URL: https://issues.apache.org/jira/browse/MYNEWT-96
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>Affects Versions: v0_8_0_beta1
>Reporter: William San Filippo
>    Assignee: Christopher Collins
> Fix For: v0_9_0_rel
>
>
> The current method of configuring various features/memory usage/etc in our 
> nimble stack is not exactly what we need as we need to have project (or 
> possibly bsp) configuration capability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-66) BLE Host - Random Addresses

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-66:
--
 Due Date: (was: 22/Feb/16)
Fix Version/s: (was: v0_8_0_beta2)
   v0_9_0_rel

> BLE Host - Random Addresses
> ---
>
> Key: MYNEWT-66
> URL: https://issues.apache.org/jira/browse/MYNEWT-66
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>Priority: Minor
> Fix For: v0_9_0_rel
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-127) BLE Host - Allow application to set advertise response data

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-127:
---
Due Date: 23/Feb/16

> BLE Host - Allow application to set advertise response data
> ---
>
> Key: MYNEWT-127
> URL: https://issues.apache.org/jira/browse/MYNEWT-127
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [3/3] incubator-mynewt-larva git commit: Add license to .gitignore file.

[Christopher Collins]

On Tue, Feb 23, 2016 at 09:39:41AM +1100, Justin Mclean wrote:
> Hi,
> 
> > Whoops, thanks Justin.  I didn't see that note in time. 
> 
> Pulling license header of files that may not require it is a non issue, I 
> very much doubt that anyone would take issue with it or in fact even notice 
> :-)
> 
> > Is there anything else you can think of that I might have missed?
> 
> AFAICS it all looks good.

At the risk of exceeding my 'thank you' quota, thanks again for your
patience and support.  I am sure the process will be a little less
painful next time :).

Chris

[VOTE] Release Mynewt 0.8.0-b1-incubating

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of
mynewt-0.8.0-b1-incubating.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.

The release candidate to be voted on is available at:

https://dist.apache.org/repos/dist/dev/incubator/mynewt/mynewt-0.8.0-b1-incubating/

The commits under consideration are as follows:

larva:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva
commit: bd2db03ccbd019a20267459bf46ae1e1428f1f46

tadpole:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole
commit: b00813ec355a0bc3681c232503aab92ea9157fa9

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 27a92e159926778f24d19b0795307a34e05ec8ed

The release candidate is signed with a GPG key available at:

https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at least
three +1 PPMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers, please feel
free to try out the release candidate and provide your votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Chris

Re: RAT (release audit tool)

[Christopher Collins]

Thanks, Justin, that is a good idea.  I'll run both of those tools.

Chris

On Sun, Feb 21, 2016 at 04:54:17PM +1100, Justin Mclean wrote:
> Hi,
> 
> It quite likely that anyone reviewing the release on the incubator will use:
> 1) Apache rat [1]
> 2) Compliance Rocks 
> 
> We might want to put a rat exclusion file together to help people and cut 
> down of the number of false positives it currently generates.
> 
> At the very least yo shovel run the tools over the source release so are 
> prepared for any issue that they might bring up.
> 
> Thanks,
> Justin
> 
> 
> 1. http://creadur.apache.org/rat/apache-rat/
> 2. http://compliance.rocks

Re: LICENSE and NOTICE contents / headers

[Christopher Collins]

On Sat, Feb 20, 2016 at 09:40:40AM +1100, Justin Mclean wrote:
> I think the LICENSE is still missing a number of things, do you look
> at my email when I went through the repos and listed what was
> contained in them? I know things have changed a little in
> tadpole/larval repos but everythink that is bundled needs to be
> accounted for. e.g. Baselibc for instance has several files in it that
> are licensed under other terms. [1]

OK, I believe I have removed the Apache license from all the
"otherwise-licensed" files, and added corresponding pointers to the
larva LICENSE file.  Everything from your earlier email ("Larva content
review for license" sent on 2016-02-04) should now be accounted for.  I
did see your note about checking the FatFS license, but larva does not
contain any FatFS files, so I did not make any mention of it in the
LICENSE file.  Larva's LICENSE file has become quite a monster, I'm
afraid.

> If it helps I can go through and list out what I think they are missing.
> 
> Also I thought we were removing anything with the "MCD-ST Liberty SW
> License”? (It’s not a comparable licence) See larval
> ./hw/mcu/stm/stm32f4xx/include/mcu/system_stm32f4xx.h

I have replaced this file with a more recent version from STM. The new
version has a BSD license.

There is one nagging issue, however.  Larva includes some files from
CMSIS-CORE which lack any license information.  In subsequent releases,
ARM added the BSD license text to these files.  However, we have made
modifications to the original files, so incorporating newer versions of
these files into Larva won't be trivial.  We will fix this issue, but I
am hoping we can take care of this between the first and second release.
In the meantime, I have added a note about this to the larva LICENSE
file.

If you could take another look at where we are, it would be much
appreciated.  Once again, thanks for your unflagging patience!

Chris

Re: LICENSE and NOTICE contents / headers

[Christopher Collins]

On Sat, Feb 20, 2016 at 09:05:58AM +1100, Justin Mclean wrote:
> > The rest of them are from files which contain the Apache license text at
> > the top of the file.  In these files, we retained the original copyright
> > notice below the Apache license.  Do you think this is problematic?
> 
> That's incorrect.while you can license the whole as Apache, each file
> needs to keep their original header and not have two headers.
> 
> The only case where this might come up is if we’re heavily modified
> the file in question.

OK, thanks for the heads up.  Is this something we should deal with
immediately, or can we fix it between now and our next release?

> Other than the above issue is it in a state that I can take another look?

Yes, I believe so.  Thanks again!

Chris

Re: LICENSE and NOTICE contents / headers

[Christopher Collins]

Thanks a lot for looking at this, Justin.

On Fri, Feb 19, 2016 at 06:16:22PM +1100, Justin Mclean wrote:
> Newt repo still has:
> ./.git/hooks/pre-rebase.sample

I believe this file is not actually in the repository.  When a git repo
is cloned, the .git directory is populated with the contents of the
user's template directory, as specified by the "[init] templatedir" git
setting.  On my machine, the default templatedir is
/usr/local/share/git-core/templates.

> And a number of files (mostly .go files) still have "Copyright 2015
> Runtime Inc.”

Good catch.  I will fix this.

> Larval has a number of files with copyright that is this presumably licensed 
> under something, for example:
> Copyright (C) 2004  Kustaa Nyholm
> Copyright (C) 2010  CJlano
> Copyright (C) 2011  Petteri Aimonen
> Copyright (c) 2004,2012 Kustaa Nyholm / SpareTimeLabs
> Copyright (c) 2007, 2008, 2009, 2010 Dado Sutter and Bogdan Marinescu
> Copyright (c) 2007, 2008, 2009, 2010, 2011 Dado Sutter and Bogdan Marinescu
> Copyright (c) 2012 Petteri Aimonen 
> Copyright (c) 2015, Nordic Semiconductor ASA
> 
> See my previous email of this for all the licenses and files.
> 
> As does tadpole, for instance:
>  * Copyright (c) 1982, 1986, 1988, 1991, 1993
>  * Copyright (c) 1991, 1993
>  * Copyright (c) 1995-2001 Kungliga Tekniska Högskolan
>  * Copyright (c) 1999-2009 KEIL, 2009-2013 ARM Germany GmbH
> # Copyright (c) 2006, 2008 Junio C Hamano

I believe these are all accounted for in the larva LICENSE file. Some of
these copyrighted files are from the following sources:

tinyprintf (BSD)
eLua (MIT)
queue.h (BSD)

The rest of them are from files which contain the Apache license text at
the top of the file.  In these files, we retained the original copyright
notice below the Apache license.  Do you think this is problematic?

That said, you are entirely correct about tadpole - I forgot to add the
necessary pointers to its LICENSE file.

Thanks,
Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 06:18:19PM +1100, Justin Mclean wrote:
> HI,
> 
> > Since we won't be releasing binaries this time around, the only
> > artifacts are: 1) the source tgz files
> 
> Perhaps a silly question. But how are those tgz files generated?

Oh, I see.  No, not silly at all.  I used the following command to create
the tgz files (executed from the repository base directory):

git archive --format tgz --output ~/tmp/rel/bin/larva/larva-0.8.0-b1.tgz 
--prefix larva-0.8.0-b1/ mynewt_0_8_0_b1_tag

With the obvious substitutions for tadpole and newt.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 06:05:20PM +1100, Justin Mclean wrote:
> What the process for generating the release artefacts?

Since we won't be releasing binaries this time around, the only
artifacts are: 1) the source tgz files, 2) the ascii signature files,
and 3) the SHA checksums.

Or maybe you are asking about the binaries which contain LGPL code?  My
apologies if I misunderstood the question.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 05:54:11PM +1100, Justin Mclean wrote:
> Hi,
> 
> >> Would you like me to give the various LICENSE and NOTICE files a once
> >> over before you make an official RC?
> > 
> > Oops, I am not sure how I missed this.  Yes, that would be extremely
> > helpful.
> 
> I assume they are in the top of each repo? I can’t get to this right now 
> (just about to go out to dinner on friday) but can look at it tomorrow.

Yes, that is correct.  Thanks, that would be great.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 04:19:57PM +1100, Justin Mclean wrote:
> Would you like me to give the various LICENSE and NOTICE files a once
> over before you make an official RC?

Oops, I am not sure how I missed this.  Yes, that would be extremely
helpful.

Thanks,
Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 04:19:57PM +1100, Justin Mclean wrote:

[convenience binaries]
> And are we 100% sure that they don’t contain the LGPL code (source or
> compiled) ?

No - the binaries certainly *do* contain LGPL code.  I take it that is a
problem :).  I think we can refrain from releasing the binaries until we
get the LGPL issue sorted out.  If others disagree with this, please
chime in.

> >
> > http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E
> >  
> > 
> 
> It’s good, but I add the git hash, tags can be deleted or changed. The
> idea is that given a successful vote someone could take the info in
> the email and produce the exact same release as you did. You may also
> offer some advice on what is needed to be checked when voting.
> 
> It also customary to send out a [DISCUSS] email as well that was the
> vote thread doesn’t get polluted by people replying with questions /
> any issues they have found..

All good points.  Noted.

Thanks,
Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 01:43:59PM +1100, Justin Mclean wrote:
> If you’re going to be RM, you should sign up to that list and/or take
> a look previous incubating release votes so you know what to expect.

Good idea.  I have subscribed to that list.

Now... :) I am afraid I'm going to have to nag you with a few more
questions.  If you could take a look when you have a second, that would
be really helpful.  Thanks for your patience!

(1)
I was a little confused about where I should put the release artifacts
prior to sending the dev vote email.  After some reading, I have
inferred that I should put the artifacts here via svn:

https://dist.apache.org/repos/dist/dev/incubator/mynewt

Is that correct?

(2)
Below is a list of files I am planning on uploading to the server:

/repos/dist/dev/incubator/mynewt/mynewt-0.8.0-b1-incubating/
larva-0.8.0-b1.tgz  # Larva source
larva-0.8.0-b1.tgz.asc  # Larva ASCII armored detached signature
larva-0.8.0-b1.tgz.sha  # Larva SHA512 checksum

newt-0.8.0-b1.tgz   # Newt
newt-0.8.0-b1.tgz.asc
newt-0.8.0-b1.tgz.sha

tadpole-0.8.0-b1.tgz# Tadpole
tadpole-0.8.0-b1.tgz.asc
tadpole-0.8.0-b1.tgz.sha

newt-bin-linux-0.8.0-b1.tgz # Newt binary for linux
newt-bin-linux-0.8.0-b1.tgz.asc
newt-bin-linux-0.8.0-b1.tgz.sha

newt-bin-osx-0.8.0-b1.tgz   # Newt binary for Mac OS X
newt-bin-osx-0.8.0-b1.tgz.asc
newt-bin-osx-0.8.0-b1.tgz.sha

/repos/dist/dev/incubator/mynewt/
KEYS# Public keys for sig. validation

The binary files are created from the newt sources as a convenience to
the user.

Does the above directory tree look reasonable to you?

(3) I was planning on using this message as a template for the vote email
that I will send to the mynewt dev list.  Do you think it is suitable?


http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E

Thanks,
Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 01:18:19PM +1100, Justin Mclean wrote:
> Hi,
> 
> > Thanks, Justin.  If we remove this from the distribution (i.e., don't
> > bundle it), do we still need to mention it in LICENSE or NOTICE?
> 
> No only things that are bundled need to be mentioned in LICENSE and
> NOTICE, so no mention in notice.

Got it.  Thanks.

> 
> But having a dependancy on lGPL / GPL gives restrictions that are not
> compatible with the Apache license so mention at in the README and
> that it will be fixed in a future release.
> 
> I seen the send button a little to quick last email. Want me to do
> what sebb suggests and email legal / Jim.

Ah, I see the post
(http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/browser).
My reading of that message was that Sam (sebb?) had already sent a note
to legal, but maybe he is waiting for someone to protest :).  Either
way, it would probably be a good idea (and much appreciated!) if you
sent a note as well, or please feel free to let me know if there is
anything I can do.

Thanks again,
Chris

Re: Kicking off a release

[Christopher Collins]

Sounds good.  I will act as the release manager.

Chris

On Thu, Feb 18, 2016 at 01:48:43PM -0800, Sterling Hughes wrote:
> 
> 
> On 2/16/16 5:07 PM, Justin Mclean wrote:
> > Hi,
> >
> > Who is going to act as release manager?
> >
> 
> Good question: I nominate Chris.
> 
> >
> >> - Add release notes to the mynewt distribution
> >> - Tag the tree with a B1 release tag (mynewt_0_8_0_b1_tag)
> >> - Start a [VOTE] thread to [VOTE] on the Mynewt release (along with
> >> the given tag)
> >> - Should that [VOTE] go through, that tag can then be built into a
> >> series of release artifacts
> >
> > The release artefacts are built first. The  [VOTE] email will have links
> > to the source tar (and binary if we’re creating them) to vote on.
> >
> > After the vote here, you then need to put it up for vote on the
> > incubator general mailing list were only incubator PMC votes are
> > binding. A few of the mentors are IPMC (myself included) so that should
> > help.
> >
> 
> 
> Nice.  So Chris (or whoever) needs to create all the release artifacts 
> (source tarball, binaries, etc.) and tag the tree.  Compose an email to 
> dev@ first (with a [VOTE] thread?), and then if that passes, compose a 
> similar email to general@, with the note that it has already passed a 
> release vote within the podling, correct?
> 
> > Only after both votes pass can you do this:
> >> - That can then be posted on the Mynewt website, along with release notes.
> >
> > And send out a release announcemt!
> >
> > The LICENSE and NOTICE files also need to be updated [1] before a VOTE
> > can be called.
> >
> > Also last time I looked 2 or 3 repos still have a few header files and
> > the like to clean up. It would probably pass an incubator vote in that
> > state (given there a JIRA to fix it) but best to clean up before release
> > I think?
> >
> 
> I'll run through and make changes today.
> 
> Thanks,
> Sterling

[jira] [Created] (MYNEWT-127) BLE Host - Allow application to set advertise response data

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-127:
--

 Summary: BLE Host - Allow application to set advertise response 
data
 Key: MYNEWT-127
 URL: https://issues.apache.org/jira/browse/MYNEWT-127
 Project: Mynewt
  Issue Type: New Feature
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v0_8_0_beta2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-124) Log buffer issues

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-124:
--

 Summary: Log buffer issues
 Key: MYNEWT-124
 URL: https://issues.apache.org/jira/browse/MYNEWT-124
 Project: Mynewt
  Issue Type: Bug
  Components: Misc
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v0_8_0_beta2


When a message is written to a log, some buffers are allocated on the stack in 
various places in the code.  This results in two issues:

# Undue stack-size requirements placed on any task which uses sys/log.
# Hard limit placed on the maximum length of a log line.

There are two functions which exhibit this behavior:
* log_printf (LOG_PRINTF_MAX_ENTRY_LEN = 128)
* console_vprintf (CONS_OUTPUT_MAX_LINE = 128)

I do not have a proposed fix.  I believe Marko suggested streaming bytes to the 
destination, rather than writing to an intermediate buffer.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-121) sys/stats - Allow access from multiple source files

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-121:
--

 Summary: sys/stats - Allow access from multiple source files
 Key: MYNEWT-121
 URL: https://issues.apache.org/jira/browse/MYNEWT-121
 Project: Mynewt
  Issue Type: Improvement
  Components: Misc
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v0_8_0_beta2


1. The STATS_SECT_START and STATS_SECT_END macros just define a struct; they 
don't create an instance.  Generally, these macros would be used in a header 
file so that source files can have access to the struct definition.

2. The addition of a STATS_SECT_DECL macro.  This macro would be used in two 
places:
* In source files to instantiate a stats struct.
* In header files to expose an extern declaration of a stats instance.

3. As a consequence of the above two points: the names of struct instances are 
no longer auto-generated.  The user needs to specify the exact name.  All 
macros which derive the instance name from the struct name are changed: now 
they just accept the instance name directly.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-68) BLE Host - Overly strict mbuf size requirements

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-68.
---
Resolution: Fixed

> BLE Host - Overly strict mbuf size requirements
> ---
>
> Key: MYNEWT-68
> URL: https://issues.apache.org/jira/browse/MYNEWT-68
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>Priority: Minor
> Fix For: v0_8_0_beta2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposed changes to sys/stats

[Christopher Collins]

Thanks for the feedback, all.  I will commit the first three changes to
the develop branch, but leave proposal 4 unimplemented.

Chris

On Tue, Feb 16, 2016 at 01:35:16PM -0800, will sanfilippo wrote:
> +1 for 1, 2 and 3.
> 
> Not sure about 4. I am fine with using the macros and prefacing the element 
> names but not sure what other issues this might cause so I will abstain.
> 
> Will
> 
> > On Feb 16, 2016, at 1:13 PM, Sterling Hughes  wrote:
> > 
> > 
> >> 1. The STATS_SECT_START and STATS_SECT_END macros just define a struct;
> >> they don't create an instance.  Generally, these macros would be used
> >> in a header file so that source files can have access to the struct
> >> definition.
> >> 
> >> 2. The addition of a STATS_SECT_DECL macro.  This macro would be used in
> >> two places:
> >> * In source files to instantiate a stats struct.
> >> * In header files to expose an extern declaration of a stats
> >>   instance.
> >> 
> >> 3. As a consequence of the above two points: the names of struct
> >> instances are no longer auto-generated.  The user needs to specify the
> >> exact name.  All macros which derive the instance name from the struct
> >> name are changed: now they just accept the instance name directly.
> >> 
> > 
> > 
> > +1
> > 
> > 
> >> 4. Remove the "s" which prefaces the name of each stat field in a
> >> statistics struct.  By doing this, the STATS_SECT_VAR, STATS_INC, and
> >> STATS_INCN macros can be removed.
> >> 
> > 
> > -1
> > 
> > I think we want these macros used everywhere: they allow us more 
> > flexibility to refactor this, and there is a relatively well defined access 
> > mechanism for stats.
> > 
> > Sterling
> 

[jira] [Resolved] (MYNEWT-64) BLE Host - HCI callback thread-safety

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-64.
---
Resolution: Fixed

This is implemented via two changes:
* Add a ble_hci_sched mutex that gets locked whenever the list of HCI tx slots 
is read or modified.
* Add a handle per HCI tx slot.  This allows client code to cancel an HCI 
transmission before the tx callback is rendered unusable.


> BLE Host - HCI callback thread-safety
> -
>
> Key: MYNEWT-64
> URL: https://issues.apache.org/jira/browse/MYNEWT-64
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> When the host schedules an outgoing HCI command, it configures a callback 
> which does the actual command formation.  Some events can occur before the 
> callback is executed which render the callback invalid (e.g., connection 
> terminated).
> The fix is to ensure the appropriate resources are protected from deletion 
> while an HCI command is scheduled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-59) BLE Host - Security Manager - Key Generation

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-59:
--
Fix Version/s: v0_9_0_beta1

> BLE Host - Security Manager - Key Generation
> 
>
> Key: MYNEWT-59
> URL: https://issues.apache.org/jira/browse/MYNEWT-59
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_9_0_beta1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-74) NFFS - Make sure RAM is freed when a file gets unlinked

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-74:
--
Fix Version/s: v0_8_0_beta2

> NFFS - Make sure RAM is freed when a file gets unlinked
> ---
>
> Key: MYNEWT-74
> URL: https://issues.apache.org/jira/browse/MYNEWT-74
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> When a file gets deleted (and all open handles closed), the following objects 
> should get freed from RAM:
> * File's inode entry
> * The file's last data block (the only one stored in RAM)
> * Hash entry for the inode entry.
> * Hash entries for each of the file's data blocks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-61) BLE Host - Security Manager - Just Works

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-61:
--
Fix Version/s: v0_9_0_beta1

> BLE Host - Security Manager - Just Works
> 
>
> Key: MYNEWT-61
> URL: https://issues.apache.org/jira/browse/MYNEWT-61
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_9_0_beta1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-64) BLE Host - HCI callback thread-safety

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-64:
--
Fix Version/s: v0_8_0_beta2

> BLE Host - HCI callback thread-safety
> -
>
> Key: MYNEWT-64
> URL: https://issues.apache.org/jira/browse/MYNEWT-64
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>
> When the host schedules an outgoing HCI command, it configures a callback 
> which does the actual command formation.  Some events can occur before the 
> callback is executed which render the callback invalid (e.g., connection 
> terminated).
> The fix is to ensure the appropriate resources are protected from deletion 
> while an HCI command is scheduled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-66) BLE Host - Random Addresses

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-66:
--
Fix Version/s: v0_8_0_beta2

> BLE Host - Random Addresses
> ---
>
> Key: MYNEWT-66
> URL: https://issues.apache.org/jira/browse/MYNEWT-66
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-60) BLE Host - Security Manager - Encryption

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-60:
--
Fix Version/s: v0_9_0_beta1

> BLE Host - Security Manager - Encryption
> 
>
> Key: MYNEWT-60
> URL: https://issues.apache.org/jira/browse/MYNEWT-60
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_9_0_beta1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-75) NFFS - Perform garbage collection when hash entry pool or data block pool exhausted

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-75:
--
Fix Version/s: v0_8_0_beta2

> NFFS - Perform garbage collection when hash entry pool or data block pool 
> exhausted
> ---
>
> Key: MYNEWT-75
> URL: https://issues.apache.org/jira/browse/MYNEWT-75
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v0_8_0_beta2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-60) BLE Host - Security Manager - Encryption

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-60:
--
Summary: BLE Host - Security Manager - Encryption  (was: Security Manager - 
Encryption)

> BLE Host - Security Manager - Encryption
> 
>
> Key: MYNEWT-60
> URL: https://issues.apache.org/jira/browse/MYNEWT-60
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-61) Security Manager - Just Works

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-61:
-

 Summary: Security Manager - Just Works
 Key: MYNEWT-61
 URL: https://issues.apache.org/jira/browse/MYNEWT-61
 Project: Mynewt
  Issue Type: New Feature
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Go include path / Git Include Path

[Christopher Collins]

The only way I could get "go get" to work with newt is by using the
".git" path.  I changed all of the newt's include paths to the current
form to allow for simpler installation instructions.

Chris

On Tue, Jan 19, 2016 at 10:07:24AM -0800, Sterling Hughes wrote:
> Howdy,
> 
> Right now there is a conflict in how newtmgr & newt include libraries using 
> go.
> 
> Newtmgr uses:
> 
> git-wip-us.apache.org/repos/asf/incubator-mynewt-newt/newtmgr
> 
> Whereas Newt uses:
> 
> git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
> 
> In order for both of these packages to compile, we're going to need to
> choose one layout and stick with it.  Personally, I'm fine with either
> -- I think newtmgr's makes more sense, but if there is a good reason
> for sticking with Newt's pathes, and I'm ok with that as well.
> 
> Thoughts?
> 
> Sterling

Re: Mynewt Windows port

[Christopher Collins]

Oops, I meant to put the appropriate URLs in those empty parenthesis.
Here they are:

Docker hub: https://hub.docker.com/
golang docker image: https://github.com/docker-library/golang

Chris

On Wed, Dec 02, 2015 at 10:29:17AM -0800, Christopher Collins wrote:
> On Wed, Dec 02, 2015 at 08:41:45PM +1100, Justin Mclean wrote:
> > Hi,
> > 
> > Out of interest where is the mynewt docker instance hosted and what
> > does it contain?  I’m asking to make sure it couldn’t be considered an
> > Apache release.
> 
> Hi Justin,
> 
> That is a good question.  The docker image is hosted on docker hub ()
> 
> The image is based off of the golang 1.5 docker image ().  In addition,
> it pulls in the following debian packages:
> * gcc-multilib (for building 32-bit sim binaries)
> * libc6-i386 (also for sim binaries)
> * libnewlib-arm-none-eabi (for cross-compiling to arm)
> * gcc-arm-none-eabi (for cross-compiling to arm)
> 
> Below is the Dockerfile that was used to create the image.  Hopefully
> none of this runs afoul of any Apache or licensing concerns!
> 
> Thanks,
> Chris
> 
> 
> -
> 
> 
> # (Dockerfile)
> 
> FROM golang:1.5
> 
> # jessie-backports required for newlib.
> RUN echo 'deb http://httpredir.debian.org/debian jessie-backports main'
> > /etc/apt/sources.list.d/backports.list && \
> apt-get update && apt-get install -y --no-install-recommends \
> gcc-multilib \
> libc6-i386 \
> libnewlib-arm-none-eabi \
> gcc-arm-none-eabi && \
> rm -rf /var/lib/apt/lists/*
> 
> RUN go get
> git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
>