Bug 13700 - archiver not creating tarballs for some recipes
Summary: archiver not creating tarballs for some recipes
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 3.0
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 3.2 M1
Assignee: Paul Barker
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-12-11 00:20 UTC by Jonathan Richardson
Modified: 2020-04-10 00:01 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
conf file (11.81 KB, application/octet-stream)
2019-12-11 00:20 UTC, Jonathan Richardson 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Richardson 2019-12-11 00:20:20 UTC 
Created attachment 4600 [details]
conf file

For some recipes, do_ar_original task is never run when inheriting archiver. Eg, this one:

libibverbs_1.2.0.bb:
LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"
SRC_URI = "https://www.openfabrics.org/downloads/verbs/libibverbs-${PV}.tar.gz"
SRC_URI[md5sum] = "208df0056ce9ae81b668c2d2d0cf2ec7"
DEPENDS = "libnl"
inherit pkgconfig autotools

This used to work fine. In task order log I see the output below after running bitbake libibverbs. I excluded all our layers and put the recipe in meta, set MACHINE = "genericx86-64". This is what I get. If I force it with -c ar_original it runs the task but still doesn't create the tarball.

do_deploy_archives (118676): log.do_deploy_archives.118676
do_fetch (118724): log.do_fetch.118724
do_unpack (118762): log.do_unpack.118762
do_patch (119735): log.do_patch.119735
do_populate_lic (119800): log.do_populate_lic.119800
do_prepare_recipe_sysroot (71924): log.do_prepare_recipe_sysroot.71924
do_configure (71933): log.do_configure.71933
do_compile (75627): log.do_compile.75627
do_install (76542): log.do_install.76542
do_package (76821): log.do_package.76821
do_populate_sysroot (76822): log.do_populate_sysroot.76822
do_packagedata (77076): log.do_packagedata.77076
do_package_write_rpm (77108): log.do_package_write_rpm.77108
do_package_qa (77109): log.do_package_qa.77109

My local.conf is attached.
Comment 1 Jonathan Richardson 2019-12-11 00:52:37 UTC 
One thing missing from my conf file, but makes no difference.
ARCHIVER_MODE[src] = "original"
Comment 2 Jonathan Richardson 2019-12-11 21:35:06 UTC 
I found the commit below actually fixed a problem where COPYLEFT_LICENSE_EXCLUDE was set to empty previously instead of the intended default values. So with the default values in, our BSD license types were being filtered. With COPYLEFT_LICENSE_INCLUDE set to null, it actually includes everything instead of including nothing.
Comment 3 Jonathan Richardson 2019-12-11 21:35:59 UTC 
commit b68c73127e2d2284a29479c0ebada32fedcb1645 (refs/bisect/bad)
Author: Adrian Bunk <bunk@stusta.de>
Date:   Sun Nov 25 20:54:03 2018 +0200

    archiver.bbclass: Fix COPYLEFT_LICENSE_{IN, EX}CLUDE
    
    Setting them to empty before inheriting copyleft_filter
    made them not getting their documented values there.
Comment 4 Ross Burton 2020-01-29 17:14:01 UTC 
Assigning to Paul as he actually knows the archiver.
Comment 5 Paul Barker 2020-04-09 11:37:14 UTC 
Is this still an issue? Looks like the archiver is behaving as expected and respecting COPYLEFT_LICENSE_INCLUDE.
Comment 6 Jonathan Richardson 2020-04-09 17:15:57 UTC 
This one can be closed. It was a behaviour change due to the bug fix described. Thanks.
Comment 7 Paul Barker 2020-04-10 00:01:43 UTC 
Closing this based on comments above.