| Summary: | compatibility with rm_work.bbclass | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Other YP Layers | Reporter: | Patrick Ohly <patrick.ohly> | ||||
| Component: | meta-swupd | Assignee: | Aaron Zinghini <aaron.zinghini> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | aaron.zinghini, sgw | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.3 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Bug Depends on: | 10584 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Patrick Ohly
2016-12-13 08:32:54 UTC
Created attachment 3631 [details]
swupd-image.bbclass stacktrace
This change appears to break things for me. I believe the problem is a missing expand arg in the "workdir = d.getVar('WORKDIR')" statement.
Actually this appears to be because I am not using the master branch of poky and that the default for getVars has changed. This leads me to the question of whether there will be a stable Morty branch of meta-swupd anytime soon? (In reply to comment #3) > Actually this appears to be because I am not using the master branch of poky > and that the default for getVars has changed. This leads me to the question > of whether there will be a stable Morty branch of meta-swupd anytime soon? I've taken over maintenance of the layer for now, but it is unclear whether that will continue, and targeting older releases wasn't part of that (tentative) plan either. I see two possible outcomes: 1. We have some interest in using swupd and resources to support it. Then proper testing needs to be set up, including older releases, and Morty will be supported. 2. There's not enough interest to justify the work. Then some of those still interested will need to step up and take over maintenance. Regarding this particular problem, is it enough to add "True" to the d.getVar() call? If that works for you, can you submit a patch? That can go into the master branch and then we can avoid forking for a while longer. Sad to hear there isn't much interest in this layer. The commercial project I work on is looking at using this so it would seem I will be helping to keep this alive. I think adding the explicit "True" would suffice for now. I'm pretty new to contributing to open-source projects and git. Do you have any info/guidelines I can use to get setup so I can submit patches? (In reply to comment #5) > Sad to hear there isn't much interest in this layer. There is interest, it's just unclear whether there's an intersection between those willing to use it and those willing to maintain it ;-/ > The commercial project > I work on is looking at using this so it would seem I will be helping to > keep this alive. Out of curiosity, which features of swupd made you choose it over the competing solutions? See also https://wiki.yoctoproject.org/wiki/System_Update > I think adding the explicit "True" would suffice for now. I'm pretty new to > contributing to open-source projects and git. Do you have any > info/guidelines I can use to get setup so I can submit patches? "git clone git://git.yoctoproject.org/meta-swupd", then make the change, test it, commit it with a commit message according to http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines, subscribe to openembedded-devel@lists.openembedded.org (see http://www.openembedded.org/wiki/Mailing_lists) then send with "git send-email --to=openembedded-devel@lists.openembedded.org '--subject-prefix=meta-swupd][PATCH' HEAD~..HEAD". Then it ends up getting reviewed and merged. The main reason for preferring swupd is for the fast minimal updates and moving away from our current approach which requires full system imaging to get OS updates. A lot of the competing projects also require U-boot, which is not an option for our HW. I will follow the guidelines you mentioned and submit the patch today. (In reply to comment #7) > The main reason for preferring swupd is for the fast minimal updates and > moving away from our current approach which requires full system imaging to > get OS updates. Agreed, file-based approaches have an advantage there. Do you do live updates (including swapping out files which may be currently in use), followed by an obligatory reboot, or do you selectively restart daemons that use old files? > A lot of the competing projects also require U-boot, which > is not an option for our HW. Is your hardware booting with UEFI? > I will follow the guidelines you mentioned and submit the patch today. Thanks! The way we would use swupd would be to check for updates on boot, apply, then reboot. Yes HW is booting with UEFI. Patch has been upstreamed. |