14907 2022-09-01 11:34:26 +0000 packaging debugsrc breaks for recipes with externalsrc and debug-with-srcpkg 2025-07-16 13:32:05 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other 4.0.11 x86 Multiple RESOLVED WONTFIX Medium+ normal 4.0.28 1 ola.x.nilsson unassigned ola.x.nilsson pavel peter.kjellerstedt randy.macleod steve --- --- No (bug/feature does not impact docs) oldest_to_newest 93948 0 ola.x.nilsson 2022-09-01 11:34:26 +0000 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. 94206 1 ola.x.nilsson 2022-10-20 11:42:36 +0000 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. 96661 2 pavel 2023-10-07 21:55:11 +0000 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]") 96662 3 ola.x.nilsson 2023-10-09 06:48:02 +0000 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. 96691 4 pavel 2023-10-12 14:52:38 +0000 (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. 96700 5 ola.x.nilsson 2023-10-13 11:07:05 +0000 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. 96701 6 ola.x.nilsson 2023-10-13 11:08:28 +0000 I verified that this is still broken on 1d6c7af0e35811e66a0b3cd3dcc7e3d15b54f99a using some small recipes. 99532 7 randy.macleod 2024-08-08 18:26:55 +0000 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 100074 8 randy.macleod 2024-10-31 15:06:39 +0000 move to unassigned. feel free to take back if you have time. 102469 9 steve 2025-07-16 13:32:05 +0000 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.