**** BEGIN LOGGING AT Thu Oct 02 03:00:01 2014 Oct 02 04:14:38 hi Oct 02 04:14:58 I am trying to override a DISTRO_FEATURE Oct 02 04:15:11 take it that local.conf is not the best place to do that? Oct 02 04:15:31 I would expect local.conf to be processed last, so I would be able to customize my build using it Oct 02 04:15:44 instead, it is the least important Oct 02 04:18:04 local.conf is what *sets* DISTRO and MACHINE Oct 02 04:18:14 it doesn't know what distro and machine config filenames to parse until it's parsed Oct 02 04:18:19 so it has to be parsed last Oct 02 04:18:41 but there are plenty of ways to do the sort of thing you want Oct 02 04:18:46 DISTRO_FEATURES_remove = "x11" Oct 02 04:18:59 assuming recent yocto, anyway Oct 02 04:44:07 but I want to add something Oct 02 04:44:17 which the layers I am using want to remove Oct 02 04:44:30 I would expect local.conf to be able to let me do that Oct 02 07:07:01 good morning Oct 02 07:40:51 morning Oct 02 08:39:54 morning all Oct 02 08:43:00 morning Oct 02 08:43:12 bluelightning: wiping everything out did help me, by the way Oct 02 08:43:25 bitbake no longer hangs on do_make_scripts :) Oct 02 08:43:51 xerent: ok... the unfortunate thing is though we may never find out what the real issue was Oct 02 08:43:59 indeed Oct 02 09:53:00 kergoth: you used yocto in an inappropriate way, i hope koen didn't notice Oct 02 09:58:01 hi. how can i disable that yocto bilds (bitbake) will always output a tar.gz? i just want the fs uncompressed Oct 02 09:58:50 oh found it. it can be done from the image recipe Oct 02 09:59:08 hi everyone. is there a simple answer to why i don't get a "sdimg" file (only ext3 files) when trying to build an image for a raspberry pi? Oct 02 10:01:12 KevinZA: IMAGE_FSTYPES is the variable that controls what types of image are produced Oct 02 10:02:22 check that you have rpi-sdimg in your value for IMAGE_FSTYPES - you can double check by looking at the output of bitbake -e Oct 02 10:03:16 hi Oct 02 10:03:35 I see in a bb file "PACKAGES =+ myfile..." Oct 02 10:03:46 is this valid ? Should'nt it be PACKAGES =+ myfile ? Oct 02 10:03:56 += Oct 02 10:04:45 ah - thanks. thats in the build/conf/local.conf? i saw something in the meta-raspberrypi conf files, and i see hob doesnt have that option. ok going command-line Oct 02 10:05:01 jmleo: =+ is like += except it prepends Oct 02 10:05:10 bluelightning: thx Oct 02 10:05:41 KevinZA: ah right yes Hob may not pick up that option value unfortunately (and probably forces it off) Oct 02 11:04:00 when building a kernel module, where does the output go? I set the CFLAGS=-M options to see exactly which header files were included, but this limits the output to preprocessor output only Oct 02 11:04:25 it's not in work folder, and not in the sysroot/usr/src/kernel either, even though makefile enters that directory when it builds Oct 02 11:25:30 ok so the issue is that I don't get any output to a file, it's output to make and make truncates it because all i see is a [CC] line in the log Oct 02 11:25:36 how can I change that Oct 02 11:32:07 xerent: I don't really understand your problem, but if it is more compiler output you want try EXTRA_OEMAKE += "V=1" in your kernel module recipe. this will add V=1 to the make commandline. Oct 02 11:38:56 my problem is that I need to understand which header files are included, full path Oct 02 11:39:16 the compiler complains about struct members being unknown but they DO exist in the header, properly Oct 02 11:39:36 so my conclusion is that the wrong header file is being included for some reason, and I need to get why Oct 02 11:39:50 or that gcc has gone insane, which is unlikely Oct 02 11:40:27 passing the -M flag to gcc will provide me with such output instead of a compiled program Oct 02 11:40:38 but the output is lost somewhere along the way Oct 02 11:40:44 and never reaches the log file Oct 02 11:41:24 all I get is a 'CC [M] /dir/foo.o' line Oct 02 11:41:45 which indicates that gcc has evaluated my query and responded with the information I wanted Oct 02 11:41:54 and that the information has been readily discarded Oct 02 11:42:02 xerent: Don't you get more output from make if you add V=1 to the make commandline? Oct 02 11:42:05 no :( Oct 02 11:43:38 xerent: Did you inspect the run.do_compile file to see that it is doing what you want? If you need to experiment, try to enter the devshell and calling the run.do_compile as any other file. Then you can do your changes directly in the run file. Oct 02 11:44:12 xerent: Of course you still need to figure out hoiw to reproduce your changes in the recipe, but as a debugging tool it can be quite useful Oct 02 11:55:43 Only two weeks until yocto day in Dusseldorf :-) Oct 02 11:56:16 Im still undecided wether to join beginner workshop or the advanced one. Oct 02 12:00:02 olani: yeah, I found that script Oct 02 12:00:19 seems no matter what I do I just get one output line of CC [M] foo.o Oct 02 12:00:44 this is a kernel module, I might add, so there might be some other Makefile that overrides it Oct 02 12:01:27 xerent: yes, I've managed to reproduce your problem with a kernel module of my own. Oct 02 12:01:43 :) Oct 02 12:05:45 setting MAKEFLAGS='V=1' generates some stuff Oct 02 13:25:44 Hey all Oct 02 13:26:35 this should be really easy I hope - ive got a random poky dir someone has sent me as part of a project. Is there a file somewhere inside that should tell me what version it thinks it is? At the moment I'm resorting to downloading various releases to compare to! Oct 02 13:26:56 pev: meta-yocto/conf/distro/poky.conf ? Oct 02 13:29:34 bluelightning: Thanks! Oct 02 13:34:31 well, as far as I can tell, the correct header file is included Oct 02 13:34:41 if I rename it, it doesn't find it Oct 02 13:34:56 if I put "lollipop" on the first line in it, I get a compile error Oct 02 13:35:09 but if I put "lollipop" right before the struct definition in question Oct 02 13:35:22 i.e. "lollipop struct foo { ... };" Oct 02 13:35:29 I don't get any compile errors Oct 02 13:35:48 there are no #if or #ifdefs around that definition Oct 02 13:36:55 oh wait, there is Oct 02 13:37:01 that's my cue Oct 02 13:37:04 :D Oct 02 14:34:02 where's the log.do_kernel_configcheck log file located? Oct 02 14:34:18 somewhere in work folder I take it :P Oct 02 14:35:25 never mind, found it Oct 02 14:48:19 | tar: license-destdir/systemd-compat-units/LICENSE: file changed as we read it Oct 02 14:48:22 anyone else getting these? Oct 02 14:48:31 in sstate_create_package Oct 02 14:48:38 we're getting these failures repeatedly on most of our automated builds Oct 02 14:48:59 hmm, wait, nevermind, i think i see the issue Oct 02 14:49:01 * kergoth checks Oct 02 15:55:56 On master right now meta-toolchain-qt5 is producing a broken qmake. It's missing qt.conf and when this is added it still fails to find the mkspecs correctly. There was some issues with multilib that broke the TARGETSYSROOT/PKG_CONFIG a few days ago so I susptect it's related to this but I am unsure where Qt is gathering this information. Oct 02 16:40:37 Hi all, quick obscure question: I'm working on a recipe that will pull from an active directory secured git repo. I include my credentials in the SRC_URI ("...user=domain\username:password") yet when yocto contacts the server it appears to strip the backslash separating the active directory domain and username Oct 02 16:41:13 you'll want to escape the \ Oct 02 16:41:15 use \\ Oct 02 16:42:07 I could have sworn I tried that. Of course it works immediately Oct 02 16:42:10 Thanks for your help Oct 02 16:42:45 As a follow up, is there a standard way of getting around having credentials stored in plain text? Oct 02 18:45:43 rburton: vg? Oct 02 19:02:36 otavio: fsl-arm is erroring as mesa and openvg-dev are conflicting. Oct 02 19:02:38 on the autobuilder Oct 02 19:03:05 rburton: I didn't get there yet Oct 02 19:03:17 rburton: I didn't look the failures yet Oct 02 19:03:32 been working in two toolchain issues Oct 02 19:06:50 otavio: ping Oct 02 19:06:58 sgw_: pong Oct 02 19:07:21 otavio: np I was not scolled to current looks like rburton already got you, sorry for the noise Oct 02 19:07:29 np Oct 02 19:07:31 :) Oct 02 19:19:05 So I thought of a thing, and I don't *think* it's happening in real use cases, but it's a possible issue for pseudo on overloaded machines. Oct 02 19:19:28 It used to be that you could just randomly kill the pseudo daemon and it would generally be fine -- nothing would get lost. Oct 02 19:19:44 With the FASTOP stuff, it's possible for the clients to not realize that a message got lost. Oct 02 19:20:01 I mention this because we had some weird behavior on a system where the pseudo server got killed by the OOM killer. Oct 02 19:24:58 is there a way to negate an entry in one of the *_FEATURES lists? like if I want to remove alsa from the MACHINE_FEATURES that is included in x86-base.inc Oct 02 19:26:05 assuming relatively recent yocto, you can use _remove Oct 02 19:26:26 either in local.conf, or you can provide your own machine .conf in your own layer which includes the other machine and then tweaks it from there Oct 02 19:26:35 MACHINE_FEATURES_remove = "alsa" Oct 02 19:26:37 ah, perfect. I'm using 1.6.1 Oct 02 19:26:42 thanks Oct 02 19:27:13 is there a way to remove an ASSUME_PROVIDED? Oct 02 19:33:29 Crofton: ASSUME_PROVIDED_remove ? Oct 02 19:34:22 I am wondering if that should work Oct 02 19:35:02 I am also wondering if we should have a way to force a native recipe to get built, even if it is ASSUME_PROVIDED Oct 02 19:35:51 you can always 'bitbake -f ' Oct 02 19:37:37 I want this to be super idiot proof :) Oct 02 19:58:00 hmmm so if BBFILE_PRIORITY of a layer is higher than OE-Core and it provides a recipe with older version than OE-Core, that gets chosen, and even DEFAULT_PREFERENCE wont work Oct 02 19:58:27 in essence if one is overriding a recipe in own layer it has to be done when absolutely used Oct 02 20:02:15 khem: yeah, that is pretty annoying. i've tried to add e.g. a _git recipe to our distro support layer and then i'm stuck defining a preferred pref on the oe-core version :) Oct 02 20:57:18 hey kergoth Oct 02 21:59:32 can you change the default terminal emulator used by bitbake on e.g. menuconfig? Oct 02 22:19:52 seebs: around? Oct 02 22:20:25 Somewhat. Oct 02 22:20:43 Brain is really not at its finest this week, but I'm at least conscious. Oct 02 22:21:05 seebs: I have this in pseudo.log "symlink err : 4869771624 ['/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/build/tmp/work/i586-poky-linux/python/2.7.3-r0.3/package/usr/lib/python2.7/encodings/gbk.pyc'] (db '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/build/tmp/work/i586-poky-linux/python/2.7.3-r0.3/package/usr/bin/python2') db mode 0120777, header mode 0100600 (unlinking db) Oct 02 22:21:05 " Oct 02 22:21:25 Huh, interesting. Oct 02 22:21:34 seebs: the thing should be a+x and it loses the +x bits Oct 02 22:21:49 If memory serves, what that says is: Oct 02 22:21:53 seebs: I'm wondering how it ended up in this position :/ Oct 02 22:21:56 We got a request involving inode 4869771624. Oct 02 22:22:20 This inode was in the database already, with the path '.../usr/bin/python2', which was a symlink, mode 0777. Oct 02 22:22:32 The request that came in was for 'gbk.pyc', which had mode 0600 and was a plain file. Oct 02 22:22:58 So what happened is: pseudo became aware of that symlink (python2), then something which was running outside of pseudo deleted the symlink, and the inode got reused. Oct 02 22:24:04 seebs: the trouble is that file (usr/bin/python) lost its execution bits Oct 02 22:24:22 amongst others, the log is full of this :/ Oct 02 22:25:04 Hmm. I wonder. What's the inode number of the python which has lost its bits? Oct 02 22:25:24 Okay, this looks like 6484. Oct 02 22:25:27 seebs: this is where it gets hard as I'm not on the original filesystem Oct 02 22:25:38 seebs: I think ross mailed you this failure btw Oct 02 22:25:48 And the attached log there looks very much like *something* did a large amount of file shuffling that wasn't run under pseudo for some reason. Oct 02 22:26:05 seebs: its just it keeps coming back :/ Oct 02 22:26:12 Yeah. Oct 02 22:26:24 what is the filesystem type? Oct 02 22:26:29 seebs: I don't know how that would happen :/ Oct 02 22:26:44 could something be shuffling inodes under the hood? -or- could there be a 32-bit binary doing something like a mv or cp or something? Oct 02 22:27:00 Any time a bunch of files get removed from the filesystem but not from the pseudo DB, you'll get really unpredictable behavior, since it all depends on who gets which inodes. Oct 02 22:27:15 hmm, xfs with 64 bit inodes Oct 02 22:27:38 does xfs not have stable inodes? (I thought it did) Oct 02 22:27:43 "/ type xfs (rw,relatime,seclabel,attr2,inode64,noquota)" Oct 02 22:28:00 we've suspected this may be specific to the centos builder Oct 02 22:28:01 seebs, AFAIK pseudo is using native inodes.. Oct 02 22:28:12 Ayup. We assume inode numbers are stable. Oct 02 22:28:27 we've seen cases on our own recipes where we're copying files and we get a failure on a mkdir -p (of a directory that already exists).. Oct 02 22:28:36 so far I doubt thats related.. but it's sure annoying.. Oct 02 22:28:49 it almost looks like something is violating the 'lock' and running at the same time.. Oct 02 22:29:28 The most common cause of this, for me personally, has been forgetting to make sure that 32-bit toolchain components had a corresponding 32-bit libpseudo. Oct 02 22:29:43 Whereupon objcopy would remake files when separating debuginfo, and things would go crazy. Oct 02 22:30:17 hmm. Oct 02 22:30:29 Does sstate ever try to archive a directory including its pseudo state data Oct 02 22:30:31 ? Oct 02 22:30:45 Like, actually archive the var/pseudo databases? Oct 02 22:32:33 seebs: no, we ensure pseudo is loaded and let it create a new db Oct 02 22:32:38 Okay. Oct 02 22:32:42 and no 32 bit here Oct 02 22:33:17 Well, hmm. In that case... Sometime in this process, just looking at the first thing in the logs: Oct 02 22:33:24 1. package/usr/bin/pydoc was created. Oct 02 22:33:42 2. something happened such that inode 4869771627 was no longer associated with package/usr/bin/pydoc Oct 02 22:33:50 3. hz.pyc was created, and got inum 4869771627. Oct 02 22:33:55 And #2 is what we need to find. Oct 02 22:35:02 Same thing with the others. A lot of files in package/usr/bin seem to have gotten their inodes reassigned to later files. Oct 02 22:36:01 Man, these error messages still suck. Some day I will get time to fix that. Oct 02 22:39:06 I'm gonna see whether I can reproduce any of this, because if it produces the log messages for me, even if it's not obviously producing bogus results, that might give me a hint. Oct 02 22:39:13 seebs: looking into files.db, there are no package/usr/bin/* files Oct 02 22:39:30 There aren't now, yeah. They got removed because their inodes were reused... Oct 02 22:39:49 seebs: I did see messages in a local clean build fwiw but related to pkgdata Oct 02 22:40:14 oooh Oct 02 22:40:19 I may have found a highly suspicious thing. Oct 02 22:41:48 seebs: its not something like only using 32 bits of the inode numbers is it? :) Oct 02 22:41:54 I don't think so. Oct 02 22:42:04 I mean, the numbers look reasonable, and I'm pretty sure my inode type is right. Oct 02 22:42:28 And I'm seeing a fair number of these which have names that look a bit like some rename operations might be slipping through. Oct 02 22:43:01 I'm seeing a lot of path mismatches between dirname/rAndOmName and dirname/actualfilename. Oct 02 22:43:29 seebs: so some operation not being intercepted? Oct 02 22:43:30 And that's a pattern that happens when tar is unpacking things. Oct 02 22:43:33 Could be. Oct 02 22:43:53 seebs: we use tar to copy files around Oct 02 22:44:05 Yeah. And it at least *used* to work reliably. Oct 02 22:44:25 Hmm. You know, for a long time, renameat() wasn't supported, and no one ever hit it. And it's implemented now, I believe... Oct 02 22:44:29 But it may be that there's a bug. Oct 02 22:47:10 Certainly, *something* seems to be wrong, because I'm seeing way, way, too many warnings and diagnostics about mismatches. Oct 02 22:49:45 seebs: I do have the original files for this still Oct 02 22:49:55 seebs: and the inode numbers in files.db just look wrong Oct 02 22:50:03 seebs: trying to figure out the pattern Oct 02 22:53:54 seebs: it looks awfully like the numbers are 32 bit truncated Oct 02 22:55:56 seebs: Filesystem: 30546842125 71CBBD20D Oct 02 22:55:56 files.db: 482071053 1CBBD20D Oct 02 22:56:37 seebs: 99.9% sure we're looking for losing the top bits somewhere since the files.db value is perfectly truncated Oct 02 22:57:06 (this was for log.do_install.13180) Oct 02 22:58:50 Huh! Oct 02 22:59:37 Well, hang on. Oct 02 22:59:45 Wait... That's odd. Oct 02 22:59:49 seebs: xfs tends to show up these issues fwiw, we had this in rpm too :/ Oct 02 22:59:58 Because I was gonnna say, the actual value in the message is "unsigned long long". Oct 02 23:00:22 seebs: I'm just reading the value from files.db Oct 02 23:00:47 Hmm. Oct 02 23:01:28 Well. Oct 02 23:01:42 So it turns out, sqlite3 integer columns are apparently able to store varying sizes. Oct 02 23:01:57 But you do probably need to use sqlite3_bind_int64 if you want them to store more than 32 bits of value. Oct 02 23:02:35 seebs: I can see that breaking it Oct 02 23:02:43 Okay, hmm. Oct 02 23:03:16 We also have at least one other problem, I think, because I'm seeing issues on a system with 32-bit inodes. Oct 02 23:03:36 seebs: can we take them one at a time? :) Oct 02 23:03:52 And I think the number of clashes is too high, because we shouldn't be seeing a huge number of files which happen to have 32 bits of identical values. Oct 02 23:04:07 seebs: I've seen this pattern with xfs before Oct 02 23:04:10 I am not sure whether we can, since I haven't got a working reproducer for the one I'm seeing. Oct 02 23:04:56 seebs: we shouldn't see large numbers of clashes with 64 bit inodes but we do, we saw this with rpm too. It must be the algorithm the filesystem uses Oct 02 23:06:54 The good news is, the extraction *from* the database is already 64-bit clean. Oct 02 23:08:28 seebs: it half works then :) Oct 02 23:09:45 Okay, proposed patch for that on master branch. It compiles. Oct 02 23:09:49 No promises past that yet. Oct 02 23:09:59 But if you wanna try it and see whether that reduces the spam, go for it. Oct 02 23:10:45 I'm trying to find a small package that exhibits the behavior I've been seeing so I can test it in a reasonable way. Oct 02 23:11:39 seebs: I will add this in and run a build on the infrastructure, then see if the files.db matches the filesystem and see if the logs have much in Oct 02 23:12:08 Mine seem to frequently start with a complaint about an inode being reused for package/somedir/.debug. Oct 02 23:12:25 And with a bunch of things in the db which have no path entry, which is odd. Oct 02 23:13:57 seebs: I've not seen that pattern, just a reproducible set of warnings about pkgdata Oct 02 23:14:05 Hmm. Oct 02 23:14:13 and pkgdata isn't important as far as pseudo is concerned so I've not worried Oct 02 23:14:23 it may be those do get modified outside pseudo context Oct 02 23:16:13 That could actually cause breakage elsewhere, possibly. I mean, it shouldn't usually, but if it results in mismatches in the database, it could break things. Oct 02 23:16:29 Because if a query comes in for something, and pseudo has records for a file with that inode, it will assume you moved the file without telling it. Oct 02 23:17:29 seebs: in the OE case it would always be better to assume it was a new file Oct 02 23:18:20 path filtering may be something we have to consider if this is a real problem since we can know which paths we care about and which we don't Oct 02 23:19:59 Well, this is interesting. Oct 02 23:20:10 If I just run do_package for a thing, I get a TON of errors. Oct 02 23:20:22 And I don't have to rerun other targets, just bitbake -f -c do_package. Oct 02 23:20:59 Yocto sighting at ARM Techcon Oct 02 23:21:00 1 Oct 02 23:21:02 ohhh hey. Oct 02 23:21:15 NOTE: util-linux: Rename /sbin/fdisk -> /sbin/fdisk.util_linux Oct 02 23:21:20 Crofton: nice Oct 02 23:21:24 Atmel demo powered by a Yocto labled power brick, not running LInux Oct 02 23:21:26 :( Oct 02 23:21:40 Crofton: ah :( Oct 02 23:21:44 nice.. :/ Oct 02 23:21:58 seebs: what about it? Oct 02 23:22:10 Well, I have a ton of messages from a Python script saying they're renaming files. Oct 02 23:22:19 And a ton of error messages from pseudo about those files having the wrong paths or inodes. Oct 02 23:22:22 I did see a NI com that runs NI real time linux, which is OE built (I think) Oct 02 23:22:30 but nothing else Oct 02 23:22:39 I didn't have time to dig hard Oct 02 23:23:05 * RP -> Zzzz Oct 02 23:23:37 seebs: if you find anything can you send me a mail or something? I've fired off builds with that patch, will poke around the builds tomorrow Oct 02 23:23:57 I'll see what I find out. Not sure how far I'll get tonight, but I definitely have SOMETHING. Oct 02 23:24:04 seebs: thanks Oct 02 23:45:36 yay, webkit-gtk-2.4.4 on armv7 (with decent configure options even) Oct 03 00:23:12 FWIW, it looks like there's a lot of path mismatch messages from pseudo which are harmless, because they apply to the case where a file is created before a previous unlink is processed, *but*, the database actually does the right thing. Oct 03 00:23:28 Testing out a patch which doesn't produce that message when it's a did_unlink message. Oct 03 01:28:47 Anyone having GCC 4.6 issues? I have a setup that was working before that now fails gcc-cross-initial with "internal compiler error: Segmentation fault". I'm assuming this is to do with me now running under ubuntu 14.04 where I was using 12.04 before... **** ENDING LOGGING AT Fri Oct 03 03:00:00 2014