**** BEGIN LOGGING AT Mon Dec 23 03:00:01 2019
Dec 23 03:15:12 <yocti> New news from stackoverflow: qemu-system-arm hangs with Raspberry Pi 2 image <https://stackoverflow.com/questions/49722384/qemu-system-arm-hangs-with-raspberry-pi-2-image>
Dec 23 05:07:46 <DvorkinDmitry> how can I enable systemd service with name "something@port" in my recipe?
Dec 23 05:08:36 <DvorkinDmitry> SYSTEMD_AUTO_ENABLE_myservice@S4 = "enable" is not allowed in recipe
Dec 23 05:34:23 <nrossi> DvorkinDmitry: Not sure if there is a better way, but serial-getty does manual symlinks during do_install, see http://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd-serialgetty.bb#n32
Dec 23 05:36:41 <DvorkinDmitry> nrossi, thank you. I saw it and don't like how it is done
Dec 23 05:38:47 <nrossi> DvorkinDmitry: you can always do the variable setting in a anon python function, it does look like systemd.bbclass handles the "a@b" syntax
Dec 23 05:39:41 <nrossi> DvorkinDmitry: oh wait no sorry, misread it. It skips the b part, just looks for the ".service" part
Dec 23 05:43:01 <DvorkinDmitry> nrossi, yes, it just installs links
Dec 23 05:44:57 <nrossi> DvorkinDmitry: the class does appear to just use systemctl preset, and it does not filter out any SYSTEMD_SERVICE values... so if you can get SYSTEMD_AUTO_ENABLE_... set, it should be able to enable the @* target
Dec 23 05:45:49 <DvorkinDmitry> nrossi, it does not filter, but I have parse error if do this
Dec 23 05:47:37 <nrossi> DvorkinDmitry: but you only need to set SYSTEMD_AUTO_ENABLE for the package, not the individual service files. So if you have SYSTEMD_SERVICE_foo = "foo@.service foo@bar.service", and SYSTEMD_AUTO_ENABLE = "enable". It should enable foo@ and foo@bar. At least that is how it appears to be coded in systemd.bbclass
Dec 23 05:47:59 <nrossi> sorry SYSTEMD_AUTO_ENABLE_foo
Dec 23 05:48:51 <DvorkinDmitry> nrossi, perfect! Let me try...
Dec 23 07:15:54 <yocti> New news from stackoverflow: Building Yocto on Pandaboard <https://stackoverflow.com/questions/30212580/building-yocto-on-pandaboard>
Dec 23 07:54:06 <nacknick> Hi. Under: build/tmp/work/raspberrypi3-poky-linux-musleabi/core-image-minimal/1.0-r0/rootfs/usr/arm-poky-linux-musleabi/bin I have many symbol links. Such as: objdump -> ../../../usr/bin/arm-poky-linux-musleabi-objdump.
Dec 23 07:54:32 <nacknick> I want to add symbol link to gcc. Where is the recipe that I should modify?
Dec 23 07:59:58 <nrossi> nacknick: look at the gcc-symlinks/g++-symlinks/etc. packages, these should provide the symlinks for you
**** BEGIN LOGGING AT Mon Dec 23 08:31:31 2019
Dec 23 08:46:23 <nacknick> OK. I don't know if someone is interested, But I opened a Telegram group for all of you. Hopefully it will be large enough... https://t.me/yoctoproject
Dec 23 08:46:27 <nacknick> Have fun
Dec 23 09:21:08 <LetoThe2nd> nacknick: good luck, but me personally will not be on telegram. already been burnt by them.
Dec 23 09:21:39 <nacknick> burnt? :o
Dec 23 09:21:58 <LetoThe2nd> nacknick: reasons: needs me a smartphone, uploads my address book for no good reason
Dec 23 09:22:18 <nacknick> You don't need a smartphone. I use it on my laptop...
Dec 23 09:22:56 <nacknick> You just need to open an account. like in freenode
Dec 23 09:23:53 <nacknick> I just offered this platform. I use it on many other things and it's brilliant. If people here are not going to cooperate - it's obviously won't work
Dec 23 09:24:10 <LetoThe2nd> like i said, good luck. /me will not cooperate.
Dec 23 09:24:23 <nacknick> OK
Dec 23 11:16:38 <yocti> New news from stackoverflow: Avoid Automatic Make Targets in Eclipse environment <https://stackoverflow.com/questions/25401907/avoid-automatic-make-targets-in-eclipse-environment>
Dec 23 12:52:22 <nacknick> I want to add symlink in rootfs's /usr/bin. What is the correct path please? `ln -s <???> my_sym_link
Dec 23 12:52:37 <nacknick> `
Dec 23 14:05:30 <rburton> ${D}${bindir}
Dec 23 14:30:54 <havok101> hi
Dec 23 14:34:37 <havok101> I'm building krogoth on a Ubuntu 16.04 VM and running into an issues where ca-certificates-native-20160104-r0 do_install is stuck and doesn't move forward. When I check htop the procese "c_rehash ." it taking 100% on one core. When I check the certs directory all the certs are there so it looks like it has finished it's job. Not sure why it isn't moving on. Any Idea? Thanks
Dec 23 14:42:11 <rburton> strace it?
Dec 23 14:42:24 <rburton> also krogoth ewww upgrade
Dec 23 14:45:45 <havok101> The way our project/product is setup that is not going to happen for a while. :(
Dec 23 14:52:39 <havok101> Just to note this has always worked, stopped working specifically on one VM that was newly built
Dec 23 16:34:18 <havok101> for anyone that needs it, it couldn't find perl.
Dec 23 17:04:38 <rburton> hooray VMs
Dec 23 17:04:47 <rburton> so we need a sanity check that the host has perl then
Dec 23 17:05:02 <rburton> havok101: i presume you mean there was literally no perl in the vm at all?
Dec 23 17:05:35 <rburton> we *do* check for perl on startup
Dec 23 17:06:20 <rburton> hm only when the sanity version changes so if you migrate a build tree between VMs then it won't re-run
Dec 23 17:06:55 <rburton> so top tip: when chasing weird build problems in a new environment create a new build dir
Dec 23 17:07:02 <rburton> to force the full sanity check to run
Dec 23 17:10:27 <havok101> perl existed on OS. It wasn't part of the environment when running update-ca-certificates. I'm not entirely sure but changing "c_rehash ." to "perl c_rehash ." worked. Launching the native c_rehash in the x86_64 dir also did not work. It needed to be preceded by "perl". I compared the update-ca-certificates and c_rehash scripts between working and non-working machines and it seemed fine.
Dec 23 17:10:39 <havok101> I can see how the sanity wouldn't fail since perl actually did exist
Dec 23 17:11:01 <rburton> the script uses a hashbang does it not
Dec 23 17:13:37 <havok101> it does. So I really don't know why it bombed "#!/home/ctDev/code/yocto/ct_meta-boot2qt/build-ct-var-som-mx6/tmp/sysroots/x86_64-linux/usr/bin/env perl"
Dec 23 18:44:30 <kergoth> Failure expanding variable AVAILABLE_LICENSES[:=], expression was ${@' '.join(available_licenses(d))} which triggered exception FileNotFoundError: [Errno 2] No such file or directory: '/data/kergoth/mel/yocto-test/cbmr-802/meta-mentor/meta-mel-support/licenses'
Dec 23 18:44:32 <kergoth> what the hell?
Dec 23 18:44:37 <kergoth> hmm
Dec 23 20:30:23 <Crofton|road> anyone have some ideas why files in IMAGE_BOOT_FILES do not make it into a wic timage?
Dec 23 20:36:37 <JPEW> Crofton|road: Do you have an entry in the .wks file with --source=bootimg-partition ?
Dec 23 20:36:53 <Crofton|road> yeah using one from oe-core
Dec 23 20:37:03 <Crofton|road> sdimage-bootpart.wks
Dec 23 20:38:10 <Crofton|road> hmmm
Dec 23 20:44:03 <Crofton|road> crazy
Dec 23 20:44:18 <Crofton|road> I fear tomorrows problem, too much socializing
Dec 23 20:55:05 <havok101> quick question I have libsdl2 building and I'm not sure which recipe is triggering it. What's a good way to figure this out?
Dec 23 20:58:25 <JPEW> havok101: bitbake -g might tell you
Dec 23 21:00:37 <havok101> thanks
Dec 23 21:05:13 <kergoth> oe-depends-dot is helpful with that
Dec 23 21:16:33 <JPEW> kergoth: Did you see my comment on pyrex?
Dec 23 21:17:24 <kergoth> nope, missed it somehow. odd. znc didn't send me that part of the backlog
Dec 23 21:17:54 <JPEW> kergoth: PYREX_OEROOT isn't referenced in the default pyrex.ini anymore, is it in your local one?
Dec 23 21:23:05 <kergoth> I'm on the next branch. ./pyrex.py mkconfig - > pyrex.ini -> pyrex.ini references PYREX_OEROOT in the comments commands block.
Dec 23 21:23:42 <kergoth> commit 69eb6e51b93a3a7227c5a91139737bc241327975 (HEAD -> next, tag: v1.0.0-beta3, origin/next) is checked out
Dec 23 21:23:54 <kergoth> s/comments/commented/
Dec 23 21:24:37 <JPEW> Ah, right.
Dec 23 21:25:42 <JPEW> kergoth: Ya, that one is wrong for sure. I missed it because it's comment out by default :)
Dec 23 21:28:01 <JPEW> kergoth: What do you have in the "commands" variable?
Dec 23 21:28:46 <kergoth> i just uncommented it to corerct the bitbake path to being in ${PYREX_OEROOT}/../bitbake, not ${PYREX_OEROOT}/bitbake
Dec 23 21:28:54 <kergoth> left it as is otherwise
Dec 23 21:29:05 <kergoth> just trying to get a basic setup with oe-core+bitbake as siblings to work
Dec 23 21:29:38 <JPEW> kergoth: It *should* work with that variable commented out; I made the container capture the bitbake path and save it off independently
Dec 23 21:29:46 <JPEW> Or at least I thought
Dec 23 21:30:26 <kergoth> didn't work here, says the bitbake path doesn't exist
Dec 23 21:30:31 <JPEW> Ok
Dec 23 21:30:43 <JPEW> My test must not be correct
Dec 23 21:58:35 <JPEW> kergoth: Weird, it works for me... would you mind sending me the file $BUILDDIR/pyrex/build.json ?
Dec 23 22:20:24 <kergoth> JPEW: it doesn't get far enough to actually do anything, there is no build.json. it fails in the initial capture.
Dec 23 22:20:25 <kergoth> JPEW: https://gist.github.com/kergoth/01f6142e830761b38d2b40e0b911a9bd
Dec 23 22:35:40 <JPEW> kergoth: OK, I know whats wrong. The bitbake directory isn't being bound into the container during capture. I think the bigger problem is that the PYREX_OEROOT variable is terribly named :)
Dec 23 22:35:44 <kergoth> JPEW: i don't think this is that different from the suggested init in the README< but maybe i'm missing something
Dec 23 22:36:05 <JPEW> kergoth: No, you're doing what the README says, it's just wrong :)
Dec 23 22:36:31 <JPEW> I think if you set PYREX_OEROOT=$PWD everything will work
Dec 23 22:36:47 <JPEW> I'll rename the variable to make it more clear what it's purpose is
Dec 23 22:42:21 <kergoth> getting this after changing the source cmd to change PYREX_OEROOT=$PWD and running bitbake -p: ERROR: Unable to find conf/bblayers.conf or conf/bitbake.conf. BBPATH is unset and/or not in a build directory?
Dec 23 22:46:05 <JPEW> kergoth: Interesting. That appears to be a zsh-ism... but I get "Pyrex user config file must be defined in $PYREXCONFFILE!" so it's not exactly better :)
Dec 23 22:46:29 <JPEW> kergoth: OK, I can reproduce both of these and I'll take a look over the holiday
Dec 23 22:49:28 <kergoth> cool, thanks
**** ENDING LOGGING AT Tue Dec 24 02:59:57 2019