is problem and have a solution ?
The only thing I could do now is to put the licenses in
"${DEPLOY_DIR}/licenses/${PACKAGE_ARCH}"
And change the code in license_image to check subdirectories in
${DEPLOY_DIR}/licenses in order to retrieve the
---
.../networkmanager/networkmanager_1.18.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.18.4.bb
b/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.18.4.bb
inde
On 06.10.19 19:32, akuster808 wrote:
>
> On 10/4/19 12:47 AM, Alexandre Bard wrote:
>> When systemd is built without internal resolver, it does not make
>> sense to expose it as a resolv-conf alternative and can even break
>> images where this alternative would
When systemd is built without internal resolver, it does not make
sense to expose it as a resolv-conf alternative and can even break
images where this alternative would be chosen, because of an
invalid symlink.
Signed-off-by: Alexandre Bard
---
meta/recipes-core/systemd/systemd_237.bb | 1 +
1
When systemd is built without internal resolver, it does not make
sense to expose it as a resolv-conf alternative and can even break
images where this alternative would be chosen, because of an
invalid symlink.
Signed-off-by: Alexandre Bard
---
meta/recipes-core/systemd/systemd_239.bb | 2 +-
1
When systemd is built without internal resolver, it does not make
sense to expose it as a resolv-conf alternative and can even break
images where this alternative would be chosen, because of an
invalid symlink.
Signed-off-by: Alexandre Bard
---
meta/recipes-core/systemd/systemd_241.bb | 2 +-
1
When systemd is built without internal resolver, it does not make
sense to expose it as a resolv-conf alternative and can even break
images where this alternative would be chosen, because of an
invalid symlink.
Signed-off-by: Alexandre Bard
---
meta/recipes-core/systemd/systemd_243.bb | 2 +-
1
