Re: Master newt does not build released software
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
On 4/2/16 1:03 PM, Christopher Collins wrote: FYI- I have updated the arduino repo with a fix for this issue. Summary of changes: * cherry-pick Marko's fix for newt 0.8.0-b2 from develop to master (commit=9c8a5806ceebc4f30432ab6dcc647cf6f4bfbce4). * Create a tag on the arduino master branch: mynewt_arduino_zero_0_0_0_tag * Update the arduino repository.yml file to point 0.0.0 to the above tag. With these changes, I can build the boot loader and blinky for the arduino zero pro from a new mynewt project. As I mentioned in an earlier email, I was not able to test the generated code on real hardware. However, the above changes are obviously an improvement over the previous state of affairs, so I went ahead and pushed the changes. Thanks chris. I tested it on real hardware, everything is working now. As a general admonition (I don't think Chris broke this :-) It doesn't matter who did tho: 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. We will be adding automated regression on real hardware in the next week or two - nonetheless, lack of this should not be an excuse for breaking the release on what is likely our most popular platform. Sterling
Re: Master newt does not build released software
FYI- I have updated the arduino repo with a fix for this issue. Summary of changes: * cherry-pick Marko's fix for newt 0.8.0-b2 from develop to master (commit=9c8a5806ceebc4f30432ab6dcc647cf6f4bfbce4). * Create a tag on the arduino master branch: mynewt_arduino_zero_0_0_0_tag * Update the arduino repository.yml file to point 0.0.0 to the above tag. With these changes, I can build the boot loader and blinky for the arduino zero pro from a new mynewt project. As I mentioned in an earlier email, I was not able to test the generated code on real hardware. However, the above changes are obviously an improvement over the previous state of affairs, so I went ahead and pushed the changes. Chris On Sat, Apr 02, 2016 at 12:37:34PM -0700, Christopher Collins wrote: > 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
Re: Master newt does not build released software
Hey, On 4/2/16 12:37 PM, Christopher Collins wrote: 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. Yes, I was bitten by this the other day. Which is why I created a tag to switch to 0-dev. 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. I'll test once you make the fix. If you can get it to compile, I'll make sure it loads on the board. Sterling
Re: Master newt does not build released software
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
Master newt does not build released software
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