Wednesday, 2019-11-06

*** vineela <vineela!~vtummala@134.134.139.83> has quit IRC00:13
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC00:16
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC00:30
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:38
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC00:54
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC00:59
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto01:01
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto01:05
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto01:06
khemmarler8997: install it directly from {WORKDIR}01:14
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC01:47
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has joined #yocto01:48
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC01:54
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto01:55
zhangzhiHello, if I modified do_install() but didn't touch do_compile() at all, will do_compile() also be processed?02:10
zhangzhifrom my local test, do_compile() won't be called. but sometimes it's called. I have no idea why02:26
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC02:26
zeddiid_thomas:  you need to set KCONFIG_MODE to “alldefconfig”02:38
zeddiiif it isn’t a *full* .config02:38
zeddiibut I’d have to see the defconfig you are using to know which it actually is.02:38
*** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto03:55
*** camus <camus!~Instantbi@58.38.93.197> has joined #yocto03:59
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC04:00
*** camus is now known as kaspter04:00
*** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto04:51
*** vineela <vineela!~vtummala@134.134.137.73> has quit IRC04:55
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto05:08
*** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto05:50
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto06:16
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC06:18
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto06:19
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto06:21
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:27
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC06:29
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto06:31
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC06:34
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto06:34
thomasd13Good morning: Short question about starting an application during booting the machine: Whats a common strategy to provide "systemd" and "init.d" recipes (which start the application at boot), whereby the machine configuration pulls the correct one?06:39
thomasd13Either systemd variant or init.d, depending which init-system the machine uses06:40
kroonthomasd13, write both a systemd service and an init script, let yocto pick whatever is configured for the distro06:51
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto06:55
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto07:10
thomasd13kroon thats what I did. I wrote systemd service and init script. I'm searching a way of HOW to let yocto (automatically) pick whatever is configured. Can you give me a hint how to accomplish this?07:13
thomasd13For now I just append manually append the specific installation package (either init.d or systemd) to the image07:14
letothe2ndthomasd13: i usually refer to the dropbear recipes, those serve as a good example for that07:15
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:16
thomasd13 letothe2nd thanks for the hint07:18
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC07:21
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC07:25
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:30
*** olani <olani!user@nat/axis/x-ppeaugbxufupzucg> has joined #yocto07:30
*** marler8997 <marler8997!0f41fc0e@ztxe01hpics304.austin.hp.com> has quit IRC07:33
*** frsc <frsc!~frsc@243-74-142-46.pool.kielnet.net> has joined #yocto07:42
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:43
olaniSaur: Testing my connection, can you see this? /Ola07:45
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC07:50
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:15
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:16
*** farnerup <farnerup!~farnerup@185.224.57.161> has joined #yocto08:18
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:22
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:37
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC08:48
*** camus <camus!~Instantbi@222.67.188.180> has joined #yocto08:51
*** kaspter <kaspter!~Instantbi@58.38.93.197> has quit IRC08:52
*** camus is now known as kaspter08:52
*** florian_kc is now known as florian08:52
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has joined #yocto08:55
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto08:57
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has joined #yocto09:06
*** yann <yann!~yann@85.118.38.73> has joined #yocto09:11
*** farnerup <farnerup!~farnerup@185.224.57.161> has quit IRC09:14
*** kaspter <kaspter!~Instantbi@222.67.188.180> has quit IRC09:15
*** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto09:15
Saurolani: Yes, I can.09:17
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC09:18
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto09:20
alessioigorgood morning!09:25
alessioigorDid someone ever use init-install-efi?09:25
alessioigorIt is a script to install an image on the target.09:26
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC09:36
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC09:37
*** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto09:38
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:44
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC09:47
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto09:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:48
*** timblechmann <timblechmann!~quassel@2001:e68:5420:d748:6d1e:3eee:e69a:7fb0> has joined #yocto09:51
timblechmannhi! is there a good way to debug, why a specific package is rebuilt? it seems that the do_rootfs step is executed for my builds, although the package content doesn't seem to have changed09:52
letothe2ndtimblechmann: the do_rootfs stage is always carried out, IIRC.09:53
letothe2ndRP: what was the rationale behind it?09:54
timblechmannletothe2nd: ah, i see. i'm currently trying to work on a recipe that unifies multiple btrfs partition images as subvolumes of another btrfs partition09:55
letothe2ndtimblechmann: completely out of my area of expertise, sorry. can only give generic advice there09:55
qschulztimblechmann: bitbake-diffsigs can be your friend :)09:56
letothe2ndso you are basically channeling a number of images into subvolumes of some master-image?09:56
timblechmannletothe2nd: exactly09:57
letothe2ndtimblechmann: interesting usecase :)09:58
timblechmannnasty: have to mount the images as loopback devices in a docker container as subvolumes only work on mounted partitions ...09:58
qschulztimblechmann: https://wiki.yoctoproject.org/wiki/images/1/18/Yocto_Summit_Lyon_Day2_2019.pdf slides 69 and 70 if bitbake-diffsigs works for your usecase09:58
timblechmannqschulz: will give it a try!09:59
mcfriskhi, I've backported cve check fixes from master/zeus to sumo in 47 or so patches. should I submit them to the mailing list? I guess from yocto project point of view sumo is dead but users like me could still care.10:00
letothe2ndmcfrisk: guess its mostly about the oe core part? in that case, sure, make a series and put it onto the oe-core list10:02
letothe2ndmcfrisk: nothing is dead as long as somebody cares for it.10:02
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto10:07
mcfriskletothe2nd: exactly. I'll post the patches then.10:08
mcfriskif no-one maintains sumo branch anymore due to builder etc issues, would be nice if someone could still just pick the patches to sumo-next even without any testing.10:08
*** jgrossholtz <jgrossholtz!~jgrosshol@249.164.25.93.rev.sfr.net> has quit IRC10:09
mcfriskoh, my gcc 7.4 update patches are also not on sumo which still uses 7.3 then.10:13
letothe2ndmcfrisk: just put it on the list to get started, we'll try and find somebody to take it up10:17
RPletothe2nd: do_rootfs doesn't always rerun10:19
RPshould only run when something changed10:19
letothe2ndRP: then i didn't RC, as so often! :)10:19
letothe2ndtoo bad my brain doesn't have ECC10:22
kroondo_rootfs likes to re-run when using rm_work10:23
kroonhttps://bugzilla.yoctoproject.org/show_bug.cgi?id=1321210:24
yoctiBug 13212: normal, Medium+, 3.1, akuster, NEW , image_qa task is always triggered with rm_work class enabled10:24
mcfriskletothe2nd: already there http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278049.html but due to problems with thud not applied in sumo either10:24
letothe2ndmcfrisk: need to poke some USians later :)10:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:26
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC11:20
*** kanavin_ <kanavin_!~kanavin@141.113.66.202> has joined #yocto11:22
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto11:23
*** kanavin <kanavin!~kanavin@141.113.64.159> has quit IRC11:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:29
mcfriskis it known that DISTRO_FEATURES += breaks build of glibc-locale in sumo, possibly other branches, and users should use DISTRO_FEATURES_append instead?11:31
*** kanavin__ <kanavin__!~kanavin@141.113.64.159> has joined #yocto11:35
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:37
*** kanavin_ <kanavin_!~kanavin@141.113.66.202> has quit IRC11:38
*** berton <berton!~berton@181.220.83.67> has quit IRC11:39
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:40
mcfriskhow long do "bitbake world" builds take? less than a day on fast 40 core machine with 128 gigs of ram and ssd? how likely are they to fail?11:48
RPseebs: if/when you're around I have some hopefully simple questions as pseudo is confusing me11:49
RPkroon: if you use rm_work that is hardly surprising11:50
RPkroon: hmm, I guess its not clearcut11:52
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC12:00
*** farnerup <farnerup!~farnerup@185.224.57.161> has joined #yocto12:04
kroonRP, the person who reported the bug suggested a change that did seem to work for me, but I can't review the patch with confidence12:06
kroonif there is an rm_work expert reading the ml I can create a patch and post it12:07
RPkroon: please do post it as it would be easier than untangling the patch from the bug report12:08
RPkroon: the expert is probably me, much as I dislike rm_work12:09
kroonRP, :-) I like its functionality since it means I can build my images in tmpfs12:10
kroonRP, i'll post a patch then12:11
* RP should rewrite that stamps function so its readable :/12:13
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC12:17
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto12:17
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto12:18
mcfriskrm_work keeps me from killing disks and ssds and needing 4TB for each build machine..12:19
mcfriskso thanks for it!12:20
mcfriskfwiw, I don't build in tmpfs but I do pin all writes to memory with kernel vm tunings which spills over to disk writes only if memory runs low. The size of build tmp is way too big for tmpfs in our builds.12:27
kroonmcfrisk, that sounds interesting12:36
*** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC12:43
rburtonmcfrisk: what are you building where tmpfs is too small even with rm_work?12:43
kroonI know icedtea7-native sure eats a lot of disk..12:45
rburtoni 'only' have a 12g or so tmpfs and its just webkit that causes issues, especially if it ends up building in parallel to clang12:47
*** olani <olani!user@nat/axis/x-ppeaugbxufupzucg> has quit IRC12:50
mcfriskrburton: yes, tmpfs is too small even with rm_work. I'm building too much, too much C++ stuff. Also estimating the tmpfs size feels impossible with sstate cache and mirror.12:53
*** BloodSurfer <BloodSurfer!d9598b8a@proxy-str.vector.com> has joined #yocto12:55
*** farnerup <farnerup!~farnerup@185.224.57.161> has quit IRC12:55
mcfriskI basically just trust kernel page cache, tuned with: /proc/sys/vm/dirty_background_bytes: 0 /proc/sys/vm/dirty_background_ratio: 90 /proc/sys/vm/dirty_bytes: 0 /proc/sys/vm/dirty_expire_centisecs: 4320000 /proc/sys/vm/dirty_ratio: 60 /proc/sys/vm/dirtytime_expire_seconds: 432000 /proc/sys/vm/dirty_writeback_centisecs: 012:59
mcfriskI've added eatmydata, LD_PRELOAD=libeatmydata.so and LD_LIBRARY_PATH=/usr/lib/libeatmydata to avoid sync() and fsync() calls from various tools.13:00
BloodSurferHeyho guys. I've got a problem and hope to find some hints here. I want to setup a HAB chain of trust based on a i.MX6Q. So far I already migrated from zImage to fitImage including a valid and verified hash (sha256). The next step would be to sign the fitImage and convice barebox to verify the signature. In the menuconfig of barebox I found the13:00
BloodSurferoption for barebox to verify the signature of the fitImage. Unfortunately I can't wrap my head around where to tell the barebox recipe it should look for the trusted pubkey. The only location a key location can be configured is inside the HAB portion of the barebox configuration. Is this the correct location? The root of trust I didn't touch yet13:00
BloodSurfersince I'd need to deal with NXP's CST toolchain and I wanted to postpone this step to later.13:00
mcfriskthen eventually rm_work comes and cleans temp files away. after a build the images and new sstate cache are available in page cache. a new CI build on same machines cleans the old ones away without flushing to disk, unless memory runs out.13:01
BloodSurferThe BSP is use comes from Phytec as the eval board I am using13:01
BloodSurferI use*13:01
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC13:01
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto13:04
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto13:13
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has quit IRC13:20
RPmcfrisk: that approach makes sense to me FWIW13:21
RPseebs: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=644638899538baf74f8ffbc47aff76dcb513bea0 is probably horrific but appears to work13:22
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto13:23
RPseebs: updated to fix the rdev major/minor writeback13:26
d_thomaszeddii, thanks I have the defconfig working.  Turns out the problem is the bbappend file I'm using to add a configuration fragment on top of the defconfig.  I must be picking up something from kernel-yocto I don't want or, like you said, not setting something right13:33
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC13:33
*** georgem_ is now known as georgem13:36
zeddiid_thomas. unless you are using one of the reference BSPs or kernel types, you won't get anything automatically added by kernel-yocto, it has no heuristics in that area, it can only do what you ask.13:37
zeddiithe only thing that it does assume, is that if a file called "defconfig" is present, that it is a full config, so it starts the merge_config process with an "allnoconfig". so if your defconfig is expecting other defaults to save the day, that won't happen.13:38
zeddiihence why people say "my defconfig was ignored" .. it wasn't, but it was applied on top of a different base than you might have thought.13:38
d_thomasI'm using a kernel from meta-atmel  (https://pastebin.com/RLD266m6) with a full config.  That stand alone is working correctly.  But then I created this bbappend file (https://pastebin.com/HHFWxkt8) so I could also use configuration fragments13:40
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto13:40
d_thomasallnoconfig is what I expect, I see what you are saying there13:41
zeddiiis everything public ? I'd be interested to run a configure myself, since it should be easy to add what you want. I can poke at the layer to see if something is being clobbered.13:42
d_thomasIt's not, but I can break the kernel out and make it public.13:43
zeddiiI don't see any extra includes in that recipe you pasted, so it should be the default kernel.bbclass configure that fires.13:44
zeddiiwhich means I should be able to figure it out from here.13:44
zeddiican you repeat the symptom you are seeing ? I think I missed that part :D13:44
zeddiiyour fragment's settings aren't showing up in the final .config ?13:44
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto13:47
d_thomasIf I delete the bbappend file and build, the defconfig is used.  If I restore the bbappend file, it appears the settings from the fragment are the only ones that are used in the final config.13:47
zeddiiwhat release of yocto are you using ?13:48
d_thomasMy test is comparing to a standalone kernel build.  No bbappend file, the Yocto result matches the stand alone build since they use the same defconfig.  Add the bbappend and the Yocto result is wildly different.13:48
d_thomasSumo13:48
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC13:48
*** yann <yann!~yann@85.118.38.73> has quit IRC13:48
d_thomasOld I know, but that's what the meta-atmel instructions started me on13:49
zeddiilet me check that a bit, that behaviour really shouldn't be possible. I need to see if there's an issue in the bbclass of that release.13:49
d_thomasThank you!13:49
*** camus is now known as kaspter13:49
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC13:52
*** yann <yann!~yann@85.118.38.73> has joined #yocto13:55
d_thomaszeddii, full source is here https://github.com/dthomas-sensonix/meta-experimental13:58
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto14:00
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC14:00
*** camus is now known as kaspter14:00
*** learning1 <learning1!~pi@121.122.92.2> has joined #yocto14:01
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto14:01
zeddiid_thomas, cool. I'll clone that and fire up a build if my code inspection fails to find the cause.14:02
d_thomaszeddii, thank you!14:03
d_thomasAdding the configuration fragments to this recipe is new, so it's very possible I'm doing something wrong.14:03
*** learningc <learningc!~pi@121.122.92.70> has quit IRC14:04
zeddiid_thomas: when you dump the environment (i.e. bitbake -e), you can see that the defconfig is before the fragment on the SRC_URI, correct ?14:08
d_thomasI see SRC_URI=""14:10
RPkroon: that patch looks right, I think I just want to rewrite that function to be a bit more understandable :/14:10
RPkroon: the " Ensure we don't 'stack' setscene extensions to thi" is what I really don't like14:11
zeddiid_thomas: and 2nd, can you dig out the merge_config_build.log ? its in your kernel's ${S}/.kernel-meta/cfg/merge_config*.log14:12
zeddiid_thomas: it may have started as SRC_URI="", but there should be other updates to it, so you'll see the finalized value with the repo/tarball + defconfig + your fragment.14:12
*** yann <yann!~yann@85.118.38.73> has quit IRC14:12
*** yann <yann!~yann@85.118.38.73> has joined #yocto14:13
d_thomasI'll look... what is ${S} likely to be?  In the /tmp/work directory?14:13
zeddiitmp/work-shared/<your machine>/kernel-source/.kernel-meta/14:14
*** copycat88 <copycat88!~copy@195.20.130.1> has joined #yocto14:15
d_thomasweird, SRC_URI isn't in that file14:16
zeddiiah. that was for the merge_config output,14:16
zeddiito get the full SRC_URI, you'd just "bitbake -e virtual/kernel" > foo.txt14:16
zeddiiand look in foo.txt14:16
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto14:17
d_thomasSRC_URI="git://github.com/linux4sam/linux-at91.git;protocol=git;branch=linux-4.19-at91 file://defconfig file://custom.cfg"14:17
zeddiiyup. that looks sane. the merge_config log file will indicate if both were processed when creating the .config or not. or if there was some other error.14:18
d_thomasYeah, that log shows defconfig as the base and the custom.cfg merging in14:21
zeddiiok. so it is all being used properly. So unless something else is coming along and clobbering the .config, there's nothing obviously wrong from the logs.14:21
zeddiiand did you try explictly setting the KCONFIG_MODE in your bbappend ?14:22
zeddiii.e. KCONFIG_MODE = "alldefconfig" ?14:22
d_thomasOops, not yet.  I'll try that now14:22
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC14:25
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC14:27
kroonRP, you mean cleaning up by using case fallthrough or something ?14:28
d_thomasThat was it!  I"m sorry, when I read about that change this morning I thought you meant to add that to the bb file.  Before doing it, I tried another experiment and got distracted.14:29
d_thomasSo what does "alldefconfig" do in the context of the bbappend file?14:29
zeddiinothing14:30
zeddiiwell, it sets a variable that is used by the kernel-yocto bbclass to feed into merge_config14:31
zeddiisince it is a recipe space variable, and you have a bappend, that's where you set it (there are local.conf tricks you can play, but that's a bad idea).14:31
kroonRP, all explicitly listed cases set i=dummy, I suppose that can be factored out14:31
d_thomasOkay.... and the kernel.bbclass uses oldnoconfig when processing defconfig, right?14:32
zeddiiit uses it for any config, yes, but since it only really doesn't defconfigs, yes :D14:33
zeddiiand oldnoconfig, is just the old name for the what you are getting with merge_config.14:34
zeddiiit has changed in the newer kernel.bbclass (IIRC), but the behaviour is the same.14:34
d_thomasOkay.... so I think the ultimate answer is that my addition of configuration fragments to this particular kernel was missing an additional setting to make it work14:35
d_thomasThanks for your help zeddii14:36
zeddiicorrect. and I've gone back and forth on the default value for the processing. since switching it to defconfig would break other workflows that want a minimial config.14:36
zeddiiand putting out a warning is hard as well .. but I bet there was one I could have cherry picked from the logs. I'll ponder that and see if I can get a hint out to the console when what you were seeing happens.14:37
d_thomasthat would be great14:37
zeddiiyah. I'll raise myself a bugzilla to look into it. (before I forget).14:38
yoctiNew news from stackoverflow: Jetson Nano And Yocto/poky Zeus <https://stackoverflow.com/questions/58732068/jetson-nano-and-yocto-poky-zeus>14:38
cengiz_iohello there!14:39
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto14:39
cengiz_ioI have some binary-only .a archives and headers that I need to package for another recipe. I originally did create a recipe like myapp-deps and overridden do_install inside it to populate sysroot. however this obviously does not propagate to populate_sdk. what's the correct way of creating your own library recipes?14:41
cengiz_ioread some recipes like jpeg2000 and others from openembbedded layer index but they don't seem to have do_populate_sdk in them.14:42
cengiz_iowhat should I use to install my .a archives and .h headers to sdk, use them during building other recipes BUT NOT include them in target image?14:43
*** copycat88 <copycat88!~copy@195.20.130.1> has quit IRC14:45
dl9pfmcfrisk: do you just call eatmydata bitbake or how do you invoce it14:49
*** yann <yann!~yann@85.118.38.73> has quit IRC14:50
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:51
*** khem <khem!~khem@unaffiliated/khem> has quit IRC14:51
RPkroon: the whole thing is just hard to read/understand :/14:58
* kroon nods14:59
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto15:01
*** yann <yann!~yann@85.118.38.73> has joined #yocto15:06
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC15:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC15:07
*** walzert50 <walzert50!8667b8c4@134.103.184.196> has joined #yocto15:11
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto15:15
*** walzert50 <walzert50!8667b8c4@134.103.184.196> has quit IRC15:22
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:22
mcfriskdl9pf: I have BB_HASHBASE_WHITELIST_append = " LD_PRELOAD" and BB_HASHCONFIG_WHITELIST_append = " LD_PRELOAD" in local.conf, then LD_LIBRARY_PATH=/usr/lib/libeatmydata and LD_PRELOAD=libeatmydata.so set in script when calling bitbake. The result is that bitbake shell tasks at least have LD_LIBRARY_PATH=/usr/lib/libeatmydata:... and LD_PRELOAD='libeatmydata.so libpseudo.so' set. Some of the bitbake python15:25
mcfrisktasks don't have it set, so some sync()/fsync() calls still happen during build, but IO is reduced. Effect can be seen with pcp.io tooling for example.15:25
RPmcfrisk: I thought pseudo was intercepting those?15:30
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto15:31
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC15:32
RPmcfrisk: "CFH" means?15:41
* RP ponders how we'd manage to build sumo now :/15:41
*** CarlGel <CarlGel!~Rika-chan@unaffiliated/carlgel> has joined #yocto15:46
mcfriskRP: call for help15:48
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto15:53
RPmcfrisk: as in you'd like to get those merged to sumo?15:55
mcfriskRP: yep15:57
mcfriskor to sumo-next or sumo-contrib if you prefer15:57
letothe2ndmcfrisk: i actually intended to poke armpit about it once he's around15:57
RPmcfrisk: the hard part is testing, not merging :/15:57
mcfriskI know15:57
RPFWIW I just hacked the autobuilder, see if I can persuade it to build sumo on a reduced set of workers15:58
mcfriskI build on Debian stale, Debian GNU/Linux 9 (stretch), containers15:59
mcfrisk(better than Ubuntu which has copyright issues distributing container images)15:59
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC15:59
RPmcfrisk: sure, but that doesn't help me with the autobuilder...16:00
RPletothe2nd: armpit is onvacation16:00
letothe2ndRP: ah!16:02
* letothe2nd decides that this is not IRC approved.16:03
milloniis there something like `bitbake -e` bit without expanding variables in tasks?16:06
RPmilloni: shell or python?16:07
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC16:07
rburtonmilloni: adding unexpand is a two line patch to https://github.com/rossburton/bb/blob/master/libexec/bb-var16:08
milloniRP: both16:09
millonirburton: i'll take a look, thanks16:10
RPmilloni: d.getVar(name, expand=False) if python16:11
rburtonmilloni: just pushed --unexpand to that tool16:11
rburton$ bb var WORKDIR m4 -u16:12
rburton${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}16:12
rburtonthe syntax is now ugly as sin, but i can fix that another time16:12
cengiz_iowhile creating a recipe, what should I use to install my .a archives and .h headers to sdk, use them during building other recipes BUT NOT include them in target image?16:22
mcfriskcengiz_io: install to -dev binary package. see examples in poky tree.16:23
cengiz_iomcfrisk: will do. thanks.16:23
mcfriskcengiz_io: for many build systems bitbake and build bbclasses do this automatically if headers and static libs are installed from do_install()16:24
cengiz_iomcfrisk well my problem is: I have a cmake app which is pulled from git but it has some binary only huge .a files and headers16:25
cengiz_iowhich are also architecture dependent. (we need to compile for x86_64 and armv7)16:25
cengiz_ioit's a huge mess. so I have created another recipe called myapp-deps and it overrides do_install and copies everything to sysroot.16:26
rburtoncengiz_io: just package them like the system defaults to.  .a files go into -staticdev packages, which are not in images or sdks by default16:26
cengiz_iorburton are those -staticdev packages derived from regular recipes? couldn't find anything about them in reference manual..16:27
rburtoncengiz_io: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#including-static-library-files16:28
rburtonthat keeps them out of images. to get that specific recipe in the sdk add it to TOOLCHAIN_TARGET_TASK16:29
cengiz_ioexcuse my ignorance but that example doesn't have any SRC_URI or something. does it?16:30
cengiz_iorburton because I don't build those libraries. they are simply binary files shared with me.. can't reproduce them.16:31
rburtoncengiz_io: thats not an example, its a fragment of bitbake.conf16:31
cengiz_iooh ok. I guessed so16:31
rburtonwrite a recipe to grab the files and install them to $D correctly16:31
rburtonthem the default packaging rules will do the right thing16:31
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:31
cengiz_ioso if I copy to a specific directory, bitbake will move them to PN-staticdev etc16:32
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:32
rburtonno16:32
rburton$libdir/*.a goes to static lib16:32
rburton$libdir/lib*.so -> -dev16:33
rburton$libdir/lib*.so.* -> PN16:33
*** camus <camus!~Instantbi@222.67.188.174> has joined #yocto16:33
rburtonbecause that's how libraries are laid out on linux16:33
cengiz_ioI got it now. what about headers? I think I can read that conf fragment to find out16:34
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC16:35
*** camus is now known as kaspter16:35
rburtoncengiz_io: install them to $includedir16:38
cengiz_iorburton yes but there are hundreds of them and they are in levels of subdirs.. does it make a difference?16:39
rburtonno16:39
rburtonthe default rule is "all of $includedir"16:39
cengiz_iothen include myapp-dev in TARGET_HOST_TASK_append right?16:39
cengiz_iofor sdk16:39
cengiz_iosorry16:40
cengiz_ioTOOLCHAIN_TARGET_TASK16:40
rburtonif myapp is already in the image then -dev will be added automatically16:40
rburtonotherwise, yes16:40
cengiz_ioit doesn't make sense to ship headers in final rootfs image so16:40
zeddii4 kernel config and module questions in the last 24 hours, something in the water ?16:41
*** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto17:05
*** frsc <frsc!~frsc@243-74-142-46.pool.kielnet.net> has quit IRC17:05
*** vineela <vineela!~vtummala@134.134.137.75> has quit IRC17:08
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto17:13
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC17:14
*** camus is now known as kaspter17:14
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:17
RPmcfrisk: good news is that after much banging of heads against the wall I've figured out the magic to restrict a build to a subset of workers...17:19
RPNot sure it can build a full build without more tweaking due to selftest though...17:20
ruru4143where are image_features defined and can i add costum image features?17:27
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:36
mcfriskRP: :)17:49
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto17:50
mcfriskruru4143: check output of "bitbake -e myimage", find location of ^IMAGE_FEATURES and check which recipes, classes, distro configuration etc contribute17:51
RPmcfrisk: I've replied on the list. I worry where this path leads :(17:53
*** yann <yann!~yann@85.118.38.73> has quit IRC17:55
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC18:06
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC18:11
*** camus <camus!~Instantbi@101.93.194.160> has joined #yocto18:11
*** camus is now known as kaspter18:14
*** vmeson <vmeson!~rmacleod@S0106c05627277493.va.shawcable.net> has quit IRC18:23
mcfriskRP: I understand the concerns. if I were to setup a project, without funding, to maintain sumo in a public git tree, could I still use some of the Yocto Project infrastructure? wiki, mailing list, git server?18:23
*** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has joined #yocto18:24
*** vmeson <vmeson!~rmacleod@S0106c05627277493.va.shawcable.net> has joined #yocto18:24
* mcfrisk will maintain sumo anyway. question is just about if I will publish the work, and where to publish the work.18:27
*** vmeson <vmeson!~rmacleod@S0106c05627277493.va.shawcable.net> has quit IRC18:30
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:31
RPmcfrisk: I think the TSC needs to discuss this18:34
RPhmm, sumo threw uninative errors :(18:36
mcfriskouch18:36
mcfriskwill reply to the list too. TSC discussion and possible decisions are needed, sure.18:37
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC18:38
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC18:38
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto18:41
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto18:50
rburtonruru4143: the documentation has a list18:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:55
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC19:02
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto19:04
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto19:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:08
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:20
*** florian_kc is now known as florian19:21
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC19:33
RPHmm, sumo shows a lot of warnings :(19:33
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto19:33
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC19:33
RPseebs: is there any mechanism in pseudo to detect if a function is present and only enable the code if so?19:35
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto19:35
seebsports/subports19:38
seebshave a look at the linux/clone code, which existed because of the multi-year-gap between "management has promised we can stop supporting RHEL4" and "we can actually stop supporting RHEL4"19:39
RPseebs: thanks, that is the pointer I needed :)19:49
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC19:52
*** BloodSurfer <BloodSurfer!d9598b8a@proxy-str.vector.com> has quit IRC20:07
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto20:15
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:16
*** aidanh_ is now known as aidanh20:16
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto20:19
*** aehs29 <aehs29!~aehs29@149.199.62.131> has quit IRC20:21
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC20:21
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC20:22
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto20:31
RPseebs: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ac02f30e3759b64ba402a2129f015fe70f2ad566 is slowly improving20:34
fraythat looks a lot less bad then I was expecting basedon the previous discussion20:44
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto20:45
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC20:47
RPfray: that doesn't mean I have this right :)20:48
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto20:52
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC20:57
seebsthat looks reasonable to me, i think?21:05
RPseebs: it seems to work...21:07
RPseebs: running tests now...21:07
mischiefwhy does systemd in yocto use /lib rather than /usr/lib?21:07
fraybecause everyone else is wrong?21:07
fray /lib is available on boot.. /usr/lib isn't available until filesystems are mounted..21:08
frayif you enable the usrmerge.. then it's all the same, and /usr/lib is used.. but you can no longer do / and /usr separation (much less used today then it used to be)21:08
RPfray: not the mounting thing again? :)21:09
frayjust explaining why /lib vs /usr/lib21:09
mischiefis usrmerge documented somewhere?21:09
RPfray: I'll mention NFS ;-)21:09
mischieffray: i am just confused because i am trying to make a recipe for a program with a systemd unit.21:11
mischiefthe binary is installed to /usr/bin but it looks like yocto's systemd.bbclass expects the systemd unit in /lib/systemd/system ..21:11
frayLook at other recipes with systemd components and use teh same ${....}21:11
frayusrmerge is a distro feature that changes the 'root_prefix' from 'base_prefix' (/) to exec_prefix (/usr)21:12
*** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto21:13
mischieffray: "/lib is available on boot.. /usr/lib isn't available until filesystems are mounted.." - so in my situation a unit in /lib would be available at boot time but not the corresponding binary in /usr/bin? that doesn't make any sense21:13
RPhmm, dynamically re-configuring the autobuilder code from under it only works to a point...21:13
frayin that case, you would need to set a dependency on mount21:13
RPmischief: there is a variable to use for installing unit files21:13
mischiefi know, i'm just trying to understand conceptually why it is the way it is21:14
fray${systemd_unitdir}21:14
* RP suspects nobody does this with filesystems anymore21:15
fraybasically there are systems that have small root filesystems, and then will put most of the code into /usr..  like I said, they are significantly more rare now then it used to be21:15
frayRP I saw someone do this last year still21:15
mischieffray: having to set RequiresMountsFor=/usr on every unit makes little sense as well21:15
fraythey had to adjust things to ensure that filesystems were mounted early.. but otherwise it worked for their config21:15
*** berton <berton!~berton@181.220.83.67> has quit IRC21:16
mischiefanyway, it matters little i guess since we have no separate /usr fs21:16
mischiefill adjust where i install the unit to /lib..21:16
fraydon't use /lib directly.. use the variable ${systemd_unitdir}21:17
mischiefi know, but i need to adjust my build system to take an argument of where to install21:17
frayof if using oe.. do_install { .. if [ $D/usr/lib != ${systemd_unitdir} ; then mv $D/usr/lib/.... ${systemd_unitdir}/...; fi }21:18
mischiefi am using meson for my program :)21:19
frayYes, but are you controlling it from OE or is it external.. if it's external you are on your own.. if you are using OE.. then you can do whatever in do_install21:19
mischiefcool, systemd pkgconfig has the unit dir in it :)21:26
* RP does a double take on his hashequiv accelerated build completing when he didn't expect it to do so for an hour or two21:31
* Crofton|work wonders what is wrong with that build21:32
RPCrofton|work: I was wondering that too21:32
frayRP does the packagefeed_stability (or some other class) help feed the hash equivalency yet?21:42
RPfray: probably obsoletes it21:43
*** vmeson <vmeson!~rmacleod@S0106ac202ece3eb3.vc.shawcable.net> has joined #yocto21:44
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.129.51> has joined #yocto21:44
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto21:46
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC22:17
*** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC22:20
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC22:22
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC22:22
rburtonmischief: at the end of the day, systemd doesn't really support mounting /lib before /usr22:30
*** georgem_ <georgem_!~georgem@216.21.169.52> has joined #yocto22:30
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC22:32
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC22:33
*** georgem_ <georgem_!~georgem@216.21.169.52> has quit IRC22:42
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC23:09
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC23:25
*** bc86 <bc86!5e2d9a0f@94.45.154.15> has joined #yocto23:34
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:54

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!