Bug 10799 - compatibility with rm_work.bbclass
Summary: compatibility with rm_work.bbclass
Status: RESOLVED FIXED
Alias: None
Product: Other YP Layers
Classification: Build System, Metadata & Runtime
Component: meta-swupd (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.3
Assignee: Aaron Zinghini
QA Contact:
URL:
Whiteboard:
Depends on: 10584
Blocks:
  Show dependency tree
 
Reported: 2016-12-13 08:32 UTC by Patrick Ohly
Modified: 2017-02-24 22:17 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
swupd-image.bbclass stacktrace (898 bytes, text/plain)
2017-02-10 19:39 UTC, Aaron Zinghini
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Ohly 2016-12-13 08:32:54 UTC
Build breaks with meta-swupd fail when rm_work.bbclass is used because meta-swupd accesses content from other recipes which might have been removed already by do_rm_work.

I have patches ready, but they depend on enhancing do_rm_work. I intend to submit together with bug #10584.
Comment 1 Aaron Zinghini 2017-02-10 19:39:47 UTC
Created attachment 3631 [details]
swupd-image.bbclass stacktrace
Comment 2 Aaron Zinghini 2017-02-10 19:41:22 UTC
This change appears to break things for me. I believe the problem is a missing expand arg in the "workdir = d.getVar('WORKDIR')" statement.
Comment 3 Aaron Zinghini 2017-02-10 19:47:08 UTC
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?
Comment 4 Patrick Ohly 2017-02-13 08:48:15 UTC
(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.
Comment 5 Aaron Zinghini 2017-02-13 17:13:26 UTC
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?
Comment 6 Patrick Ohly 2017-02-13 17:33:12 UTC
(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.
Comment 7 Aaron Zinghini 2017-02-13 17:47:01 UTC
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.
Comment 8 Patrick Ohly 2017-02-13 18:56:03 UTC
(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!
Comment 9 Aaron Zinghini 2017-02-13 21:35:34 UTC
The way we would use swupd would be to check for updates on boot, apply, then reboot. Yes HW is booting with UEFI.
Comment 10 Aaron Zinghini 2017-02-24 21:45:52 UTC
Patch has been upstreamed.