Commit c725bdb29b2669e53ea0f9d30f9683f094c9b326 (and 195b61756bae2d0066b411eea9e14da9de3992a9 on the kirkstone branch) tries to fix packaging of debugsrc for recipes that are using externalsrc. Unfortunately the current code does not work for recipes where S == B. In this case the source files will be copied directy to /usr/src/debug, which will work until there is a file name collision. For instance two recipes with a file ${S}/main.c using externalsrc at the same time. I did a workaround by replacing checkbuildpath with def checkbuildpath(file, d): tmpdir = d.getVar('S') # <= Instead of TMPDIR with open(file) as f: file_content = f.read() if tmpdir in file_content: return True return False It's possible that this change or similar would also solve the original problem [YOCTO #8015], but I have not tested that. I tried to find any tests for packaging of debugsrc but had no luck.
This bug is not on current master. I tried to update the Version and Target Milestone fields to reflect this, I hope I did not get it wrong.
Hello, Can you please share reproducer for this bug? I've tried to create two recipes with main.c (simple hello world application) and externalsrc. Both recipes can be bitbake'd and installed and S == B. Here is testcase I'm using: def test_externalsrc_s_equal_b(self): test_recipes = ["test-externalsrc1", "test-externalsrc2"] config = 'INHERIT += "externalsrc"\n' tmpdir = tempfile.mkdtemp(prefix='tmpextsrc') with open("{}/main.c".format(tmpdir), 'x') as main: main.write(""" #include <stdio.h> int main(){ printf("Hello world!"); return 0; }; """) for test_recipe in test_recipes: config += 'EXTERNALSRC:pn-{} = "{}"\n'.format(test_recipe, tmpdir) config += 'EXTERNALSRC_BUILD:pn-{} = "{}"\n'.format(test_recipe, tmpdir) self.write_config(config) for test_recipe in test_recipes: v = get_bb_vars(['S','B'], test_recipe) s = v['S'] b = v['B'] self.assertTrue(s == b, "$S != $B : {} != {}".format(s,b)) res = bitbake("{}".format(" ".join(test_recipes))).status self.assertEqual(0, res, "Failed to build two packages with externalsrc, possible regression Yocto [#14907]")
I think this was fixed on master by Richards rewrite of package.bbclass in Poky commit 1d6c7af0e35811e66a0b3cd3dcc7e3d15b54f99a. The bug is probably still on kirkstone. I tried to update the issue in october of 2022 to reflect that, but I'm not sure I got it right.
(In reply to Ola Nilsson from comment #3) > I think this was fixed on master by Richards rewrite of package.bbclass in > Poky commit 1d6c7af0e35811e66a0b3cd3dcc7e3d15b54f99a. > > The bug is probably still on kirkstone. > > I tried to update the issue in october of 2022 to reflect that, but I'm not > sure I got it right. This was clear, thank you. But the problem is I could not reproduce with kirkstone commit 195b61756bae2d0066b411eea9e14da9de3992a9 you have mentioned in the description.
You wont see any error unless you install both src-packages in the same image, like when building a debugfs. Check the paths in .../packages-split/PN-src and you should find usr/src/debug/main.c in both. A better thing to test is that no source files are installed directly into usr/src/debug. They should all be in usr/src/debug/PN.
I verified that this is still broken on 1d6c7af0e35811e66a0b3cd3dcc7e3d15b54f99a using some small recipes.
Pavel, Bumping to 4.0.21. Do you expect (hope!) to have time to work on YP bug in the coming weeks and months? ../Randy
move to unassigned. feel free to take back if you have time.
It's been almost three years and there has been no progress on fixing this. Closing bug as it is unlikely to get any further attention.