*** vineela <vineela!~vtummala@134.134.139.83> has quit IRC | 00:13 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 00:16 | |
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 00:30 | |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:38 | |
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC | 00:54 | |
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC | 00:59 | |
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 01:01 | |
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 01:05 | |
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 01:06 | |
khem | marler8997: install it directly from {WORKDIR} | 01:14 |
---|---|---|
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC | 01:47 | |
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has joined #yocto | 01:48 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 01:54 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:55 | |
zhangzhi | Hello, if I modified do_install() but didn't touch do_compile() at all, will do_compile() also be processed? | 02:10 |
zhangzhi | from my local test, do_compile() won't be called. but sometimes it's called. I have no idea why | 02:26 |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 02:26 | |
zeddii | d_thomas: you need to set KCONFIG_MODE to “alldefconfig” | 02:38 |
zeddii | if it isn’t a *full* .config | 02:38 |
zeddii | but 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 #yocto | 03:55 | |
*** camus <camus!~Instantbi@58.38.93.197> has joined #yocto | 03:59 | |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 04:00 | |
*** camus is now known as kaspter | 04:00 | |
*** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto | 04:51 | |
*** vineela <vineela!~vtummala@134.134.137.73> has quit IRC | 04:55 | |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:08 | |
*** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:50 | |
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 06:16 | |
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 06:18 | |
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 06:19 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:21 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:27 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 06:29 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:31 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 06:34 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:34 | |
thomasd13 | Good 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 |
thomasd13 | Either systemd variant or init.d, depending which init-system the machine uses | 06:40 |
kroon | thomasd13, write both a systemd service and an init script, let yocto pick whatever is configured for the distro | 06:51 |
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 06:55 | |
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 07:10 | |
thomasd13 | kroon 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 |
thomasd13 | For now I just append manually append the specific installation package (either init.d or systemd) to the image | 07:14 |
letothe2nd | thomasd13: i usually refer to the dropbear recipes, those serve as a good example for that | 07:15 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:16 | |
thomasd13 | letothe2nd thanks for the hint | 07:18 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:21 | |
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC | 07:25 | |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:30 | |
*** olani <olani!user@nat/axis/x-ppeaugbxufupzucg> has joined #yocto | 07:30 | |
*** marler8997 <marler8997!0f41fc0e@ztxe01hpics304.austin.hp.com> has quit IRC | 07:33 | |
*** frsc <frsc!~frsc@243-74-142-46.pool.kielnet.net> has joined #yocto | 07:42 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:43 | |
olani | Saur: Testing my connection, can you see this? /Ola | 07:45 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:50 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:15 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:16 | |
*** farnerup <farnerup!~farnerup@185.224.57.161> has joined #yocto | 08:18 | |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:22 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:37 | |
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC | 08:48 | |
*** camus <camus!~Instantbi@222.67.188.180> has joined #yocto | 08:51 | |
*** kaspter <kaspter!~Instantbi@58.38.93.197> has quit IRC | 08:52 | |
*** camus is now known as kaspter | 08:52 | |
*** florian_kc is now known as florian | 08:52 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has joined #yocto | 08:55 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 08:57 | |
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has joined #yocto | 09:06 | |
*** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:11 | |
*** farnerup <farnerup!~farnerup@185.224.57.161> has quit IRC | 09:14 | |
*** kaspter <kaspter!~Instantbi@222.67.188.180> has quit IRC | 09:15 | |
*** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 09:15 | |
Saur | olani: Yes, I can. | 09:17 |
*** zhangzhi <zhangzhi!882b00ba@136.43.0.186> has quit IRC | 09:18 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:20 | |
alessioigor | good morning! | 09:25 |
alessioigor | Did someone ever use init-install-efi? | 09:25 |
alessioigor | It 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 IRC | 09:36 | |
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 09:37 | |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 09:38 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:44 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 09:47 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 09:48 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:48 | |
*** timblechmann <timblechmann!~quassel@2001:e68:5420:d748:6d1e:3eee:e69a:7fb0> has joined #yocto | 09:51 | |
timblechmann | hi! 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 changed | 09:52 |
letothe2nd | timblechmann: the do_rootfs stage is always carried out, IIRC. | 09:53 |
letothe2nd | RP: what was the rationale behind it? | 09:54 |
timblechmann | letothe2nd: ah, i see. i'm currently trying to work on a recipe that unifies multiple btrfs partition images as subvolumes of another btrfs partition | 09:55 |
letothe2nd | timblechmann: completely out of my area of expertise, sorry. can only give generic advice there | 09:55 |
qschulz | timblechmann: bitbake-diffsigs can be your friend :) | 09:56 |
letothe2nd | so you are basically channeling a number of images into subvolumes of some master-image? | 09:56 |
timblechmann | letothe2nd: exactly | 09:57 |
letothe2nd | timblechmann: interesting usecase :) | 09:58 |
timblechmann | nasty: have to mount the images as loopback devices in a docker container as subvolumes only work on mounted partitions ... | 09:58 |
qschulz | timblechmann: https://wiki.yoctoproject.org/wiki/images/1/18/Yocto_Summit_Lyon_Day2_2019.pdf slides 69 and 70 if bitbake-diffsigs works for your usecase | 09:58 |
timblechmann | qschulz: will give it a try! | 09:59 |
mcfrisk | hi, 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 |
letothe2nd | mcfrisk: guess its mostly about the oe core part? in that case, sure, make a series and put it onto the oe-core list | 10:02 |
letothe2nd | mcfrisk: nothing is dead as long as somebody cares for it. | 10:02 |
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 10:07 | |
mcfrisk | letothe2nd: exactly. I'll post the patches then. | 10:08 |
mcfrisk | if 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 IRC | 10:09 | |
mcfrisk | oh, my gcc 7.4 update patches are also not on sumo which still uses 7.3 then. | 10:13 |
letothe2nd | mcfrisk: just put it on the list to get started, we'll try and find somebody to take it up | 10:17 |
RP | letothe2nd: do_rootfs doesn't always rerun | 10:19 |
RP | should only run when something changed | 10:19 |
letothe2nd | RP: then i didn't RC, as so often! :) | 10:19 |
letothe2nd | too bad my brain doesn't have ECC | 10:22 |
kroon | do_rootfs likes to re-run when using rm_work | 10:23 |
kroon | https://bugzilla.yoctoproject.org/show_bug.cgi?id=13212 | 10:24 |
yocti | Bug 13212: normal, Medium+, 3.1, akuster, NEW , image_qa task is always triggered with rm_work class enabled | 10:24 |
mcfrisk | letothe2nd: already there http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278049.html but due to problems with thud not applied in sumo either | 10:24 |
letothe2nd | mcfrisk: need to poke some USians later :) | 10:26 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:26 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:26 | |
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 11:20 | |
*** kanavin_ <kanavin_!~kanavin@141.113.66.202> has joined #yocto | 11:22 | |
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 11:23 | |
*** kanavin <kanavin!~kanavin@141.113.64.159> has quit IRC | 11:24 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:29 | |
mcfrisk | is 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 #yocto | 11:35 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:37 | |
*** kanavin_ <kanavin_!~kanavin@141.113.66.202> has quit IRC | 11:38 | |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 11:39 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:40 | |
mcfrisk | how 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 |
RP | seebs: if/when you're around I have some hopefully simple questions as pseudo is confusing me | 11:49 |
RP | kroon: if you use rm_work that is hardly surprising | 11:50 |
RP | kroon: hmm, I guess its not clearcut | 11:52 |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC | 12:00 | |
*** farnerup <farnerup!~farnerup@185.224.57.161> has joined #yocto | 12:04 | |
kroon | RP, the person who reported the bug suggested a change that did seem to work for me, but I can't review the patch with confidence | 12:06 |
kroon | if there is an rm_work expert reading the ml I can create a patch and post it | 12:07 |
RP | kroon: please do post it as it would be easier than untangling the patch from the bug report | 12:08 |
RP | kroon: the expert is probably me, much as I dislike rm_work | 12:09 |
kroon | RP, :-) I like its functionality since it means I can build my images in tmpfs | 12:10 |
kroon | RP, i'll post a patch then | 12: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 IRC | 12:17 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 12:17 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 12:18 | |
mcfrisk | rm_work keeps me from killing disks and ssds and needing 4TB for each build machine.. | 12:19 |
mcfrisk | so thanks for it! | 12:20 |
mcfrisk | fwiw, 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 |
kroon | mcfrisk, that sounds interesting | 12:36 |
*** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 12:43 | |
rburton | mcfrisk: what are you building where tmpfs is too small even with rm_work? | 12:43 |
kroon | I know icedtea7-native sure eats a lot of disk.. | 12:45 |
rburton | i 'only' have a 12g or so tmpfs and its just webkit that causes issues, especially if it ends up building in parallel to clang | 12:47 |
*** olani <olani!user@nat/axis/x-ppeaugbxufupzucg> has quit IRC | 12:50 | |
mcfrisk | rburton: 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 #yocto | 12:55 | |
*** farnerup <farnerup!~farnerup@185.224.57.161> has quit IRC | 12:55 | |
mcfrisk | I 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: 0 | 12:59 |
mcfrisk | I'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 |
BloodSurfer | Heyho 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 the | 13:00 |
BloodSurfer | option 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 yet | 13:00 |
BloodSurfer | since I'd need to deal with NXP's CST toolchain and I wanted to postpone this step to later. | 13:00 |
mcfrisk | then 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 |
BloodSurfer | The BSP is use comes from Phytec as the eval board I am using | 13:01 |
BloodSurfer | I use* | 13:01 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 13:01 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 13:04 | |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto | 13:13 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has quit IRC | 13:20 | |
RP | mcfrisk: that approach makes sense to me FWIW | 13:21 |
RP | seebs: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=644638899538baf74f8ffbc47aff76dcb513bea0 is probably horrific but appears to work | 13:22 |
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 13:23 | |
RP | seebs: updated to fix the rdev major/minor writeback | 13:26 |
d_thomas | zeddii, 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 right | 13:33 |
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC | 13:33 | |
*** georgem_ is now known as georgem | 13:36 | |
zeddii | d_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 |
zeddii | the 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 |
zeddii | hence 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_thomas | I'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 fragments | 13:40 |
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 13:40 | |
d_thomas | allnoconfig is what I expect, I see what you are saying there | 13:41 |
zeddii | is 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_thomas | It's not, but I can break the kernel out and make it public. | 13:43 |
zeddii | I don't see any extra includes in that recipe you pasted, so it should be the default kernel.bbclass configure that fires. | 13:44 |
zeddii | which means I should be able to figure it out from here. | 13:44 |
zeddii | can you repeat the symptom you are seeing ? I think I missed that part :D | 13:44 |
zeddii | your fragment's settings aren't showing up in the final .config ? | 13:44 |
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 13:47 | |
d_thomas | If 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 |
zeddii | what release of yocto are you using ? | 13:48 |
d_thomas | My 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_thomas | Sumo | 13:48 |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 13:48 | |
*** yann <yann!~yann@85.118.38.73> has quit IRC | 13:48 | |
d_thomas | Old I know, but that's what the meta-atmel instructions started me on | 13:49 |
zeddii | let 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_thomas | Thank you! | 13:49 |
*** camus is now known as kaspter | 13:49 | |
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 13:52 | |
*** yann <yann!~yann@85.118.38.73> has joined #yocto | 13:55 | |
d_thomas | zeddii, full source is here https://github.com/dthomas-sensonix/meta-experimental | 13:58 |
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 14:00 | |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 14:00 | |
*** camus is now known as kaspter | 14:00 | |
*** learning1 <learning1!~pi@121.122.92.2> has joined #yocto | 14:01 | |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 14:01 | |
zeddii | d_thomas, cool. I'll clone that and fire up a build if my code inspection fails to find the cause. | 14:02 |
d_thomas | zeddii, thank you! | 14:03 |
d_thomas | Adding 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 IRC | 14:04 | |
zeddii | d_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_thomas | I see SRC_URI="" | 14:10 |
RP | kroon: that patch looks right, I think I just want to rewrite that function to be a bit more understandable :/ | 14:10 |
RP | kroon: the " Ensure we don't 'stack' setscene extensions to thi" is what I really don't like | 14:11 |
zeddii | d_thomas: and 2nd, can you dig out the merge_config_build.log ? its in your kernel's ${S}/.kernel-meta/cfg/merge_config*.log | 14:12 |
zeddii | d_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 IRC | 14:12 | |
*** yann <yann!~yann@85.118.38.73> has joined #yocto | 14:13 | |
d_thomas | I'll look... what is ${S} likely to be? In the /tmp/work directory? | 14:13 |
zeddii | tmp/work-shared/<your machine>/kernel-source/.kernel-meta/ | 14:14 |
*** copycat88 <copycat88!~copy@195.20.130.1> has joined #yocto | 14:15 | |
d_thomas | weird, SRC_URI isn't in that file | 14:16 |
zeddii | ah. that was for the merge_config output, | 14:16 |
zeddii | to get the full SRC_URI, you'd just "bitbake -e virtual/kernel" > foo.txt | 14:16 |
zeddii | and look in foo.txt | 14:16 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 14:17 | |
d_thomas | SRC_URI="git://github.com/linux4sam/linux-at91.git;protocol=git;branch=linux-4.19-at91 file://defconfig file://custom.cfg" | 14:17 |
zeddii | yup. 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_thomas | Yeah, that log shows defconfig as the base and the custom.cfg merging in | 14:21 |
zeddii | ok. 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 |
zeddii | and did you try explictly setting the KCONFIG_MODE in your bbappend ? | 14:22 |
zeddii | i.e. KCONFIG_MODE = "alldefconfig" ? | 14:22 |
d_thomas | Oops, not yet. I'll try that now | 14:22 |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 14:25 | |
*** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 14:27 | |
kroon | RP, you mean cleaning up by using case fallthrough or something ? | 14:28 |
d_thomas | That 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_thomas | So what does "alldefconfig" do in the context of the bbappend file? | 14:29 |
zeddii | nothing | 14:30 |
zeddii | well, it sets a variable that is used by the kernel-yocto bbclass to feed into merge_config | 14:31 |
zeddii | since 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 |
kroon | RP, all explicitly listed cases set i=dummy, I suppose that can be factored out | 14:31 |
d_thomas | Okay.... and the kernel.bbclass uses oldnoconfig when processing defconfig, right? | 14:32 |
zeddii | it uses it for any config, yes, but since it only really doesn't defconfigs, yes :D | 14:33 |
zeddii | and oldnoconfig, is just the old name for the what you are getting with merge_config. | 14:34 |
zeddii | it has changed in the newer kernel.bbclass (IIRC), but the behaviour is the same. | 14:34 |
d_thomas | Okay.... 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 work | 14:35 |
d_thomas | Thanks for your help zeddii | 14:36 |
zeddii | correct. 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 |
zeddii | and 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_thomas | that would be great | 14:37 |
zeddii | yah. I'll raise myself a bugzilla to look into it. (before I forget). | 14:38 |
yocti | New news from stackoverflow: Jetson Nano And Yocto/poky Zeus <https://stackoverflow.com/questions/58732068/jetson-nano-and-yocto-poky-zeus> | 14:38 |
cengiz_io | hello there! | 14:39 |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 14:39 | |
cengiz_io | I 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_io | read 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_io | 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? | 14:43 |
*** copycat88 <copycat88!~copy@195.20.130.1> has quit IRC | 14:45 | |
dl9pf | mcfrisk: do you just call eatmydata bitbake or how do you invoce it | 14:49 |
*** yann <yann!~yann@85.118.38.73> has quit IRC | 14:50 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:51 | |
*** khem <khem!~khem@unaffiliated/khem> has quit IRC | 14:51 | |
RP | kroon: the whole thing is just hard to read/understand :/ | 14:58 |
* kroon nods | 14:59 | |
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 15:01 | |
*** yann <yann!~yann@85.118.38.73> has joined #yocto | 15:06 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 15:06 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 15:07 | |
*** walzert50 <walzert50!8667b8c4@134.103.184.196> has joined #yocto | 15:11 | |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:15 | |
*** walzert50 <walzert50!8667b8c4@134.103.184.196> has quit IRC | 15:22 | |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:22 | |
mcfrisk | dl9pf: 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 python | 15:25 |
mcfrisk | tasks 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 |
RP | mcfrisk: I thought pseudo was intercepting those? | 15:30 |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 15:31 | |
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 15:32 | |
RP | mcfrisk: "CFH" means? | 15:41 |
* RP ponders how we'd manage to build sumo now :/ | 15:41 | |
*** CarlGel <CarlGel!~Rika-chan@unaffiliated/carlgel> has joined #yocto | 15:46 | |
mcfrisk | RP: call for help | 15:48 |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:53 | |
RP | mcfrisk: as in you'd like to get those merged to sumo? | 15:55 |
mcfrisk | RP: yep | 15:57 |
mcfrisk | or to sumo-next or sumo-contrib if you prefer | 15:57 |
letothe2nd | mcfrisk: i actually intended to poke armpit about it once he's around | 15:57 |
RP | mcfrisk: the hard part is testing, not merging :/ | 15:57 |
mcfrisk | I know | 15:57 |
RP | FWIW I just hacked the autobuilder, see if I can persuade it to build sumo on a reduced set of workers | 15:58 |
mcfrisk | I build on Debian stale, Debian GNU/Linux 9 (stretch), containers | 15: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 IRC | 15:59 | |
RP | mcfrisk: sure, but that doesn't help me with the autobuilder... | 16:00 |
RP | letothe2nd: armpit is onvacation | 16:00 |
letothe2nd | RP: ah! | 16:02 |
* letothe2nd decides that this is not IRC approved. | 16:03 | |
milloni | is there something like `bitbake -e` bit without expanding variables in tasks? | 16:06 |
RP | milloni: shell or python? | 16:07 |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 16:07 | |
rburton | milloni: adding unexpand is a two line patch to https://github.com/rossburton/bb/blob/master/libexec/bb-var | 16:08 |
milloni | RP: both | 16:09 |
milloni | rburton: i'll take a look, thanks | 16:10 |
RP | milloni: d.getVar(name, expand=False) if python | 16:11 |
rburton | milloni: just pushed --unexpand to that tool | 16:11 |
rburton | $ bb var WORKDIR m4 -u | 16:12 |
rburton | ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} | 16:12 |
rburton | the syntax is now ugly as sin, but i can fix that another time | 16:12 |
cengiz_io | while 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 |
mcfrisk | cengiz_io: install to -dev binary package. see examples in poky tree. | 16:23 |
cengiz_io | mcfrisk: will do. thanks. | 16:23 |
mcfrisk | cengiz_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_io | mcfrisk well my problem is: I have a cmake app which is pulled from git but it has some binary only huge .a files and headers | 16:25 |
cengiz_io | which are also architecture dependent. (we need to compile for x86_64 and armv7) | 16:25 |
cengiz_io | it'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 |
rburton | cengiz_io: just package them like the system defaults to. .a files go into -staticdev packages, which are not in images or sdks by default | 16:26 |
cengiz_io | rburton are those -staticdev packages derived from regular recipes? couldn't find anything about them in reference manual.. | 16:27 |
rburton | cengiz_io: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#including-static-library-files | 16:28 |
rburton | that keeps them out of images. to get that specific recipe in the sdk add it to TOOLCHAIN_TARGET_TASK | 16:29 |
cengiz_io | excuse my ignorance but that example doesn't have any SRC_URI or something. does it? | 16:30 |
cengiz_io | rburton because I don't build those libraries. they are simply binary files shared with me.. can't reproduce them. | 16:31 |
rburton | cengiz_io: thats not an example, its a fragment of bitbake.conf | 16:31 |
cengiz_io | oh ok. I guessed so | 16:31 |
rburton | write a recipe to grab the files and install them to $D correctly | 16:31 |
rburton | them the default packaging rules will do the right thing | 16:31 |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:31 | |
cengiz_io | so if I copy to a specific directory, bitbake will move them to PN-staticdev etc | 16:32 |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:32 | |
rburton | no | 16:32 |
rburton | $libdir/*.a goes to static lib | 16:32 |
rburton | $libdir/lib*.so -> -dev | 16:33 |
rburton | $libdir/lib*.so.* -> PN | 16:33 |
*** camus <camus!~Instantbi@222.67.188.174> has joined #yocto | 16:33 | |
rburton | because that's how libraries are laid out on linux | 16:33 |
cengiz_io | I got it now. what about headers? I think I can read that conf fragment to find out | 16:34 |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 16:35 | |
*** camus is now known as kaspter | 16:35 | |
rburton | cengiz_io: install them to $includedir | 16:38 |
cengiz_io | rburton yes but there are hundreds of them and they are in levels of subdirs.. does it make a difference? | 16:39 |
rburton | no | 16:39 |
rburton | the default rule is "all of $includedir" | 16:39 |
cengiz_io | then include myapp-dev in TARGET_HOST_TASK_append right? | 16:39 |
cengiz_io | for sdk | 16:39 |
cengiz_io | sorry | 16:40 |
cengiz_io | TOOLCHAIN_TARGET_TASK | 16:40 |
rburton | if myapp is already in the image then -dev will be added automatically | 16:40 |
rburton | otherwise, yes | 16:40 |
cengiz_io | it doesn't make sense to ship headers in final rootfs image so | 16:40 |
zeddii | 4 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 #yocto | 17:05 | |
*** frsc <frsc!~frsc@243-74-142-46.pool.kielnet.net> has quit IRC | 17:05 | |
*** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 17:08 | |
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 17:13 | |
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 17:14 | |
*** camus is now known as kaspter | 17:14 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:17 | |
RP | mcfrisk: 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 |
RP | Not sure it can build a full build without more tweaking due to selftest though... | 17:20 |
ruru4143 | where are image_features defined and can i add costum image features? | 17:27 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:36 | |
mcfrisk | RP: :) | 17:49 |
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 17:50 | |
mcfrisk | ruru4143: check output of "bitbake -e myimage", find location of ^IMAGE_FEATURES and check which recipes, classes, distro configuration etc contribute | 17:51 |
RP | mcfrisk: I've replied on the list. I worry where this path leads :( | 17:53 |
*** yann <yann!~yann@85.118.38.73> has quit IRC | 17:55 | |
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 18:06 | |
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 18:11 | |
*** camus <camus!~Instantbi@101.93.194.160> has joined #yocto | 18:11 | |
*** camus is now known as kaspter | 18:14 | |
*** vmeson <vmeson!~rmacleod@S0106c05627277493.va.shawcable.net> has quit IRC | 18:23 | |
mcfrisk | RP: 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 #yocto | 18:24 | |
*** vmeson <vmeson!~rmacleod@S0106c05627277493.va.shawcable.net> has joined #yocto | 18: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 IRC | 18:30 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:31 | |
RP | mcfrisk: I think the TSC needs to discuss this | 18:34 |
RP | hmm, sumo threw uninative errors :( | 18:36 |
mcfrisk | ouch | 18:36 |
mcfrisk | will 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 IRC | 18:38 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 18:38 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 18:41 | |
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 18:50 | |
rburton | ruru4143: the documentation has a list | 18:54 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 18:55 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 19:02 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 19:04 | |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 19:05 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:08 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 19:20 | |
*** florian_kc is now known as florian | 19:21 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:33 | |
RP | Hmm, sumo shows a lot of warnings :( | 19:33 |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:33 | |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 19:33 | |
RP | seebs: 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 #yocto | 19:35 | |
seebs | ports/subports | 19:38 |
seebs | have 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 |
RP | seebs: thanks, that is the pointer I needed :) | 19:49 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 19:52 | |
*** BloodSurfer <BloodSurfer!d9598b8a@proxy-str.vector.com> has quit IRC | 20:07 | |
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 20:15 | |
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 20:16 | |
*** aidanh_ is now known as aidanh | 20:16 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 20:19 | |
*** aehs29 <aehs29!~aehs29@149.199.62.131> has quit IRC | 20:21 | |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC | 20:21 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:22 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:31 | |
RP | seebs: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ac02f30e3759b64ba402a2129f015fe70f2ad566 is slowly improving | 20:34 |
fray | that looks a lot less bad then I was expecting basedon the previous discussion | 20:44 |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto | 20:45 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 20:47 | |
RP | fray: that doesn't mean I have this right :) | 20:48 |
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 20:52 | |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC | 20:57 | |
seebs | that looks reasonable to me, i think? | 21:05 |
RP | seebs: it seems to work... | 21:07 |
RP | seebs: running tests now... | 21:07 |
mischief | why does systemd in yocto use /lib rather than /usr/lib? | 21:07 |
fray | because everyone else is wrong? | 21:07 |
fray | /lib is available on boot.. /usr/lib isn't available until filesystems are mounted.. | 21:08 |
fray | if 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 |
RP | fray: not the mounting thing again? :) | 21:09 |
fray | just explaining why /lib vs /usr/lib | 21:09 |
mischief | is usrmerge documented somewhere? | 21:09 |
RP | fray: I'll mention NFS ;-) | 21:09 |
mischief | fray: i am just confused because i am trying to make a recipe for a program with a systemd unit. | 21:11 |
mischief | the binary is installed to /usr/bin but it looks like yocto's systemd.bbclass expects the systemd unit in /lib/systemd/system .. | 21:11 |
fray | Look at other recipes with systemd components and use teh same ${....} | 21:11 |
fray | usrmerge 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 #yocto | 21:13 | |
mischief | fray: "/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 sense | 21:13 |
RP | hmm, dynamically re-configuring the autobuilder code from under it only works to a point... | 21:13 |
fray | in that case, you would need to set a dependency on mount | 21:13 |
RP | mischief: there is a variable to use for installing unit files | 21:13 |
mischief | i know, i'm just trying to understand conceptually why it is the way it is | 21:14 |
fray | ${systemd_unitdir} | 21:14 |
* RP suspects nobody does this with filesystems anymore | 21:15 | |
fray | basically 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 be | 21:15 |
fray | RP I saw someone do this last year still | 21:15 |
mischief | fray: having to set RequiresMountsFor=/usr on every unit makes little sense as well | 21:15 |
fray | they had to adjust things to ensure that filesystems were mounted early.. but otherwise it worked for their config | 21:15 |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 21:16 | |
mischief | anyway, it matters little i guess since we have no separate /usr fs | 21:16 |
mischief | ill adjust where i install the unit to /lib.. | 21:16 |
fray | don't use /lib directly.. use the variable ${systemd_unitdir} | 21:17 |
mischief | i know, but i need to adjust my build system to take an argument of where to install | 21:17 |
fray | of if using oe.. do_install { .. if [ $D/usr/lib != ${systemd_unitdir} ; then mv $D/usr/lib/.... ${systemd_unitdir}/...; fi } | 21:18 |
mischief | i am using meson for my program :) | 21:19 |
fray | Yes, 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_install | 21:19 |
mischief | cool, 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 two | 21:31 | |
* Crofton|work wonders what is wrong with that build | 21:32 | |
RP | Crofton|work: I was wondering that too | 21:32 |
fray | RP does the packagefeed_stability (or some other class) help feed the hash equivalency yet? | 21:42 |
RP | fray: probably obsoletes it | 21:43 |
*** vmeson <vmeson!~rmacleod@S0106ac202ece3eb3.vc.shawcable.net> has joined #yocto | 21:44 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.129.51> has joined #yocto | 21:44 | |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto | 21:46 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 22:17 | |
*** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC | 22:20 | |
*** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC | 22:22 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 22:22 | |
rburton | mischief: at the end of the day, systemd doesn't really support mounting /lib before /usr | 22:30 |
*** georgem_ <georgem_!~georgem@216.21.169.52> has joined #yocto | 22:30 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:32 | |
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 22:33 | |
*** georgem_ <georgem_!~georgem@216.21.169.52> has quit IRC | 22:42 | |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:09 | |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 23:25 | |
*** bc86 <bc86!5e2d9a0f@94.45.154.15> has joined #yocto | 23:34 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:54 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!