<jclsn[m]>
The previous pipelines just timed out here
<jclsn[m]>
No idea why
<jclsn[m]>
What are the reason what bitbake could just hang? I have never seen this before
<jclsn[m]>
s/what/that/
kanavin has joined #yocto
kanavin has quit [Quit: Leaving]
<ptsneves>
have a look at the process list and see what exactly is hung
leon-anavi has joined #yocto
<jclsn[m]>
ptsneves: with `ps` you mean?
<ptsneves>
yes
<ptsneves>
ps aux
<jclsn[m]>
No idea how to do that in a pipeline
<ptsneves>
You would need to connect to the pipeline slave and execute it there
<ptsneves>
assuming you are talking about jenkins pipelines
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<qschulz>
jclsn[m]: might just be it's currently fetching something
<qschulz>
I had this issue with linux-yocto some time ago
<qschulz>
basically, there's some issue with the premirrors hosted on yoctoproject.org because it just gets too many requests
<qschulz>
might be worth checking if this reproduces with a locally hosted premirror (or download everything once on your jenkins pipeline and then set DL_DIR to point to that location so it does not need to fetch it externally)
kanavin has joined #yocto
jkroon_ has joined #yocto
jkroon_ has quit [Client Quit]
rob_w has quit [Ping timeout: 252 seconds]
kroon has joined #yocto
Schiller has joined #yocto
Tyaku has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<Schiller>
In the YPAutobuilder schedulers.py script is there a simple way to add a Revision to the <branchdefaults> list or do i have to rewrite everything?
<RP>
Schiller: branchdefaults doesn't currently support revisions, it only supports branch names. The code doing props[branchkey] = branchdefaults[branchname][branchkey] has a line below which sets commit_{} - you'd need to change that
<Schiller>
RP: ok thanks. Also the variables [branchname] and [branchkey] i know what they respresent but i dont see where there are defined.
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP>
Schiller: branchkey is defined in that function
<RP>
branchname is a function parameter?
<Schiller>
RP mb checked it again now i see. Currently i have the Revision just added in the config.repos and just grep item [2] then. Ill try to find a work around. Thanks.
peoliye has quit [Quit: Client closed]
<Tyaku>
Hi, I come again with a dummy question. I'am doing a recipe for a project which is not mine. To build this project we have to create a symbolic link like this: "ln -s ${gecko_sdk}/util/third_party/openthread ${gecko_sdk}/util/third_party/ot-br-posix/third_party/openthread/repo" directly in the sources. What is the best option to do it ?
<Tyaku>
create the symbolic link in the do_configure_prepend() ?
<Tyaku>
Currently I do this: "ln -s ${WORKDIR}/git/util/third_party/openthread ${WORKDIR}/git/util/third_party/ot-br-posix/third_party/openthread/repo" in do_configure_prepend()
<qschulz>
Tyaku: you could probably just do ln -s util/third_party/openthread util/third_party/ot-br-posix/third_party/openthread/repo
<qschulz>
since do_configure is probably run in S?
<qschulz>
which is WORKDIR/git
<qschulz>
but otherwise, does not really seem like a big issue what you're doing, not knowing the context or the reason for this symlink
<Tyaku>
in my case I change the S because the project that i build is "a part" of the big git: S = "${WORKDIR}/git/util/third_party/ot-br-posix"
<qschulz>
Tyaku: you can do relative symlinking
davidinux has joined #yocto
<jclsn[m]>
<qschulz> "might be worth checking if..." <- Yeah I have already set that up. Have to look into I guess. Thanks
florian has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<LetoThe2nd>
yo dudX
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
GuestNew118 has joined #yocto
<GuestNew118>
someone uses whitesource (command-line tool that scans directories' open source components for vulnerable libraries and source files) to scan a project ?
<kroon>
#fedora
<Schiller>
RP: I did add a Revision item to the <branchdefaults> List and edited the <parent_default_props> function to also fill out the commit with that item. Works fine. Thanks again.
camus has quit [Remote host closed the connection]
<Schiller>
RP: Another question is coming up regarding the <wait-quick> and <wait-full> builds as i am customizing the <schedulers.py> heavily atm. I know those are the triggerable builds but regardless i am able to use any scheduler in this project without using those two builds. In my company we also just have 2 running images atm. What is the big benefit
<Schiller>
of these builds because idk why i shouldn't just remove them. Maybe i missed something. Would be nice if someone could answer that.
xantoz has joined #yocto
xantoz has joined #yocto
camus has joined #yocto
wkawka has joined #yocto
wkawka has quit [Client Quit]
wkawka has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
<RP>
Schiller: if you don't need them just remove them
starblue has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
goliath has joined #yocto
dacav has quit [Ping timeout: 240 seconds]
<sotaoverride>
IMAGE_FSTYPES is set to ext4.xz, I need a way of calling a function once ext4.xz has been generated. I tried using IMAGE_POSTPROCESS_COMMAND, after deploy_image_ext4, and a couple of other things, but nothing has worked out for me so far.
<qschulz>
sotaoverride: addtask do_image_zip after do_image_ext4 before do_image_complete
rfuentess has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
xmn has joined #yocto
<chep>
Hi
<chep>
I'm trying to fetch sources with gitsm:// via http but I need a username and a password. When I use user=username:password, it works but only for main repository. bitbake tries to fetch submodules without using my username and password
<chep>
How can I tell bitbake to use them also for submodules?
<frosteyes>
Hi everybody. I am looking into integrating unified Kernel image for UEFI with yocto. Have anyone been working with this?
<frosteyes>
E.g. to combine the bzimage with the efi stub, together with the cmdline in a efi file and place on a vfat partion.
<qschulz>
ndec: michaelo: (maybe RP too?) any idea why there are tons of eclipse subdirectories in the old docs?
<RP>
qschulz: probably a bug in some old publishing script
<RP>
qschulz: happy to clean them up...
yudjinn[m] has quit [Read error: Connection timed out]
<qschulz>
RP: that or we can do it in the run-docs-build script, up to you :)
<qschulz>
find -name eclipse -type d -delete will do just fine :)
<RP>
qschulz: well, I was meaning I was happy for it to be run on the run-docs-build script
yudjinn[m] has joined #yocto
<frosteyes>
And hope to see some of you in Austin later this summer :)
<qschulz>
RP: will send a patch :)
rfuentess has joined #yocto
ilunev has joined #yocto
fabatera[m] has joined #yocto
kriive has quit [Remote host closed the connection]
<qschulz>
RP: I think we now have a good candidate version (v16) for merging for the old docs banner. (dont know if you were still following, hence the highlight :) )
<RP>
qschulz: I've been watching. If it passes your tests I'm happy!
<qschulz>
RP: quick check in a couple of versions and one or two pages, it displays what we want
<chep>
landgraf: it worked, thanks
<qschulz>
I could do a diff on the html pages before/after to see if there aren't any spurious changes if you want
seninha has joined #yocto
<RP>
qschulz: I guess I should try this with meld and check it does what we think
prabhakarlad has quit [Quit: Client closed]
<qschulz>
RP: I hope you have a powerful PC and some time ahead :)
<qschulz>
because there are many files changed (you'll see the time it takes to patch everything :) )
<fabatera[m]>
The same image builds/rebuilds Ok locally. It looks like it's the docker/reused SSTATE/Hardknott combination (+ mydevice.bb recipe ?!?)
<ptsneves>
fabatera[m] are you sure you are passing the MACHINE variable? A recipe with COMPATIBLE_MACHINE for a specific machine would lead to this, if not correctly set
ecdhe has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
<qschulz>
sotaoverride: you might also want to add ext4.xz to IMAGE_TYPES because only ext4 and ext4.gz exist ATM (see in meta/classes/image_types.bbclass)
<qschulz>
actually maybe not, since ext4.xz will probably use the conversion_cmd... don't know
<sotaoverride>
qschulz, so I do have ext4.xz to image types ..
<sotaoverride>
unclear why this still wont work
<qschulz>
do you get an ext4.xz at the end of the process?
<sotaoverride>
yep I get that fine
<sotaoverride>
like when I do complete builts I do get the ext4.xz to show up fine
<qschulz>
and I assume your zip task cannot find the ext4.xz?
<sotaoverride>
yeah
<qschulz>
ok, I think do_image_ext4 is just creating the ext4 but there's another task somewhere to actually do the compression
<sotaoverride>
i ask the zip task to cd into the deploy dir (where the ext4.xz eventually ends up) but the task cant find it there
<sotaoverride>
from the manaual i was hoping there would bea task called do_deploy_image_ext4.xz or something, but thats not the case
<sotaoverride>
or do_image_ext.xz even
<ptsneves>
git grep for CONVERSIONTYPES or have a look at them in the doc
<ptsneves>
sotaoverride
<sotaoverride>
ok there's a task for compressing ext4 to xz?
wkawka has quit [Quit: Client closed]
<qschulz>
might not be a task, it could be a postfunc of the do_image_ext4, I don't know
<qschulz>
you can check with bitbake -c listtasks <image-recipe> see if there's a task name that could match
<sotaoverride>
whats CONVERSIONTYPES again, I coudlnt get anything to show up in the ref manaual
<sotaoverride>
qschulz: can I use post functions as a hook somwhow?
<qschulz>
michaelo: we're missing CONVERSIONTYPES in the docs (and probably a few other variables from image*.bbclass
<qschulz>
sotaoverride: don't know, I would have to dig into image_types.bbclass and image.bbclass and I don't have time right now :/ maybe someone else knows by heart
<ptsneves>
yep CONVERSIONTYPES is missing. The only reference to it is that they are the new variable to use
<ptsneves>
i am almost sure the task that does the conversion is do_image_ext4
<ptsneves>
the compression is done by an extra step on the IMAGE_CMD_ext4 from a cursory look.
<sotaoverride>
IMAGE_CMD_ext4 is a task too then?
<sotaoverride>
which I can use as a hook for my function?
<JaMa>
tlwoerner: no problem :)
<ptsneves>
IMAGE_CMD_ext4 is a command used by do_image_ext4 :)
<ptsneves>
the code is not the most beautiful honestly. For your hook you can append to IMAGE_CMD_ext4 the rest of your command
Tyaku has quit [Quit: Lost terminal]
<ptsneves>
or you can create a CONVERSION_CMD and register it in CONVERSION_TYPES
<ptsneves>
a bit of trial and error, with reading the image_types.bbclass and image.bbclass should get you there
<JPEW>
RP moto-timo: I'm going to miss bug triage today; have to go kick the hardware test cluster :)
rob_w has quit [Remote host closed the connection]
<moto-timo>
JPEW: ack
<ptsneves>
i think it is a good topic for a blog post by the way :) If i have the time i will have look at it
<sotaoverride>
I havent done much of command registrations, or looked into CONVERSION_TYPES
<sotaoverride>
whats IMAGE_CMD_ext4 again, a task or something else?
<RP>
JPEW: thanks for the headsup
<sotaoverride>
where can I read up on CONVERSION_TYPES?
sakoman has joined #yocto
<sotaoverride>
qschulz: I did do a bitbake -c listtasks and the only relevant task that comes up is do_image_ext4
<sotaoverride>
for now can I just run my task after do_image_qa, would the ext4.xz be available by then?
<qschulz>
sotaoverride: you can read up on CONVERSIONTYPES in the code only at the moment unfortunately
<sotaoverride>
its weird how I cant get this to work IMAGE_POSTPROCESS_COMMAND += " do_image_zip;" either. From what Ive read ext4.xz should be avialable around this time
<sotaoverride>
im using some dunfell based bsp, let me see if its in here
<qschulz>
sotaoverride: you're very likely not reading in the proper directory
<sotaoverride>
umm so it does eventaully end up in the directroy im reading
<sotaoverride>
do these images sit elsewhere before?
<sotaoverride>
${DEPLOY_DIR_IMAGE}
<sotaoverride>
is what im thinking is the dir
<RP>
qschulz: found an issue with that patch, replied on list
<qschulz>
RP: oh. nice catch
<qschulz>
RP: we already have extensive doc, no need to make it look bigger by duplicating the content :D
<RP>
qschulz: exactly :)
thomas__ has quit [Ping timeout: 240 seconds]
<sotaoverride>
maybe I should try DEPLOYDIR rather than DEPLOY_DIR_IMAGE
<sotaoverride>
just trying everything at this point..
wkawka has joined #yocto
Guest87 has joined #yocto
vladest has quit [Remote host closed the connection]
<sotaoverride>
how do I append my own function to IMAGE_CMD_ext4 = "oe_mkext234fs ext4 ${EXTRA_IMAGECMD}"
<Guest87>
hello, I am trying to define a kernel bsp definition in-recipe and keep running into "could not locate BSP definition" error. how can i tell what files the metadata is looking for in my recipe path?
vladest has joined #yocto
* RP
has reduced the "New" count of patches in oe-core patchwork from 4000+ to 740
<michaelo>
qschulz: thanks for the notification about CONVERSIONTYPES. I added it to my notes :)
<kayterina[m]>
I have built pyinstaller, pyinstaller-contrib and altgraph all native recipes. Now in my_recipe.bb I can execute in do_compile(): "pyinstaller --clean --onedir -s ${S}/my.py "
<kayterina[m]>
In build folder I get x86 libraries. I was aiming to create for ARM. What I am missing?
<qschulz>
kayterina[m]: pyinstaller needs to cross-compile
nk058[m] has quit [Quit: You have been kicked for being idle]
rfuentess has quit [Remote host closed the connection]
<kayterina[m]>
Can't I invoke the yocto cross-compiler inside a task?
<qschulz>
kayterina[m]: you can
<qschulz>
but I assume pyinstaller needs to be told what to use
<kayterina[m]>
how do I find my cross-compiler? which...?
<qschulz>
kayterina[m]: yocto already sets environment variable correctly, but the tools might not use the environment variables or they might override them. you can check which things are available by looking at WORKDIR/temp/run.do_compile for example
<qschulz>
in there you have CC, CFLAGS and all that kind of stuff
<kayterina[m]>
Indeed. And are these known inside do_compile() ? I can invoke for example $CC or give it as an argument to pyinstaller to use/
<qschulz>
what is inside run.do_compile file is what's usable by it
<qschulz>
so yes, you should be able to use $CC directly in there
<kayterina[m]>
I will try tomorrow,thank you schulz
<qschulz>
kayterina[m]: good luck! let us know how it goes :)
<qschulz>
also, why do you want to not include the interpreter in the image (which I assume is why you want to use pyinstaller?)
seninha has quit [Quit: Leaving]
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 246 seconds]
seninha has joined #yocto
<sotaoverride>
why doesnt addtask do_image_zip after do_image_complete
<sotaoverride>
work and adding a before does?
<sotaoverride>
is it valid behvior to have it work only with a before, or just a bug?
florian_kc has quit [Ping timeout: 240 seconds]
Bardon_ has quit [Ping timeout: 240 seconds]
Bardon has joined #yocto
amahnui1 has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<rburton>
you've added a task called image_zip that depends on image_complete running
<rburton>
do you expect it to run if you do 'bitbake recipename'?
<rburton>
because you've not added into the dependency chain, it's a separate branch
<rburton>
https://flowchart.fun/f#CYew+gTiIC4GYGcBQACFowEsC2BDA5gKZgBemADquuDgcQMYjbkA2hMhVaGARgK6YWwIA <-- when you 'bitbake recipe' you're actually doing 'bitbake recipe:do_build'
<rburton>
so now you can see why your task doesn't run