If a file to be packaged contains a wildcard (e.g. *) in its name, there is another file which would match the expression that the wildcarded filename produces, and that wildcarded filename ends up in a FILES_ variable (e.g. when do_split_packages() is used) then populate_packages() can end up looping forever. Obviously the use of wildcards in actual filenames is extremely ill-advised, however I came across this problem when trying to write a recipe for Webmin (the issue being with the file logrotate/config-*-linux which also matches logrotate/config-open-linux) so there are packages out there in the wild that unfortunately have this issue. An obvious workaround would be to just rename the file to something more sensible, however there's no guarantee that more of these files won't be added in later versions, and stalling forever is not really a good failure mode.
I have a tentative fix for this but it's too risky to slip into 1.2, especially given how uncommon this issue will be. Moving to 1.3.
Is the fix available? It has already slipped from 1.2 -> 1.3 -> 1.4 now -> 1.5!
You're right, this has slipped; I am now testing a much more straightforward fix and should be able to send it soon.
Patch sent for review, but I don't expect it to go into 1.5.
Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=567754acb80e5d1c6cabdb1dae1ea4fbea80e52a
Paul, I could not reproduce this behavior. Used * in name for webmin file that should match logrotate files but nothing happened. The same behavior before and after patch merge to master branch. Could you please give me a hint on this matter.
What exactly did you do to test this?
Just added a new config-*-linux file to sources and pointed the new location of the tar.gz in the webmin recipe. Then bitbake webmin and logrotate. I guess i'm missing a step or something...
Probably an easier test would be to just disable the workarounds in the webmin recipe for the problem and see if do_package completes.
Switching to verified. Commit ID: 6ee5d95317de77c1cfb6db6f1ab2de77f5fa085e @Paul: commenting the workaround reproduced the loop.