<ejoerns[m]>
Hi together, is it expected that when using DEPENDS:append = " something" together with BBCLASSEXTEND = "native" the native package will have a dependency on both 'something-native' *and* 'something'? When using "+=" it works fine (only 'something-native' ends up in dependecies), thus it seems like :append kicks in twice?
<qschulz>
ejoerns[m]: that seems incorrect. Can you check with bitbake-getvar -r your-recipe DEPENDS and check that something-native and something comes from the same line?
Herrie|Laptop has quit [Ping timeout: 255 seconds]
<rob_w>
qschulz: thx will test it right away
<ejoerns[m]>
qschulz: 'something-native' comes from map_dependencies of native.bbclass (this is the part that I would expect), 'something' is only listed in an :append line before. The expanded value then contains both. So it seems like it is already in the list when native rewriting happens, but added again after
<ejoerns[m]>
(poky, kirkstone 4.05)
<qschulz>
ejoerns[m]: I believe it does not matter, because something dependency for a native build would be the same as something-native
prabhakarlad has joined #yocto
amitk_ has quit [Ping timeout: 256 seconds]
<ejoerns[m]>
qschulz: It should give a native package depending on a target package, which in most cases really isn't what you want.
amitk has joined #yocto
<ejoerns[m]>
Since I can reproduce this with another random poky setup I guess this is some 'normal' behavior of bitbake parsing that I haven't been aware of (and didn't want to be, anyway 😏)
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<qschulz>
ejoerns[m]: no because for a "native" package, the "target" architecture is actually the native architecture
mvlad has joined #yocto
<qschulz>
ejoerns[m]: I guess you can fill a bug on our bugzilla to ask if this is expected? If you could provide a very simple recipe on top of vanilla poky, that'd be the best
AntA has quit [Ping timeout: 260 seconds]
<qschulz>
it doesn't need to compile, just needs to parse I guess
<qschulz>
RP: maybe you know ^ DEPENDS:append = "something" BBCLASSEXTEND = "native" adds both something and something-native to DEPENDS of the native recipe
<ejoerns[m]>
qschulz: yes, submitting a bug would be my next step, but I wanted to make sure that I do not hit something very well known ;) Thx for your guidance!
seninha has joined #yocto
<qschulz>
ejoerns[m]: I'm as surprised as you are, but I don't think it brings the MACHINE architecture's recipe variant in the dependencies of the native recipe (you could always check in the recipe-sysroot* directories and check that no MACHINE architecture's binaries/shlibs are available there)
<RP>
qschulz: I'm not entirely surprised but that wasn't likely the design intent
<RP>
qschulz: I can guess why, the write of DEPENDS back doesn't cancel the append?
d-s-e has joined #yocto
amitk has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
amitk has joined #yocto
seninha has quit [Quit: Leaving]
seninha has joined #yocto
gho has joined #yocto
ajfriesen6 has joined #yocto
<qschulz>
nmcli returns some weird characters instead of colors, does anyone know what is the culprit?
<qschulz>
NO_COLOR=1 works fine but obviously I would expect something on the system level
ajfriesen has quit [Ping timeout: 252 seconds]
ajfriesen6 is now known as ajfriesen
amitk has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<landgraf>
qschulz: I got your point :) just was worried why I've not seen the missed branch warning
Poppy has joined #yocto
<Poppy>
I don't know but on kirkstone branch I got this warning "do_rootfs: QA Issue: The license listed GPL-2.0-or-later was not in the licenses collected for recipe libpam [license-file-missing] " for libxau/ libxdmcp / libx11 any tips to solve that ?
zpfvo has quit [Ping timeout: 264 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<ejoerns[m]>
RP: if an append can be canceled there, this sounds pretty much like what it should do, yes (also see my original question above)
Jham has joined #yocto
<qschulz>
landgraf: :)
amitk has joined #yocto
<RP>
ejoerns[m]: it is possible, just hard
<RP>
ejoerns[m]: the problem is in native.bbclass, the map_dependencies() function and the "parsing=True" to the setVar call
<RP>
"The implementation uses datastore/parser parameters to ensure that the variable overrides are not overwritten when calling setVar which is appropriate for a function as close to the core as this one is."
<ejoerns[m]>
RP: I see
<RP>
ejoerns[m]: there are some overrides we want to preserve and some we don't (:append is an unconditional override)
<ejoerns[m]>
RP: so this assumption was wrong? Or is it still true and additional handling needs to be established?
<RP>
ejoerns[m]: there is an unforeseen edge case
<ejoerns[m]>
RP: I understand that e.g. class-specific overrides should be preserved there, yes
<RP>
ejoerns[m]: we don't have any way to say "preserve these overrides but not those ones"
<ejoerns[m]>
RP: So it's a "Dont' use (unconditional) :append for DEPENDS etc. " first of all?
<RP>
ejoerns[m]: I don't like that. I think we should add some API to bitbake to allow unconditional overrides to be cleared
<ejoerns[m]>
RP: me neither, but I don't feel deep enough into this, yet to propose a working solution :D
<RP>
if we added filters around variables, this problem goes away
<RP>
ejoerns[m]: at the very least can you write a bug report for this so we can document what we've worked out
<ejoerns[m]>
@RP sure!
tnovotny has quit [Ping timeout: 260 seconds]
yssh has joined #yocto
manuel1985 has joined #yocto
<yssh>
Can I build a yocto project(sample project as given on the yocto website:https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#welcome)
<yssh>
through a bootable USB - which has kali linux live ?
tnovotny has joined #yocto
<rburton>
yssh: if kali has the build depends (as listed in the quick start) and you have access to a large, fast disk, then sure. Both of those might be problems though. If you're asking because you've a windows machine and a bootable usb stick gives you linux, then you can build using WSL2 on windows.
<yssh>
rburton My system(linux installed) doesn't seems to be able to build yocto project - AGL ,
<yssh>
That's why I wanted to build it on my friend's computer using a live usb.
<rburton>
why doesn't your system work?
<yssh>
My system has less memory(4gb) so during build time getting error: running out of memory...
<Granjow>
Hi guys, is there somewhere a bit of information about .wic (where to get tools to work with them, what the connection with .wks and kickstart is, what the file format looks like)? Everything seems to point to pykickstart which to me appears to use a plaintext configuration file and which can write images for floppy disks and CD-ROM.
<Granjow>
Okay, so .wks defines the partition layout and contents of the .wic file which is a deployable (bmaptool/dd) disk image. Can wic be compiled outside of yocto? Is this a yocto built-in tool, or does it have something like a GitHub repo with code and docs and stuff?
<rburton>
yssh: i'm guessing the uninative tarball contains binaries that refuse to run on your machine. delete the build tree (tmp/) and add INHERIT:remove = "uninative" to local.conf, then try again
<yssh>
OK
<rburton>
just tmp, no need to delete downloads or sstate-cache
<yssh>
Ok
amitk has quit [Ping timeout: 260 seconds]
<rburton>
yssh: your build is going to take a very, very long time.
<yssh>
Ok
<louson>
landgraf: hello. I have troubles to pass the ssh test. I have added dropbear but I get a permission denied. I have added the empty-root-password image feature but that does not set the password. How can I do that without modifying the layers ?
Algotech75 has joined #yocto
<rburton>
RP: we should check that the new buildtools doesn't have an overly-optimistic ISA level requirement
<yocton>
louson: You may want to use EXTRA_IMAGE_FEATURES = "debug-tweaks" instead of "empty-root-password"
<yocton>
louson: see poky/meta/classes-recipe/rootfs-postcommands.bbclass:13
<Poppy>
after adding multiple SRC_URI in image recipe I got "sx512-image-1.0-r0 do_rootfs:QA Issue: The license listed GPL-2.0-or-later was not in the licenses collected for recipe libpam [license-file-missing]" any tips to remove the warning ?
manuel1985 has quit [Ping timeout: 265 seconds]
vladest has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
<RP>
rburton: hmm, true
<RP>
rburton: I wonder what we assume? :/
d-s-e has quit [Ping timeout: 260 seconds]
* RP
thinks he's found a patch people will hate him for
* JaMa
grumbles in expectation :)
<RP>
JaMa: you will find it annoying but probably like it overall :)
<JaMa>
yeah, I like your commits, I just grumble about everything :)
<RP>
Perhaps I'm pushing the defaults a little there, not sure
<rburton>
like it :)
<JaMa>
I like it already :) I've suggested it after ffmpeg patch-fuzz landed in last kirkstone update, it does cause do_patch to fail, right?
<RP>
JaMa: it was that issue which made me want to go and investigate this
<RP>
rburton: I'll remind you when meta-arm explodes
<JaMa>
we have all WARN_QA in ERROR_QA already in webOS builds (including patch-fuzz), so this won't cause any more work for me and will actually save a bit (as similar issue happened recently in our internal component and was "hidden" by retriggering the verification build)
<louson>
yocton: thanks, I misread the documentation. I also needed allow-empty-password and allow-root-login (or debug-tweaks)
<RP>
JaMa: the bigger question is do all your patches have Upstream-Status?
<JaMa>
no, will keep that one in WARN_QA (together with buildpaths :/)
<rburton>
RP: our internal CI has fatal warnings :)
prabhakarlad has quit [Quit: Client closed]
<RP>
JaMa: fair enough
<RP>
This change probably is the right thing to do, it just won't make me popular
Algotech13 has joined #yocto
<JaMa>
agreed with the first part (already cherry-picked to my builds)
tnovotny has quit [Quit: Leaving]
<JaMa>
even meta-ros had very crude check for Upstream-Status (sadly with many Pending), but even Pending is better than no information at all
Algotech75 has quit [Ping timeout: 248 seconds]
vladest has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
<yssh>
rburton Again failed! the build with same error:
<yssh>
` ERROR: Failed to spawn fakeroot worker to run /home/bullbust/Work/OSP/Yocto/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_install: [Errno 32] Broken pipe `
<rburton>
yssh: what does NATIVELSBSTRING = say at the top of the bitbake output?
<yssh>
NATIVELSBSTRING = "debian-11"
<rburton>
try deleting sstate-cache and tmp, maybe there's a subtle issue there.
<rburton>
you can just bitbake base-files to speed things up a little
<yssh>
ok
<rburton>
and i'm assuming you've not done anything to local.conf
<yssh>
no I don't
<yssh>
didn't*
<JaMa>
khem: with time64.inc I'm seeing target binutils failing with http://gecko.lge.com:80/Builds/Details/1279217 (with 1.40 as well as 1.39 and with ld-is-gold as well as without), have you seen that as well?
<yssh>
I have made some changes at first as shown in the docs.
<rburton>
yssh: comment out BB_HASHSERVE_UPSTREAM and SSTATE_MIRRORS again, just to be sure that they're not tainting your build
<yssh>
ok
<JaMa>
hmm what would prevent pseudo-native to be reused from SSTATE_MIRRORS from some other debian-11 with higher ISA?
sakoman has joined #yocto
<RP>
JaMa: is uninative active?
<RP>
JaMa: older bitbakes did have issues pulling pseudo-native from sstate too
<JaMa>
I was thinking about yssh's case
<yssh>
Can I ask what is exactly pseudo-native?
<RP>
yssh: it is a fakeroot emulator which lets us pretend to do things as root yet not be
<JaMa>
that with or without uninative we don't prevent host's native toolchain to pass e.g. some -march
<RP>
yssh: fakeroot tasks run under pseudo so the fact the fakeroot worker is failing to start suggests a problem in pseudo
<yssh>
ohh... sounds like it a hacking tool
<RP>
yssh: it can only ever do anything your user can do, it is all just an illusion :)
<yssh>
RP Ok,
<yssh>
thanks
<JaMa>
yssh: it will be great to discover what's the issue, but after that building on AMD C-70 will be a bit painful, unless you're paid by hour and this laptop was provided by company to do OE builds :)
yssh66 has joined #yocto
<landgraf>
sounds like dream job
yssh66 has quit [Client Quit]
<JaMa>
landgraf: yeah, but you cannot play solitaire on the same laptop when build is running
yssh43 has joined #yocto
yssh43 has quit [Client Quit]
yssh has quit [Ping timeout: 260 seconds]
<manuel1985>
Can xfce run under xwayland?
yssh has joined #yocto
<RP>
heh, rouge bisect checked out a bitbake from 2015, couldn't find "python" and I got very confused
<landgraf>
manuel1985: No, afaik
<manuel1985>
landgraf: Thanks
<qschulz>
manuel1985: they are planning to do it one day, but doesn't seem to be atm no
<rburton>
manuel_: my understanding is that xwayland is for running X *apps* under a primarily wayland session, not a whole window manager
<rburton>
weston is the wm, in xwayland
jquaresma[m] has joined #yocto
perceval[m] has quit [Quit: You have been kicked for being idle]
vladest has quit [Ping timeout: 252 seconds]
Algotech75 has joined #yocto
Algotech13 has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
seninha has quit [Quit: Leaving]
seninha has joined #yocto
vladest has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
rfuentess has quit [Remote host closed the connection]
d-s-e has quit [Quit: Konversation terminated!]
<JaMa>
203 patch-status-noncore WARN_QA in almost complete build - bad but I was expecting worse
frieder has quit [Remote host closed the connection]
<rburton>
RP: so our 4.1.2 build tools says x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4
<rburton>
that seems a little keen?
<rburton>
or am I misunderstanding
zpfvo has quit [Ping timeout: 268 seconds]
Jham has quit [Quit: Leaving]
<JaMa>
khem: I've used wrong link, should be http://errors.yoctoproject.org/Errors/Details/687476/ and the versions should be 2.39 and 2.40 as you probably guessed, I see that RP reported the same failures on ML as well
mckoan is now known as mckoan|away
gho has quit [Quit: Leaving.]
louson has quit [Quit: leaving]
manuel1985 has quit [Ping timeout: 256 seconds]
amelius has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
<rburton>
urh downloads.yocto is on strike again
sakoman has quit [Quit: Leaving.]
florian has quit [Quit: Ex-Chat]
leon-anavi has quit [Quit: Leaving]
vladest has quit [Ping timeout: 246 seconds]
<RP>
rburton: does halstead know?
<rburton>
not yet
<halstead>
I don't. But I do now..
<rburton>
i was downloading at 100kbps which gets boring when its a huge buildtools
<halstead>
I'm currently tracking down some packet loss issues on that network
seninha has quit [Ping timeout: 256 seconds]
<halstead>
rburton: Do you happen to have the url of the buildtools in question handy?