**** BEGIN LOGGING AT Thu May 15 02:59:59 2014 May 15 06:57:44 morgen May 15 07:12:57 hi yocto, is there any variable to get the image_name (Ex., core-mage-minimal) May 15 07:35:21 good morning May 15 08:19:43 How hard is it to add the latest webkit (2.4.2) to the sato stuff? May 15 08:19:53 now it's 1.8.3 which is added May 15 08:20:15 or is there some branch available with the latest greatest things on it? May 15 08:48:25 morning all May 15 08:50:31 hi bluelightning, all May 15 08:52:01 hi mckoan May 15 08:56:00 hey guys, is there any guide / tutorial on rewriting shell do_rootfs for yocto 1.6? May 15 08:56:30 ot maybe someone could help me to update https://github.com/cgwalters/poky/blob/gnomeostree-3.10-dylan/meta-gnomeos/classes/gnomeos-contents.bbclass for daisy? May 15 09:00:13 vrutkovs: to be honest I would have to suggest not completely re-implementing image.bbclass like that, since the breakage you're experiencing is the result... May 15 09:00:32 I wasn't aware Colin had done that May 15 09:01:07 bluelightning: yeah, I guess it was a gross hack. Any recommendation on doing it right? I'm a complete n00b in this May 15 09:02:09 vrutkovs: I guess what I would do is examine what this custom class is doing May 15 09:02:22 first, which packages it adds - these can be handled easily with the default image.bbclass May 15 09:03:17 bluelightning: afaik the class simply prepares a rootfs, all the packages are handled in task-gnomeos-contents-runtime May 15 09:04:03 then, most of the rest of it seems to be hacks at the contents of the rootfs after installing, which again can be implemented with image.bbclass using ROOTFS_POSTPROCESS_COMMAND May 15 09:04:24 (you can still have a custom class that your images inherit, but it should build on top of image.bbclass rather than supplanting it) May 15 09:04:52 okay, I'm gonna try 'inherit image' and 'ROOTFS_POSTPROCESS_COMMAND += "prepare_rootfs;"' May 15 09:34:40 wv: last time i looked webkit had grown a ruby dependency, which makes it less than easy May 15 12:56:52 howdy! does Error 23: command not supported ring a bell for TCF/eclipse here May 15 12:57:39 remote running works fine, remote system browsing over TCF works, just trying to debug ives the above message May 15 13:24:59 hello is there someone who knows about bluez4 why pand is disabled ? May 15 13:26:40 sce: i can't think of a specific reason, feel free to add a PACKAGECONFIG to enable it (and send a patch when it works) May 15 13:26:51 oki May 15 13:26:55 i will try May 15 13:34:19 ah, the tcf problem is related to bug #5069 May 15 13:34:20 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5069 enhancement, Medium, 1.7, laurentiu.palcu, NEW , Eclipse TCF can support arm cpu debug now,but tcf-agent_git.bb can't do it this time. May 15 13:58:56 * ajtag is back (gone 00:02:30) May 15 15:32:04 busybox udhcpc does not seem to run as a daemon. How do you make sure that you get a new IP address if network is back again or if the network changes? May 15 15:32:07 I only found how/why it was removed: http://patchwork.openembedded.org/patch/33183/ May 15 15:56:17 I submitted bug 6339 about it. May 15 15:56:17 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6339 normal, Undecided, ---, richard.purdie, NEW , busybox dhcp client not started reliable May 15 17:53:38 So, does anyone ever mess with or use security_flags.inc? My specific question: Why does SECURITY_LDFLAGS not default to including -pie? It seems like a lot of packages may end up getting linked with LDFLAGS but not CFLAGS, or perhaps I am misunderstanding the relationship between them? May 15 18:00:16 FYI: there are still pieces of software in oe-core which don't obey LDFLAGS. meta-sourcery has a few of those fixes, since the external toolchain doesn't default to the gnu hash options we want, whereas the internal toolchain does, so its less noticeable May 15 20:13:18 how do you guys set up the firewall? Own firewall script in init.d or rc.local? May 15 20:56:38 Huh. May 15 20:56:50 Someone just pointed me at a 777 mode packages-split directory. May 15 20:56:56 That can't possibly be intentional, can it? May 15 20:57:38 heh, that sounds bad. i'd say bad umask, but don't we sanitize that? May 15 20:57:42 * kergoth shrugs May 15 20:57:46 I think so. And mine are all 700. May 15 20:58:01 ... no, wait. They're *mostly* 700. May 15 20:58:25 43:116 out of my sample for 777:700 May 15 20:58:30 i discovered a fun little issue the other day. if you inadvertantly do a build under a dir that's set g+s, then that leaks all the way down the child dirs into the rootfs :) May 15 20:58:38 gah May 15 20:58:54 of course, g+s is supposed to work that way, flowing into children, but it seems like we should make sure that doesn't affect our build output :) May 15 21:01:30 Yeah, it does. May 15 21:02:56 i was doing that build where i keep rebuilding from scratch montioring buildhistory, and i kept noticing g+s coming and going :) May 15 21:14:01 kergoth, weren't you seeing some kind of permission-changing errors recently? May 15 21:15:02 yep, we're seeing a variety of wrong file owner problems onf iles in the rootfs. i've seen both random files getting owned by xuser, even *ping*, and random files being owned by the build user id May 15 21:15:15 Huh. We're not seeing that that I know of. May 15 21:16:12 If you get the time or spare cpu cycles, try firing off https://gist.github.com/kergoth/b00e2c84b2d4e1e5ec82, if you would May 15 21:16:16 What we are seeing is pretty unpredictable modes on packages-split. May 15 21:16:23 i'm seeing it with pure upstream poky master, nothing mentor included May 15 21:16:26 interesting May 15 21:16:32 Perhaps most disturbingly, I always get 700 or 777, but someone else is also seeing 775 or 755. May 15 21:20:15 gah, not this one again - https://gist.github.com/kergoth/b1a702ce198b1104bdf6 May 15 21:20:21 * kergoth tries to remember what we did to work around that last May 15 21:25:50 Well, hmm. There's at least one umask(0) in the system (prserv does it), but that shouldn't affect this, but it looks like there may be something happening elsewhere. May 15 21:46:04 Huh. May 15 21:46:15 So bin/bitbake-worker checks for a task-dep on umask, and if one is present, sets umask to that. May 15 21:46:30 There do not appear to be any circumstances under which it will attempt to reset the umask. May 15 21:50:32 Huh. Just adding a bb.note() to bitbake-worker does not actually produce visible output, apparently. May 15 22:01:34 Huh. That's not it, and now I am suddenly curious: What on earth is making these mode 700 packages-split directories, when nothing I see is setting umask to 077? May 15 22:26:21 hi there why I get this error: May 15 22:26:22 QA Issue: package libqxt contains bad RPATH /home/rspock/Distributore/Yocto/mc2/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/libqxt/1.0-r1/build/lib in file /home/rspock/Distributore/Yocto/mc2/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/libqxt/1.0-r1/packages-split/libqxt/usr/bin/qxtjsonrpc May 15 22:26:30 libqxt is my own recipe May 15 22:28:59 rspock: you should disable rpaths in the build configuration for libxt May 15 22:29:13 (meaning, whatever scripts libxt uses to build) May 15 22:29:56 there is a configuration script in libqxt but I doesn't work in yocto May 15 22:30:24 so I set some variables and then run qmake directly May 15 22:32:10 how can I remove rpath from compiler flags May 15 22:58:36 Sp May 15 22:58:37 So. May 15 22:58:49 It turns out that GNU tar changes its behavior, in some cases, based on whether or not you appear to be root. May 15 22:59:15 And in particular, GNU tar 1.23, if it thinks you are root, and it is extracting a mode 777 directory, may end up calling mkdir(dir, 0700) May 15 23:00:37 So *part* of the issue is that packages-split can get created with different modes, but once that's done, how they'll look after extraction from sstate may depend on whether things think they are running as root, and which version of tar is being used. May 15 23:33:32 So. May 15 23:33:53 GNU tar, it turns out, will *always* try to use fchmodat(..., AT_SYMLINK_NOFOLLOW) May 15 23:34:04 And only if that fails will it try again without AT_SYMLINK_NOFOLLOW. May 15 23:34:17 But pseudo always ignores failures from the underlying chmod call, because they are probably harmless. May 15 23:34:24 So GNU tar never *retries*. May 15 23:34:42 So if you are running under pseudo, GNU tar will not necessarily restore permissions as expected on some files. May 15 23:34:59 But the exact behavior can vary depending on umask, whether or not geteuid() said 0, or whatever else. May 15 23:39:22 so what is the right general behavior? May 15 23:40:55 I am not sure. May 15 23:41:20 I suspect this may be a thing that works differently on Solaris, say, but I don't have to worry about that just this minute. May 15 23:41:35 I am currently experimenting with "just don't set that flag bit in calls to the underlying chmodat system call". May 15 23:41:55 And that does indeed fix the observed behavior. May 15 23:42:06 Of course. That just gets me to the state where these directories are "correctly" restored mode 777. May 15 23:42:21 Now I need to find out why they were set that way in the first place, because that's *also* almost certainly wrong. May 15 23:49:18 kergoth, if you have some time to kill: PSEUDO_1_6_0 now has a fix for a chmod problem that *shouldn't* be affecting real rootfs stuff, because the pseudo database was getting the intended values, but might have broken stuff in very strange ways. May 15 23:49:31 I haven't done a recipe or update for it yet, but it's out there. (It also has extended attribute support.) May 15 23:49:39 k, will play with it and see how it behaves for us May 15 23:51:26 I don't *think* this should affect rootfs stuff, but, well. There's lots of magic here. May 15 23:51:48 I was totally unaware, until about an hour or two ago, that GNU tar did *completely different* things when creating directories depending on whether or not it thought you were root. May 15 23:52:34 at least some of our issues were affecting package contents too, not just the rootfs, and of course ipks contain tarballs May 15 23:52:38 will see May 15 23:53:10 That *shouldn't* be a possible problem from this, I don't think, but... May 15 23:53:43 Well, obviously, there's stuff I don't understand involved. May 15 23:54:00 I am still reeling from "we are absolutely sure this flag will be rejected, so we always call fchmodat twice, once with it, and then once without it". May 16 01:35:14 So, that turned out to be easy to find once I had the bogus directory permissions gone, I think. May 16 01:35:40 In populate_packages, there's a "for pkg in package_list" which us run with umask(0) because it doesn't want umask interfering with file operations... May 16 01:35:58 And the first thing it does is bb.utils.mkdirhier(root), where "root" is packages-split/packagename. May 16 01:36:58 I think bb.utils.mkdirhier() should take an optional mode, and if that's provided, pass it on to os.makedirs. And should perhaps default to 755 if none is provided. May 16 01:38:48 I also wonder if pseudo should perhaps silently mask *out* go=w from modes when calling real-chmod, at the same time that it's masking *in* u=rwx. **** ENDING LOGGING AT Fri May 16 02:59:58 2014