**** BEGIN LOGGING AT Wed Sep 13 03:00:01 2017 Sep 13 07:22:52 nefethael: I was talking of the overlay patch that was pointed to you... Sep 13 07:23:07 local overrides at imge-generation time Sep 13 07:42:31 boucman_work: ok, it's strange that kind of stuff is not already mainstream :) Sep 13 07:45:35 nefethael: my guess is that the way the yocto people think yocto is used and the problems I have in deep embedded systems are a bit different. That patch was also there to make them aware that the "distro+local administrator" doesn't relly work when there is no user Sep 13 07:45:54 the only place to do admin-level modifications is at image generation time, but yocto is not geared for that Sep 13 07:46:48 my patch is one way to do that but there may be other ways... the yocto people might have other plans, or no plan at all. Any way, my patch doesn't need deep surgery, it can be added as a separate layer, so no big deal Sep 13 07:48:23 boucman_work: indeed. btw, any public layer using that class ? or your work is private ? Sep 13 07:49:11 nefethael: it's kinda private... our private layer is "stuff we need but should be mainlined" so we don't want external people depending on it. We remove recipes without warning when they are mainlline Sep 13 07:49:51 but the patch is in the ML, so it's trivial to add to your layer if you need it Sep 13 07:52:25 yes sure, just french curiousity Sep 13 08:02:28 nefethael: hey, french here too, I can understand that :P Sep 13 08:03:00 héhé Sep 13 10:35:58 Hi guys, I emailed yesterday on the yocto mailing list regarding gdbserver debugging and missing /usr/src/debug in -dbg packages or files not found respectively. Can anyone here help, or shall I submit a bug report?! Sep 13 11:48:39 Hi all, I have two variations of a library (diff configs), one installed under /usr/lib and the other under /opt/xxx/lib. Checking the generated RPM files all files are under the right dirs but I get warnings "The recipe xxx is trying to install files into a shared area when those files already exist." How can I stop this warning since they are completely independent? Sep 13 11:53:42 rdanter: did you clean your build directory, just in case these conflicts are leftovers from before you had the libs separated correctly? Sep 13 11:54:20 Also, it's probably a good idea to set PRIVATE_LIBS for these to avoid automatic dependency calculation jumping around between providers, depending on which one of them was built later Sep 13 11:54:37 neverpanic: yes, even tried recreating the whole project Sep 13 11:55:02 I will take a look at PRIVATE_LIBS, thanks for the hint :) Sep 13 11:59:39 rdanter: Did you check that the files staged into the sysroot do not conflict? Sep 13 12:12:07 I will check, just building at the moment with PRIVATE_LIBS set Sep 13 12:24:59 hi Sep 13 12:25:18 would it be possible to get the recipe wich builds a package? Sep 13 12:34:17 neverpanic: adding PRIVATE_LIBS removed half the warnings, now I only get those about runtime-reverse manifests, before I had that and runtime. Sep 13 12:36:14 any ideas for these other warnings? Sep 13 12:39:34 pastebin please. Sep 13 12:40:41 warnings or recipe? Sep 13 12:41:07 warnings, I'd say. Sep 13 12:44:26 https://paste.ubuntu.com/25527326/ Sep 13 12:46:45 Ah, so the problem are the runtime-reverse files, which are generated from the libraries automatically and installed in the pkgdata folder. Those then conflict with the original ones. Sep 13 12:47:25 I would have assumed setting PRIVATE_LIBS would no longer generate those files, but it seems that's not the case. You'll probably have to do some digging in the bbclasses that generate those files to find out how to avoid them for your boost-cpp11. Sep 13 12:48:04 ok, thanks again Sep 13 12:58:03 hey, what would i do if i want to use a .bbappend only if a certain image is being built? Sep 13 13:05:34 peacememories: different options exist. You could use a different layer for this bbappend and include this layer only for the specific image. You could also use BBMASK. But maybe there are better solutions out there. Sep 13 13:05:52 You cannot make packages behave differently using the images in which they are going to be included. You could use a different MACHINE, a copy of the recipe with a different PN, a layer only enabled when you build packages for this image Sep 13 13:07:21 hmm okay. different question: say i wanted to change my u-boot package when building for flash storage (enabling ubivol support), could i do this with some sort of machine/image "feature" that i can enable in local.conf? Sep 13 13:08:47 one of our test boards already has a complete bsp, and i am loathe to create another one just for adding ubivol support to uboot, but i don't want to add it to the image either. and i also might not always want to build it that way Sep 13 13:10:57 peacememories: wouldn't the usual way to do this be creating a disto for this specific use case, add a layer in your distro config and put a bbappend that enables ubivol support into this layer? Sep 13 13:11:17 that distro config can of course also re-use the bsp you already have Sep 13 13:15:28 okay, i guess i'll need to look into distro configs^^ Sep 13 13:15:32 thanks for the info :) Sep 13 13:15:39 peacememories, why don't you use a variable wich disable by default the ubi in the recipe, then when you want to enable it you overide the variable from the local.conf? Sep 13 13:18:11 aurele i could probably also just add a bbappend-file to my current layer and just deal with the fact that i may have added useless features in some builds for the time being. it's only a test system after all, i will need to write a bsp for our target platform anyway^^ Sep 13 13:30:26 i want to install festival on the target image, it gives me this error "ERROR: festival-2.3-r0 do_compile: oe_runmake failed" i have added the meta-oe to bblayer also . how to solve this error ? Sep 13 13:32:31 coldZERO, does it give you more error information that you could post in a link? the error says it failed running make on the package, but there should be more details :) Sep 13 13:38:58 hello, is it possible to write a bitbake recipe that creates an sdcard image that includes two very different rootfs in different partitions? assume I do not want to use wic for sdcard image creation and want to get away with just one bitbake command Sep 13 13:39:51 what would be the proper procedure for implementing this if at all possible? a custom bbclass? Sep 13 14:00:27 eduardas_m: sounds like you want to write a class that replicates wic :) Sep 13 14:02:24 @peacememories : it gives me another error now and here is the log : https://pastebin.com/K3DqmeiU Sep 13 14:20:49 rburton: is there a wic source that simply lets add files to a partition? Sep 13 14:21:30 because I need to add an initrd inside one of the partitions Sep 13 14:21:52 which is built differently than the other two rootfs'es I need Sep 13 14:41:42 Hi, Does someone know a place where bitbake recipes for the x86-64 compiler target could be found ? something like udev-native or things like that ? Sep 13 14:42:19 eduardas_m: bootimg-partition plugin can do that. files should be in deploy directory and mentioned in IMAGE_BOOT_FILES variable. Sep 13 14:42:55 eduardas_m: you can see examples in meta-yocto-bsp/conf/machine/beaglebone.conf and meta-yocto-bsp/conf/machine/edgerouter.conf Sep 13 14:43:58 eduardas_m: and in correspondent wks files meta-yocto-bsp/wic/beaglebone.wks meta-yocto-bsp/wic/edgerouter.wks Sep 13 14:53:53 ed21: thank you a lot, will take a look at it right now Sep 13 14:54:51 eduardas_m: no prob. btw, files can be renamed. you can see it in edgerouter.conf Sep 13 14:55:07 janho: Are you looking for poky/meta/recipes-devtools/gcc? Sep 13 14:55:42 Although IIRC bitbake does not build a separate compiler for your build machine, it uses your system compiler. Sep 13 14:56:04 neverpanic, no, I'm looking for udev-native :/ to compile tools Sep 13 14:56:56 I need the libudev headers and library from host compiler Sep 13 14:59:35 poky/meta/recipes-core/udev, seems like you'd to add a bbappend that adds BBCLASSEXTEND = "native", though. Sep 13 15:00:05 oh tks, I didn't think to bappend for this purpose Sep 13 15:00:10 I try it Sep 13 16:06:10 If I want yocto to run my cronjobs can I just create a custom file in cron.d? Sep 13 16:06:18 Im installing the crony package. Sep 13 16:20:05 RP: IIRC you have once described some issue in pseudo, which wasn't completely fixed only improved to be a lot more rare, I'm still seeing some recipes to sometimes create files with UID/GID of the user running bitbake, but only very rarely (like 2 times in 1000 rebuilds of given recipe with latest pseudo) with the version in morty it happens a bit more often (like 5 times in 1000), does it ring a bell? The Sep 13 16:20:11 pseudo log shows many errors, but with both versions and in both builds when the UID is correct and when it's not Sep 13 16:22:09 JaMa: the issue I 'fixed' was a hang which was replaced with a slight chance of data corruption with high numbers of processes. There is something odd goes wrong with glibc-locale and others and I have no real understanding of that except that its to do with deleted files and reuse of inodes from previous files which were deleted outside pseudo Sep 13 16:26:17 JaMa: FWIW, I've also seen this issue Sep 13 16:27:49 RP: neverpanic: yes that looks like related to inodes, in my logs I see: https://pastebin.com/WNjF8Jgv Sep 13 16:28:41 JaMa: I'd guess rm_work makes it worse Sep 13 16:29:11 by removing the pseudo database from previous run? Sep 13 16:29:58 or rather recreating files all the time? because I'm not sure if pseudo directory is removed by rm_work Sep 13 16:33:47 I have a imx6 system running krogoth and systemd. I want it to log verbosely to the console, but currently it doesn't. How do I enable this? Sep 13 16:34:43 Hey everyone, I'm trying to do an rsync with http://downloads.yoctoproject.org/releases/yocto/ to get all of the IPK files for a given release, but it seems to be password protected. Does anyone know how to circumvent this/a mirror? Sep 13 16:35:01 Interestingly I have a console=ttymxc0,115200 console=ttymxc0,115200 console=tty1 statement in the kernel cmd line. On ubuntu systems this should be enough to get logging, but apparently not here Sep 13 16:36:16 sveinse: check for 'quiet' or a change to the log level on the commandline Sep 13 16:36:25 kernel commandline, that is Sep 13 16:36:33 kergoth: I have level 4 on loglevel. Sep 13 16:36:53 What direction is more level? Do you know Sep 13 16:38:59 7 is nice :D Sep 13 16:41:28 How is a service stopped under systemd? Isn't SIGTERM sent to it? Sep 13 16:41:50 JaMa: pseudo directory is removed I think so perhaps its related to rebuilds? Sep 13 16:42:45 RP: neverpanic: I've tried to find the more significant difference in pseudo.log files with: for E in "inode mismatch" "creat ignored for existing file" "path mismatch" "creat for.*replaces existing"; do echo $E; for L in WORKDIR.*/pseudo/pseudo.log; do grep -q "$E" $L && grep -c "$E" $L && echo $L; done; done Sep 13 16:43:17 My service has some important cleanup to do before a shutdown, and the service use 10-20secs in response to SIGTERM. But systemd kills it withing 2 seconds. The DefaultTimeoutStopSec is set to 1m30s, so apparently something else is happeneing Sep 13 16:43:23 and "path mismatch" is very common shown at least 231 times in small component, but builds with wrong UIDs have slightly different number Sep 13 16:44:08 but other 3 log entries are shown usually only in build where the UID was wrong in the end Sep 13 16:44:28 but I have also one build where they were shown, but UID correct Sep 13 16:45:49 what is your filesystem? Sep 13 16:46:18 there are two causes (that I know of) for the inode mismatch.. either the file was modified outside of pseudo control -- or you are on a filesystem that does not have persistent inodes Sep 13 16:46:38 fray: ext4 (rw,noatime,barrier=0,commit=6000) Sep 13 16:46:48 fray: I think we have many issues with modified outside pseudo control (deleted) Sep 13 16:46:52 ya, that should not have the persistence issues Sep 13 16:47:20 fray: I think it can under certain circumstances :/ Sep 13 16:47:30 * RP just doesn't know what they are Sep 13 16:48:22 there is the potential for inode truncation on '32-bit' with larger then 32-bit number of inodes on the system... but that should also be rare Sep 13 16:48:46 (with LFS enabled, which I believe is the default -- I don't think it will actually occur in practice) Sep 13 16:49:25 RP: I'm restarting the test, but it looks like rm_work wasn't used in my previous loop, because I'm doing bitbake -c cleansstate foo && bitbake -c build foo in Yocto 2.2 Morty where it doesn't trigger rm_work task Sep 13 16:57:44 fray: Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Sep 13 16:58:09 fray: if LFS is the large_file ext4 feature than I have it enabled as well Sep 13 16:58:25 I don't remember how to do it, but you'd need to check the total number of inodes on the device.. see if it's larger then 32-bit.. Sep 13 16:58:43 that would be the corner case that -could- trigger a problem, one that I've not seen because LFS should prevent that Sep 13 16:59:05 /dev/mapper/vg00-jenkins 65798144 10108243 55689901 16% /jenkins Sep 13 16:59:09 JaMa: I would love a way of reproducing it. rburton and I do see this on local rebuilds now and again, usually glibc-locale, usually when large parts of the system have changed sig Sep 13 16:59:26 JaMa: I have to suspect inode numbers since it isn't always reproducible :/ Sep 13 17:00:48 RP: maybe we can make those 3 pseudo log entries more visible/fatal for the build and then it might be easier to spot what leads to it, than noticing it afterwards from wrong UID Sep 13 17:01:42 or at least to find out if there are valid reasons for those to happen at all Sep 13 17:02:51 JaMa: "creat ignored for existing file 'file-with-wrong-UID'." does sound very like the file was deleted but had an ID in the pseudo database Sep 13 17:03:05 JaMa: I wonder if we could/should add some kind of sanity test Sep 13 17:04:37 RP: it's also interesting that these UID issues seems to be triggered only for some files, e.g. in the component I'm testing it's always one from 2 files and in glibc-locale I also remember seens just few files, so it's not completely random Sep 13 17:05:11 is some task running in parallel w/ othe rprocessing that is under pseudo control? Sep 13 17:05:39 the other cause could be something (on the host) with setuid running (since that would prevent pseudo).. but I can't think of ANY standard tool that should/could be under setuid Sep 13 17:07:06 RP: sanity check just grepping pseudo.log like we do for configure issues? that's good idea and easy to implement Sep 13 17:08:55 fray: in my case while rebuilding the same component 1000 times, there is very little parallelism involved, but I can set BB_THREAD to 1 Sep 13 17:09:53 on the other hand with 2 failures in 1000, it won't prove anything to do another 1000 without issue with BB_NUMBER=1 Sep 13 17:10:13 we need at least a bit more reliable reproducer Sep 13 17:10:34 parallelism I was thinking was something that a make or do_install or something was running.. Sep 13 17:10:41 RP: I'll add that sanity check and give it a spin Sep 13 17:10:54 lets say do_compile runs and spews off some background processes.. finishes, and bitbake moves on to do_install (under pseudo) and starts doing things.. Sep 13 17:11:13 if somehow they 'clash', that could cause a problem.. I have seen that in some of the more complicated builders (in the past).. Sep 13 17:11:16 but nothign recently Sep 13 17:11:24 I see, but I doubt that it happens in my component Sep 13 17:12:09 it doesn't do anything special, for the file which ends with wrong UID it calls qmake REPLACE and that's it Sep 13 17:13:27 be interesting to know what this 'qmake REPLACE' does internally.. Sep 13 17:13:34 uses some kind of syscall of function not emulated? Sep 13 17:31:17 kergoth: ping ... i found your message about: "| build.exe: error: Option -n only allows one instance in command line! " (ovmf) do you remember how that was fixed ? Sep 13 17:31:32 (reference https://www.yoctoproject.org/irc/%23yocto.2017-04-04.log.html) Sep 13 17:33:01 dl9pf: it just needs PARALLEL_MAKE = "". the recipe already disables it for native, but it can fail on target too Sep 13 17:33:06 haven't had a chance to submit it Sep 13 18:00:05 kergoth: aah, tnx. Sep 13 18:01:50 not a very informative error, took some trial and error :) Sep 13 18:02:08 kergoth: i bet. i can offer to take care Sep 13 18:02:20 I assume pyro + master needs it. Sep 13 19:07:10 is there a way to disable IPv6 in Morty? Sep 13 19:09:36 remove ipv6 from distro features? Sep 13 19:09:48 i presume you're writing software for The Past :) Sep 13 19:10:59 afternoon. I have a question: I am finding it hard to change kernel configuration. Sep 13 19:11:17 I do a -c menuconfig Sep 13 19:11:29 and it utterly ignores my changes. Sep 13 19:11:46 I just need to add some options to the standard configuration. Sep 13 19:11:53 What would be the best way to do that? Sep 13 19:13:34 rburton: yes - making a time machine, it only goes backwards. :( Sep 13 19:13:56 Does anyone know, is that a bitbake argument to tell it to ignore hash mistmatches on builds? Sep 13 19:14:51 https://www.irccloud.com/pastebin/jLLL5evM/ Sep 13 19:15:10 Im getting that, basically, its showing a mismatch for a remote file it tries to pull down. Sep 13 19:15:26 Im not sure how to work around that. Sep 13 19:17:03 tcpdump: why not placing the correct checksums, as indicate in the log? Sep 13 19:21:59 lsandov1: im not even sure where thats being called from? Sep 13 19:35:33 Figured it out. Sep 13 19:35:55 rburton: DISTRO_FEATURES_remove = "ipv6" Sep 13 19:35:56 ? Sep 13 19:37:33 yes Sep 13 20:26:50 Dear All, Sep 13 20:26:50 Can somebody explain me following phenomen: Sep 13 20:26:50 1. I do have on meta-foo, Sep 13 20:26:50 Which has two recipies -> recipe-image1.bb which has a lot of stuff in IMAGE_INSTALL and is large (300 Mib) and recipe-image2.bb, which is supposed to be tiny one. Sep 13 20:26:50 The problem is that for both of them (bitbake -e recipe | grep ^IMAGE_INSTALL) I do have a lot of packages defined with IMAGE_INSTALL. Sep 13 20:26:50 Shouldn't those two packages have disjont IMAGE_INSTALL settings? Sep 13 20:28:49 It seems like IMAGE_INSTALL for recipe-image2.bb gets some stuff appended: Sep 13 20:33:07 use bitbake -e, it'll show a history of changes to the variable, and its final value, so you can see how precisely it got set the way it is Sep 13 20:34:12 kergoth: without bitbake -e, one would be lost! Sep 13 20:34:37 considering how few inspection tools we have, the ones we do have are even more important, yes :) Sep 13 20:35:10 hehe right Sep 13 20:35:26 kergoth: especially handy bitbake -e | grep ^IMAGE_INSTALL Sep 13 20:35:43 kergoth: the other inspection tool I can think of is git grep Sep 13 20:35:53 because the bare bitbake -e is to verbose Sep 13 20:36:09 lukma: if you grep it out, you can easily miss the variable tracking history that immediately precedes the variable definition itself Sep 13 20:36:31 if you want to see that info, pipe to less and searchf or it instead Sep 13 20:36:45 kergoth: Ok Sep 13 20:38:17 kergoth: And the penny has dropped Sep 13 20:38:58 it seems like the problem is with common ./conf/xxx.distro file which adds to IMAGE_INSTALL Sep 13 20:39:25 no distro should ever be touching IMAGE_INSTALL Sep 13 20:39:39 that violates our independent axes of distro/machine/image Sep 13 20:39:53 if the distro really wants something in its default images across the board, there are better variables for that Sep 13 20:41:06 kergoth: I do have a set of 'base' packages Sep 13 20:41:25 and I thought that it would be nice to "pack" them all to *.distro file Sep 13 20:41:40 What other technique shall I use to achieve that ? Sep 13 20:41:44 we already have packagegroup recipes with sets of packages, can you not use and/or modify those? Sep 13 20:41:48 packagegroup-base, etc Sep 13 20:42:13 Those are embedded oriented one, also the rootfs is pretty tunned Sep 13 20:42:37 if your rootfs is that tuned, you should just create your own image recipes and packagegroup recipes Sep 13 20:42:46 and install htose packagegroups in your images Sep 13 20:43:02 if something is truly common to them all, just create a bbclass with the bits common to your images, and inherit it in them all Sep 13 20:43:11 lots of cleaner ways than doing things in your global configuration Sep 13 20:44:46 I've thought that *.distro is for this (I do create my own distribution of SW, with _ appended for different ones) Sep 13 20:45:59 kergoth: I'm just curious: Sep 13 20:46:15 In the distro I do use: IMAGE_INSTALL_append = " nano " (which is as you said wrong) Sep 13 20:46:29 yeah, that's completely wrong, and not at all what distros are for in the yocto universe Sep 13 20:46:56 but then in the recipe-image2.bb there is IMAGE_INSTALL = "list of packages" Sep 13 20:47:00 distros are global configuration and policy. how things are built, what feautres are supported, either globally or in particular recipes, what packaging formats are used, etc Sep 13 20:47:16 why thins IMAGE_INSTALL = behaves like IMAGE_INSTALL_append ? Sep 13 20:47:18 _append is a postponed operation, it'll happen after the assignment int he recipe, so will be added to both Sep 13 20:47:21 it doesn't Sep 13 20:47:46 as i just said, _append isn't immediate, it appends to the value of th evariable later on, when it's used. the assignment in the recipe won't override that Sep 13 20:47:52 kergoth -> so now it is clear .... :) Sep 13 20:47:57 see the bitbake user manual for detials on the file format Sep 13 20:48:13 with _append OE waits till IMAGE_INSTALL = Sep 13 20:48:24 and then "appends" to it Sep 13 20:49:45 Ok, I will poke around for packagegroup way of definition Sep 13 20:50:18 append, prepend, and remove are all postponed operations. they occur at when the variables are used, which is long after the parsing of the recipes Sep 13 20:54:31 kergoth: Thanks for your support. Sep 13 20:54:41 I now do understand where I did the mistake Sep 13 20:55:29 kergoth: Is it possible to make RDEPENDS_${PN}_machine = conditional assignment? Sep 13 20:55:46 I do have some packages which are applicable only to special machines Sep 13 21:26:03 RP: that insane check for pseudo.log was just RFC, the v1 from ML might be a bit too strict, I can send v2 without inode mismatch and bb.error like in http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=614cf284c56574d460dca124e72a62df64925d84 Sep 13 21:26:56 RP: thanks for quick merge of the backports to pyro and morty Sep 13 21:32:04 JaMa: I wasn't planning on taking that to master, just playing with it Sep 13 21:32:33 JaMa: I'm curious if those other errors in dbus for example might let us spot real issues Sep 13 21:34:12 JaMa: np on the backports, those ones should be easy/safe I hop Sep 13 21:34:13 hope Sep 13 21:38:21 some people at work got new fast machines and were complaining about this glibc-locale QA issue recently Sep 13 21:39:04 RP: the dbus and systemd pseudo erorrs were both about passwd and group files, so maybe all recipes with useradd trigger this Sep 13 21:39:33 and there weren't the other errors shown in the pseudo.log with UID issue Sep 13 21:43:41 JaMa: I wondered about useradd... Sep 13 22:31:35 JaMa, fray: bitbake dbus; bitbake dbus -c install -f; bitbake dbus is a reliable trigger for creating messages Sep 13 22:34:20 RP: only for the inode mismatch right? Sep 13 22:35:04 btw: my last buildhistory diff shows a lot of packages differences like: Sep 13 22:35:05 -PKG = libcairo-staticdev Sep 13 22:35:05 PKGR = r0pro5 Sep 13 22:35:05 +PKG = libcairo-staticdev Sep 13 22:35:43 is the order of lines undeterministic or was it changed recenly? This build is from Morty and I haven't seen any buildhistory related changes there Sep 13 22:37:15 hi Sep 13 22:38:05 I am still using sysvinit and serial console is b0rked Sep 13 22:39:04 culprit seems to be ac0e9541f start_getty: Over added SERIAL_CONSOLE cause error in userspace log YOCTO #10844 Sep 13 22:39:19 JaMa: yes, but I think these other issues can grow from the inode mismatches... Sep 13 22:39:23 grep fails on 'PXA serial' Sep 13 22:39:46 JaMa: nothing changed afaik Sep 13 22:54:53 RP: I just got another wrong UID issue, but this time from CONTROL file (with ipk package class) "QA Issue: foo: /foo-dbg/CONTROL/control is owned by uid 1101, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]" Sep 13 22:56:14 ant_home: there a space in there? which grep fails? Sep 13 22:56:34 first one, finds just PXA Sep 13 22:57:00 activr_serial Sep 13 22:57:20 and this time nothing interesting in pseudo.log Sep 13 22:58:18 https://pastebin.com/i7C2MTDZ Sep 13 23:01:08 sgw, root@c7x0:~# cat /proc/tty/driver/PXA\ serial Sep 13 23:02:32 I got a failure (master-next) Sep 13 23:02:34 point to: Sep 13 23:02:38 lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True) Sep 13 23:03:40 got failres related to recipe-sysroot-native/installeddeps/...complete as well Sep 13 23:03:54 ant_home: not sure why the first one would fail I think this one is failing maybe, we need quotes around the $line? Sep 13 23:03:59 Presumably this is a similar lock file dumped out by bitbake (outside of regular pseudo) Sep 13 23:04:07 + activetty=$(grep -v "unknown" /proc/tty/driver/$line | tail -n +2 | grep -oh "^\s*\S*[0-9]") Sep 13 23:05:36 sgw, not enough. still wrong $line from before Sep 13 23:05:39 root@c7x0:~# grep "serial" /proc/tty/drivers | grep -oh "^\s*\S*[0-9]*" Sep 13 23:05:39 PXA Sep 13 23:07:45 sgw, but: Sep 13 23:07:46 root@c7x0:~# grep -v "unknown" /proc/tty/driver/PXA\ serial | tail -n +2 | grep Sep 13 23:07:46 -oh "^\s*\S*[0-9]" Sep 13 23:07:46 0 Sep 13 23:07:46 1 Sep 13 23:07:46 2 Sep 13 23:08:03 imho is just the first grep to fix Sep 13 23:09:18 sorry, lost the last char hee... Sep 13 23:09:57 second grep is fine once we fix the $line Sep 13 23:22:15 RP: in slightly bigger build I got errors from this do_qa_pseudo (even after ignoring inode mismatches) from 51 recipes including some packagegroups, so it might be still too much Sep 13 23:24:47 if I filter only those from oe-core: update-rc.d glibc linux-yocto glibc-locale packagegroup-core-boot packagegroup-core-ssh-dropbear ncurses util-macros util-linux lttng-ust python3 glib-2.0 python libconfig nettle flex curl sed llvm perl coreutils elfutils pango libnl openssh iptables strace nss alsa-plugins grub-efi sysvinit systemtap gdb lttng-modules Sep 14 00:29:44 Hi guys Sep 14 00:36:20 I'm writing a custom recipe for my app and it depends on libfdt.so (provided by dtc package) Sep 14 00:36:35 Since it's a runtime dependency I listed "dtc" under RDEPENDS variable Sep 14 00:36:54 however the configure step for my package fails saying libfdt.so not found Sep 14 00:38:36 however if I move dtc to DEPENDS variable, everything works well Sep 14 00:39:23 but why is this the case? Shouldn't runtime dependencies be in RDEPENDS as a matter of principle? Sep 14 00:41:24 angspatt03: RDEPENDS influences which packages get *installed*. Using DEPENDS is the correct variable here. Sep 14 00:42:51 hmm, so rdepends is for library that are not linked during compile time, but used in other ways: like dlopen() Sep 14 00:43:03 is my understand correct? Sep 14 00:43:14 angspatt03: (R)DEPENDS sound very similar but are quite different: RDEPENDS is a list of packages, whereas DEPENDS is a list of recipes... Sep 14 00:43:48 angspatt03: yes, DEPENDS is for build time dependencies, and RDEPENDS you would use for something which is really only required at runtime (e.g. library loaded via dlopen()) Sep 14 00:43:59 that makes sense Sep 14 00:44:08 thanks sagner! Sep 14 00:45:05 FWIW, the ref manual has also a rather good documentation about it: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-DEPENDS Sep 14 00:48:22 cool! All I consulted were some SO posts, but this makes it clear **** ENDING LOGGING AT Thu Sep 14 03:00:00 2017