**** BEGIN LOGGING AT Thu Sep 12 03:02:41 2019 Sep 12 05:10:45 Is there any way in a recipe to reference the base path of the layer that it exists in? Sep 12 05:11:29 I have some private key files etc. that are not placed in the recipe dir, but in a subdir directly under my layer root. Sep 12 05:21:05 iceaway, I know at least you can capture THISDIR with immediate expansion, :=, and use a relative path to any place in your layer Sep 12 05:26:22 kroon: thanks, will try that! Sep 12 05:28:29 I have another really strange issue, related to u-boot. I want to change between two different root file system, for firmware upgrade purposes, and in my uboot env the variable mmcroot= sets which root file system to boot from. The issue is that if I modify mmcroot from Linux with fw_setenv, it looks like it is successful with fw_printenv. But when I reboot mmcroot (if I print it in u-boot) will have Sep 12 05:28:35 reverted to the default value. If I continue booting into Linux and use fw_printenv however, I can see the value I set before rebooting. Sep 12 05:29:13 I can even add new variables with fw_printenv, which are retained after rebooting, but mmcroot seems like it always is overwritten when u-boot starts. Sep 12 05:34:06 iceaway, sounds like u-boot is not looking at the same env file that linux updates ? Sep 12 05:36:09 iceaway, can you see the variables you set with fw_printenv in u-boot ? Sep 12 05:36:11 That is what I thought too, but if I create a new variable with fw_setenv, I can see that variable in u-boot. Sep 12 05:36:29 I can also change other variables like mmcpart. but there seems to be some magic with mmcroot. Sep 12 05:36:41 iceaway, maybe some u-boot script resets it ? Sep 12 05:37:15 Possibly, not anything in the env though, I grepped the entire env for mmcroot and it does not appear to be set by any other script. Sep 12 05:37:53 not even via some sneaky variable substitution tricks Sep 12 05:39:17 Hmm I suppose it could be that, u-boot scripting is a bit of black magic to me. Sep 12 05:39:46 dev=root, mmc$dev=foobar - you get the deal Sep 12 05:40:14 I will have another look at the enviroment stuff :) Sep 12 05:43:56 Nothing really pops out for me. If anyone cares to have a look: https://pastebin.com/DkYqK9F0 Sep 12 05:45:59 Weird thing is that when Linux starts again, the mmcroot variable has been reverted to what I set before the reboot. So the change in u-boot does not seem to go into non-volatile storage. Sep 12 06:09:38 iceaway, nothing stands out to me. maybe its time to patch u-boot to debug if/when mmcroot is set Sep 12 06:14:25 kroon: yes, might have to do that. Thanks for the help. Sep 12 09:10:26 New news from stackoverflow: How do i patch in yocto? Sep 12 10:04:46 hello, i'm developing gui application in qt for raspberry pi, the application should start on boot (via sytemd service), I'd rather not start it as root, so I've added some users using extrausers class. Unfortunately, my application needs access to /dev/vchciq (GPU interface), which is owned by root/root. I'd like to add user group, such as gui for users that should be able to use GPU - that's not a problem, extrausers to the resque. The problem (or Sep 12 10:04:48 question) is where/when should I change the ownership of /dev/vchciq? Am I able to d that on build level? Or should I make some kind of service, that changes that on boot? Sep 12 10:05:18 write a udev rule to change the permissions as the node is created Sep 12 10:05:28 (as all the nodes in /dev are generated by udev) Sep 12 10:05:35 thank you, I'll investigate Sep 12 10:06:08 (as all the nodes in /dev are generated by udev) <- this looks exactly like the thing I was looking for, thanks rburton Sep 12 11:46:52 zeddii, if I need to bisect a linux-yocto regression, what is the standard procedure? Sep 12 13:20:29 I'm trying to find out how to get rid of a large lib in my image that I don't need. So I ran "oe-pkgdata-util find-path /usr/lib64/libVSC.so", to get the name of the recipe. But I cannot find that recipe anywhere. I tried looking for .bb files in my meta layers, and ran "bitbake-layers show-recipes" but it did not show up. Sep 12 13:30:01 iceaway, maybe you have better luck with: oe-pkgdata-util find-path *libVSC* Sep 12 13:32:32 kroon: I did find the recipe that brings in that lib, or at least the name of it, but when I search for that name I cannot find the actual recipe. Sep 12 13:33:53 Could it be hidden by some PROVIDES variable in another recipe? Sep 12 13:34:22 iceaway, packages can get renamed Sep 12 13:34:58 debian-style Sep 12 13:36:07 so you found which *package* the file comes from, but not the recipe which generated that package Sep 12 13:36:28 ahh right, the old package vs recipe confusion strikes again. Sep 12 13:37:08 more digging... Sep 12 14:20:46 I'm having great difficulty cross compiling a python3 package which is not a yocto /oe recipe yet. Sep 12 14:21:21 It uses cmake to build some binary components and it consistently finds libraries in the recipe-sysroot-native directory instead of recipe-sysroot. Sep 12 14:21:44 cmake.bbclass has "set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})" Sep 12 14:22:34 which suggests that both are added and, from what I've read, it should find stuff in ${STAGING_DIR_HOST} first. The library is there, but it still tries to link to the native one and fails. Sep 12 14:32:51 YP bug triage as started Sep 12 15:07:03 JPEW: if you want to fix RPs bitbake patch go for it :) Sep 12 15:10:11 rburton: I'm fixing it by replacing the whole thing :) Sep 12 15:10:58 rburton: We have to completely re-write the server and change the protocol in order for it to scale as well as we need. Sep 12 15:14:47 replacing it like writing it in Java ? Sep 12 15:29:36 armpit: heh, that would almost be worthwhile if it lead to more meta-java improvements ;) Sep 12 15:37:16 Java is only good in cup but rust or goland might be good options Sep 12 16:22:06 I'm getting errors with " rdepends on [debug-deps]". Is there an easy way to see why these rdepends are occuring? Sometimes when I see these errors it will say one so rdpeends on another, but I'm not getting that output this time Sep 12 16:40:56 I looked at the do_package_qa log and I saw some bbnote messages, I think I found out which file it was Sep 12 16:47:52 marler8997, you can always check insane.bbclass Sep 12 16:48:45 Yeah I could add some debug in there Sep 12 17:40:04 adelcast: if [ ! -z "$SOURCE_DATE_EPOCH" ]; then => if [ -n "$SOURCE_DATE_EPOCH" ]; then Sep 12 17:52:04 adelcast: also is it really necessary to depend on gnu tar? Sep 12 17:53:26 Can I have multiple but different versions of yocto/bitbake-memory-resident servers running at the same time ? Sep 12 17:53:48 (for different builds of course) Sep 12 18:02:53 And is there a faster way to extract TMPDIR besides running "bitbake -e | grep ^TMPDIR=" ? Sep 12 18:11:34 Piraty: the issue is --clamp-mtime, AFAIK that requires gnu tar > 1.28 Sep 12 18:11:55 yes, that's what the comment says Sep 12 18:12:36 why not set the time to SOURCE_EPOCH to all files alike ? Sep 12 18:13:17 usually developers have a mechanism to determine SOURCE_EPOCH on their own (or the buildsystem), at least i have Sep 12 18:13:23 the idea is to only modify the mtime for files that are created at build time, to have consistency Sep 12 18:14:46 https://git.dpkg.org/git/dpkg/dpkg.git/tree/dpkg-deb/build.c Sep 12 18:14:54 (that's what dpkg build does) Sep 12 18:16:06 that would be a good point (if feature parity is a goal ;) ) Sep 12 18:17:01 not necessarily parity since opkg is more lightweight Sep 12 18:17:21 but for most functionality, I do try to stay as close to debian as possible Sep 12 18:17:38 btw if gnu tar is the required one, tar -a would save you from the pipe to the compressor by only specifying the suffix. as far as i know, busybox tar has (or used to have) a different way of handling -a Sep 12 18:18:02 nevermind my noise then, thanks for maintaining opkg Sep 12 18:18:54 =), no worries, I do appreciate all input to improve the codebase Sep 12 18:38:02 adelcast: patch looks good, i can test it later Sep 12 18:38:52 rburton: thanks! Sep 12 18:40:04 adelcast: shouldn't you have prefix opkg-utils ? also, which bugzilla do you refer to? Sep 12 18:44:06 Piraty, yeah, that was my bad, the header message should have had [opkg-utils] to make sure this message was going to opkg-utils, not regular opkg Sep 12 18:44:26 was slightly confused for 5 sec Sep 12 18:44:32 all opkg bugs are tracked in bugzilla, under the yocto project Sep 12 18:44:42 i think you can set that prefix in the respective repo's .git/config Sep 12 18:44:49 https://bugzilla.yoctoproject.org/buglist.cgi?product=opkg&component=opkg Sep 12 18:45:00 ah, good to know, might as well just do that now Sep 12 18:45:03 ah this was new to me Sep 12 18:45:51 yeah, officially opkg is part of the yocto project, the source code is on yocto's git servers and bugs are tracked in yocto's bugzilla Sep 12 18:47:29 yet the ML is on google Sep 12 18:47:50 only yocto's opkg, not openwrt's yocto ;) Sep 12 18:48:53 yeah.....that other opkg is, well, a different story...I have been trying to see if we can merge, but haven't had luck Sep 12 18:55:13 the ML being on google really doesn't mean much, yocto has adopted projects that originally started elsewhere, transitioning mailing lists is a pain for everybody.. Sep 12 18:59:26 merging is hard code-wise or people-wise? Sep 12 19:01:35 people-wise, unsurprisingly....a couple of years ago someone took the effort of porting the OpenWRT patches to master yocto opkg and I worked with him to merge all of them Sep 12 19:02:03 but the openWRT guys showed no interest on starting using upstream yocto opkg Sep 12 19:02:36 and their opkg is weird...is branched off a random commit on 0.2.7, at least that's what it used to be last time I checked Sep 12 19:14:27 at least the use cmake, but that's a very small win then Sep 12 20:10:42 hi all Sep 12 20:11:42 is it possible to alter MACHINE_FEATURES from my layer but without re-creating the machine .conf file from the bsp that I use? Sep 12 20:12:40 I tried from local.conf and layer.conf but I can't do a MACHINE_FEATURES_remove on a per-machine basis Sep 12 20:12:54 thanks Sep 12 20:51:20 gondor: I would suggest to create a new machine conf Sep 12 20:51:41 which inherits the original machine and you override needed bits in that config Sep 12 22:10:04 JaMa: Thanks for the pointer. I seriously doubt it fixes the problem in the case, but I did figure out the issue I asked about yesterday. Sep 12 22:10:06 https://pastebin.com/Y8T6kbcZ Sep 12 22:10:33 The FILERPROVIDES was getting scrambled when usrmerge was on. Sep 12 22:10:56 So it causes the lib32-bash to look like it doesn't actually provide /bin/bash Sep 12 22:11:32 I'll send a patch out for consideration after more builds and analysis of the issue. Sep 12 22:12:44 yes, so it set the FILERPROVIDES as providing lib32-/bin/bash for you, right? Sep 12 22:13:31 that's the same as what I was seeing, but that's because of multilib, not usrmerge, isn't it? Sep 12 22:14:23 The multilib case seems to work ok. Sep 12 22:14:35 The usrmerge adds in a hard specification which gets overwritten. Sep 12 22:15:02 I had been debugging between a multilib build with and without usrmerge. Sep 12 22:16:48 At any rate, that seems to be logical way to fix it, but I don't want to break something worse. That condition is pretty deep in the call chain of lots of other functions for the variable manipulation. Sep 12 22:21:03 ok, for me this is broken in all builds using multilib without usrmerge, but my work arounds work as well, so I can live with it Sep 12 22:26:19 Ah... I can explain away why it breaks in the generic multilib case. Sep 12 22:26:47 It is the update-alternatives code that bash used that caused it to work for the multilib case without usrmerge. Sep 12 22:27:08 If the update alternatives are off, or not processed etc... You'd get the same exact error. Sep 12 22:27:33 That is why I figured the classextend change wouldn't exactly fix your issue. Sep 12 22:28:11 You would also need to have the same line of code the usrmerge activates in the bash recipe, and then you'd stop seeing all those errors. Sep 12 22:28:54 I had added a pile of print()'s to figure out what was going on. Sep 12 22:41:06 unfortunatelly u-a isn't the only issue with multilib, see http://git.openembedded.org/openembedded-core/commit/?id=01b9810ff1cea53ae321f6fbe760b83573ed78c0 **** ENDING LOGGING AT Fri Sep 13 02:59:57 2019