| Summary: | Log all real SRCREVs, including deferencing AUTOREVs | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jerrod Peach <peachj> |
| Component: | core | Assignee: | Paul Eggleton <bluelightning> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | andreea.b.proca, bluelightning, meta.mr.watcher, meta.watcher, richard.purdie, sgw |
| Version: | unspecified | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | Additional patch posted for review | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
Does bitbake -s do what you want? Nope, bitbake -s appears to print out PV, and only in some cases does PV actually contain the real SRCREV. I need something that will always retrieve the correct and real revision when a suitable VCS is used, no matter what the user has opted to do. FWIW I agree we need to fix this and I understand the problem. In 1) the information is actually in the persist database (tmp/cache/bb_persist_data.sqlite3) and not in the main cache. I don't have an immediate solution and am travelling at the moment but I will give this some thought. Patch merged (commit d4e470322658af75db276ecbe8d906949541c872) Cheers, Constantin Upon closer review I think we can improve the output formatting to be a bit more consistent with the rest of buildhistory; additionally the current implementation does not work for native packages. I'm working on a patch to address these issues. Patch has been merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9a3fbf92c4af93cdb66d515c3cd3e64610fbee4a Verified. |
I'm wanting to implement Yocto to build Linux distros for my company, but I've got two problems. 1) Builds using AUTOREV are difficult to reproduce. That's because the revision used for AUTOREV isn't stored in an easily-accessible place. More specifically, it's in the parse cache database, but only if you don't get a sstate cache hit when building a package using AUTOREV. If you do, I don't think the real revision shows up anywhere after the build. This point actually isn't that big of a deal, because builds that need reproducing shouldn't use AUTOREV, but I do want to be able to deal with it should that need arise. 2) It's hard to tell exactly what changed between builds when you're using AUTOREV. This is a bigger deal, because I imagine most of our developers are going to need to tell what changed between builds to know what broke a build after the fact. What broke them will have likely changed under cover of AUTOREV, as most work will probably go on in branches where AUTOREV is being used for actively worked-upon units. So, I'd like a way to easily log all real SRCREVs, including dereferincing AUTOREVs, to fix my problems. I was going to implement a task that would create a file of this format for each package: ${BBFILE} ${SRC_URI} ${SRCREV} ["AUTOREV" if revision came from AUTOREV] That file was going to be named after the package itself, and would ultimately wind up under tmp/srcrev after an install by the sstate mechanisms. But, I was thwarted in this effort by Bug 3039. Could this type of feature be added, even if it's not exactly in this fashion?