Re: [yocto] EXTRA_USERS_PARAMS doesn't work to generate password for root and add new users

[Mauro]

On 22/08/23 03:58, Crane wrote:

Hello,

I am trying to generate a password for root and add a new user. Here is 
the code in the image recipe:


IMAGE_FEATURES:remove = "debug-tweaks"
INHERIT += "extrausers"
EXTRA_USERS_PARAMS += "usermod -P root root; useradd -P 2023 crane"

When using "inherit extrausers", there is an error of "usermod command 
did not succeed."


When checking the parameter, the result is:
EXTRA_USERS_PARAMS=" usermod -P root root; useradd -P 2023 crane; "

The image does requires a password for root, but doesn't generate 
anything in /etc/shadow and doesn't add new user in /etc/shadow as well.


I am wondering what might be missing. Can anyone give me any clue?

Thanks!
Crane




Hi,

the error could be related to the -P option in useradd command: the 
option, that allows to pass a cleartext password to the command, is not 
present anymore in recent useradd versions.


Instead you can use the -p option, that allows to pass an encrypted 
password.

Something like that:

EXTRA_USERS_PARAMS=" usermod -p `openssl passwd -6 root` root; useradd 
-P 2023 crane; "


Regards
--
Mauro Salvini | KOAN sas | Bergamo - Italia
embedded software engineering
http://KoanSoftware.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60847): https://lists.yoctoproject.org/g/yocto/message/60847
Mute This Topic: https://lists.yoctoproject.org/mt/100887124/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] EXTRA_USERS_PARAMS doesn't work to generate password for root and add new users

[Crane]

Hello,

I am trying to generate a password for root and add a new user. Here is the 
code in the image recipe:

IMAGE_FEATURES:remove = "debug-tweaks"
INHERIT += "extrausers"
EXTRA_USERS_PARAMS += "usermod -P root root; useradd -P 2023 crane"

When using "inherit extrausers", there is an error of "usermod command did not 
succeed."

When checking the parameter, the result is:
EXTRA_USERS_PARAMS=" usermod -P root root; useradd -P 2023 crane; "

The image does requires a password for root, but doesn't generate anything in 
/etc/shadow and doesn't add new user in /etc/shadow as well.

I am wondering what might be missing. Can anyone give me any clue?

Thanks!
Crane

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60846): https://lists.yoctoproject.org/g/yocto/message/60846
Mute This Topic: https://lists.yoctoproject.org/mt/100887124/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] M+ & H bugs with Milestone Movements WW33

[Stephen Jolley]

All,

YP M+ or high bugs which moved to a new milestone in WW33 are listed below:
Priority Bug ID Short Description Changer Owner Was Became
Medium+ 15194  AB-INT:
python3-numpy is not reproducible randy.macl...@windriver.com
tgamb...@baylibre.com 0.0.0 4.3 M3

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60845): https://lists.yoctoproject.org/g/yocto/message/60845
Mute This Topic: https://lists.yoctoproject.org/mt/100885749/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW33!

[Stephen Jolley]

All,

The below were the owners of enhancements or bugs closed during the last
week!
Who Count
richard.pur...@linuxfoundation.org 1
randy.macl...@windriver.com 1
frederic.martins...@gmail.com 1
Grand Total 3

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60844): https://lists.yoctoproject.org/g/yocto/message/60844
Mute This Topic: https://lists.yoctoproject.org/mt/100885736/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 4.3

[Stephen Jolley]

All,

Below is the list of top 28 bug owners as of the end of WW33 who have open
medium or higher bugs and enhancements against YP 4.3. There are 47
possible work days left until the final release candidates for YP 4.3 needs
to be released.
Who Count
michael.opdenac...@bootlin.com 34
ross.bur...@arm.com 33
richard.pur...@linuxfoundation.org 26
randy.macl...@windriver.com 23
david.re...@windriver.com 23
bruce.ashfi...@gmail.com 22
jpewhac...@gmail.com 11
pa...@zhukoff.net 6
sakib.sa...@windriver.com 5
pi...@pidge.org 5
yash.shi...@windriver.com 4
tim.orl...@konsulko.com 3
alexis.loth...@bootlin.com 3
sundeep.kokko...@windriver.com 2
jon.ma...@arm.com 2
alexandre.bell...@bootlin.com 2
yoann.con...@smile.fr 1
tvgamb...@gmail.com 1
thr...@amazon.de 1
thomas.per...@bootlin.com 1
pokyli...@reliableembeddedsystems.com 1
p.lob...@welotec.com 1
martin.ja...@gmail.com 1
mark.asselst...@windriver.com 1
louis.ran...@syslinbit.com 1
jens.ge...@desy.de 1
fathi.bou...@linaro.org 1
alejan...@enedino.org 1
Grand Total 216

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60843): https://lists.yoctoproject.org/g/yocto/message/60843
Mute This Topic: https://lists.yoctoproject.org/mt/100885693/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:
https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 421
unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “4.3”, “4.4”, "4.99" and "Future", the more
pressing/urgent issues being in "4.3" and then “4.4”.

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs


Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60842): https://lists.yoctoproject.org/g/yocto/message/60842
Mute This Topic: https://lists.yoctoproject.org/mt/100885669/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SDK build generally broken?

[Richard Purdie]

On Mon, 2023-08-21 at 12:49 +, David Daniel wrote:
> Hello everybody
> 
> Has anyone successfully built an SDK lately? I cannot build any SDK,
> neither for my image nor for core-image-minimal.
> 
> If I define my own image I get the error (I already wrote - nobody any
> idea?) that the dummy-sdk package is to be built for a different
> architecture:
> 
> 
> x86_64_nativesdk   3.1.2-r0oe-repo  330 k
>  nativesdk-openssl-conf x86_64_nativesdk   3.1.2-r0   
>  oe-repo   12 k
>  target-sdk-provides-dummy  sdk_provides_dummy_target  1.0-r0 
>  oe-repo  9.0 k
> 
> THIS ERROR ONLY APPEARS IF I DEFINE MY OWN IMAGE (though the image can be 
> built and works).
> 
> I guess this is due to the following code in the sdk-dummy recipe:
> 
> python() {
> # Put the package somewhere separate to ensure it's never used except
> # when we want it
> # (note that we have to do this in anonymous python here to avoid
> # allarch.bbclass disabling itself)
> d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
> }
> 
> But furthermore, I am completely unable to build the SDK with my
> machine - I took the machine from the working image sources I am
> working with and took a plain master poky checkout (bleeding master).
> When I want to build the SDK for the core-image-minimal I get the
> following error:
> 
> ERROR: m4-native-1.4.19-r0 do_collect_spdx_deps: Error executing a python 
> function in exec_func_python() autogenerated:
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_collect_spdx_deps(d)
>  0003:
> File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
> lineno: 494, function: do_collect_spdx_deps
>  0490:from pathlib import Path
>  0491:
>  0492:spdx_deps_file = Path(d.getVar("SPDXDEPS"))
>  0493:
>  *** 0494:deps = collect_direct_deps(d, "do_create_spdx")
>  0495:
>  0496:with spdx_deps_file.open("w") as f:
>  0497:json.dump(deps, f)
>  0498:}
> File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
> lineno: 475, function: collect_direct_deps
>  0471:deps = set()
>  0472:for dep_name in this_dep[3]:
>  0473:dep_data = taskdepdata[dep_name]
>  0474:if dep_data[1] == dep_task and dep_data[0] != pn:
>  *** 0475:deps.add((dep_data[0], dep_data[7]))
>  0476:
>  0477:return sorted(deps)
>  0478:
>  0479:collect_direct_deps[vardepsexclude] += "BB_TASKDEPDATA"
> Exception: IndexError: list index out of range
> 
> ERROR: Logfile of failure stored in: 
> /mnt/data/yocto/bf133/sdk/build/tmp/work/x86_64-linux/m4-native/1.4.19/temp/log.do_collect_spdx_deps.731506
> ERROR: Task 
> (/home/david/yocto/bf133/poky/meta/recipes-devtools/m4/m4-native_1.4.19.bb:do_collect_spdx_deps)
>  failed with exit code '1'
> 
> Is the generation of an SDK outdated, not recommended, not maintained
> anymore? Or do you have any recommendations to troubleshoot these
> issues?

SDK builds are tested on the autobuilder so it does work, at least
there.

Are you using the right version of bitbake with that metadata? That
index issue looks a bit to me like it is the wrong version of bitbake.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60841): https://lists.yoctoproject.org/g/yocto/message/60841
Mute This Topic: https://lists.yoctoproject.org/mt/100872021/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Poky/Mickledore bitbake menuconfig does not work

[Sebert, Holger.ext]

Hi,

I am using a Yocto-Poky-Mickledore (version 4.2.1) based system.

For configuring the kernel, I would like to use the command

bitbake -c menuconfig virtual/kernel

If I do that, Bitbake opens an xterm window and runs the build steps
for Kconfig. However, after the compiler has finised, the xterm window
immediately closes and Bitbake exists as if nothing happened, i.e. it
does not show any error message or similar.

I investigated the problem and found out that, internally, Bitbake
calls the following command for starting Kconfig:

make menuconfig CC="ccache x86_64-system-linux-gcc ..." \
CFLAGS="..." HOSTCC="ccache gcc" HOSTCCFLAGS="..."

The quotes, however, seem to get lost when starting the actual command
in the terminal. This leads to a command line like follows:

make menuconfig CC=ccache x86_64-system-linux-gcc ... \
CFLAGS=... HOSTCC="ccache gcc" HOSTCCFLAGS="...

which is clearly wrong.

The following patch fixes the problem in meta/classes-recipe/cml1.bbclass:

diff --git a/meta/classes-recipe/cml1.bbclass b/meta/classes-recipe/cml1.bbclass
index a09a042c3f..d6001d6fd0 100644
--- a/meta/classes-recipe/cml1.bbclass
+++ b/meta/classes-recipe/cml1.bbclass
@@ -53,7 +53,8 @@ python do_menuconfig() {
 # ensure that environment variables are overwritten with this tasks 'd' 
values
 d.appendVar("OE_TERMINAL_EXPORTS", " PKG_CONFIG_DIR PKG_CONFIG_PATH 
PKG_CONFIG_LIBDIR PKG_CONFIG_SYSROOT_DIR")

-oe_terminal("sh -c \"make %s; if [ \\$? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
+make_cmd = "make %s" % d.getVar('KCONFIG_CONFIG_COMMAND').replace('"', 
'\\"')
+oe_terminal("sh -c \"%s; if [ \\$? -ne 0 ]; then echo 'Command failed.'; 
printf 'Press any key to continue... '; read r; fi\"" % make_cmd,
 d.getVar('PN') + ' Configuration', d)

What do you think? Is my observed behavior a configuration error of my
setup or does the patch above indeed make sense?

Best regards,
Holger

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60840): https://lists.yoctoproject.org/g/yocto/message/60840
Mute This Topic: https://lists.yoctoproject.org/mt/100872991/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SDK build generally broken?

[Alexander Kanavin]

SDK testing happens several times a day in yocto CI. You should
probably try building for core-image-minimal with only poky, no custom
layers, as that is where it's tested. Then bring bits of your custom
setup until it starts failing.

Alex

On Mon, 21 Aug 2023 at 14:49, David Daniel  wrote:
>
> Hello everybody
>
> Has anyone successfully built an SDK lately? I cannot build any SDK,
> neither for my image nor for core-image-minimal.
>
> If I define my own image I get the error (I already wrote - nobody any
> idea?) that the dummy-sdk package is to be built for a different
> architecture:
>
>
> x86_64_nativesdk   3.1.2-r0oe-repo  330 k
>  nativesdk-openssl-conf x86_64_nativesdk   3.1.2-r0   
>  oe-repo   12 k
>  target-sdk-provides-dummy  sdk_provides_dummy_target  1.0-r0 
>  oe-repo  9.0 k
>
> THIS ERROR ONLY APPEARS IF I DEFINE MY OWN IMAGE (though the image can be 
> built and works).
>
> I guess this is due to the following code in the sdk-dummy recipe:
>
> python() {
> # Put the package somewhere separate to ensure it's never used except
> # when we want it
> # (note that we have to do this in anonymous python here to avoid
> # allarch.bbclass disabling itself)
> d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
> }
>
> But furthermore, I am completely unable to build the SDK with my
> machine - I took the machine from the working image sources I am
> working with and took a plain master poky checkout (bleeding master).
> When I want to build the SDK for the core-image-minimal I get the
> following error:
>
> ERROR: m4-native-1.4.19-r0 do_collect_spdx_deps: Error executing a python 
> function in exec_func_python() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_collect_spdx_deps(d)
>  0003:
> File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
> lineno: 494, function: do_collect_spdx_deps
>  0490:from pathlib import Path
>  0491:
>  0492:spdx_deps_file = Path(d.getVar("SPDXDEPS"))
>  0493:
>  *** 0494:deps = collect_direct_deps(d, "do_create_spdx")
>  0495:
>  0496:with spdx_deps_file.open("w") as f:
>  0497:json.dump(deps, f)
>  0498:}
> File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
> lineno: 475, function: collect_direct_deps
>  0471:deps = set()
>  0472:for dep_name in this_dep[3]:
>  0473:dep_data = taskdepdata[dep_name]
>  0474:if dep_data[1] == dep_task and dep_data[0] != pn:
>  *** 0475:deps.add((dep_data[0], dep_data[7]))
>  0476:
>  0477:return sorted(deps)
>  0478:
>  0479:collect_direct_deps[vardepsexclude] += "BB_TASKDEPDATA"
> Exception: IndexError: list index out of range
>
> ERROR: Logfile of failure stored in: 
> /mnt/data/yocto/bf133/sdk/build/tmp/work/x86_64-linux/m4-native/1.4.19/temp/log.do_collect_spdx_deps.731506
> ERROR: Task 
> (/home/david/yocto/bf133/poky/meta/recipes-devtools/m4/m4-native_1.4.19.bb:do_collect_spdx_deps)
>  failed with exit code '1'
>
> Is the generation of an SDK outdated, not recommended, not maintained
> anymore? Or do you have any recommendations to troubleshoot these
> issues?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60839): https://lists.yoctoproject.org/g/yocto/message/60839
Mute This Topic: https://lists.yoctoproject.org/mt/100872021/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] SDK build generally broken?

[David Daniel]

Hello everybody

Has anyone successfully built an SDK lately? I cannot build any SDK,
neither for my image nor for core-image-minimal.

If I define my own image I get the error (I already wrote - nobody any
idea?) that the dummy-sdk package is to be built for a different
architecture:


x86_64_nativesdk   3.1.2-r0oe-repo  330 k
 nativesdk-openssl-conf x86_64_nativesdk   3.1.2-r0
oe-repo   12 k
 target-sdk-provides-dummy  sdk_provides_dummy_target  1.0-r0  
oe-repo  9.0 k

THIS ERROR ONLY APPEARS IF I DEFINE MY OWN IMAGE (though the image can be built 
and works).

I guess this is due to the following code in the sdk-dummy recipe:

python() {
# Put the package somewhere separate to ensure it's never used except
# when we want it
# (note that we have to do this in anonymous python here to avoid
# allarch.bbclass disabling itself)
d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
}

But furthermore, I am completely unable to build the SDK with my
machine - I took the machine from the working image sources I am
working with and took a plain master poky checkout (bleeding master).
When I want to build the SDK for the core-image-minimal I get the
following error:

ERROR: m4-native-1.4.19-r0 do_collect_spdx_deps: Error executing a python 
function in exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_collect_spdx_deps(d)
 0003:
File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
lineno: 494, function: do_collect_spdx_deps
 0490:from pathlib import Path
 0491:
 0492:spdx_deps_file = Path(d.getVar("SPDXDEPS"))
 0493:
 *** 0494:deps = collect_direct_deps(d, "do_create_spdx")
 0495:
 0496:with spdx_deps_file.open("w") as f:
 0497:json.dump(deps, f)
 0498:}
File: '/home/david/yocto/bf133/poky/meta/classes/create-spdx-2.2.bbclass', 
lineno: 475, function: collect_direct_deps
 0471:deps = set()
 0472:for dep_name in this_dep[3]:
 0473:dep_data = taskdepdata[dep_name]
 0474:if dep_data[1] == dep_task and dep_data[0] != pn:
 *** 0475:deps.add((dep_data[0], dep_data[7]))
 0476:
 0477:return sorted(deps)
 0478:
 0479:collect_direct_deps[vardepsexclude] += "BB_TASKDEPDATA"
Exception: IndexError: list index out of range

ERROR: Logfile of failure stored in: 
/mnt/data/yocto/bf133/sdk/build/tmp/work/x86_64-linux/m4-native/1.4.19/temp/log.do_collect_spdx_deps.731506
ERROR: Task 
(/home/david/yocto/bf133/poky/meta/recipes-devtools/m4/m4-native_1.4.19.bb:do_collect_spdx_deps)
 failed with exit code '1'

Is the generation of an SDK outdated, not recommended, not maintained
anymore? Or do you have any recommendations to troubleshoot these
issues?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60838): https://lists.yoctoproject.org/g/yocto/message/60838
Mute This Topic: https://lists.yoctoproject.org/mt/100872021/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to build a specified recipe every bitbake

[Ross Burton]

On 12 Aug 2023, at 08:23, Jiliang Cai via lists.yoctoproject.org 
 wrote:
> 
> On Fri, Aug 11, 2023 at 12:47 AM, Ross Burton wrote:
> On 11 Aug 2023, at 03:21, Jiliang Cai via lists.yoctoproject.org 
>  wrote:
> I have a recipe abc_1.0.bb. It generates a txt contains all layers git commit
> ID into /etc. It is installed into image by IMAGE_INSTALL:append = " abc". If 
> you want a list of layers/SHAs in your image, look at the image-buildinfo 
> class. I use this bbclass, but it sometimes records inaccurate SHAs.
> For example, when I first bitbake based a dirty layer meta-aaa, the SHA works
> as expected, followed by a 'modified'. But when I submitted the meta-aaa
> modification and ran bitbake again, nothing happened, and the file /etc/build
> was not regenerated.
> Although meta-aaa is already clean at this time, the old SHA and 'modified' 
> are
> still displayed in the rootfs build file.

I suspect the problem is that you didn’t actually change the content of the 
files, so the image didn’t rebuild.

I’d call this a by-design quirk: if I was using image-buildinfo I wouldn’t want 
the image to rebuild just because I fixed a typo in a commit message.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60837): https://lists.yoctoproject.org/g/yocto/message/60837
Mute This Topic: https://lists.yoctoproject.org/mt/100677035/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-