**** BEGIN LOGGING AT Mon Feb 22 02:59:58 2016 Feb 22 06:14:44 Hi, I am trying to do a yocto build on Fedora23( I know that its not recommended to use it). But still I am getting this error Feb 22 06:14:45 http://fpaste.org/327147/56121677/ Feb 22 06:15:22 any idea? Feb 22 07:22:51 j Feb 22 07:38:45 niteshnarayanlal: I don't recall fedora being not recommended, I'm actually using fedora 23 (and even 22) on my build machines Feb 22 07:44:28 mborzecki, have u faced any issues while building? Feb 22 07:44:31 http://fpaste.org/327147/56121677/ Feb 22 07:49:25 niteshnarayanlal: not really, but looking at your log, it looks like openssl-native failed, it tried to link libcrypto shared lib, but the objects were built without -fPIC, I'd start by looking at the log files in recipe's ${T}, there should be a log.do_compile file Feb 22 11:35:51 Hi. How do I change u-boot environment vars with the build? Feb 22 11:38:41 Hi all. I'd like to evaluate the different package managers on our hardware. Hence I need yocto to build older versions of the packages so i can actually upgrade them during runtime Feb 22 11:38:56 Is there any way i can specify what package versions to build e.g. in local.conf? Feb 22 11:40:59 Anticom: the recipe defines the package you are building Feb 22 11:41:15 rtr_: http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#ref-classes-uboot-config This might get you started Feb 22 11:41:34 so you could use appends to change the versions being built Feb 22 11:41:46 CTtpollard: The recipie is part of our production source so i don't want to mess with it Feb 22 11:41:54 hm Feb 22 11:44:39 CTtpollard: How exactly would i do that using bbappends? Feb 22 11:44:53 I'm still fairly new to yocto Feb 22 11:45:32 Anticom: you can override the src_uri of the recipe source Feb 22 12:31:18 CTtpollard: Okay so for example if i'd like to build an older version of openssh, how would i modify SRC_URI in thishttp://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssh/openssh_7.1p2.bb ? Feb 22 12:31:28 can't i just override ${PV} somehow? Feb 22 12:34:01 Anticom: just changing PV will break stuff if the package depends on patches or things like that. Feb 22 12:34:03 @Anticom I tried adding UBOOT_CONFIG to my machine conf file. But I'm getting below error Feb 22 12:34:47 Anticom: why not create a dummy layer+package for your tests? or tinker the GNU hello recipe? i mean, that one is meant for tests like that. Feb 22 12:34:48 LetoThe2nd: But there has to be an older package version somewhere, doesn't it? Is there no way i can specify "use version x in favor of version y" ? Feb 22 12:35:07 ERROR: u-boot-toradex-fsl PROVIDES u-boot but was skipped: You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time. Feb 22 12:35:15 Anticom: the older version exists, it is just not there in your checkout. Feb 22 12:35:27 LetoThe2nd: well to get some real performance measures i'd like to have decently sized packages to upgrade Feb 22 12:35:35 Anticom: its "your deirectory state" versus "the history of the repository" Feb 22 12:35:39 upgrading a 1k hello world package is fast nevertheless i suppose Feb 22 12:36:14 Anticom: otherwise you'll have to gather a bunch of different version recipes, stuff them all into your layer, and then switch them between rebuilding. Feb 22 12:36:31 I'm getting dizzy :S Feb 22 12:36:38 thought yocto was simpler than that Feb 22 12:36:43 something like preferred_version or such Feb 22 12:36:58 LetoThe2nd: defaulting to "latest-stable" or something like that Feb 22 12:37:01 yea, that would be awesome Feb 22 12:37:12 Anticom: its just that your mindset and what OE does do not correlate (yet) Feb 22 12:37:13 so i could go back in time for some selected packages Feb 22 12:37:27 Anticom: well defaulting to latest is what it doest AFAIK. Feb 22 12:37:49 LetoThe2nd: Yea but it's not a simple env variable i'd have to override / set to actually change the version Feb 22 12:38:12 Anticom: umm... it is? Feb 22 12:38:15 Anticom: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#var-PREFERRED_VERSION Feb 22 12:38:32 Well i guess i could build the older versions of the packages with the toolchain yocto spits out, downgrade during runtime and then upgrade again Feb 22 12:38:50 OH :O Feb 22 12:39:30 LetoThe2nd: so for openssh it would be as simple as setting PREFERED_VERSION_openssh="6.%" to get 6.x? Feb 22 12:39:54 Anticom: yes and no. yes, if there actually is a recipe that provides the desired. Feb 22 12:40:02 the recipe might not work with a different version to what is defined Feb 22 12:40:17 for instance the patches it carries might not apply Feb 22 12:40:24 Anticom: that variable does not magically version-switch inside your recipe, it is used to switch BETWEEN recipes. Feb 22 12:42:38 Anticom: example: the gcc plurality in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc Feb 22 12:43:09 Anticom: preferred_version can switch between those incarnations. in can not make a 4.9-recipe automagically provide a 5.3 Feb 22 12:47:26 LetoThe2nd: And how do i know, what versions are provided? I'm currently using openembedded's layer index to look up layers and recipes but it only shows the most recent version, doesn't it? Feb 22 12:47:44 oh, it doesn't right? Feb 22 12:47:51 Anticom: you know which are provided by looking at the directories. Feb 22 12:47:52 it does show each version as different recipe Feb 22 12:48:28 Anticom: maybe the layer index can help you, right. but the sad but true reality is: using OE in real life means a lot of experience and knowledge. Feb 22 12:48:47 which i don't have (yet) :/ Feb 22 12:49:30 Anticom: it comes with time, especially that wasted on failures. Feb 22 12:49:45 Legit Feb 22 12:50:34 Thank you for all the explanation already CTtpollard and LetoThe2nd Feb 22 12:50:54 np Feb 22 12:51:20 np. yw Feb 22 13:16:43 Hi. How do I modify uboot environment variable with build. My machine's conf/machine/apalis-imx6.conf has this in it --> UBOOT_MACHINE = "apalis_imx6_defconfig" Feb 22 13:17:16 II'm tyring to g to add this line --> UBOOT_CONFIG[setup] += "setenv setupargs consoleblank=0 no_console_suspend=1 console=${console},${baudrate}n8" Feb 22 13:18:25 But it seeme UBOOT_CONFIG is not allowed when UBOOT_MACHINE is present Feb 22 13:18:37 Can some one please help me with this? Feb 22 13:32:51 rtr_: UBOOT_CONFIG is not for setting the environment, but for specifying your U-Boot device config, what you already do with UBOOT_MACHINE. Feb 22 13:33:46 rtr_: I don't know if there is a way to set the environment with Yocto, but I don't think so Feb 22 13:47:20 @frsc Oh. Ok. Thanks Feb 22 13:59:53 Hi. I'm wondering about CMAKE_BUILD_TYPE. Looking into cmake.bbclass I see both CMAKE_*_FLAGS and CMAKE_*_FLAGS_RELEASE being set. But I don't see CMAKE_BUILD_TYPE set anywhere. Am I missing something, or the _RELEASE vars are not used unless I somehow (e.g. via EXTRA_OECMAKE) add -DCMAKE_BUILD_TYPE=Release? Feb 22 15:46:38 sourceware git doesn't like us, glibc is failing to fetch :/ Feb 22 15:46:52 halstead: any update on openembedded-commits ML? Feb 22 15:57:45 JaMa, ping Feb 22 16:05:30 pong Feb 22 16:05:57 armpit: Feb 22 16:08:37 JaMa, any ETA on the ntp package update merge to master? it contains many CVE fixes that I want to pull over to jethro Feb 22 16:09:51 armpit: ntp is in meta-networking, you need to poke joeythesaint Feb 22 16:10:01 there are many stalled meta-networking changes.. Feb 22 16:10:11 k Feb 22 16:10:30 Quite a few. But I'm on them today. Feb 22 16:13:03 joeythesaint, thanks Feb 22 16:27:54 armpit: I backported a patch to dizzy, it's for rpmresolve. Would be possible to integrate such patch? Feb 22 16:36:39 justanotherboy, sure Feb 22 16:38:34 * armpit probably should include glibc fixes.. to dizzy Feb 22 16:48:25 JaMa, I found the missing config and just added it. Thank you for the ping and please let me know if you notice any issues. Feb 22 16:48:48 thanks armpit Feb 22 16:49:42 halstead: thanks Feb 22 16:50:11 lets see when RP pushes something to oe-core Feb 22 17:05:17 JaMa: for a second I thought you meant oe-core was broken and missing some key patch! :) Feb 22 17:06:39 RP: i have a case where a preferred_provider shows one value in bitbake -e, but bitbake obeys another when actually going to build Feb 22 17:06:59 kergoth: silently? Feb 22 17:07:24 well, the recipe i want to build won't build since it's not the preferred provider, even though -e says it is. overrides are involved Feb 22 17:08:47 kergoth: I can believe that could happen. Is key expansion involved? Feb 22 17:09:00 To be more explicit, I have PREFERRED_PROVIDER_virtual/nativesdk-update-alternatives set to nativesdk-chkconfig-alternatives, but PREFERRED_PROVIDER_virtual/nativesdk-update-alternatives_sdkmingw32 set to nativesdk-opkg-utils, sdkmingw32 is in OVERRIDES, yet it's building nativesdk-chkconfig-alternatives. i figured something was overriding it, but -e shows it as opkg-utils Feb 22 17:09:01 nope Feb 22 17:11:10 RP: sorry and thanks for patches you sent for meta-oe Feb 22 17:11:11 * kergoth tries without the override to check sanity Feb 22 17:11:40 JaMa: np, I'm feeling a bit guilty about some of the failures in meta-oe :/ Feb 22 17:12:23 you shouldn't, drive-by-contributors are guilty of many un-maintained recipes there Feb 22 17:12:49 and that's why I'm trying to use PNBLACKLISTs more agressively to get rid of (or at least clearly mark) such recipes Feb 22 17:12:50 kergoth: there is the PREFERRED_PROVIDER remapping code which its possible is also interacting badly in this case Feb 22 17:13:25 i'm wondering if the bits that skip non-preferred are acting too early, so the correct provider isn't seen as available Feb 22 17:13:31 meta-oe could use some love :) Feb 22 17:13:42 JaMa: I did see that and I think its a good way to mark up things with issues, a clearer path to deprecation/removal in meta-oe might help Feb 22 17:14:08 at least it's more visible than the status reports I'm sending Feb 22 17:14:21 kergoth: its possible. I think its something you'll have to dig into :/ Feb 22 17:14:28 * kergoth nods Feb 22 17:14:34 JaMa: yes, I know all about status reports people don't read :) Feb 22 17:14:42 just figured i'd run it by you in case it was something obvious first :) Feb 22 17:15:02 kergoth: I do have an open bug about PREFERRED_VERSION doing odd things with nativesdk too Feb 22 17:15:13 kergoth: fwiw I vaguely remember similar case a while ago, so this issue probably isn't "new" Feb 22 17:15:16 kergoth: probably not related but could be :/ Feb 22 17:15:19 k Feb 22 17:40:37 I know I saw this someplace but cannot locate it now. There was a way to tag a directory within a recipe so that it would not be deleted during a package upgrage (via package manager). could someone please tell me what recipe var name I should look for? Feb 22 17:42:42 nm, CONFFILES Feb 22 17:52:27 * zeddii_home updated to fix a getVar expansion error in meta-virt, and is now getting reams of errors in do_dumpdata. Feb 22 17:52:36 rm -rf tmp time perhaps Feb 22 18:18:53 halstead: oe-commits just received few e-mails from oe-core repo, so it seems fine now, thanks Feb 22 18:21:24 Thank you JaMa Feb 22 18:34:29 JaMa: do you have an opinion on the 32-bit armv8-a patches? Feb 22 18:52:10 has anyone been seeing errors similar to this ? http://pastebin.com/Sni14VbE Feb 22 18:53:15 errors are coming from the archiver.. but thats all I can tell Feb 22 18:53:40 yah. I updated to fix an expansion error in meta-virt this morning Feb 22 18:53:43 changed nothing else Feb 22 18:53:49 and now I’m getting reams of those,. Feb 22 18:54:37 the log file is no more informative Feb 22 18:54:47 only thing I can suggest is looking in the archive.bbclass and instrumenting it.. Feb 22 18:59:18 any good patches around to use to fix the pkgconfig QA warnings? Feb 22 19:23:05 heya, so RP, I hear there are issues with pseudo restarting under sufficiently-heavy load? Feb 22 19:50:38 rburton: I'm still waiting for results from tune-test and answer for Andre's question Feb 22 19:56:48 JaMa: didn't he reply with tunetest results a few days ago? Feb 22 20:05:55 I don't see it in my inbox Feb 22 20:06:38 hmm he did https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg77197.html **** BEGIN LOGGING AT Mon Feb 22 20:21:41 2016 Feb 22 20:22:48 * nerdboy still looking for a good workaround for the qemu postinst loop Feb 22 20:23:12 better than kill/skip three of them anyway... Feb 22 20:24:19 rburton: anything since this? https://bugs.launchpad.net/qemu/+bug/1245703 Feb 22 20:24:33 nope Feb 22 20:24:43 if you fancy it rewrite that bit of qemu Feb 22 20:25:13 simply avoiding circular symlinks has worked so far Feb 22 20:26:48 avoiding meaning what exactly? is there something i can unmount? Feb 22 20:27:08 only seeing this on one machine Feb 22 20:27:13 go figure... Feb 22 20:28:51 the problem as i saw it was it finding a circular symlink tree inside the rootfs Feb 22 20:29:19 so udev-ptest shipped an unpacked tree of device nodes and symlinks which looped Feb 22 20:29:31 strace it to find out what it's iterating through Feb 22 20:29:50 i've never seen it break outside of the sysroot Feb 22 20:30:45 so it's only if udev-ptest is installed in the rootfs? Feb 22 20:30:48 someone using read-only rootfs and fontcache? Seems to be broken again Feb 22 20:30:59 nerdboy: well we fixed that some time ago Feb 22 20:31:06 and fc-output isn't very useful Feb 22 20:31:08 /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache: failed Feb 22 20:31:11 if you've an old release there may be a commit you want to backport Feb 22 20:31:23 no, i'm on jethro Feb 22 20:31:42 nerdboy: strace please Feb 22 20:31:59 i did that, wasn't very helpful Feb 22 20:32:06 maybe you can see something Feb 22 20:32:11 this is the whole output of the update_fontcache postinst https://bpaste.net/show/8473df403a7e Feb 22 20:33:11 nerdboy: if its the circular bug you'll see it thrashing over a few entries in a tight loop Feb 22 20:33:27 JaMa: that is epically useless Feb 22 20:33:57 JaMa: can you file a bug to get a readonly image tested in the selftest? Feb 22 20:36:45 I think I need to cross gateway #oe and #yocto Feb 22 20:39:09 * zeddii_home has a getVar failure in libc-headers now. been one of those run in circles kinda days Feb 22 20:39:21 rburton: #9155 Feb 22 20:39:27 cheers Feb 22 20:40:49 khem`: Xth retry on jenkins build finally downloaded glibc from sourceware git Feb 22 20:41:14 and libsdl2 patch fails to apply, RP already has fix in master-next, it would be nice to fix soon Feb 22 20:41:35 seebs: yes, https://bugzilla.yoctoproject.org/show_bug.cgi?id=9112 has the details. I did add much more verbose logging but can't seem to reproduce the failure with that logging, seems to have too much overhead :/ Feb 22 20:41:36 Bug 9112: normal, High, 2.1 M3, peter.seebach, NEW , pseudo server connection failed Feb 22 20:41:47 JaMa: build is looking fairly green so I can merge that now... Feb 22 20:45:50 * zeddii_home is glad some where builds are green. Feb 22 20:48:58 zeddii_home: did bisection of PAT work btw? Feb 22 20:49:11 zeddii_home: I don't see them often so I'm trying to enjoy them ;-) Feb 22 20:49:47 RP: that would imply I could build a rootfs Feb 22 20:49:56 I updated and have been broken all day Feb 22 20:50:11 something in my settings for src archiver, etc, are playing with the getVar update to break things Feb 22 20:51:27 http://pastebin.com/TjQs8R6Z Feb 22 20:51:34 http://pastebin.com/Sni14VbE Feb 22 20:51:36 zeddii_home: did you update bitbake? Feb 22 20:51:46 * zeddii_home is instrumenting and trying again Feb 22 20:52:04 this is in my poky build, so everything should be in sync. Feb 22 20:52:17 but this is a src archiver, multilib, rpm build .. so there’s lots of moving parts. Feb 22 20:52:37 zeddii_home: that first one is a missing expand parameter to getVar as the error says. I doubt that is OE-Core code Feb 22 20:53:25 zeddii_home: second one I'm less sure about, not see that before Feb 22 20:53:39 fray and I looked at the variable, the getVar calls in the src_archiver string all have getVar with ‘true’, so for now, i just commented out the src archiver inherit, and I ran into the second Feb 22 20:53:44 good times. Feb 22 20:53:50 I’ll figure it out, it’ll just take a bit of poking. Feb 22 20:55:27 * zeddii_home sees only three instances of ‘autogenerated’ anywhere in meta. Feb 22 20:58:40 RP: is there some known issue in latest pseudo which you're trying to address in those 5 master-next patches or are you working on some further improvement and current pseudo is fine? Feb 22 20:59:08 RP: I'm asking because I plan to backport it to our dizzy build, because those random changes in buildhistory really bugger me Feb 22 20:59:58 So, RP, I don't usually see this, are we seeing it only with Large Values Of N? Feb 22 21:00:08 Also, have we tried easy stuff like bumping ulimit values? Feb 22 21:04:29 hello guys Feb 22 21:04:43 I've run into a problem trying to bitbake poky for intel galileo Feb 22 21:04:56 after configuring and trying to run bitbake I get the following error: Feb 22 21:04:58 Unable to parse \/conf/layer.conf: file \/conf/layer.conf not found in /home/sixsmith/Desktop/iotdk/meta-yocto:/home/sixsmith/Desktop/iotdk/build Feb 22 21:05:17 I've tried this on Mint, Debian and Ubuntu... same thing Feb 22 21:05:39 ... okay that was a critical reading failure Feb 22 21:05:52 my brain somehow shoved your name into the sentence and came up with "after six months of trying to run bitbake" Feb 22 21:05:54 and the thing is that layer.conf exists! Feb 22 21:06:03 haha :)) Feb 22 21:06:05 Hmm. Are the backslashes in the actual message? Feb 22 21:06:12 yes Feb 22 21:06:20 I copy pasted from the console here Feb 22 21:06:21 I am highly suspicious of that. Feb 22 21:06:26 JaMa: We are seeing occasional pseudo aborts (exit code 134) so there is an issue we're still trying to pin down. This is why the heavy -next builds atm Feb 22 21:06:31 Because I don't think there' should be a "\/conf" thing. Feb 22 21:07:06 I followed the guide at: https://software.intel.com/en-us/blogs/2015/03/04/creating-a-yocto-image-for-the-intel-galileo-board-using-split-layers?language=en Feb 22 21:07:08 The aborts are, I believe, restricted to cases where the client failed to launch a server, and I'm about to do some debugging on that. I am suspecting it will be process or open file limits, or something similar. Feb 22 21:07:18 seebs: The build failures tend to happen in the world builds and there aren't any other signs of resource issues, the system is just under heavy load Feb 22 21:07:33 seebs: i.e. I'm not aware of us hitting any ulimit Feb 22 21:08:13 seebs: I still think its a load/timeout problem :/ Feb 22 21:08:30 seebs: we know what the autobuilder looks like when we do hit resource walls and its not like this :/ Feb 22 21:09:11 What is weird to me is that we don't seem to be able to hit it on smaller builds. Feb 22 21:09:12 Hmm. Feb 22 21:09:13 RP: thanks, I'll hold the backport for abit longer than Feb 22 21:09:24 Okay, so what if you set the retry value to, say, 8-10 or so? Do you see it more? Feb 22 21:09:44 JaMa: FWIW it would have used to just silently fail to start the server and do the wrong thing which is obviously bad in different ways... Feb 22 21:09:49 zeddii_home: so i saw a few build failures in linux-libc-headers from find asserting and aborting… looks like they were all caused by findutils-native 4.5.19 being built. i've filed a bug upstream and stopped that being built (patch submitted here) but just in case you see it and start wondering... Feb 22 21:10:33 seebs: I added a debug patch which is rather heavy and we don't see the failures at all with that. If this current build doesn't show them with my heavy patch and the low retries, I'll take my logging out and retry with the low number of retries alone Feb 22 21:10:47 sixsmith: look in your conf/local.conf and conf/bblayers.conf for any \ characters, they should probably be deleted. Feb 22 21:11:04 seebs: if I'm right about it being a timeout/shutdown issue, we should see the error frequency rise Feb 22 21:12:00 seebs: keep in mind it can sometimes take 2-3 8 hours builds to get a good idea if its failing or not, its not easy to reproduce :( Feb 22 21:12:25 rburton: this is part of my bblayers.conf: BBLAYERS ?= " \ Feb 22 21:12:25 /home/sixsmith/Desktop/iotdk/meta \ Feb 22 21:12:26 rburton: noted Feb 22 21:12:34 I can’t get near an image linking at the moment. Feb 22 21:12:39 so I’ll see! Feb 22 21:12:56 rburton: but deleting that "\" character does nothing... also what conf/local.conf? in the recipes folders? Feb 22 21:13:02 I’m just queing up all requests people make, until I can figure out why my features and master don’t play together Feb 22 21:14:00 sixsmith: the ones at the end of the ilne are right, as they escape the newline. its possible that you have a \ with a space after it - the line end newlines *need* to be the last character Feb 22 21:14:20 Huh, it seems odd for the debugging to have that much effect, even fairly heavy debugging should be unmeasurable compared to the sleep times. Feb 22 21:15:03 whitespace is the root of all evil Feb 22 21:15:16 i thought that was tab indentation Feb 22 21:15:23 that too Feb 22 21:15:53 nope, same thing Feb 22 21:16:17 do I have to run "source" again after editing the bblayers? Feb 22 21:16:29 I think I don't ... Feb 22 21:22:50 seebs: did you see my patch? Feb 22 21:23:02 seebs: but yes, I thought it odd too Feb 22 21:23:30 I haven't read the patch, yet. I was gonna add a fancy logging thing myself, but I am sorta getting that itchy-feeling that means that I am thinking about the problem wrong. Feb 22 21:23:52 i get that when i know i've fixed something twice already in the last few years Feb 22 21:24:20 Okay, just staring at it. Feb 22 21:24:37 The logic is unambiguously wrong. It should work anyway, but it's clearly wrong in a way that makes me think I had not thought this through correctly. Feb 22 21:25:25 In particular, there's two different attempts to spawn the server possible within a single pseudo_client_setup, and that is almost certainly a logic bug. Feb 22 21:26:46 seebs: before you add let more logging, please do have a look at my patch, even if its just to tell me I was insane ;-) Feb 22 21:29:03 ... Hmm. Okay, I may be confused, I can't actually find the patch. At least, I don't see it on 9112, and I didn't immediately see it in email. Feb 22 21:30:01 seebs, look at master-next of the poky repository. the pseudo patches (all of them) are there Feb 22 21:30:38 RP did you drop the retry down? Feb 22 21:30:46 Ahh, 'k. Feb 22 21:31:00 I don't actually have a poky tree checked out right now. Feb 22 21:31:11 you havn't seen my patch either.. moving some logging around and such Feb 22 21:31:37 k Feb 22 21:34:05 sixsmith: no, you don't need to source the env setup script Feb 22 21:34:30 sixsmith: could you please use pastebin.com or similar to show us your full bblayers.conf Feb 22 21:34:37 of course Feb 22 21:34:39 just a sec Feb 22 21:34:42 fray: I did, that is running now Feb 22 21:35:28 fray: just getting to the interesting bit of the build Feb 22 21:36:20 here's the bblayers.conf Feb 22 21:36:21 https://ghostbin.com/paste/sa68z Feb 22 21:36:22 Looks reasonable-ish. Feb 22 21:36:37 Thinking about it, I suspect that the exit status of the server will almost always be uninteresting, since it forks. Feb 22 21:36:48 rp, ok Feb 22 21:37:18 seebs, exit status of the server should be 0 (fork successful) or not zero (something failed prior to fork) Feb 22 21:37:35 all indications so far is the failure is prior to the fork Feb 22 21:37:47 huh Feb 22 21:37:50 seebs: yes, looks very much like something before the fork Feb 22 21:38:22 oh Feb 22 21:38:23 hey Feb 22 21:38:37 I found a path where I'd printf a %s with a NULL. Feb 22 21:38:41 I think glibc will fix that up for me, but it's still a bug. Feb 22 21:39:07 ohhhh hey Feb 22 21:39:13 There's an unchecked unlink. Feb 22 21:39:16 seebs, more or less what the logging so far has showed is that the pid file never gets updated Feb 22 21:39:26 so we know it's BEFORE where the pid would have been written.. Feb 22 21:39:47 so the systm loops over the spawn server always starting with the same "couldn't kill server"..... Feb 22 21:40:10 and we're not sure it's ever safe to unlink the pid file w/o creating a race.. but?? Feb 22 21:40:16 So there's a point where we try to bind the socket to the path. But if something else caused the path to exist, that'd fail. And if the unlink failed, then it'd ALWAYS fail. Feb 22 21:40:29 If nothing else, there should be error checking. Feb 22 21:40:39 makes sense Feb 22 21:41:39 RP captured one failure where it spun 49 times with the failed to kill, start problem.. then the 50th it did start the server, but it was too late and dropped out.. Feb 22 21:41:46 some SOMETHING is causing that odd behavior Feb 22 21:43:13 Yeah. Feb 22 21:43:38 I'm sorta thinking maybe something where a client manages to get the socket open, but then the server doesn't manage to interact with it, but I don't think that'd actually prevent unlinking the socket. Feb 22 21:43:51 Anyway, there are definitely some logic errors in here, even if they're pretty minor. Feb 22 21:44:18 But they could be causing it to not correctly diagnose a more serious thing. Ugh. Feb 22 21:44:38 And now I have a headache. Feb 22 21:49:09 seebs: that was me last week :/ Feb 22 21:49:17 heh Feb 22 21:49:18 * RP needs to step afk for a bit, back in 1-2 hours Feb 22 21:50:11 Okay. I think my tentative plan is to do a cleanup patch that fixes logic problems and adds some extra logging for things I care about, and maybe see if I can provoke the failure. Still really curious about what triggers it. Feb 22 21:51:27 moin Feb 22 21:51:29 is it OK to post patches as attachment to the yocto mailing list? Feb 22 21:51:56 did something change in do_patch recently? I'm not seeing the failed patch filename anymore Feb 22 21:51:59 hmm Feb 22 21:52:10 * kergoth scratches head Feb 22 21:52:33 ah, nm, found it Feb 22 21:55:52 sixsmith: that last like with the \" is wrong... either drop the \ or move the " to the next line Feb 22 21:56:26 sixsmith: that last line, I meant to type (of the BBLAYERS setting) Feb 22 21:56:39 yep, just removed it... somebody in #poky told me to Feb 22 21:56:42 but now Feb 22 21:56:44 I have this: Feb 22 21:56:45 ERROR: OE-core's config sanity checker detected a potential misconfiguration. Feb 22 21:56:46 Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Feb 22 21:56:46 Following is the list of potential problems / advisories: Feb 22 21:56:46 libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be found in PATH. Please either install it, or configure qemu not to require sdl. Feb 22 21:57:06 the message tells you the problem, and waht to do about it Feb 22 21:58:24 I assume I should apt-get install this since it doesn't exist Feb 22 21:58:38 oh wait not that Feb 22 22:01:44 yes, either apt-get install it or comment out the lines in local.conf that enable its use Feb 22 22:01:51 as the message says.. Feb 22 22:05:32 I think it started to work Feb 22 22:05:54 good god and thought this is a weekend project Feb 22 22:06:14 my plan is to add a package to the distro, gphoto2 to be specific Feb 22 22:06:31 I've tried compiling that under poky on galileo but it didn't work out Feb 22 22:07:15 isn't there a package repo providing that already? Feb 22 22:10:59 no Feb 22 22:11:34 thank you really a lot for the help, it's late and I"m really sleepy now because of this mess Feb 22 22:11:45 I'll probably come back tomorrow if something doesn't work out Feb 22 22:11:49 have a nice day! Feb 22 23:37:22 seebs, fray: We have seen a failure on the current build. The logs didn't trigger my logging Feb 22 23:38:08 seebs, fray: Partly thats because I lowered the retries below my trigger point, it also tells us the forked processes doesn't hit the exit(1) though Feb 22 23:38:25 Hmm, interesting. Feb 22 23:38:39 You know. Feb 22 23:38:39 I just noticed ANOTHER thing I don't check for. Feb 22 23:38:43 I don't check for child PID of -1. Feb 22 23:43:19 seebs, fray: So the question is whether there is another patchset I should try next, before I head to bed? Feb 22 23:43:53 I don't think so. I'm sorta thinking to take my time on this and rethink all the stuff carefully, because I'm sorta suspecting there's at least a few logic errors, or things I didn't sanity-check enough, hiding in there. Feb 22 23:44:29 So I wanna basically revamp the startup/spawn code because I don't trust it very much. It's been getting by on just being lucky for a long time, it seems to me, and I'm not sure why it's suddenly vulnerable now. Feb 22 23:45:56 Actually, come to think of it. I now sort of wonder: Was this always broken? Because it only showed up relatively recently, and I'm not sure what changed. The "shut down the server automatically" thing was quite a while back. Feb 22 23:46:18 I sorta suspect that, in fact, it's always been slightly-broken, but we never noticed because the chances that any *given* pseudo failure will produce a noticeable problem are probably low. Feb 22 23:46:49 seebs: I think we've just been lucky in the past that where its failed to connect, the fallthrough hasn't been noticed. We have seen oddities for a while going back to dizzy as JaMa mentioned earlier. Now we properly handle the abort, we're clearly seeing the scale of the issue Feb 22 23:47:01 Yeah. Feb 23 00:16:53 seebs, fray: in which case I'll retry my logging but tweaked to hopefully provide better data this time **** ENDING LOGGING AT Tue Feb 23 02:59:58 2016