<Sunny>
Does anyone know how to obtain SRC_URI's git repo URI in extenal source builds?
xmn has quit [Quit: xmn]
davidinux has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
pgowda_ has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
kanavin has quit [Ping timeout: 268 seconds]
rob_w has joined #yocto
kanavin has joined #yocto
oobitots has joined #yocto
sstiller has joined #yocto
GNUmoon has joined #yocto
mckoan|away is now known as mckoan
Schlumpf has joined #yocto
<kernelspace>
gm, trying to have a kernel 4.4 in a dunfell, but just after i get errors with gstreamer / qt. What's your suggestion ? uograde kernel as per dunfell (5.4) or trying to version-down gstreamer and other stuff ?
zpfvo has joined #yocto
camus1 has joined #yocto
goliath has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
<hmw[m]>
<sunny> "Does anyone know how to obtain..." <- do you whant to get or set the src_url of a existing recept ?
coldspark29 has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
zpfvo has joined #yocto
<JosefHolzmayrThe>
you dudX
<JosefHolzmayrThe>
*yo, even
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
<mckoan>
JosefHolzmayrThe: good morning
<coldspark29[m]>
Morning
<coldspark29[m]>
Where do I find the .config or defconfig file after having run `bitbake -c menuconfig virtual/kernel`? I can't find any changes to commit
<mckoan>
coldspark29[m]: however it is in tmp/work-shared/YOURKERNELNAME/kernel-build-artifacts
<coldspark29[m]>
Thanks
<coldspark29[m]>
I found that .config myself by now
<coldspark29[m]>
You sent me that before
<coldspark29[m]>
Now I know how to commit the changes :)
michalkotyla has quit [Quit: michalkotyla]
michalkotyla has joined #yocto
<coldspark29[m]>
mckoan: I am getting an error when trying to build though. I already have a linux-imx_5.4.bb file in the folder and created a .bbappend with the same name. Now the .bb file can't be parsed
<mckoan>
coldspark29[m]: describe "the .bb file can't be parsed"
jpuhlman has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
Sunny has quit [Ping timeout: 256 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
florian_kc has joined #yocto
leon-anavi has joined #yocto
Ad0 has quit [Ping timeout: 268 seconds]
jwillikers has joined #yocto
<JosefHolzmayrThe>
shouldn't a runqemu instance be able to access the web?
<landgraf>
JosefHolzmayrThe: it depends. you can always make it with passing additional qemu parameters
<JosefHolzmayrThe>
landgraf: have an example nearby?
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<landgraf>
JosefHolzmayrThe: qemuparams="-net user -net model=e1000" - something like that should work in most cases. you can find more info in the qemu man page (like bridging etc)
zpfvo has quit [Ping timeout: 252 seconds]
<JosefHolzmayrThe>
seems just name resolution is missing at the moment.
zpfvo has joined #yocto
<landgraf>
JosefHolzmayrThe: I prefer ` -net bridge` but it requires additional host configuration (/etc/qemu/bridge.conf modification, NAT etc).
<JosefHolzmayrThe>
landgraf: generally i absolutely agree, but this time i just need an ad-hoc hack to try one thing out, then dispose it again.
<landgraf>
JosefHolzmayrThe: then "user" is your friend.
<landgraf>
it worked for me just fine few weeks ago
<JosefHolzmayrThe>
landgraf: thanks!
<landgraf>
yw
jwillikers has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
<landgraf>
JosefHolzmayrThe: correction: It's qemuparams=" -net user -nic model=e1000 " (replace e1000 with virtio if your guest system supports this)
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
<smurray>
JosefHolzmayrThe: I tend to just use the "slirp" option to runqemu if it's outbound access I'm concerned about
<angolini>
I'm working with a tarball which brings two kernel modules source code, each one in one different sub directory. Is there a way to configure MODULES_MODULE_SYMVERS_LOCATION so the module.bbclass is able to handle the 2 modules?
jwillikers has joined #yocto
<angolini>
I'm patching a recipe with the goal of signing the modules (and for that, using module.bbclass). The do_install() cd the subdir, and execute the module_do_install. And I can have the recipe to do one, or the other, but I could not find a way to change MODULES_MODULE_SYMVER_LOCATION between the 2 executions. And I'm out of ideas
sakoman has joined #yocto
Ad0 has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
<kernelspace>
on dunfell, building qtbase_git i am getting "calculator.cpp:314:5: error: 'qApp' was not declared in this scope" ... quite strange
codavi has joined #yocto
rob_w has quit [Ping timeout: 256 seconds]
Guest95 has joined #yocto
ar__ has joined #yocto
<barath>
would anyone happen to know why, in general, config flags would not be enabled/set when building a kernel with yocto (custom "from scratch" in-recipe bsp) when building the kernel manually works just fine? yocto doesnt complain during the configcheck either. the merge_config_build.log just says that it wasnt set...
michalkotyla has quit [Read error: Connection reset by peer]
codavi has quit [Ping timeout: 240 seconds]
<rburton>
barath: you're most likely not telling the recipe to use a defconfig
<barath>
hm, do I need one? apologies if this is very noobish of me, but currently we're basically building our kernel with something like make ARCH=arm64 allnoconfig our_custom_config.conf
<barath>
I'm trying to simply replicate that with yocto. which lead me down the rabbit hole of creating my own custom bsp next to a kernel recipe based on linux-yocto-custom. so I might have screwed up something somewhere, but it's not clear to me what
<rburton>
and you're putting your config file in the kernel SRC_URI as defconfig?
<rburton>
the kernel class will run make olddefconfig if you give it a defconfig file
<zeddii>
RP, halstead: I'm technically not working .. but wanted to send my -stable kernel updates. I'm not on my regular servers, since I'm not at home. Everything I attempted to push to poky-contrib never showed up last night (sync issue ?) .. is there some known issue ? (I am pushing to push.yoctoproject.org, etc).
<zeddii>
I had some for dunfell as well that I wanted to send to steve. same issue. never showed up on contrib.
<RP>
zeddii: is it there now? The new infra is slower to mirror
<barath>
via something like file://myplatform;type=kmeta;destsuffix=myplatform
<zeddii>
RP: I gave it 8 hours and it never showed.
jpuhlman_ has joined #yocto
jpuhlman_ is now known as jpuhlman
<zeddii>
I tried pushing a branch new branch, and that didn't show either.
<RP>
zeddii: and you're pushing to push.yp.org ?
<barath>
I can see that my config is parsed and partly applied, but some config options simply arent set by the kconfig process (by inspecting logs and tracing the various kernel tooling scripts)
<zeddii>
To ssh://push.yoctoproject.org/poky-contrib
<zeddii>
this was me flailing. but again, not on my machine that I normally use. I 'm sure I've screwed something up.
<barath>
(specifically, in merge_conflict_build.log I for instance see "Value requested for CONFIG_DEBUG_INFO_BTF not in final .config Requested value: CONFIG_DEBUG_INFO_BTF=y Actual value:"
<barath>
ie an empty actual value. looking at (what I think) is the resulting .config used by yocto when compiling the kernel, that config is missing)
<RP>
zeddii: I see zedd/kernel-test, kernel-dunfell and kernel-next updated but the revision is 9 months old afd18df322349333b41b4e5572f6f5281e08b89e
<zeddii>
yah. these should be commits from last night!
<zeddii>
zedd/kernel is the one I normally use, nothing showed up.
<RP>
zeddii: timestamp is just strange
<RP>
zeddii: I didn't see zedd/kernel change
<zeddii>
yah. not sure what is going on there. I did push to zedd/kernel-dunfell to do the ones for Steve, can you see that one ? should be from yesterday as HEAD
<RP>
zeddii: kernel-dunfell shows as afd18df322349333b41b4e5572f6f5281e08b89e which is also a Mar 11 commiut
<zeddii>
yah. that's what I was seeing via the web interface as well.
<zeddii>
I just re-pushed zedd/kernel and zedd/kernel-dunfell with my ones from last night. I'm watching again.
<zeddii>
zedd/kernel just showed on the web interface. let me check dunfell
<RP>
zeddii: zedd/kernel shows linux-yocto/5.10: update to v5.10.87 now which is from yesterday
<zeddii>
yah. it behaved distincly differently just now on the push. I just up arrowed and re-did it!
<zeddii>
and kernel-dunfell now shows.
<zeddii>
I guess it's a solved problem now. I should have just re-tried the push this morning, versus checking the cgit interface to see if they finally sync'd
<zeddii>
now let me see if the pull requests will send
Minvera has joined #yocto
<RP>
zeddii: no idea what changed :/
<zeddii>
yah. no idea either. the same pull request script runs I was using last night are working .. much happier now that the commits are present! :P I'll move on and consider it a mystery.
<RP>
zeddii: merging may take a while as we're about to lose the autobuilder for a few days
<zeddii>
zero rush at all on them!
<zeddii>
I just wanted to get them onto the list in case someone wonders if I'm still tracking the latest updates :D
<RP>
zeddii: no problem, just want to ensure people know things will slow down for a bit
<zeddii>
I'll all for that. I'm only scanning email myself over terrible wifi at my parents :D
<zeddii>
at least those are sent now. I'm going for a walk in the woods with a chainsaw. If I'm typing slower in the coming weeks, you'll know it went badly.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<RP>
zeddii: we're not allowed to use chainsaws here :/
<sakoman>
zeddii: Thanks for the patches, I've got them in the patch set I'm testing on the autobuilder right now. I may lose the autobuilder before it completes . . .
ar__ is now known as akiCA
Tokamak has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
Tokamak_ has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
Sunny has joined #yocto
alimon has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
vd33 has joined #yocto
Schlumpf has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
oobitots has quit [Quit: Client closed]
Guest95 has quit [Quit: Client closed]
<sgw>
RP: Morning, In anon python() is the d (datastore) a global context or recipe context? I am trying to do a "warn once" and using d.setVar("my_warn_once", "1"), but that appears to be setting in the recipe context, thoughts?
<sgw>
rburton: ^^^
<RP>
sgw: it is recipe context
<rburton>
ah if you're emitting the message in a recipe then yeah its recipe-space
<rburton>
you can make it once-per-recipe but not once-ever
<sgw>
Is there a way to create global context variable I can set? short of touching a file?
<RP>
sgw: from a recipe context?
<rburton>
not afaik
<sgw>
RP: yes, from a recipe context (anon python() actually), my memory is probably not unless there is some bitbake trick.
vmeson has quit [Quit: Konversation terminated!]
vmeson has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
<RP>
sgw: you can't do that from recipe context, no
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<sgw>
RP: thanks, that's what I thought was going to be the answer.
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
<Sunny>
sgw: Try to set a global variable in the recipe my_warn_once=0 and try setting it to 1 in your anony function. Let me know if this helps.
<Sunny>
either set it on the top or do an export my_warn_once=0
mckoan is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
pgowda_ has quit [Quit: Connection closed for inactivity]
sstiller has quit [Quit: Leaving]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
paulg has joined #yocto
Sunny has quit [Quit: Client closed]
<vd33>
I have a special image written raw in the wks file. What variable is more suited to add this image as a dependency for do_image_wic?
* RP
isn't really seeing how we can use unshare from bitbake to create a new network namespace without bitbake itself having admin privs :(
<RP>
I'd hoped we should have some suid helper but that isn't going to work with the apis in question
<vd33>
EXTRA_IMAGEDEPENDS will pull this dependency for every images and every formats so it doesn't seem very suitable, and WKS_FILE_DEPENDS does seem to work as expected. Setting do_image_wic[depends] from a machine config looks a bit too intrusive