mranostaj has quit [Remote host closed the connection]
roussinm has quit [Quit: WeeChat 3.3-dev]
mranostaj has joined #yocto
goliath has joined #yocto
xmn has joined #yocto
yates has quit [Ping timeout: 268 seconds]
vmeson has quit [Ping timeout: 245 seconds]
ThomasD13 has joined #yocto
<JosefHolzmayr[m]>
yo dudX
<erbo>
JosefHolzmayr[m]: morning! So, I see that you're all formal with the name these days. No more God-Emperor?
frieder has joined #yocto
<JosefHolzmayr[m]>
erbo: heh, I've mostly retired the god emperor, yeah.
<JosefHolzmayr[m]>
erbo: when i picked that nick it was to reflect me as a personal thing. these days i'm mostly showing up as a form of public persona, therefore using the jester is more appropriate.
arunss has quit [Quit: Leaving]
<erbo>
makes sense :)
<JosefHolzmayr[m]>
i am inclined to interpret that as a personal insult (making sense) ;-)
<erbo>
Oh, I thought it would only be an insult to the old personal self and not the new public "front". My bad ;)
<JosefHolzmayr[m]>
i never make sense in whatever form ;-)
<erbo>
I bet the viewers of your videos would beg to differ
<JosefHolzmayr[m]>
hrhr
xmn has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zyga-mbp has joined #yocto
ant__ has quit [Quit: Leaving]
eduardas has joined #yocto
rfuentess has joined #yocto
goliath has quit [Quit: SIGSEGV]
mckoan|away is now known as mckoan
<mckoan>
good morning
<JosefHolzmayr[m]>
yo mckoan
leon-anavi has joined #yocto
jmiehe has joined #yocto
<mckoan>
JosefHolzmayr[m]: hey, unfortunately I won't be able to attend your webinar this afternoon because I'm running a training course
<mckoan>
JosefHolzmayr[m]: are you going to record it?
<JosefHolzmayr[m]>
mckoan: heh no worries, there won't be anything in there that you don't know already. and its tomorrow.. plus, yes, the linux foundation has the recordings available then.
<mckoan>
JosefHolzmayr[m]: yes, tomorrow. Thanks
goliath has joined #yocto
novaldex has joined #yocto
Ad0 has quit [Ping timeout: 265 seconds]
Ad0 has joined #yocto
Little_rabbit has joined #yocto
florian has joined #yocto
<Little_rabbit>
Is there something besides rm_work which would prevent the creation of the content of the rootfs directly in `work/machine/core-image-minimal/1.0/rootfs`?
<Little_rabbit>
The dir gets created but no content is there. Was hoping to examine the rootfs after the build.
<qschulz>
Little_rabbit: probably need to cleansstate the core-image-minimal to trigger a rebuild and repopulate the rootfs dir without rm_work enabled
<rburton>
not a cleansstate, never cleansstate
<rburton>
if the task isn't re-running as the rootfs already exists in deploy, then bitbake core-image-minimal -C rootfs
olani[m] has joined #yocto
<qschulz>
rburton: you'll anyway need to cleansstate after the -C is run to perform a non-tainted build
prabhakarlad has quit [Ping timeout: 256 seconds]
Guest78 has joined #yocto
<Little_rabbit>
I did clean cleansstate, and the effects of `-c build_without_rm_work` do show with the populated directory structure in `work/machine/core-image-minimal/1.0` (as opposed to only temp with rm_work). . However the rootfs isn't populated.
Guest78 has quit [Client Quit]
<Little_rabbit>
The directory `work/machine/core-image-minimal/1.0/rootfs` ends up empty.
<qschulz>
are you actually building core-image-minimal?
<Little_rabbit>
Could be some of the non standard layers I guess then
prabhakarlad has joined #yocto
manuel1985 has joined #yocto
<Little_rabbit>
Seem's like something related to `-c build_without_rm_work`. If I remove `INHERIT += "rm_work"` from local.conf the rootfs content does get generated
<yates>
RP: i don't see how the cross-gcc compiler (for csky) yocto is generating for me can be using the glibc startup file crtiS since it doesn't exist under the glibc/sysroots/csky folder from github
<JosefHolzmayr[m]>
jorschulko I guess that "a bit" is quite an understatement.
Tyaku has joined #yocto
<RP>
yates: I don't know much about csky
<jorschulko>
Yeah... apparently changes within the repo manifest aren't detected by the repo fetcher either... https://www.openembedded.org/pipermail/bitbake-devel/2017-August/018699.html. Current implementation does not really seem to be usable. What a shame, repo would have matched my usecase perfectly
<JosefHolzmayr[m]>
jorschulko: time to send patches to make it usable, then! :)
<jorschulko>
Yeah, thinking about it ;)
<JaMa>
RP: I haven't found which commit caused this, but for last 2-3 days I'm seeng "NOTE: Running setscene task 1 of 51763 (various tasks)" where the "1" doesn't change anymore, have you seen this as well?
Vonter has joined #yocto
<Tyaku>
Hi, Today i would like to build a simple software that use a library build from another recipe. On the library recipe i have this: https://pastebin.com/7sn6cZY9 and on the "hello world" that use the library, i have this: https://pastebin.com/AhzpNGsm When I build I have this error: "Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them
<rburton>
Tyaku: do what the error says: set FILES_* appropriate. this is covered in the manual
<RP>
JaMa: ah, I think I see what you mean. It is that commit
<JaMa>
RP: for me it worked e.g. jenkins build from 6 days ago shows "Running setscene task 7 of 18265"
<RP>
JaMa: I fixed the interactive view and broke the other one :(
<RP>
JaMa: the numbers for setscene tasks were wrong anyway :(
<JaMa>
yes I think I was seeing larger task number than the "total" in of sometimes
<RP>
build without rehashing were ok, if rehashing happened you for task 18000 of 2400
<Tyaku>
rburton: We have to do it on the recipe that provide the library or in the recipe that use ?
<rburton>
the recipe that emits the error
<JaMa>
I almost never run interactive view (always use tee to some file)
<rburton>
why is that? the log is always written to disk too
<RP>
JaMa: right, I'm not sure we can win though as with all the runqueue changes, the stats data is tricky :(
zyga-mbp has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
camus has quit [Quit: camus]
Gaffel has joined #yocto
camus has joined #yocto
novaldex|away is now known as novaldex
zyga-mbp has joined #yocto
novaldex has quit [Quit: Client closed]
michaelo[m] has joined #yocto
novaldex has joined #yocto
<michaelo>
Hello. I think I found an issue in the documentation. "bitbake core-image-minimal -c checkpkg" doesn't work any more. Shall I use something like "devtool check-upgrade-status"? I know it's not specific to that image...
<Tyaku>
Did you know where I can find some docs about how to make a recipe that create a static lib ?
<Tyaku>
Ok, I have a recipe A, that build binnaries and static libraries. I want to use the static lib of A from recipe B.
<Tyaku>
On the recipe A, I just have this in do_install(): "install -m 0644 ${B}/lib/libCHIP.a ${D}${libdir}"
<Tyaku>
At this point, I see that the library doesn't appear in /usr/lib or in the system. (I don't know if it's normal)
OutBackDingo has joined #yocto
<RP>
michaelo: yes, well spotted
<RP>
michaelo: it never should have been image specific anyway (another good reason we changed it)
<qschulz>
Tyaku: I think the whole point of static libraries is that you don't need them at runtime since they're part of your binaries
<qschulz>
and I would assume .a files would be in -dbg or -dev packages by default
kiran has joined #yocto
<qschulz>
also not sure to understand why you want to really use a static lib?
<michaelo>
RP: many thanks. So, we cannot run "test_checkpkg" tasks through bitbake, right?
<Tyaku>
qschulz: My question was just to verify the fact that .a is not on the system. So this point is OK. My objective is to BUILD during "bitbake" a recipe B that use a STATIC library generated by another recipe.
<qschulz>
Tyaku: the question is why :)
<Tyaku>
But, How to be sure the recipe A is generating the .a file ?
<Tyaku>
Why what ?
<qschulz>
why do you want to use a static library?
<qschulz>
you go into the workdir of recipe A and check that .a is compiled
camus1 has joined #yocto
<qschulz>
then you check that it is available in $workdir/image
<qschulz>
if not, FILES variable is incorrect or you aren't installing it
<Tyaku>
Because the project that create the library generate a .a file. And because i don't need it as a shared library since I will have only one software using it
<qschulz>
if it is, then check $workdir/sysroot-destdir it should be in there
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
<qschulz>
if not, then adapt the path of your static lib to be installed in a directory in SYROOT_DIRS or add the path to it
<qschulz>
then from recipe B, you should have your .a in recipe-sysroot, if not, forgotten DEPENDS
<Tyaku>
I found the library here: tmp/work/cortexa53-crypto-poky-linux/matter/0.0+gitAUTOINC+0b406ded65-r0/out/lib
<Tyaku>
In workdir/image it's strange ! I have a /usr folder, and in this folder there is a "bin" folder AND a "lib" file. Why the file is not called libCHIP.a ? >_<
<qschulz>
also i'm pretty sure libs shouldn't be in /usr/bin :)
<Tyaku>
Yeah, they should be in /usr/lib, but it should be /usr/lib/libCHIP.a and not /usr/lib-> Where "lib" is the library.
jorschulko has quit [Quit: leaving]
<Tyaku>
Ok, I found the problem: I didn't create the folder ${libdir} before trying to copy files into it.
<Tyaku>
qschulz: Another question: If the recipe A build some tools and a static lib. Of courses the static lib don't necessary needs to be in the rootfs but we need it to build the recipe B. Is there something to do for the .a not be in the final rootfs but present to build the recipe B ? (possibly related to -dbg -dev -static, i'm going to read about it)
novaldex has left #yocto [#yocto]
Ad0 has quit [Ping timeout: 265 seconds]
<smurray>
Tyaku: that's the default behavior, static libs go into the -static package and those aren't installed into rootfs unless you explicitly say to
kiran has quit [Quit: Konversation terminated!]
<Tyaku>
Oh so I understand a possible another mistake !!!!! I think in the receipe B i have to DEPENDS on "A-staticdev" instead of "A"
<qschulz>
Tyaku: no
<qschulz>
DEPENDS is on recipes, RDPEENDS is on packages
<qschulz>
│16:12:11 qsqschulz | if it is, then check $workdir/sysroot-destdir it should be in there
<qschulz>
│16:12:44 qsqschulz | if not, then adapt the path of your static lib to be installed in a directory in SYROOT_DIRS or add the path to it
<qschulz>
packaging has nothing to do with the availability of files in other recipes
Ad0 has joined #yocto
<Tyaku>
Currently in $workdir/image and $workdir/sysroot-destdir I have the library in /usr/lib/libCHIP.a
Belsirk has joined #yocto
<Tyaku>
So when we are dealing with static libs, what is the best practice from recipe B to use a library from recipe A ? Using RDPENDS with -static version ?
<qschulz>
Tyaku: RDEPENDS are runtime dependencies, static libs aren't runtime dependencies but build time
frieder has quit [Remote host closed the connection]
<Tyaku>
Now on recipe B i have another error (so now it find the library maybe) but this error is more terrible. I try to see what happends.
<qschulz>
so you need DEPENDS=A
vd has joined #yocto
rfuentess has quit [Ping timeout: 268 seconds]
Belsirk is now known as rfuentess
<Tyaku>
qschulz: I understand that static libs are using during the build time, but we have to install them to be able to build another recipe using it. So they are necessary on the rootfs at the end.
<rburton>
DEPENDS lists recipes that you depend on
<rburton>
because at build time there isn't a rootfs
<rburton>
you mean sysroot, which is tied to a recipe
<Tyaku>
So you mean in normal time, we don't need to install the static libs in recipe A to be able to use it from recipe B that depends on A ?
<rburton>
when is 'normal'?
<qschulz>
Tyaku: if you don't install the static lib, it won't be available in other recipes so yes you do need to install it
<qschulz>
but the install task is not installing into the rootfs
<Tyaku>
If yes, I think i know why in my situation it didn't work like this ... I am using the GN class to build the recipe A, and this class (if i understand) don't store the files in normal folder, for example we have to do "install ${B}/chip-echo-requester ${D}${bindir}" instead of "install chip-echo-requester ${D}${bindir}" to install something.
<qschulz>
it is installing in a skeleton of a rootfs, which is then split into different packages
<qschulz>
when you specify packages in your image recipe to be installed, bitbake will ask the package manager to install the rpm/deb/ipk package into a directory which will act as the rootfs
<qschulz>
then bitbake creates a tarball (or whatever you asked it to create) from this rootfs, which effectively creates a rootfs usable for the target
<qschulz>
for build time, you need to install your lib because the sysroot is made out of the content of the skeleton rootfs, otherwise there'd be way too many files shared between recipes
<qschulz>
made out of *parts* of the skeleton rootfs
<Tyaku>
qschulz: your explanation is excellent
<Tyaku>
qschulz: Thank you <3
<rburton>
as long as A installs the library to $D$libdir, and your B DEPENDS=A, then B will statically link to A and you're done.
<Tyaku>
I confirm what you said with a test, and it's correct the library installed is not in final rootfs, but can be used to build because I don't have the "file not found" error during build of recipe B.
<Tyaku>
Now I have another error, more difficult to explain. My Recipe A use the "GN / Ninja" build system and build correctly. Now when recipe B depends on A and after the "file not found" (libCHIP.a) is fixed, i have another problem: "{Recipe B:} failed with exit code 1: ninja: error: unknown target 'install'"
<Tyaku>
This error is strange because recipe B don't use GN or Ninja. It's a simple CMake recipe.
<yates>
gentlement: when yocto prepares to build a package xyz, it copies some stuff from somewhere over to xyz/{rv}/recipe-sysroot. right? what recipe, .class, or whatever is responsible for doing this? from where does it copy?
<rburton>
yates: from each recipe's sysroot, in tmp/sysroot-components/
pgowda has quit [Quit: Connection closed for inactivity]
<whuang0389>
haha unfortunately my team doesn't want to use busybox
<jordemort>
i'm looking into an initramfs that's gotten too big and it appears that it contains both a zimage and a fitimage in /boot, and sure enough those things are present in the manifest and also in the .cpio.gz - any hints on how to track down how those are getting pulled in? must be a package dependency somehow? i'm looking at other initramfs recipes and they don't seem to do anything special to fend off a kernel getting installed in them
<whuang0389>
and we don't have a space issue so we're aren't looking to create a very small image
<jordemort>
whuang0389: i think you want procps
<whuang0389>
thanks, i was just looking at that!
<jordemort>
looks like it makes a `procps-ps` package that you could install to just get `ps` (looking at hardknott)
<hpsy>
Is UPSTREAM_CHECK_COMMITS an undocumented feature?, I see it in a lot of recipes but can't find any information about it. I am guessing it is similar to the other UPSTREAM_CHECK_* variables.
<rburton>
hpsy: apparently so. can you file a bug?
<yates>
rburton: thanks. do you know which recipe, .class, or whatever is responsible for doing this? i need to know because there are no less than 4 sources of crti.o in tmp/sysroots-components and i need to know which one is being used
<rburton>
the task log will list what sysroots are being pulled in
<rburton>
that tells you what it installed into the sysroot
<yates>
ok
hpsy has quit [Quit: Client closed]
hpsy has joined #yocto
jmiehe has quit [Quit: jmiehe]
<rfs613>
recently there have been a number of CVEs against "tar" which are actually in nodejs (node-tar). Curious if anyone has looked into filtering these automatically using the "Target Software" field of the CPE information?
Tokamak has quit [Read error: Connection reset by peer]
<rfs613>
(as opposed to manually reviewing and whitelisting the individually, and for each active yocto branch)
<RP>
JPEW: I think the timestamp clamping breaks things like the gcc source tree files shared between bits of the gcc build
<angolini>
oh, let me say it here. In this meeting that happens today, I have only 30 minutes (the beginning) so I always have to drop at the middle (unfortunately) I try to not mess too much the meeting
<JPEW>
The gcc source tree is the input to do_package?
<JPEW>
(or some other sstate task?)
<angolini>
I know the meeting is being recorded, but I have never could find a link to get to the recording.
<jordemort>
looks like my initramfs images were inheriting from core-image, which installs packagegroup-core-boot, which installs kernels; switching to just inheriting image instead
BCMM has quit [Ping timeout: 252 seconds]
hpsy has quit [Changing host]
hpsy has joined #yocto
<RP>
JPEW: do_populate_sysroot
<rburton>
rfs613: nobody has actually looked into how to do it automatically yet afaik
<RP>
JPEW: we might be able to surpress the timestamp clamping for populate_sysroot
Tokamak has joined #yocto
<JPEW>
RP: Lets see.... that would be OK because it basically has special rules b/c of RSS?
<JPEW>
Or it's not ideal but would work
<RP>
JPEW: we don't include the timestamps in the outhash for populate_sysroot anyway do we?
* JPEW
checks
<rfs613>
rburton: okay thanks. I might take a look, might be a good learning exercise to improve my python. Though I suspect the bigger issue is how to match this extra field against yocto's metadata, eg what to compare it against.
<JPEW>
RP: We do not
<JPEW>
We actually only include the timestamps for do_package and only when BUILD_REPRODUCIBLE_BINARIES is set
goliath has joined #yocto
hpsy has quit [Quit: Client closed]
<JPEW>
I suppose we need the timestamp clamping code to only apply with the same logic as the outhash calculation
* JPEW
Wonders if we can codify that in some common location
Belsirk has quit [Quit: CHELAS!!!!!!!!]
<RP>
JPEW: I will hack something to at least test this
<RP>
common location could be hard
iwoloschin has joined #yocto
<vd>
can SRC_URI contain several directories with the same name?
<vd>
I'm trying to figure out a way to merge many "env" directories (one per override) into one in a recipe
<iwoloschin>
Is it possible to include a python3 package that just uses pyproject.toml (I'm using poetry)? I honestly don't really know what I'm doing with yocto, but when I tried naively doing this it failed trying to find setup.py.
<RP>
vd: I think the fetcher can handle directories named after overrides, at least some of them.
<vd>
RP: that'd be interesting! I was thinking about finding 'env-*' in ${WORKDIR} and naming them like env-$override but that doesn't seem right
<RP>
so files/qemux86/xx would be preferred compared to files/xx
florian has quit [Quit: Ex-Chat]
argonautx has quit [Quit: Leaving]
<vd>
RP ho ok, but that's a matter of preferring a directory over another, I want all of them to be merged. So I guess I have no choice but to give them a unique name, i.e. env-foo and SRC_URI_append_foo = " file://env-foo"
dev1990 has joined #yocto
gsalazar has quit [Ping timeout: 268 seconds]
manuel1985 has quit [Quit: Leaving]
mihai- has joined #yocto
iwoloschin has quit [Quit: Client closed]
mihai has quit [Ping timeout: 265 seconds]
berton[m] has joined #yocto
florian has joined #yocto
iwoloschin has joined #yocto
iwoloschin has quit [Client Quit]
mihai- is now known as mihai
vd has quit [Quit: Client closed]
vd has joined #yocto
whuang0389 has quit [Quit: Client closed]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<vd>
does FOO_append_a_b appends FOO only if OVERRIDES contains both "a" and "b"?
<rfs613>
rburton: after a bit of investigation and testing, it seems that we could set CVE_PRODUCT = "gnu:tar", replacing the current CVE_CHECK_WHITELIST, since the node-tar CVEs have vendor like "tar_project" and "npmjs".
<rfs613>
My earlier idea, of filtering on "Target Software", is more difficult because that field is not extracted from JSON into the sqlite database currently, so we'd need to change the schema, etc.
<rburton>
rfs613: perfect, and that could probably remove a load of the whitelisting too
michaelo has quit [Remote host closed the connection]
<rfs613>
rburton: okay, i'll send a patch - I tested on dunfell, but this should apply equally to the newer branches, I'd think
michaelo has joined #yocto
florian has quit [Ping timeout: 268 seconds]
<rfs613>
hmm, looks like vim syntax highting needs an update for the new append syntax.
<michaelo>
rfs613: that already happened. Let me look for this...
<rfs613>
michaelo: it's no big deal, don't spend effort on looking, it will show up in $distro eventually ;-)
<JPEW>
The vim plugin is also in bitbake itself; I just recently updated it to handle the new syntax
<JPEW>
kergoth: having two versions of the plugin is confusing :)
bunk has joined #yocto
florian has joined #yocto
<rfs613>
rburton: patch sent to list. I forgot to mention that it should go on older branches. Can provide dunfell version (filename differs, as it's an older version of tar)
Spooster has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<kergoth>
JPEW: I agree, originally the intention was to keep it as the same content but in an easier to use form (vim plugin managers are common, and many require a particular repo layout, so can't use it from bitbake directly), but unintentionally separated. I'd like to see it kept as a separate repo but on git.yp.org personally, but that's just my opinion
<kergoth>
er, unintentionally *deviated*, not separated
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]