**** BEGIN LOGGING AT Mon Aug 15 02:59:58 2016 Aug 15 05:12:45 whats TERM set to Aug 15 05:13:01 usually its a problem with virtual terminals Aug 15 05:13:09 does it work with screen ? Aug 15 07:41:29 is it possible to do_install_append_$machine ? Aug 15 08:06:46 also, it's possible to use sed in do_install commands right? Aug 15 08:13:49 seds claiming the file doe not exist at the given path in the sysroot, but it does Aug 15 09:04:18 iskander: `echo $TERM`, then maybe `export TERM=linux` or `export TERM=xterm` Aug 15 12:02:45 jubr, it is still not working Aug 15 12:02:51 tried both Aug 15 12:03:18 make: *** No rule to make target `menuconfig'. Stop. Aug 15 12:03:19 Command failed. Aug 15 12:03:20 Press any key to continue... Aug 15 13:38:51 anyone have some experience with HP ProDesk 600 G2 mini ? i cant get it to boot. It runs the installer but after its done and reboots it prints "efi: requested map not found" Aug 15 14:36:02 Are there any benefits from letting multiple yocto trees, versions and machines use the same sstate cache? E.g. building for ARM vs Intel. Or one build building for jethro while another is building krogoth. Aug 15 14:37:05 yes. particularly in the former case. many 'native' recipes are built, which target the build machine. those are teh same between MACHINEs Aug 15 14:39:01 +1, althought may not be quite as usual across different releases, but certainly targets Aug 15 14:40:09 How do you share sstate across multiple users? I mean, do you allow all users to contribute to the common sstate? Or do you only generate it from a controlled build, like a build server? Aug 15 14:40:24 Do you allow it grow indefinitely? Aug 15 14:41:50 NFS is the only scheme that can be used that provides a two-way update of the remote sstate cache? Aug 15 14:45:05 sveinse: that's really up to you Aug 15 14:45:26 we control our sstate size by removing files based on access time. i.e. nothing has used the file in over a week, gone Aug 15 14:49:28 kergoth: Ah, that's a pretty smart way of managing it. (Yet this is the first time in years I've heard a use case for atime) Aug 15 14:51:09 :) yeah, i've used it both for yocto downloads and sstate, and it's about the only time i've used it too Aug 15 14:51:53 how do you share to the users? Aug 15 14:52:06 that depends Aug 15 14:52:32 at my company, we update our sstate on an internal server from our automated builds with rsync and share that via http, and have a cron job on that server for the atime cleanup Aug 15 14:52:37 same with downloads Aug 15 14:52:40 note that sstate over NFS is good at exposing bad NFS servers Aug 15 14:52:47 hah, indeed Aug 15 14:55:27 Many of our devs are remote, so VPN is being used, with NFS begin tricky at best. So I think we'll settle at http. Aug 15 14:56:07 To my understanding that will build up a local sstate cache with what has been downloaded and what has been generated locally, right? So I could make a script that rsync back from the user's local sstate to the server sstate cache, and thus providing to the sstate pool? Aug 15 14:56:25 or do a nightly automated build to populate the cache Aug 15 14:58:48 rburton: yeah, for those builds that are "mainline". However, like now, where I'm experimenting with new BSPs and Yocto version. At the start of this conversation it was said that there are advantages to share sstate caches across such changes. And there are multiple devs working on these experiments, so sharing is a great way of doing this Aug 15 14:59:14 (But we might consider multiple sstate caches for the different development stages) Aug 15 15:04:44 (this is going to be interesting: Storing sstate cache on a NTFS fs... Windows runs into corners when ':' are encountered) Aug 15 15:05:19 not sure we support sstate on ntfs Aug 15 15:05:31 can you even create a file with : in on ntfs? Aug 15 15:06:46 khem: http://errors.yoctoproject.org/Errors/Details/74601/ <— thoughts? Aug 15 15:07:29 rburton: I'm out of disk space -- again -- and I'm syncing sstate-cache to a small USB3 drive I have with NTFS. It seems ubuntu's fusefs is happy with it. Let's see how it goes Aug 15 15:09:07 How do I workaround (INSANE_SKIP): QA Issue: libXYZ.la failed sanity test (workdir) in path [....]sysroot-destdir/usr/lib [la] Aug 15 15:10:27 dfrey: well one fix is to delete the .la files as they're pointless and cause problems like this. Aug 15 15:10:50 we just rsync from our automated builds to populate the cache for engineers to use, and don't share sstate for changes not in mainline, here. sstate can bloat up awfully fast with every little local change you're making. Aug 15 15:11:05 hello! is there any way I can have a recipe point to a local git repo rather than a remote one? Aug 15 15:11:33 nisha: either use externalsrc or a file: url. i.e. git:///some/local/path;protocol=file Aug 15 15:11:40 rburton: roger that, I'll add that to the recipe. Now how can I workaround it for the build with INSANE_SKIP ? Aug 15 15:11:44 that'll pass file:///some/local/path to the git-clone Aug 15 15:12:07 kergoth, thanks! I'll try that Aug 15 15:12:23 dl9pf: well if you delete the file it can't trigger the sanity check Aug 15 15:12:39 you want to fix it as otherwise you've a way of breaking future builds Aug 15 15:12:44 (which is why the check exists) Aug 15 15:13:34 rburton: yes the fix will be done (rm .la) - for the moment I need to build to proceed, so I can find the other failing stuff Aug 15 15:14:09 rburton: Just unplugged my NTFS drive with sstate cache and plugged it into windows. It seems to be intact. That is I see the files, but I can't read them. Aug 15 15:14:51 dl9pf: INSANE_SKIP_(package) += "workdir" iirc. but if you're editing the recipe then just throw in a rm Aug 15 15:15:13 I had a suspicion that that would happen. NTFS is a fairly agnostic file system in this respect. Its windows GUI which is croaking on "invalid" filenames Aug 15 15:15:27 sveinse: ah interesting Aug 15 15:15:41 NTFS even have symlinks. Windows don't use it, themselves thou Aug 15 15:15:57 rburton: tnx. I'll have to poke the recipe maintainer. Aug 15 15:18:05 kergoth, I get an error: Failed to fetch URL git:///path/to/local/repo;protocol=file Aug 15 15:18:22 insufficient information. check the do_fetch log file Aug 15 15:21:49 hmm...not sure why it is doing this: DEBUG: For url git:///home/nisha/work/cascadia/dlt-daemon;protocol=file returning http://downloads.yoctoproject.org/mirror/sources/git2_home.nisha.work.cascadia.dlt-daemon.tar.gz Aug 15 15:22:31 so it's looking for a tarball? Aug 15 15:41:50 I keep getting "fatal: Not a git repository (or any parent up to mount point /home)" multiple times while building an image. How can I track down which recipe generate this? Aug 15 15:51:50 sveinse: i've seen older pulseaudio releases do that but we patch that out of them now Aug 15 15:52:23 you could enable kernel auditing and get a trace of file access for /home/.git/ Aug 15 15:57:20 svense: I've seen that before when the git repo bb is trying to access is not on the same filesystem as the build directory. E.g., it's symlinked to someplace else or it's on a bin-mount fs. Aug 15 16:06:26 rburton: Good idea -- My knowledge of kernel tracing is limited, but we can assume that is's the git executable accessing .git, can't we? And the parent process to git is bitbake isn't it? Aug 15 16:09:07 its quite possibly a configure.ac trying to determine if its in a git clone to mark the version, or something Aug 15 16:14:31 sveinse: BB_NUMBER_THREADS = '1' with a `bitbake $image-recipe | cat -` will give you nice sequential output - it skips the fancy rendering Aug 15 16:17:32 you could grep the cooker log to see if the message ended up in there, and if it did work out what tasks were active at the time Aug 15 16:21:30 cat - is redundant, fyi, cat reads from stdin and writes to stdout by default Aug 15 16:21:32 just | cat will do Aug 15 16:21:34 :) Aug 15 16:25:46 * jubr could pretend he borked his copy-paste of `| cat -n` -- but he won't :) Aug 15 16:26:11 tnx for the tip! Aug 15 16:30:45 :) Aug 15 16:31:57 I'm having a Yocto problem on Debian. I'm fairly new to Yocto so I'm ignorant of many things, but I've been told that there are "virtual" names in some places for packages, of the form "virtual/whatever" Aug 15 16:32:31 For some reason, the Yocto build I'm attempting, with Debian package generation, is generating a DEBIAN/control file that still includes the full "virtual/whatever" in the package name. Aug 15 16:32:44 Because '/' is an invalid character for a package name, this fails the build immediately Aug 15 16:32:57 Any ideas what I might be missing would be appreciated! Aug 15 16:33:09 This is Yocto-2.0.1 for reference. Aug 15 16:42:58 AgentElrond: I recall you doing a `bitbake -c menuconfig virtual/kernel`, can you try if using the real recipe would help? Probably something like `linux-$machine` Aug 15 16:44:51 jubr: I haven't used menuconfig or any "virtual/whatever" in the command-line. I have just used "bitbake overall-package-whatever" Aug 15 16:52:03 This is similar to what I'm seeing: https://community.nxp.com/thread/394705 Aug 15 16:56:36 AgentElrond: i think that was a bug in the recipes, virtual/ shouldn't be used in target packages. meta-oe had some fixes for that. Aug 15 16:56:51 This is even closer to what I see. https://github.com/imyller/meta-nodejs/issues/3 Aug 15 16:57:21 RPROVIDES specifically seems to be the line that causes issues with virtual/ for do_package_write_deb Aug 15 16:58:20 basically recipes shouldn't be using / in target names as dpkg doesn't like them Aug 15 16:58:27 unfortuntately nobody actually tests with dpkg Aug 15 16:58:41 because 99% of people use rpm or opkg, which don't object as much Aug 15 16:59:04 so my recommendation is "use opkg or rpm", followed by fix the recipes to not use virtual/ in target package names Aug 15 16:59:14 as build-time PROVIDES/DEPENDS its fine Aug 15 16:59:30 Noted :) Aug 15 16:59:41 definitely stop using / in package names anyway Aug 15 16:59:47 Would fixing the RPROVIDES line be a likely solution, or is it going to be more trouble than it's worth? Aug 15 16:59:59 its *the* fix Aug 15 17:00:10 Thanks again, sorry about the spam Aug 15 17:01:54 rburton: Does PROVIDES solves RDEPENDS needs? Aug 15 17:02:23 Package A RDEPENDS on virtual/foo. Package B PROVIDES virtual/foo? Aug 15 17:02:39 no Aug 15 17:02:53 provides/depends are build time, rprovides/rdepends are run time. two en tirely different namespaces Aug 15 17:03:10 So how do you solve the RDEPENDS without using a slash? Aug 15 17:04:02 yocto has some notable differences from Debian package building Aug 15 17:05:01 stwcx: Perhaps a package RDEPENDS on a name without a slash, e.g. YOUR_PREFIX_package? Aug 15 17:06:15 AgentElrond: The point of virtual is to be able to abstract a concept though. A package can need virtual/foo and multiple packages can satisify virtual/foo in their own wa. Aug 15 17:06:16 y Aug 15 17:07:00 either use VIRTUAL-RUNTIME, which is a way of selecting runtime packages using build time variables rather than selection at the package manager level, or use rprovides/rdepends without a / Aug 15 17:07:10 virtual/ is just a convention anyway, your virtaul package name can be anything Aug 15 17:07:13 call it 'blah' for all we care Aug 15 17:07:25 virtual/ssl is an example on some systems because openssl and libressl both provide the same functionality. Aug 15 17:07:36 so call it virtual-ssl and move on Aug 15 17:07:37 kergoth: With that in mind, is there any reason for them to not be virtual-foo ? Aug 15 17:07:41 ;) Ok. Aug 15 17:07:46 again, the name can be anything the package manager supports Aug 15 17:07:50 virtual/ is a convention, that's all Aug 15 17:07:59 and a convention only for build time at that Aug 15 17:08:11 kergoth: I wasn't sure if Yocto has anything special for virtual/. I do see that in a few .py files when I do a grep. Aug 15 17:08:39 there are a couple bits primarily to strip off or add back the prefix, when our bbclasses mangle the name Aug 15 17:08:52 so e.g. it ends up virtual/nativesdk-foo, not nativesdk-virtual/foo Aug 15 17:08:54 minor stuff Aug 15 17:09:13 can't think of much else off the top of my head, but maybe there's other bits. hopefully not Aug 15 17:10:28 kergoth: There is a little bit of stuff in lib/bb/providers.py and lib/bb/runqueue.py. runqueue.py looks the most interesting. Aug 15 17:10:43 Looks like it creates a special log file of those virtual lookups. Aug 15 17:11:15 sounds questionable, it should be able to identify cases where multiple recipes provide the same thing and use that, but i could be missing something Aug 15 17:11:17 * kergoth shrugs Aug 15 17:53:04 How do I resolve a dependency loop? I got a large printout of two identified loops, but I have to admit I have problems seeing where the loop is Aug 15 17:53:27 good question, everybody has that problem :) Aug 15 17:53:43 the info is better than nothing, but it's still a lot of troubleshooting and manual digging into the recipes mentioned Aug 15 17:54:05 That is, I do know where it comes from: I added a dependency on qtbase from avahi. Aug 15 17:54:42 okay, so remove that and then dig into the dependency graph to see why qtbase depends on avahi. Aug 15 17:55:22 bitbake -u depexp -g qtbase may be of use, or bb whatdepends avahi qtbsae if you have bb, or a number of other options Aug 15 17:55:27 I added a PACKAGECONFIG --enable-qt5 to avahi. Aug 15 17:55:35 they'll at least show the dependency graph, if not the *why* Aug 15 17:55:56 right, so obviously if that introduces a cycle, then we know qt must need avahi as well as avahi needing qt. so again, dig into the former Aug 15 17:55:57 kergoth: wasn't there a dot that could show the deps? Aug 15 17:56:05 that's what bitbake -g is Aug 15 17:56:11 -u depexp gives an x11 gui to that info Aug 15 17:56:19 ah, right Aug 15 17:56:33 but bitbake -g and examining the .dot files or using graph-tool woudl be an option too Aug 15 17:59:26 from a quick check with whatdepends, it's pulseaudio. qtbase wants both pulseaudio and libnss-mdns, both of which result in pulseaudio being built, and pulseaudio wants avahi. Aug 15 18:01:27 yes, I just found the same thing: qtbase wants pulseaudio, which wants avahi. So when I setup avahi to depend on qt5base.... Aug 15 18:02:49 There is no way round this I suppose other than building the package twice? Make a new recipe avahi-qt5 which only packages libavai-qt5? Aug 15 18:03:08 hmm, then you run a real risk of packages being out of sync... Aug 15 18:03:52 unless you don't want pulseaudio and can disable that in qtbase, yeah, i think that's about the only way, unless you arrange for special tasks to subvert the cycle Aug 15 18:04:47 No, we don't use pulseaudio. So that might be the approach. Thanks Aug 15 18:05:51 * sveinse thinks fiddling in qt5 recipes is always a lot of fun Aug 15 18:07:25 Hi, I'm trying to get sshd running on a small image I'm creating but I'm running into some trouble. It seems that the start script isn't running because there is no file /etc/init.d/functions Aug 15 18:07:48 I've added the server to my image with the following line: IMAGE_FEATURES += "debug-tweaks ssh-server-openssh" Aug 15 18:44:53 Wow. DISTRO_FEATURES_BACKFILL_CONSIDERED has to be yoctos most nonintuitive variable, IMHO. Aug 15 18:45:46 the concept is actually pretty simple. backfilled features are appended regardless of what you set DISTRO_FEATURES to. considered backfilled features are those you've explicitly decided you want disabled anyway. Aug 15 18:45:50 but the variable naming is perhaps not ideal Aug 15 18:46:21 backfill is needed to let the core change the default distro features even when external distros set (rather than add/remove) DISTRO_FEATURES in their distro .conf Aug 15 18:47:27 But I use this to /remove/ functionality (pulseaudio in my case). So please explain BACKFILL? My lingual interpretation of "backFILL" and consider, suggests adding something, doesn't it? Aug 15 18:48:09 i just told you Aug 15 18:48:18 DISTRO_FEATURES_BACKFILL are items added to DISTRO_FEATURES behind the scenes Aug 15 18:48:23 it *is* adding something Aug 15 18:48:57 the _CONSIDERED part says you considered those items and want them not backfilled. as i said, that variable naming is likely not ideal. DISTRO_FEATURES_BACKFILL is named appropriately, but DISTRO_FEATURES_BACKFILL_CONSIDERED Is less than intuitive Aug 15 18:51:13 okay. I'm not going to make this my fight anyways, I was just curious. Perhaps DISTRO_FEATURES_BACKFILL_OMIT or some other negative/subtractive statement would have been better. EOD for my part :D Aug 15 18:51:45 i'm agreeing with you. i said 2-3 times, the _CONSIDERED variable is likely named badly :P Aug 15 18:52:18 yes, I got that XD Aug 15 18:52:34 not the first time our variable naming wasn't ideal Aug 15 18:54:11 sadly we're stuck with it unless we provide compatibility along the way Aug 15 18:54:22 I find the obsession about using 'tmp' really fun Aug 15 18:55:07 over the years plenty of folks had moved the output of the build out of tmpdir, but once sstate was added that become not really possible due to how sstate packaging works (paths are all relative to the same root) Aug 15 18:55:22 would be nice to add support for that again by adding an intermediate path for the sstate archival Aug 15 18:56:15 worth noting that you can trivially rename it to something else, if you want. it's not an obession, it's a default directory name. TMPDIR = "${TOPDIR}/foo" for example Aug 15 18:56:44 having everything we do relative to $PWD was a key design consideration when we started the project -- we needed to stay self contained to avoid mucking with the user's system Aug 15 18:57:17 that's fair enough, it just seems... odd Aug 15 18:57:43 how so? the vast majority of what ends up there is temporary, it's just intermediate artifacts of the build process. Aug 15 18:58:56 And you have more than one tmp. each recipe has its own tmp and a work. So you'll end up typing tmp a lot when doing development Aug 15 19:00:28 well, tmp/deploy/images is an output, not a temporary directory. But perhaps the thinking is that you have a build management system that fetches the artefacts from tmp/, moves it elsewhere and deletes the tmp dir Aug 15 19:02:06 I haven't got any problems with this, I just raised my eyebrows a few times when getting used to this. I guess all build systems has its own things and quirks Aug 15 19:35:24 Is it possible to exclude recipes from builds? We have a meta layer which provides recipes for our application and images. Depending on which BSP we use, different image recipes must be used. Unfortunately unreferenced recipes still fail on require, so we cannot collect all of them into one layer when a globbed BBFILES path is used in layer.conf Aug 15 19:48:40 sveinse: you can break up your repo so some appends are only used if the corresponding layer is included in teh configuration. Aug 15 19:49:36 sveinse: add https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5-L10 or equivalent (other layers do this too), then move your appends into a subdir based on the layer name (as used in BBFILE_COLLECTIONS, not the path on disk. i.e. 'openembedded-layer' not 'meta-oe') Aug 15 20:25:51 Hmm. I'm guessing if I rename part of the path above the yocto build, the build will be invalidated or fail? Aug 15 20:26:12 e.g. once a build has already finished, if I rename the directory to yocto_bob instead of yocto_default? Aug 15 20:27:44 I'm assuming all you'd need to do is source ae-init-build-env again Aug 15 20:27:53 oe* Aug 15 20:28:13 I was afraid absolute paths would get baked into dependencies / caches / scripts / whatever Aug 15 20:28:27 Perhaps my fears were groundless Aug 15 20:30:20 AgentElrond: you'll need to wipe tmp Aug 15 20:32:19 kergoth: Thanks, that's what I was afraid of. The tmp directory is some 3+ hours of building and 11+ GB of data. Aug 15 20:32:36 ? Aug 15 20:32:43 if your sstate is outside of tmp, rebuilding from sstate is trivial Aug 15 20:32:45 doesn't take long at all Aug 15 20:33:00 Well, my system might be very slow to compile Aug 15 20:33:06 But I'll bear that in mind Aug 15 20:33:45 sstate is prebuilt binaries, the whole point of sstate is to *not* compile. Aug 15 20:33:52 builds from sstate == extracting some tarballs Aug 15 20:34:32 Thank you for yet again correcting my ignorance Aug 15 20:35:04 I'm TRYING to educate myself on some things via google and hands-on experience, but I still spam the IRC channel more than is necessary Aug 15 20:35:17 np Aug 15 20:35:33 there's a lot to pick up, quite a learning curve. worthwhile, but still a lot of complexity to pick up **** ENDING LOGGING AT Tue Aug 16 02:59:58 2016