**** BEGIN LOGGING AT Wed Nov 06 03:00:06 2019 Nov 06 06:39:27 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? Nov 06 06:40:12 Either systemd variant or init.d, depending which init-system the machine uses Nov 06 06:51:42 thomasd13, write both a systemd service and an init script, let yocto pick whatever is configured for the distro Nov 06 07:13:26 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? Nov 06 07:14:11 For now I just append manually append the specific installation package (either init.d or systemd) to the image Nov 06 07:15:34 thomasd13: i usually refer to the dropbear recipes, those serve as a good example for that Nov 06 07:18:57 letothe2nd thanks for the hint Nov 06 07:45:53 Saur: Testing my connection, can you see this? /Ola Nov 06 09:17:11 olani: Yes, I can. Nov 06 09:25:37 good morning! Nov 06 09:25:40 Did someone ever use init-install-efi? Nov 06 09:26:13 It is a script to install an image on the target. Nov 06 09:52:48 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 Nov 06 09:53:55 timblechmann: the do_rootfs stage is always carried out, IIRC. Nov 06 09:54:11 RP: what was the rationale behind it? Nov 06 09:55:15 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 Nov 06 09:55:51 timblechmann: completely out of my area of expertise, sorry. can only give generic advice there Nov 06 09:56:29 timblechmann: bitbake-diffsigs can be your friend :) Nov 06 09:56:51 so you are basically channeling a number of images into subvolumes of some master-image? Nov 06 09:57:51 letothe2nd: exactly Nov 06 09:58:01 timblechmann: interesting usecase :) Nov 06 09:58:36 nasty: have to mount the images as loopback devices in a docker container as subvolumes only work on mounted partitions ... Nov 06 09:58:59 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 Nov 06 09:59:18 qschulz: will give it a try! Nov 06 10:00:52 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. Nov 06 10:02:02 mcfrisk: guess its mostly about the oe core part? in that case, sure, make a series and put it onto the oe-core list Nov 06 10:02:34 mcfrisk: nothing is dead as long as somebody cares for it. Nov 06 10:08:03 letothe2nd: exactly. I'll post the patches then. Nov 06 10:08:53 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. Nov 06 10:13:42 oh, my gcc 7.4 update patches are also not on sumo which still uses 7.3 then. Nov 06 10:17:46 mcfrisk: just put it on the list to get started, we'll try and find somebody to take it up Nov 06 10:19:09 letothe2nd: do_rootfs doesn't always rerun Nov 06 10:19:17 should only run when something changed Nov 06 10:19:27 RP: then i didn't RC, as so often! :) Nov 06 10:22:50 too bad my brain doesn't have ECC Nov 06 10:23:09 do_rootfs likes to re-run when using rm_work Nov 06 10:24:08 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13212 Nov 06 10:24:10 Bug 13212: normal, Medium+, 3.1, akuster, NEW , image_qa task is always triggered with rm_work class enabled Nov 06 10:24:15 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 Nov 06 10:26:06 mcfrisk: need to poke some USians later :) Nov 06 11:31:11 is it known that DISTRO_FEATURES += breaks build of glibc-locale in sumo, possibly other branches, and users should use DISTRO_FEATURES_append instead? Nov 06 11:48:30 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? Nov 06 11:49:55 seebs: if/when you're around I have some hopefully simple questions as pseudo is confusing me Nov 06 11:50:39 kroon: if you use rm_work that is hardly surprising Nov 06 11:52:40 kroon: hmm, I guess its not clearcut Nov 06 12:06:53 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 Nov 06 12:07:42 if there is an rm_work expert reading the ml I can create a patch and post it Nov 06 12:08:48 kroon: please do post it as it would be easier than untangling the patch from the bug report Nov 06 12:09:02 kroon: the expert is probably me, much as I dislike rm_work Nov 06 12:10:53 RP, :-) I like its functionality since it means I can build my images in tmpfs Nov 06 12:11:02 RP, i'll post a patch then Nov 06 12:13:17 * RP should rewrite that stamps function so its readable :/ Nov 06 12:19:59 rm_work keeps me from killing disks and ssds and needing 4TB for each build machine.. Nov 06 12:20:16 so thanks for it! Nov 06 12:27:29 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. Nov 06 12:36:13 mcfrisk, that sounds interesting Nov 06 12:43:39 mcfrisk: what are you building where tmpfs is too small even with rm_work? Nov 06 12:45:11 I know icedtea7-native sure eats a lot of disk.. Nov 06 12:47:07 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 Nov 06 12:53:59 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. Nov 06 12:59:24 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 Nov 06 13:00:28 I've added eatmydata, LD_PRELOAD=libeatmydata.so and LD_LIBRARY_PATH=/usr/lib/libeatmydata to avoid sync() and fsync() calls from various tools. Nov 06 13:00:48 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 Nov 06 13:00:49 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 Nov 06 13:00:49 since I'd need to deal with NXP's CST toolchain and I wanted to postpone this step to later. Nov 06 13:01:27 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. Nov 06 13:01:29 The BSP is use comes from Phytec as the eval board I am using Nov 06 13:01:37 I use* Nov 06 13:21:07 mcfrisk: that approach makes sense to me FWIW Nov 06 13:22:45 seebs: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=644638899538baf74f8ffbc47aff76dcb513bea0 is probably horrific but appears to work Nov 06 13:26:32 seebs: updated to fix the rdev major/minor writeback Nov 06 13:33:21 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 Nov 06 13:37:23 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. Nov 06 13:38:10 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. Nov 06 13:38:32 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. Nov 06 13:40:30 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 Nov 06 13:41:39 allnoconfig is what I expect, I see what you are saying there Nov 06 13:42:49 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. Nov 06 13:43:20 It's not, but I can break the kernel out and make it public. Nov 06 13:44:12 I don't see any extra includes in that recipe you pasted, so it should be the default kernel.bbclass configure that fires. Nov 06 13:44:18 which means I should be able to figure it out from here. Nov 06 13:44:33 can you repeat the symptom you are seeing ? I think I missed that part :D Nov 06 13:44:44 your fragment's settings aren't showing up in the final .config ? Nov 06 13:47:34 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. Nov 06 13:48:42 what release of yocto are you using ? Nov 06 13:48:46 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. Nov 06 13:48:47 Sumo Nov 06 13:49:04 Old I know, but that's what the meta-atmel instructions started me on Nov 06 13:49:21 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. Nov 06 13:49:38 Thank you! Nov 06 13:58:55 zeddii, full source is here https://github.com/dthomas-sensonix/meta-experimental Nov 06 14:02:36 d_thomas, cool. I'll clone that and fire up a build if my code inspection fails to find the cause. Nov 06 14:03:24 zeddii, thank you! Nov 06 14:03:45 Adding the configuration fragments to this recipe is new, so it's very possible I'm doing something wrong. Nov 06 14:08:41 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 ? Nov 06 14:10:30 I see SRC_URI="" Nov 06 14:10:54 kroon: that patch looks right, I think I just want to rewrite that function to be a bit more understandable :/ Nov 06 14:11:16 kroon: the " Ensure we don't 'stack' setscene extensions to thi" is what I really don't like Nov 06 14:12:01 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 Nov 06 14:12:34 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. Nov 06 14:13:40 I'll look... what is ${S} likely to be? In the /tmp/work directory? Nov 06 14:14:48 tmp/work-shared//kernel-source/.kernel-meta/ Nov 06 14:16:13 weird, SRC_URI isn't in that file Nov 06 14:16:28 ah. that was for the merge_config output, Nov 06 14:16:45 to get the full SRC_URI, you'd just "bitbake -e virtual/kernel" > foo.txt Nov 06 14:16:49 and look in foo.txt Nov 06 14:17:58 SRC_URI="git://github.com/linux4sam/linux-at91.git;protocol=git;branch=linux-4.19-at91 file://defconfig file://custom.cfg" Nov 06 14:18:37 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. Nov 06 14:21:02 Yeah, that log shows defconfig as the base and the custom.cfg merging in Nov 06 14:21:47 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. Nov 06 14:22:10 and did you try explictly setting the KCONFIG_MODE in your bbappend ? Nov 06 14:22:21 i.e. KCONFIG_MODE = "alldefconfig" ? Nov 06 14:22:44 Oops, not yet. I'll try that now Nov 06 14:28:26 RP, you mean cleaning up by using case fallthrough or something ? Nov 06 14:29:01 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. Nov 06 14:29:18 So what does "alldefconfig" do in the context of the bbappend file? Nov 06 14:30:50 nothing Nov 06 14:31:17 well, it sets a variable that is used by the kernel-yocto bbclass to feed into merge_config Nov 06 14:31:44 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). Nov 06 14:31:54 RP, all explicitly listed cases set i=dummy, I suppose that can be factored out Nov 06 14:32:42 Okay.... and the kernel.bbclass uses oldnoconfig when processing defconfig, right? Nov 06 14:33:33 it uses it for any config, yes, but since it only really doesn't defconfigs, yes :D Nov 06 14:34:07 and oldnoconfig, is just the old name for the what you are getting with merge_config. Nov 06 14:34:27 it has changed in the newer kernel.bbclass (IIRC), but the behaviour is the same. Nov 06 14:35:03 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 Nov 06 14:36:30 Thanks for your help zeddii Nov 06 14:36:34 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. Nov 06 14:37:11 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. Nov 06 14:37:46 that would be great Nov 06 14:38:37 yah. I'll raise myself a bugzilla to look into it. (before I forget). Nov 06 14:38:48 New news from stackoverflow: Jetson Nano And Yocto/poky Zeus Nov 06 14:39:06 hello there! Nov 06 14:41:03 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? Nov 06 14:42:10 read some recipes like jpeg2000 and others from openembbedded layer index but they don't seem to have do_populate_sdk in them. Nov 06 14:43:02 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? Nov 06 14:49:41 mcfrisk: do you just call eatmydata bitbake or how do you invoce it Nov 06 14:58:29 kroon: the whole thing is just hard to read/understand :/ Nov 06 14:59:31 * kroon nods Nov 06 15:25:06 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 Nov 06 15:25:12 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. Nov 06 15:30:24 mcfrisk: I thought pseudo was intercepting those? Nov 06 15:41:20 mcfrisk: "CFH" means? Nov 06 15:41:57 * RP ponders how we'd manage to build sumo now :/ Nov 06 15:48:11 RP: call for help Nov 06 15:55:42 mcfrisk: as in you'd like to get those merged to sumo? Nov 06 15:57:01 RP: yep Nov 06 15:57:20 or to sumo-next or sumo-contrib if you prefer Nov 06 15:57:23 mcfrisk: i actually intended to poke armpit about it once he's around Nov 06 15:57:47 mcfrisk: the hard part is testing, not merging :/ Nov 06 15:57:52 I know Nov 06 15:58:09 FWIW I just hacked the autobuilder, see if I can persuade it to build sumo on a reduced set of workers Nov 06 15:59:05 I build on Debian stale, Debian GNU/Linux 9 (stretch), containers Nov 06 15:59:30 (better than Ubuntu which has copyright issues distributing container images) Nov 06 16:00:16 mcfrisk: sure, but that doesn't help me with the autobuilder... Nov 06 16:00:34 letothe2nd: armpit is onvacation Nov 06 16:02:25 RP: ah! Nov 06 16:03:48 * letothe2nd decides that this is not IRC approved. Nov 06 16:06:16 is there something like `bitbake -e` bit without expanding variables in tasks? Nov 06 16:07:08 milloni: shell or python? Nov 06 16:08:43 milloni: adding unexpand is a two line patch to https://github.com/rossburton/bb/blob/master/libexec/bb-var Nov 06 16:09:15 RP: both Nov 06 16:10:16 rburton: i'll take a look, thanks Nov 06 16:11:22 milloni: d.getVar(name, expand=False) if python Nov 06 16:11:50 milloni: just pushed --unexpand to that tool Nov 06 16:12:00 $ bb var WORKDIR m4 -u Nov 06 16:12:00 ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} Nov 06 16:12:26 the syntax is now ugly as sin, but i can fix that another time Nov 06 16:22:19 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? Nov 06 16:23:05 cengiz_io: install to -dev binary package. see examples in poky tree. Nov 06 16:23:27 mcfrisk: will do. thanks. Nov 06 16:24:30 cengiz_io: for many build systems bitbake and build bbclasses do this automatically if headers and static libs are installed from do_install() Nov 06 16:25:24 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 Nov 06 16:25:57 which are also architecture dependent. (we need to compile for x86_64 and armv7) Nov 06 16:26:41 it's a huge mess. so I have created another recipe called myapp-deps and it overrides do_install and copies everything to sysroot. Nov 06 16:26:43 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 Nov 06 16:27:50 rburton are those -staticdev packages derived from regular recipes? couldn't find anything about them in reference manual.. Nov 06 16:28:25 cengiz_io: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#including-static-library-files Nov 06 16:29:44 that keeps them out of images. to get that specific recipe in the sdk add it to TOOLCHAIN_TARGET_TASK Nov 06 16:30:04 excuse my ignorance but that example doesn't have any SRC_URI or something. does it? Nov 06 16:30:59 rburton because I don't build those libraries. they are simply binary files shared with me.. can't reproduce them. Nov 06 16:31:25 cengiz_io: thats not an example, its a fragment of bitbake.conf Nov 06 16:31:35 oh ok. I guessed so Nov 06 16:31:42 write a recipe to grab the files and install them to $D correctly Nov 06 16:31:49 them the default packaging rules will do the right thing Nov 06 16:32:01 so if I copy to a specific directory, bitbake will move them to PN-staticdev etc Nov 06 16:32:39 no Nov 06 16:32:46 $libdir/*.a goes to static lib Nov 06 16:33:06 $libdir/lib*.so -> -dev Nov 06 16:33:18 $libdir/lib*.so.* -> PN Nov 06 16:33:28 because that's how libraries are laid out on linux Nov 06 16:34:50 I got it now. what about headers? I think I can read that conf fragment to find out Nov 06 16:38:28 cengiz_io: install them to $includedir Nov 06 16:39:07 rburton yes but there are hundreds of them and they are in levels of subdirs.. does it make a difference? Nov 06 16:39:16 no Nov 06 16:39:26 the default rule is "all of $includedir" Nov 06 16:39:42 then include myapp-dev in TARGET_HOST_TASK_append right? Nov 06 16:39:48 for sdk Nov 06 16:40:00 sorry Nov 06 16:40:04 TOOLCHAIN_TARGET_TASK Nov 06 16:40:07 if myapp is already in the image then -dev will be added automatically Nov 06 16:40:14 otherwise, yes Nov 06 16:40:34 it doesn't make sense to ship headers in final rootfs image so Nov 06 16:41:04 4 kernel config and module questions in the last 24 hours, something in the water ? Nov 06 17:19:29 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... Nov 06 17:20:17 Not sure it can build a full build without more tweaking due to selftest though... Nov 06 17:27:58 where are image_features defined and can i add costum image features? Nov 06 17:49:53 RP: :) Nov 06 17:51:17 ruru4143: check output of "bitbake -e myimage", find location of ^IMAGE_FEATURES and check which recipes, classes, distro configuration etc contribute Nov 06 17:53:57 mcfrisk: I've replied on the list. I worry where this path leads :( Nov 06 18:23:59 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? Nov 06 18:27:02 * mcfrisk will maintain sumo anyway. question is just about if I will publish the work, and where to publish the work. Nov 06 18:34:16 mcfrisk: I think the TSC needs to discuss this Nov 06 18:36:32 hmm, sumo threw uninative errors :( Nov 06 18:36:45 ouch Nov 06 18:37:35 will reply to the list too. TSC discussion and possible decisions are needed, sure. Nov 06 18:54:26 ruru4143: the documentation has a list Nov 06 19:33:37 Hmm, sumo shows a lot of warnings :( Nov 06 19:35:42 seebs: is there any mechanism in pseudo to detect if a function is present and only enable the code if so? Nov 06 19:38:32 ports/subports Nov 06 19:39:01 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" Nov 06 19:49:11 seebs: thanks, that is the pointer I needed :) Nov 06 20:34:59 seebs: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ac02f30e3759b64ba402a2129f015fe70f2ad566 is slowly improving Nov 06 20:44:44 that looks a lot less bad then I was expecting basedon the previous discussion Nov 06 20:48:25 fray: that doesn't mean I have this right :) Nov 06 21:05:35 that looks reasonable to me, i think? Nov 06 21:07:19 seebs: it seems to work... Nov 06 21:07:27 seebs: running tests now... Nov 06 21:07:29 why does systemd in yocto use /lib rather than /usr/lib? Nov 06 21:07:44 because everyone else is wrong? Nov 06 21:08:09 /lib is available on boot.. /usr/lib isn't available until filesystems are mounted.. Nov 06 21:08:32 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) Nov 06 21:09:01 fray: not the mounting thing again? :) Nov 06 21:09:16 just explaining why /lib vs /usr/lib Nov 06 21:09:31 is usrmerge documented somewhere? Nov 06 21:09:36 fray: I'll mention NFS ;-) Nov 06 21:11:08 fray: i am just confused because i am trying to make a recipe for a program with a systemd unit. Nov 06 21:11:38 the binary is installed to /usr/bin but it looks like yocto's systemd.bbclass expects the systemd unit in /lib/systemd/system .. Nov 06 21:11:44 Look at other recipes with systemd components and use teh same ${....} Nov 06 21:12:51 usrmerge is a distro feature that changes the 'root_prefix' from 'base_prefix' (/) to exec_prefix (/usr) Nov 06 21:13:11 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 Nov 06 21:13:32 hmm, dynamically re-configuring the autobuilder code from under it only works to a point... Nov 06 21:13:34 in that case, you would need to set a dependency on mount Nov 06 21:13:57 mischief: there is a variable to use for installing unit files Nov 06 21:14:35 i know, i'm just trying to understand conceptually why it is the way it is Nov 06 21:14:51 ${systemd_unitdir} Nov 06 21:15:25 * RP suspects nobody does this with filesystems anymore Nov 06 21:15:26 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 Nov 06 21:15:40 RP I saw someone do this last year still Nov 06 21:15:42 fray: having to set RequiresMountsFor=/usr on every unit makes little sense as well Nov 06 21:15:57 they had to adjust things to ensure that filesystems were mounted early.. but otherwise it worked for their config Nov 06 21:16:45 anyway, it matters little i guess since we have no separate /usr fs Nov 06 21:16:52 ill adjust where i install the unit to /lib.. Nov 06 21:17:04 don't use /lib directly.. use the variable ${systemd_unitdir} Nov 06 21:17:27 i know, but i need to adjust my build system to take an argument of where to install Nov 06 21:18:58 of if using oe.. do_install { .. if [ $D/usr/lib != ${systemd_unitdir} ; then mv $D/usr/lib/.... ${systemd_unitdir}/...; fi } Nov 06 21:19:19 i am using meson for my program :) Nov 06 21:19:58 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 Nov 06 21:26:43 cool, systemd pkgconfig has the unit dir in it :) Nov 06 21:31:32 * 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 Nov 06 21:32:30 * Crofton|work wonders what is wrong with that build Nov 06 21:32:50 Crofton|work: I was wondering that too Nov 06 21:42:19 RP does the packagefeed_stability (or some other class) help feed the hash equivalency yet? Nov 06 21:43:38 fray: probably obsoletes it Nov 06 22:30:45 mischief: at the end of the day, systemd doesn't really support mounting /lib before /usr **** ENDING LOGGING AT Thu Nov 07 02:59:57 2019