**** BEGIN LOGGING AT Thu Apr 17 02:59:58 2014 Apr 17 08:41:14 morning all... Apr 17 08:44:33 good morning Apr 17 08:54:43 morning all Apr 17 09:07:33 Argh! Why did the kernel MMC devs decide to have no connection between slot id's and devnodes...! Apr 17 09:07:49 * pev slaps his forehead **** BEGIN LOGGING AT Thu Apr 17 13:14:40 2014 Apr 17 14:05:42 fyi: denix and I are working the BBB boot issue. Apr 17 14:07:05 wmills: thanks Apr 17 17:24:30 So, historically, pseudo has intercepted *xattr() calls so it can set errno to ENOTSUP. Apr 17 17:24:49 This is because, if the xattr() calls work, coreutils will sometimes use fancy extended attributes to implement plain-old chmod. Apr 17 17:25:28 And I am wondering if anyone can point me at an actual standard, or documentation, explaining the exact syntax of those fancy extended attributes... Apr 17 17:33:08 anyone know about building llvm for gpu support? Apr 17 17:40:27 darknighte: it is builtin based on platform Apr 17 17:41:05 hey khem. Apr 17 17:41:46 I am using a new toolchain and I suspect that I have a misconfiguration somewhere with that. Apr 17 17:42:06 in any case, I have a dependency on mesa, which brings in llvm. Apr 17 17:42:22 both the llvm configure/compile stages complete, but the install fails. Apr 17 17:42:26 darknighte: yes and llvm should use neon on armv7+ Apr 17 17:45:10 seebs: attr utility is what can be used to change extended attribs Apr 17 17:45:44 darknighte: whats is failing error in install Apr 17 17:45:44 khem: I'm trying to walk back from the error output to figure out the misconfiguration, but haven't had much luch so far Apr 17 17:48:27 khem: The thing I'm looking for is that, on at least one system, plain old chmod(1) was actually using setxattr() to set extended attributes which happened to map onto posix permissions. Apr 17 17:48:56 And I'm trying to figure out where I saw that and do some testing against it, but I can't remember where it was exactly. Apr 17 17:49:13 seebs: most distros uses attr Apr 17 17:49:26 Oh, I'm sure that would work *also*. Apr 17 17:49:36 chmod could be doing it on OpenBSD may be :) Apr 17 17:49:47 It was a Linux, because I encountered it in pseudo. Apr 17 17:49:54 chmod(a) was using setxattr() to set perms? that sounds twisted Apr 17 17:49:58 s/a/1/ Apr 17 17:49:59 This is why pseudo has error-out-instantly implementations of *xattr(). Apr 17 17:50:21 And yeah, I was really unhappy with that one once I figured it out. Would probably have been at least two years ago, too. Apr 17 17:51:04 kergoth: BSD ones do IIRC Apr 17 17:51:11 Only thing I can find is that listxattr(2) man page says "Filesystems like ext2, ext3, and XFS which implement POSIX ACLs using extended attributes, might return a list like this:" Apr 17 17:51:14 huh, interesting Apr 17 17:51:36 It's not *totally* insane, I guess, although it seems like a ton of overhead compared to a 16-bit value in the inode. Apr 17 17:56:20 some security stuff use extended attributes Apr 17 17:56:32 I guess to meet FIPS reqs Apr 17 19:11:49 fyi, just submitted a patch for BBB boot issue Apr 17 20:36:56 I am having a problem in poky 1.3 + meta-systemd: libsystemd-login0 is not being installed, and dbus is failing to start due to missing this library, but I cannot figure out how to get it installed. Apr 17 20:37:43 the actual IPK is named libsystemd-login0, but it's not mentioned in the systemd bb file anywhere, so if I try to add it to IMAGE_INSTALL, bitbake says it's an unbuildable dependency chain Apr 17 20:38:05 neither is libsystemd-login mentioned anywhere, so I can't figure out how to get it installed Apr 17 20:38:53 To further the mystery: I'm completely unable to figure out how libsystemd-login is actually being packaged at all, even looking at my poky 1.5 sources, I can't see where this is packaged or how Apr 17 20:54:25 Ok, I see where it's splitting out the libsystemd-* packages in the systemd bb file: populate_packages_prepend Apr 17 20:54:56 but that still doesn't answer my question about how I can specify to install a package in my image that is never mentioned in the bb file Apr 17 21:35:44 How do I get a package into the image that is automatically generated by do_split_packages()? If I add it to IMAGE_INSTALL, bitbake tells me there is an unbuildable dependency chain. Apr 17 21:50:42 so, I want to be able to compare automated build sstates vs my current build using bitbake -S printdiff. but the SSTATE_DIR from the build doesn't contain the intermediate sigdata, so it's not possible to do a detailed comparison. you have to also capture the automated build STAMPS_DIR sigdata files, copy them to your own STAMPS_DIR, and then do the bitbake -S. this isn't ideal. I wonder if there's a way to emit the stamps_dir sigdata into Apr 17 21:50:42 SSTATE_DIR as siginfo files with appropriate names there Apr 17 21:53:50 Hmm. Apr 17 21:54:27 I'd worry a bit about filesystem/directory-size issues, but that's solvable. Apr 17 21:55:10 mebrown: the recipe needs to add the appropriate patterns to PACKAGES_DYNAMIC for the dynamically generated packages Apr 17 21:55:21 mebrown: then bitbake will know it can emit those binary packages, and thereby resolve the runtime dependencies Apr 17 22:00:00 Hmm, suppose I could ship my automated build STAMPS_DIR subset (just sigdata not covered by siginfo) inside the shipped SSTATE_DIR, in a subdir, and write a little shell script to use it to do the bitbake -S printdiff Apr 17 22:00:02 * kergoth scratches head Apr 17 22:04:20 * kergoth 'll have to pester RP about this tomorrow, having an SSTATE_DIR that isn't alone sufficient to determine why those sstates aren't being used, is not ideal Apr 17 22:10:29 Yeah, that does seem like it wouldn't give the desired results for some purposes. Apr 17 22:11:33 the issue is, SSTATE_DIR includes e.g. siginfo for populate_sysroot, but no siginfo for do_fetch, do_install, all the intermediate steps leading up to that. without that, it can't track down the root causes of a change very well Apr 17 22:11:45 so bitbake -S printdiff just dumps a list of changed tasks, with nearly zero variable info Apr 17 22:11:49 which is pretty useless :) Apr 17 22:18:49 Hmm, I wonder if I could subclass a new SignatureGenerator which dumps sigdata into SSTATE_DIR, and also override sstatesig.py in lib/oe/ to also check there for sigdata files Apr 17 22:18:58 * kergoth ponders Apr 17 23:29:52 aha, I was entirely mistaken. intermediate siginfos are written to SSTATE_DIR, just an artifact of our build process that isn't shipping them Apr 17 23:51:11 Hmm, it is a potential concern that SSTATE_MIRRORS only fetches the task siginfo, not the intermediate task siginfo, though. Apr 17 23:51:13 * kergoth ponders Apr 18 00:02:37 evening Apr 18 00:04:56 going a bit nuts here - trying to build gstreamer & gst-plugins-good-udp on top of my minimal image but whenever I include the plugins it pulls in 500+ more packages including all the X11 stuff. I've made sure x11 has been removed from DISTRO_FEATURES but not sure what else you can do to stop this? Apr 18 00:11:45 if you removed x11 from distro features, no x11 stuff will be built. it won't even be possible to build much of it, as it causes libx11 to be unbuildable Apr 18 00:24:57 Hm, thanks - Ill have another look... Apr 18 00:26:28 Also, is there not a tftp client in the default recipes in Yocto? Apr 18 00:42:58 pev: see the layer index. it searches both the core metadata and the many other available layers in the community. From a quick search (http://layers.openembedded.org/layerindex/branch/master/recipes/?q=tftp) it looks like atftp, inetutils, and tftp-hpa are all available in meta-networking, which lives in meta-oe Apr 18 00:43:10 http://layers.openembedded.org/layerindex/branch/master/layer/meta-networking/ Apr 18 00:44:23 Ah! That's a handy util, thanks! Apr 18 00:58:52 np **** ENDING LOGGING AT Fri Apr 18 02:59:59 2014