| Summary: | Installing conflicting files in RSS results in an exception | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Peter Kjellerstedt <peter.kjellerstedt> | ||||
| Component: | core | Assignee: | Richard Purdie <richard.purdie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | meta.mr.watcher, meta.watcher | ||||
| Version: | 2.3.2 | ||||||
| Target Milestone: | 4.99 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| See Also: | https://bugzilla.yoctoproject.org/show_bug.cgi?id=13702 | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
This should be fixed in master. Can you try picking oe-core 2ebbeb61114e4b847e9164c621ac87b5cf03a299 and seeing if it helps for you? Unfortunately, it does not. The change in 2ebbeb61 solved the case where (using my example recipes) foobar depends on both foo and bar, which both provide "/usr/include/foobar.h". However, my case is that the dependency in foobar changes from foo to bar (which I now realized may not have been obvious from my description as it was only implied from the suggested steps to reproduce the problem). And this problem still remains on master as well. Try also picking add4f107c151d32d9ea914bb0b93c3d3c17c776c? The commit add4f107 has already been cherry-picked to the pyro branch. And as I said, the problem exists on master as well. I can't replicate the problem you're seeing with master and your test recipes. Can you replicate with current master (at time of writing same as rocko)? Peter, can you replicate with current master? Sorry for not responding earlier. I tried it again just now with the current Poky master, and it still happens exactly as described. The key to recreating the problem is step 3 in the steps to reproduce as it changes the dependency from one recipe to another where both installs the same file. The error conditions may seem constructed at first, but this is actually something that can easily happen when changing the preferred provider of a recipe from one provider to another. Managed to replicate this with current master.
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/home/ross/Yocto/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot
0547: dest = newmanifest[l]
0548: if l.endswith("/"):
0549: staging_copydir(l, targetdir, dest, seendirs)
0550: continue
*** 0551: staging_copyfile(l, targetdir, dest, postinsts, seendirs)
0552:
0553: bb.note("Installed into sysroot: %s" % str(msg_adding))
0554: bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
0555:
File: '/home/ross/Yocto/poky/meta/classes/staging.bbclass', lineno: 152, function: staging_copyfile
0148: os.symlink(linkto, dest)
0149: #bb.warn(c)
0150: else:
0151: try:
*** 0152: os.link(c, dest)
0153: except OSError as err:
0154: if err.errno == errno.EXDEV:
0155: bb.utils.copyfile(c, dest)
0156: else:
Exception: FileExistsError: [Errno 17] File exists: '/data/poky-tmp/master/sysroots-components/corei7-64/libx11/usr/include/X11/extensions/XKBgeom.h' -> '/data/poky-tmp/master/work/corei7-64-poky-linux/gnome-desktop-testing/2018.1-r0/recipe-sysroot/usr/include/X11/extensions/XKBgeom.h'
Building shared-mime-info. XKBgeom.h just moved from xorgproto to libx11, and the sysroot wasn't cleaned enough to handle this.
Wasn't there a fix for this merged recently? (assigning to RP as master of staging) I've confirmed that with master now with the sysroot cleanup code, there was a fix added which does fix this test case. |
Created attachment 4049 [details] Test recipes With Morty and earlier, if two packages tried to install the same file in the sysroot, it would result in a long error message explaining what was going on and basically recommending to remove tmp unless one knows what to do. However, with Pyro and later this situation instead results in the following exception in staging.bbclass: ERROR: foobar-1.0-r0 do_prepare_recipe_sysroot: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: <module> 0001: *** 0002:extend_recipe_sysroot(d) 0003: File: 'meta/classes/staging.bbclass', lineno: 628, function: extend_recipe_sysroot 0624: dest = newmanifest[l] 0625: if l.endswith("/"): 0626: staging_copydir(l, targetdir, dest, seendirs) 0627: continue *** 0628: staging_copyfile(l, targetdir, dest, postinsts, seendirs) 0629: 0630: for f in fixme: 0631: if f == '': 0632: staging_processfixme(fixme[f], recipesysroot, recipesysroot, recipesysrootnative, d) File: 'meta/classes/staging.bbclass', lineno: 233, function: staging_copyfile 0229: os.symlink(linkto, dest) 0230: #bb.warn(c) 0231: else: 0232: try: *** 0233: os.link(c, dest) 0234: except OSError as err: 0235: if err.errno == errno.EXDEV: 0236: bb.utils.copyfile(c, dest) 0237: else: Exception: FileExistsError: [Errno 17] File exists: 'tmp/sysroots-components/mips32r2el-nf/bar/usr/include/foobar/foobar.h' -> 'tmp/work/mips32r2el-nf-poky-linux/foobar/1.0-r0/recipe-sysroot/usr/include/foobar/foobar.h' How to reproduce: 1) Install the recipes from the attached tar ball in any layer. 2) Run "bitbake foobar". 3) Modify recipes-devtools/foobar/foobar.bb and change the build dependency from "foo" to "bar". 4) Run "bitbake foobar" again.