**** BEGIN LOGGING AT Thu Aug 14 02:59:59 2014 Aug 14 05:40:51 sgw_: what is /usr/bin/perl version ? Aug 14 06:03:36 hi everybody Aug 14 06:04:05 does anyone have an idea on how to enable the build of the qttestbrowser using the qtwebkit recipe in meta-qt? Aug 14 06:04:37 seems to me the build is a production build which skips compilation of qttestbrowser Aug 14 06:05:59 Tools/qmake/mkspecs/features/configure.prf already has build_testbrowser and build_qttestsupport in WEBKIT_TOOLS_CONFIG variable but that does not help Aug 14 07:25:41 hai yocto, After boot the kernel its hang up over "at91sam9x5ek login:" i couldn't login or enter the user name . How can i resolve this? Aug 14 08:00:18 good morning Aug 14 08:00:51 good afternoon Aug 14 08:55:25 How qemu dtb file is compiled from Yocto source? Aug 14 09:00:23 <[Sno]> how can I change the deployed web-server from lighttpd to nginx (lighttpd comes with packagegroup-core-full-cmdline which is required by core-image-lsb) Aug 14 09:00:57 [Sno]: do you still need busybox ? Aug 14 09:06:04 How dtb file is compiled from qemu recipe file? Aug 14 09:09:55 <[Sno]> lpapp: I'd like to keep it, yes Aug 14 09:13:03 <[Sno]> lpapp: the image is there: https://github.com/rehsack/meta-jens/tree/master/recipes-graphics/images Aug 14 09:13:19 <[Sno]> likely I can do it better ;) Aug 14 10:52:04 (cross from #oe) I have the problem that with a yocto/oe toolchain (created with meta-toolchain-sdk) I can not start the menuconfig for kernel configuration (after source .../environment-setup-...). I have found the problem and a solution (please read this short thread http://www.spinics.net/lists/linux-kbuild/msg09959.html). Can someone test this patch that "-c menuconfig" is still functional. Aug 14 11:54:51 <[Sno]> lpapp: do you have a recommendation without busybox? Aug 14 12:15:24 [Sno]: cannot you exclude it (_remove or something)? Aug 14 12:15:48 it seems that my foo-git package is not rebuilt even though the git repository got new commits. Shouldn't it automatically rebuild stuff after fetching the new commits? Aug 14 12:17:35 I have SRCREV = "${AUTOREV}" there. Aug 14 12:20:04 gdo you have SRCPV in PV? Aug 14 12:27:25 JaMa: nope Aug 14 12:33:53 JaMa: is that mandatory for getting the new commits automatically? Aug 14 12:42:02 <[Sno]> lpapp: we recognized that it updates automatically when you include the rev in SRC_URI="git://...;rev=deadbeef" Aug 14 12:42:17 <[Sno]> lpapp: how should such a _remove line look like? Aug 14 12:43:49 [Sno]: but then you hard code the revision. Aug 14 12:45:31 [Sno]: I do not know the syntax, but it was added pro-dylan iirc based on _append, it is something like _exclude/remove or something. Aug 14 12:46:08 post-dylan* Aug 14 12:52:25 lpapp: afaik yes Aug 14 13:11:20 With Fedora 20, I am seeing a lot of screen pauses. (Typed all before this aside before seeing any on screen) They are frequent and annoying and I don't see any CPU spikes or any logging to explain them. Where else can I look for a culprit? Aug 14 14:00:15 lpapp: yes, you need to have SRCPV in PV, otherwise PV doesn't change, so you recipe is not rebuilt Aug 14 14:03:28 ndec_ that's not -strictly- true.. the change of the SRCPV will trigger a rebuild, and with the PR service enable will cause the PR number to increment... however without the SRCPV, it's unclear to other developers it's a SCM based recipe.. Aug 14 14:04:04 this PV is modified to include SRCPV so the developers know it's an SCM based recipe, and the change of the SRCPV will make it to clear to the system and developers the version has changed (without making them manage anything themselves) Aug 14 14:04:10 JaMa: ndec_ ok, thanks, but I think there could be a sane default in Yocto, namely: PV = "${SRCPV}" when AUTOREV is specified. Aug 14 14:04:11 hmm. PR.. that's something i don't use ;-) Aug 14 14:04:51 Ya, when you use an autorev scheme.. it may be required.. I'm not sure Aug 14 14:05:20 I do have some recipes that use SCM backends, but don't list SRCPV.. but that is because I'm pointing to specific commit that represents a release point Aug 14 14:05:22 lpapp: well, not sure what a sane default would be.. PV is rarely just SRCPV Aug 14 14:05:31 but something like 1.0+gitSRCPV Aug 14 14:05:38 correct.. it's usually "basever+scmSRCPV" Aug 14 14:06:09 and only the recipe developer knows hwat basever is.. Aug 14 14:06:12 ndec_: then you override, done. Aug 14 14:06:21 ndec: but for people like me, I would not need to do anything special. Aug 14 14:06:38 fray_: I think that without SRCPV in PV the do_fetch task doesn't have the AUTOREV value in signature -> isn't reexecuted when there is new change Aug 14 14:06:43 PV=SRCPV would be quite bad for git where commits aren't in 'increasing' order. not sure it would be a good default Aug 14 14:06:58 the default PV comes from the recipe filename.. Aug 14 14:07:14 so you shouldn't globally set PV=SRCPV or you'll brake that assumption.. Aug 14 14:07:27 JaMa, ya the AUTOREV may be unique.. I haven't explored that enought to know the edge conditions Aug 14 14:07:33 ndec: SRCPV should be increasing, thanks to the prefix added by PR service Aug 14 14:07:39 ndec: it is a good default since it does not break your picky case, yet it will work for me who could not care less about a simple name. Aug 14 14:07:59 I'm sure it was behaving like this in dylan, I think it wasn't changed since then Aug 14 14:09:10 ndec: 1.0+gitSRCPV is a very bad idea for _me_ because the whole point is not to maintain the version... it will break at 1.1 and 2.0... Aug 14 14:09:19 or even 1.0.1 to be fair. Aug 14 14:09:38 well, i was not proposing to make my suggestion a default.. Aug 14 14:09:52 lpapp: then you can set it to just SRCPV if you _want_, but it shouldn't be default Aug 14 14:10:00 JaMa: why not? Aug 14 14:10:12 what does it break? Aug 14 14:10:33 versioning between builders not sharing the same PR service for example Aug 14 14:10:34 cause clearly, it makes some people happy, so what breakage would it cause for others as a disadvantage? Aug 14 14:10:50 if it's broken for -you- it does not mean it's broken for everyone else.. Aug 14 14:11:17 changing build versions causes havoc for people trying to do on-target package upgrades.. even between a 1.6 to 1.7 release time.. Aug 14 14:11:36 that is irrelevant, we are talking about autorev. Aug 14 14:11:38 some of the decisions made in the past don't make sense anymore -- but we're stuck with them, and they cause little issue Aug 14 14:11:39 not all the case. Aug 14 14:11:51 not to mention I have never mentioned it is broken for everyone, so I must decline that assumption. Aug 14 14:12:51 JaMa: is this PR service some new thing? Aug 14 14:13:02 PR service was introduced in 1.3 or 1.4 Aug 14 14:13:58 1.4 Aug 14 14:14:05 yeah, relatively new, OK, well, I was not aware of it. Aug 14 14:14:13 when I started reading the manuals, it was not there yet. Aug 14 14:14:19 I must read upon that before I can reply. Aug 14 14:15:56 when I was making the recipes, I was told just to remove the PR field, and everything will be alright. Aug 14 14:16:12 yes, the PR server is what automatically increments them Aug 14 14:16:44 uses the base PV, and PR numbers... as well as the checksum of parts of the recipe to determine if an existing PR number has been issued or if a new one is to be generated.. Aug 14 14:16:55 it generates them in increasing order to facilitiate on-target package upgrades Aug 14 14:21:23 so what is wrong about having localhost always the PR service? Aug 14 14:28:42 so i have an out-of-tree kernel module, and i can bitbake it just fine. however, for iterative development, i would like to just “make” it with the toolchain, what’s the best way to do that? Aug 14 14:28:57 the kernel development manual mentions how to do it on the target, i want to do it on the host Aug 14 14:31:52 one way is setup a recipe.. then use bitbake -c devshell recipe Aug 14 14:33:42 (and why is localhost:0 not the default PR service?) Aug 14 14:34:14 that will have the toolchain setup (trying out right now, taking a while) Aug 14 14:35:41 lpapp: because PR service is disabled by default Aug 14 14:36:19 fray: that gives me an error about M= file not found, that doesn’t seem good (after running make) Aug 14 14:37:05 I'm not sure.. if you can find Zeddii, he'd be the one to ask Aug 14 14:37:44 ah it’s missing KERNEL_SRC i guess Aug 14 14:39:43 khem: good morning, noticed you ping'ed me late last night: Perl version: v5.16.3 Aug 14 14:41:06 JaMa: why is that? Aug 14 14:41:55 for people who are NOT doing on target package upgrades, the PR service is extra overhead Aug 14 14:42:31 it is only overhead for building. Aug 14 14:42:39 is it non-negligible? Aug 14 14:43:37 and for people who cares about on target upgrades, they usually want to use PR service provided by their distro -> so there cannot be good default Aug 14 14:44:43 I am not convinced about the constant "there is no default for the majority, so there should be none approach", but ok. Aug 14 14:45:00 I will put it into our local.conf sample, thanks. (localhost:0) Aug 14 14:45:07 there is reasonable default "disabled" Aug 14 14:45:48 well, we will agree to disagree whether that is reasonable :) Aug 14 14:46:14 IMHO, setting the default to localhost:0 is ok for many people, and the one who would like to have custom, they will need to provide their way either way. Aug 14 14:46:37 regardless of the default, but it would help the people who are happy with localhost. Aug 14 14:46:44 the current default does not help even those people. Aug 14 14:47:27 it won't help people who are happy without PR service Aug 14 14:47:55 disabling does not seem to help there either, so it is the same, no? Aug 14 14:48:11 no Aug 14 14:49:19 it is a bit like if we cannot help 60% (I am not convinced that a correct measure for custom anyway), we do not help 30% either. Aug 14 14:51:00 anyway, for fact, this is a regression since it did use to work without enabling it explicitly. Now, we got all of this broken all of a sudden, apparently. Aug 14 14:51:08 this is regression* Aug 14 14:51:44 nothing is broken when PR service is disabled Aug 14 14:52:25 and it's probably more like 30% custom, 30% disabled, 30% localhost, 10% doesn't care Aug 14 14:52:25 ok, I think it would be better to clarify what "PR service disabled" means. What happens if I do not use PR in the recipe? Will it automatically incremented? Aug 14 14:52:37 the main issue is that this reasoning can be applied to pretty much *any* configuration. oe/yocto is a toolset to help you build/make your own distro/builds. you cannot make defaults for every config that will satisfy everyone.. better let people do their own config.. Aug 14 14:52:43 be* Aug 14 14:53:10 no it wont be automatically increamented (and it wasn't before) so it's no regression Aug 14 14:53:21 I sure was told it was. Aug 14 14:53:33 one of my patches was even rejected for that nitpicky reason that it had the PR in. Aug 14 14:53:56 the suggestion was "Remove it because it will be incremented automatically". Aug 14 14:54:06 (I can look up the email if you want) Aug 14 14:54:07 for poeple you're using PR service Aug 14 14:54:41 no need to look it up.. I've wrote many replies like that myself Aug 14 14:55:16 so the suggestion was to break the recipe for people not using PR service? Aug 14 14:55:39 (i.e. when the PR service is disabled - default) Aug 14 14:56:04 if you're not using the PR service, you aren't the kind of person who cares if PR is incremented Aug 14 14:56:59 fray: does Zeddii hang around here? Aug 14 14:57:13 but what I am saying is the opposite: I would like to use it since it is error-prone to manually increment blabla, but I do not agree with the overhead of a custom service. I prefer KISS which means auto-increment by one here, not to force me to manually keep track of it by default. Aug 14 14:57:20 i’ve figure my thing out, i wonder if there’s a way to have the toolchain set KERNEL_SRC, i can always add it to the environment source by hand Aug 14 14:59:34 so with the current system in place: I can only do this, right? echo 'PRSERV_HOST = "localhost:0"' >> ../meta-foo/conf/local.conf.sample? Aug 14 14:59:43 (based on my need above) Aug 14 15:01:01 yes Aug 14 15:01:06 personally i have that it my site.conf Aug 14 15:01:57 webos-ports and SHR have it in setup scripts (using remove PR service) Aug 14 15:02:23 rburton: thanks, fair enough, I will move it there. Aug 14 15:03:10 rburton: you say this, as you have 1 'site.conf' for all workspace.. is that correct? if so, how do you globablly set your site.conf? Aug 14 15:04:45 so the PR service only steps in if there is no PR specified in the recipe? Aug 14 15:04:54 or it is always overriding that? Aug 14 15:05:32 lpapp: if the recipe doesn't set a PR then the default is r0 Aug 14 15:05:44 and then r1, r2, etc? Aug 14 15:05:49 (with localhost:0, that is) Aug 14 15:05:57 (see bitbake.conf) Aug 14 15:06:08 the PR service adds a .x Aug 14 15:06:14 so you get r0.1, r0.2 Aug 14 15:06:28 never reaches r1? Aug 14 15:06:33 correct Aug 14 15:06:36 wow Aug 14 15:06:44 this lets you use the PR service and explicit PRs at the same time Aug 14 15:07:04 well, it is just packaging version, isn't it? Aug 14 15:07:13 PV remains the same anyway, right? Aug 14 15:07:21 (if that is correct, I could not care less what PR is) Aug 14 15:07:33 (as long as it is not the same and somehow incremented) Aug 14 15:07:41 the PR is embedded in the package name and versioning Aug 14 15:08:00 yes, but not in the software version itself. Aug 14 15:08:04 right Aug 14 15:08:09 good, so yeah, thanks. Aug 14 15:08:09 thats PV and isn't touched Aug 14 15:08:39 eg i have sato-icon-theme_0.4.1-r6.1_all.ipk in my deploy/ipk Aug 14 15:08:57 so you have a custom PR service? Aug 14 15:09:04 or your localhost is customized? Aug 14 15:09:11 not at all Aug 14 15:09:20 as i said, i takes the PR and adds .x Aug 14 15:09:21 but r6.1 > r0.X Aug 14 15:09:41 and sato-icon-theme has an explicit PR=r6 Aug 14 15:09:42 ah Aug 14 15:09:46 I see what you mean. Aug 14 15:10:00 (that was a carefully chosen example) Aug 14 15:10:10 so what happens if you do not specify PR, 1,2,3,4? Aug 14 15:10:25 ah, no, r0 Aug 14 15:10:27 you said that above. Aug 14 15:42:51 is it a general practice that people use an ipkg folder in projects similarly to the good old "debian" for in-project packaging? Aug 14 15:43:02 that would spare us going to Yocto for every single local change. Aug 14 15:43:23 I could just say make ipkg and the package is generated that I can install on the rootfs. Aug 14 15:43:44 I have only done this many times with debian/ subfolder, but I wonder if some bitbake/ subfolder with the recipe and bitbake in there could also do it somehow? Aug 14 15:44:15 the alternative is to set up a local directory URL which cannot be committed to our Yocto repository for obvious reasons, etc. Aug 14 15:44:26 whereas a "bitbake/" directory could be easily committed to the project repository. Aug 14 15:47:24 if you wanted to drive opkg directly you'd need to write opkg-native packaging Aug 14 15:47:45 cannot we get yocto generate that for us and sync? Aug 14 15:48:00 you could Aug 14 15:48:10 package_ipk obviously generates it Aug 14 15:49:01 I am new to the yocto project. I am trying to build an image for a beaglebone with bluez5 (for low power bluetooth). I have added this to my local.conf file but the build complains that bluez4 is still included. Anything I can try to fix this? Aug 14 15:49:27 rburton: ok, well, that sounds like a plan, based on my experience with debian/, it is probably not something that some other people will not follow. Aug 14 15:49:39 I mean, probably some people already are doing it. Aug 14 15:49:51 lpapp: maybe, not aware of any myself Aug 14 15:50:13 rburton: well, it makes sense for CI, too. Aug 14 15:50:22 surely CI should be done in yocto Aug 14 15:50:43 for interim builds, I am not sure. Aug 14 15:50:56 for release builds, sure. Aug 14 15:50:58 people i know that do tight hack-compile-install-test cycles tend to use the devshell or adt and copies binaries directly to the target, avoiding packages Aug 14 15:51:13 that is a very bad approach Aug 14 15:51:30 it disrespects security, let alone the error prone process when you have many files to put to many places. Aug 14 15:51:41 but for some it might work for simple things. Aug 14 15:52:02 I would not allow my embedded system accept unsigned random files :) Aug 14 15:52:47 hey guys. I have a question about compiling opencv with yocto. when I do bitbake opencv, it gets hung up on trying to compile the eigen library, with the following error code. http://pastie.org/private/w9gr8cuenrvrkgrxeh3ejw I'm wondering if there is a known fix for this. Let me know if you need more info Aug 14 15:52:48 also, doing manually the packaging might be just reinventing the package, when you need more than just a binary in /usr/bin, e.g. man pages, configuration into /etc/, libraries, tools, etc. Aug 14 15:53:18 lpapp: exactly Aug 14 15:53:30 sunzun: eigen is a header-only template, it is not compiled on its own Aug 14 15:53:41 you mean when it is compiled against opencv? Aug 14 15:53:53 rburton: exactly which part? Aug 14 15:54:05 lpapp: reinventing all the packaging Aug 14 15:54:29 sunzun: looks like the eigen recipe hasn't been tested for ages and is broken with the "recent' (several months ago) cmake changes Aug 14 15:54:32 rburton: yes, but isn't it simpler to sync the result of package_ipk to avoid the reinventing? Aug 14 15:54:43 sunzun: the error report seems to be clear to me. Aug 14 15:55:22 sunzun: in-source builds are bad, so you will need to figure out why it is doing it. Aug 14 15:55:24 lpapp: its simpler to use bitbake to build the package in the first place surely. Aug 14 15:56:04 rburton: why? That requires Yocto knowledge for every developer, not just the system builder. Aug 14 15:56:21 lpapp: yeah, it says that you can't build in source, but I'm not quite sure where i would go to fix this. I've taken a look at the eigen recipe, and I'm not sure how to patch it to fix it, nor can I find a patch that's available Aug 14 15:56:45 like I said, eigen is a template-header, it is not built on its own Aug 14 15:56:56 (at least it was last time I checked in its core mission) Aug 14 15:57:05 you need to fix whatever is trying to use it, assuming opencv here. Aug 14 15:58:03 rburton: also, how would you arrange local hack trials with Yocto? It cannot be checked into the mainline repository of our Yocto stuff Aug 14 15:58:24 rburton: and every developer might have different local path, and I would rather leave it that way with their preference. I am not a unity purist. Aug 14 15:58:40 lpapp: not sure i understand what you mean by local hack trials Aug 14 15:58:41 rburton: but if there is an ipkg folder, they just run make ipkg Aug 14 15:58:59 rburton: modifying the source code locally to attempt to add a feature or fix a bug, and then would like to ship it onto the target for testing. Aug 14 15:59:58 how would you do that with Yocto that is better than make ipkg? Aug 14 15:59:59 sunzun: you should probably check that you're using the latest libeigen recipe, the commit log shows a commit in june that fixing build problems Aug 14 16:00:33 lpapp: not even bother with a package and rsync to the target Aug 14 16:01:01 rburton: why not? Aug 14 16:01:03 lpapp: yeah I figure the issue is more with cmake and opencv than with eigen itself.all of the stuff I find on google regarding cmake and yocto is somewhat old, and as you mentioned, this may be a recent change that broke it Aug 14 16:01:27 rburton: yeah, double checked that I am. the patch that fixed this bug perviously no longer works Aug 14 16:01:50 libeigen? :) Aug 14 16:01:51 what is that? Aug 14 16:02:13 AFAIK it does not generate any library. Aug 14 16:02:48 lpapp: that's the name of the recipe though Aug 14 16:02:55 rburton: what is wrong about make ipkg (which also does the scp)? Aug 14 16:03:00 lpapp: nothing Aug 14 16:03:11 good, and how would it be better with Yocto? Aug 14 16:03:36 I cannot reasonably imagine testing local stuff with yocto. Aug 14 16:03:36 lpapp: https://github.com/openembedded/meta-oe/tree/master/meta-oe/recipes-support/libeigen Aug 14 16:03:46 that's the recipe I'm using Aug 14 16:03:54 afaik, that's the latest version? Aug 14 16:04:16 yes and no Aug 14 16:04:22 the recipe might be latest, eigen nope. Aug 14 16:05:04 sunzun: right, should have worked :/ Aug 14 16:05:33 rburton: yeah, I know. it's weird that it's showing a bug that a previous patch should have fixed Aug 14 16:06:48 rburton: currently, I made a foo-git package and CI (Jenkins) does not clean the workspace between runs, but it feels hackish. Aug 14 16:07:00 obviously, rebuilding the whole system is too long to be an option. Aug 14 16:07:38 that is why I think life would be better with ipk/ Aug 14 16:08:46 lpapp: yeah, I can see that eigen is header only. but it uses cmake to install. I guess I need to change the way yocto uses cmake (basically just need to figure out how to make it "build" outside the source directory as per the error message lol). any suggestions on where to start? I'm pretty new to yocto itself Aug 14 16:09:03 sunzun: your problem is build, not install. Aug 14 16:09:19 sunzun: meta/classes/cmake.bbclass, maybe. Aug 14 16:09:38 hmm okay. I'll start looking into it. thanks. Aug 14 16:10:18 sunzun: well, first I would check the logs in temp/ Aug 14 16:10:59 sunzun: the class does builds in a build/ dir by default, unless you've got a non-current cmake.bbclass Aug 14 16:11:14 sunzun: actually, do you have meta-oe master but an old oe-core? Aug 14 16:11:35 so is it possible to install our SDK (core-image-minimal pretty much) and run bitbake through a recipe in the application repository? Aug 14 16:11:46 lpapp: the logs are basically what I pasted. no other information. Aug 14 16:11:49 and bitbake picking up the deps from the SDK? Aug 14 16:13:10 rburton: I cloned both yocto and everything else in the last two days. unless things have changed since then, it should be up to date. I'll double check though; I've already had to change a bunch of other things that were broken (and shouldn't have been), so this might be another one Aug 14 16:14:35 sunzun: heh, you are having fun, I hear you :-) Aug 14 16:15:12 sunzun: probably best to mail oe-devel, it's probably a simple fix for someone with the time to look at it (not me, in meetings right now) Aug 14 16:17:35 hey, what do you know, when I meld the current cmake.bbclass and the one i have, there are several differences. makes sense. complete sense. Aug 14 16:17:50 lpapp: you know it. :D Aug 14 16:18:57 sunzun: sounds like you've got a messed up clone? Aug 14 16:20:51 rburton: we're required to use a certain branch; sounds like the branch we're supposed to use clearly doesn't work with some stuff, but since it's the only version that works with our software, I'm just going to have to go through everything manually and fix things myself as they come up Aug 14 16:21:14 sunzun: if you want to use eg daisy of oe-core, then ensure you also use the daisy meta-oe branch Aug 14 16:21:27 sunzun: as meta-oe master depends on oe-core master Aug 14 16:22:57 rburton: hmm... you're right. I forgot to switch over the meta-oe branch since I cloned that separately Aug 14 16:23:25 doesn't fix my issue though, although it probably saved a lot of future headache Aug 14 16:31:20 vagrant4ever: re: bluez4 vs bluez5, it's not very easy to switch at the moment. at mentor we switched to bluez5 by default and added bits to make it a little easier to switch, but it's not merged. a new virtual provide has to be added, and software that can support both need its deps adjusted to the virtual. it has to be done carefully, as not all software supports both. software that uses libbluetooth will work with both, as will software Aug 14 16:31:21 adjusted to work with both dbus apis, but then there's the question of how to handle the runtime dependency, so really need both a new virtual provide and a new virtual-runtime. see meta-mel in meta-mentor to see how we're handling it. I intend to submit to oe-core, but haven't gotten to it yet Aug 14 16:34:00 i also have a prototype private layer which replaces the internal bluetooth implementation with a no-op third party implementation, to make it easier to drop in a commercial bluetooth implementation (additional runtime virtuals coupled with carefully disabling packagegroups and excluding packages that unconditionally pull in bluez to remove the internal default implementation) Aug 14 16:34:23 that said, i'm not 100% happy with it, hence not pushing much of that stuff yet Aug 14 16:43:12 kergoth: thanks for the information. Being new to this build environment seems like it will be tough to switch. At this time I really only care about interacting with BLE devices. Would it be possible/smart to go with a minimalist build, add bluez5 and only packages I will need? Aug 14 16:43:53 the only concern there is that bluez4 might still be pulled in via dependencies. you can certainly give that a shot, though, it'd be a reasonable starting point Aug 14 16:44:30 I usually "whack" the dependency issue by blacklisting bluez4 ... that way if something requires it, I get a nice list and can try to deal with it Aug 14 16:44:53 yeah, that's exactly what i did too :) Aug 14 16:44:54 PNBLACKLIST[bluez4] = "We support bluez5 now." Aug 14 16:44:56 blacklist is handy for that Aug 14 16:44:57 :) Aug 14 16:48:15 fray, kergoth: thanks I will give that a try. Aug 14 16:49:41 we should think about moving to bluez5 by default and making 4 an optional switch, but it might be too late to consider such a thing for this release. i really need to do a better job of working within the yocto process, but it's tough to find time, i tend to have to focus on getting crap working for mentor, and then play catch up after the release Aug 14 17:07:06 kergoth: I share same pain Aug 14 17:33:38 man, the unexpected rebuild of everything from scratch is SO PAINFUL Aug 14 17:33:50 expect a quick build to test something, and suddenly blocked for an hour Aug 14 17:34:00 whats worse is when -S printdiff says nothing changed Aug 14 17:34:04 yet everything is rebuilding from scratch anyway Aug 14 17:38:13 hmm Aug 14 17:38:25 printdiff is like a balm Aug 14 17:39:20 kergoth: pretty sure the outside world is still there... maybe this is your chance... Aug 14 17:39:43 make a run for the door, quick! Aug 14 17:40:00 * kergoth looks longingly toward the front window of the coffee shop Aug 14 17:40:06 printidff is great, when it actually works Aug 14 17:40:12 nerdboy: no encouraging slacking! Aug 14 17:40:21 which admittedly is usually the case, but not always Aug 14 17:40:29 unless I get to slack off too! :) Aug 14 17:40:43 i've seen builds where everything rebuilt from scratch, and the resulting sstate archives *have the exact same signatures and filenames as the ones i already had* Aug 14 17:40:49 haven't nailed that behavior down yet, though Aug 14 17:40:54 * nerdboy "blocked" by webkit Aug 14 17:41:11 time to talk to the wife... Aug 14 17:43:44 has anyone successfully managed to use gdbserver here with Yocto for debugging, like ever? Aug 14 17:45:48 it is such a painful territory even without Yocto, so I wonder if someone had already written a good tutorial about it. Aug 14 17:46:35 I have, but not within the last few months.. Aug 14 17:46:55 I cannot get it work properly with Yocto, I do not know why. Aug 14 17:47:00 I usually have to look up the steps when I do it Aug 14 17:48:07 http://paste.kde.org/praueca7s Aug 14 17:48:16 I wrote a debug.sh script so that I can use debug.sh myprogram Aug 14 17:48:30 but the script is not the point, I am just showing what I am trying Aug 14 17:48:56 so basically getting the stripped binary from the image rootfs and getting the symbol file from the -dbg package's packages-split sub-directory Aug 14 17:49:07 target remote is just one of many.. before that you normally configure where the -dbg symbols are.. etc.. Aug 14 17:49:10 on the target, I am just running gdbserver 192.168.0.32:2345 foo Aug 14 17:49:18 ya, that sounds correct Aug 14 17:49:31 and I have this in my ~/.gdbinit file: Aug 14 17:49:42 set sysroot ./tmp/work/foo-foo-linux-gnueabi/foo-core-image/1.0-r0/rootfs/ Aug 14 17:49:49 I will add that sysroot step to my script later. Aug 14 17:50:01 but that is about what I am trying to do; I observe random behavior :) Aug 14 17:50:06 I usually construct a special rootfs that has the debug and set it there.. Aug 14 17:50:13 I don't generally use the tmp/work version Aug 14 17:50:23 sometimes a breakpoint is not hit even the code path is hit; sometimes it jumps forth and back in the code even though I use -O0 and -g, etc. Aug 14 17:53:19 well, hand-crafting a custom rootfs... I am not sure that is good... you better use the SDK then if you do not like the Yocto environment's internal rootfs. Aug 14 17:53:33 Hmm, do we have a bitbake argument to exit after the sstates are fetched / after the runqueue is prepared, but before the build starts? Aug 14 17:53:36 i'm guessing probably not Aug 14 17:53:48 wonder if that'd be worth adding, to pre-fetch your sstates without doing so manually Aug 14 17:54:09 khem___: any ideas on the eglibc issue? Aug 14 17:55:21 sgw_: I tried to reproduce it on my end but did not happen Aug 14 17:55:35 I was using ubuntu 12.04 for this Aug 14 17:56:21 khem___: I am on my F19 machine, let me check my 13.10 machine Aug 14 17:57:40 I create a parallel 'rootfs' that only incudes the -dbg packages.. it's simple enough to do and doesn't require any special work Aug 14 17:57:59 alternatively you run the image generation twice, the second time with the pkg-dbgs enabled Aug 14 17:58:19 that is not an option Aug 14 17:58:22 I sent a patch for that PREFERRED_PROVIDER problem I was having. Aug 14 17:58:28 that would be quite cumbersome to switch forth and back IMO Aug 14 17:58:34 for every single developer Aug 14 17:58:37 it's simple.. Aug 14 17:58:43 some people do not even know Yocto, and they should not. Aug 14 17:58:45 image-dbg.bb: Aug 14 17:58:46 they get a ready-made rootfs Aug 14 17:58:50 require image.bb Aug 14 17:58:51 which is non-debug Aug 14 17:58:55 IMAGE_FEATURES += "pkg-dbgs" Aug 14 17:58:57 .... Aug 14 17:59:02 bitbake image image-dbg Aug 14 17:59:11 you get two images.. one for the system and one for the debugger Aug 14 17:59:40 for the rootfs with only -dbg packages, we have pending patches to do that automatically when a var is set, in meta-mentor, https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/lib/oe/rootfs.py#L26 Aug 14 17:59:45 otherise I just look at what I'm dbeugging and extract the -dbg packages myself Aug 14 17:59:49 fray_: the process is straight-forward, but not simple Aug 14 17:59:51 * kergoth grumbles Aug 14 17:59:56 it involves lots of steps, including image reflash Aug 14 18:00:03 that is very complex an environment for debugging. Aug 14 18:00:11 a little program Aug 14 18:00:12 you do NOT flash the target with the dbeug image, ever.. Aug 14 18:00:14 it's not requried Aug 14 18:00:26 gdbserver and gdb (cross) will connect the dots.. Aug 14 18:00:38 I was assuming the debugger would run elsewhere, not on the target. Aug 14 18:00:45 oh, sometimes it is required, like now Aug 14 18:00:52 when I got fedup with gdbserver, and putting gdb onto the target. Aug 14 18:00:57 (using NFS) Aug 14 18:01:10 khem___: yup it happens on my 13.10 machine also, which has perl 5.14.2 Aug 14 18:01:24 anyway, I will call it a bad day Aug 14 18:01:24 cya Aug 14 18:01:34 kergoth, I'm all for that patch.. we've got a similar hack in our stuff to generate a -dbg only FS.. it's a pain Aug 14 18:02:13 its handy either to hand to the local gdb with a remote gdbserver, or to write onto a usb stick for on-target Aug 14 18:02:21 yup Aug 14 18:03:01 the one we wrote (1.5 time frame-ish) simply iterated over the install set and installed the dbg into a separate directory.. but it was too much of a hack to submit.. Aug 14 18:03:11 a python based approach for that is significantly better Aug 14 18:07:00 * nerdboy thought the wall was chipping away, but has apparently been quickly shored up Aug 14 18:07:29 does anyone know offhand if PATH only contains the pattern, or the entire path? Aug 14 18:07:38 e.g. file://foo/.* https://foo.com/bar/PATH Aug 14 18:07:46 does that fetch bar/foo/blah, or bar/blah? Aug 14 18:08:26 * kergoth constructs a test mirrors var and cranks up fetch debugging Aug 14 18:30:05 khem: I can easily reproduce it with the conf command that gets run during the config process KCONFIG= /usr/bin/conf --oldaskconfig option-groups.def Aug 14 18:42:22 hah. create a build dir called `build-PATH`, then add a file://${TOPDIR}/ path to MIRRORS. prepare to be amused Aug 14 18:42:53 we should have had some sort of token marker for those replacements, ${} or %{} or something :) Aug 14 18:45:06 gah, the verbosity of a -DDD build is still absolutely insane. forgot how bad that was :) Aug 14 18:49:53 hi kergoth Aug 14 18:50:32 hey mranostay Aug 14 18:51:04 kergoth: how are the bits baking? Aug 14 18:53:26 spilling on the floor, sounds like... Aug 14 18:55:48 arguing with bitbake again :) Aug 14 18:55:51 mostly losing Aug 14 19:12:55 hmm, anyone know what the status of Qt5 on i.MX6 is on Daisy? Aug 14 19:24:01 okay, what exactly is the relationship between poky/meta and oe-core/meta ? Aug 14 19:24:16 they're almost identical (but not quite) Aug 14 19:24:41 are they manually synced at some interval? Aug 14 19:28:11 other than the *.conf.sample files in oe-core the only differences i see are mine Aug 14 19:28:41 yet the other day there was difference (upstream) in a bbclass file... Aug 14 19:28:42 nerdboy: poky/meta is created with combo-layer tool Aug 14 19:28:58 from oe-core and other stuff? Aug 14 19:29:02 yes Aug 14 19:29:31 that last difference is still confusing me... just a commit timing thing? Aug 14 19:30:40 JaMa: how often does that happen and get committed to the poky repo? Aug 14 19:31:15 don't know Aug 14 19:31:35 at least in the past, there were local changes that hadn't yet gone into bitbake/oe-core, despite the use of combo-layer, but hopefully that's not the case anymore :) Aug 14 19:31:59 i guess i'll know when bleeding-edge gstreamer shows up in poky? Aug 14 19:32:15 that sounds like the other direction... Aug 14 19:32:29 it goes both ways? Aug 14 19:33:21 combo-layer allows to split patches, but I think that it's used only one-way Aug 14 19:33:52 i'm assuming this isn't documented anywhere yet? Aug 14 19:34:26 JaMa: you know what the status of Qt5(via directFB) support on i.MX6 on the daisy release is? Aug 14 19:35:53 OE @ ~/extras/poky $ diff -rq meta ~/openembedded-core/meta Aug 14 19:35:53 Only in /OE/openembedded-core/meta/conf: bblayers.conf.sample Aug 14 19:35:53 Only in /OE/openembedded-core/meta/conf: local.conf.sample Aug 14 19:35:53 Only in /OE/openembedded-core/meta/conf: local.conf.sample.extended Aug 14 19:35:53 Only in /OE/openembedded-core/meta/conf: site.conf.sample Aug 14 19:36:00 I don't see any other difference Aug 14 19:36:12 darknighte: no idea Aug 14 19:36:25 yup, pulled on master again and got the new gstreamer stuff Aug 14 19:36:51 wasn't there when it broke latest (upstream) rpi updates Aug 14 19:37:12 timing is everything, apparently... Aug 14 19:37:16 JaMa: rats. thx anyway Aug 14 19:37:40 RP: is there some reason why conf.sample files are in poky only in ./meta-yocto/conf/? Aug 14 19:39:34 local.conf.sample.extended site.conf.sample are identical, bblayers.conf.sample local.conf.sample are a bit different Aug 14 19:44:38 2 Aug 14 19:45:10 42 Aug 14 20:00:36 anyone know why gdb would be compiled with --with-ncurses and --disable-tui? Seems funny because I thought it only used ncurses for tui mode. Aug 14 20:01:46 sgw_: Does it happen with poky-tiny config or normal poky config for you Aug 14 20:03:40 JaMa: meta-yocto actually is the poky distro layer Aug 14 20:04:15 mv meta-yocto meta-poky to increase clarity Aug 14 20:04:56 I asked for it during ELC 2011 Aug 14 20:05:21 thatd be nice, would definitely reduce confusion Aug 14 20:07:03 I agree, but the fact that poky uses combo-layer makes it a bit different setup then others do e.g. others use layers as they are and add a setup layer and a distro layer to form the complete set Aug 14 20:07:22 so meta-yocto kind of looses the significance of being a distro layer there Aug 14 20:08:02 this is a different approach but some folks want it this way Aug 14 20:08:13 where all metadata is under single git repo Aug 14 20:11:08 meh, I'd like to leverage the internal setup scripts more, rather than rolling our own so much, but the core ones are still rather limited Aug 14 20:11:11 hmm Aug 14 20:26:48 khem: yes, but that doesn't explain why their were removed from meta subdirectory (unless something requires them to be uniq) Aug 14 20:42:59 maybe a "repo" repo/manifest instead Aug 14 20:43:34 ie, one for poky (sans hand-made layer tool), one for oe-core, etc Aug 14 20:43:51 plus document using them Aug 14 20:44:35 some (non-core) setups already do that... Aug 14 20:46:16 but yeah, i thought the main difference/intent of poky repo was to provide yocto-bsp, poky/meta, demo images, etc, all in one repo Aug 14 20:47:05 khem: normal configuration multiple build machines and different MACHINE settings (arm/x86) Aug 14 20:47:21 oh, and yocto reference kernel and default machine support for a handful of machines Aug 14 20:55:07 good morning Aug 14 21:16:14 Hey everybody Aug 14 21:17:24 hi Aug 14 21:17:35 Can anyone help me with a udev issue? Aug 14 21:18:41 theguy: depends on what it is Aug 14 21:19:25 theguy: what issue Aug 14 21:19:26 sgw_: hmm ok. I will try to reproduce it with OE-Core tonight Aug 14 21:21:36 udev problem as in installing your own custom rule perhaps? Aug 14 21:22:33 khem: Ok, I will be back around after 8 - 9ish or so tonight. Aug 14 21:22:38 JaMa: they got filtered out mainly to reduce confusion Aug 14 21:22:46 and yes, that layer should have been called meta-poky Aug 14 21:22:59 I still sometimes wonder about changing the name Aug 14 21:24:43 RP: master-next is missing 1 gcc patch Aug 14 21:24:46 from me Aug 14 21:26:39 http://patchwork.openembedded.org/patch/78131/ and http://patchwork.openembedded.org/patch/78135/ Aug 14 21:30:14 khem: I was waiting for Peter to rebase them Aug 14 21:34:15 New to Yocto. Using daisy release, but meta-java doesn't have daisy branch. Should i take dora or master? Aug 14 21:35:02 he did I think Aug 14 21:35:19 hbruce: master Aug 14 21:36:51 khem: right, but not when I last built -next ;-) Aug 14 21:36:55 khem: I'm updating Aug 14 21:39:05 RP: ok here is the rebased versions on top of master-next http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl Aug 14 21:40:21 Actually no, udev problem where my drive does not disappear from /dev when I remove it Aug 14 21:41:33 is there something in fstab? Aug 14 21:41:48 related to whatever the device is... Aug 14 21:43:07 so you get something like a stale /dev/sdb,/dev/sdb1 ? Aug 14 21:43:39 Nothing in fstab Aug 14 21:43:52 i have seen that lately, but on my desktop after a usb bus hiccup Aug 14 21:43:52 And exactly. It's /dev/sda and /dev/sda1 Aug 14 21:45:00 3.13.6 gentoo-sources and udev-212-r1 Aug 14 21:45:03 It works fine for a while, then suddenly after a reboot /dev/sda is there when it shouldn't be Aug 14 21:45:23 reboot with device still inserted? Aug 14 21:45:24 I'm running 3.0.35 Aug 14 21:45:41 with the freescale 4.0.0 bsp Aug 14 21:46:54 If I insert and remove the drive, udev still detects it and mounts/unmounts it automatically Aug 14 21:47:11 But it just doesn't remove /dev/sda anymore Aug 14 21:47:19 been using 3.15/patched mainline and bleeding-edge u-boot on wand/udoo Aug 14 21:47:47 theguy: you mean with the stale /dev file there? Aug 14 21:48:21 Yeah. The file /dev/sda stays whether the drive is inserted or not, but udev seems happy and it mounts/unmounts correctly Aug 14 21:48:28 then it detects/mounts as sdb if sda is stale... at least it should... Aug 14 21:48:41 It still gets used as /dev/sda Aug 14 21:48:47 ? Aug 14 21:49:12 not with (systend) udev... Aug 14 21:49:39 Yeah it's weird. I've seen it on my desktop before where it will increment the letter if one goes stale, but in this case it keeps using /dev/sda. It's just that the file doesn't go away when the drive is removed. Aug 14 21:49:46 oe uses 18x-something i belivee Aug 14 21:49:58 18x? Aug 14 21:50:05 udev version? Aug 14 21:50:15 as opposed to 20x Aug 14 21:50:17 yeah Aug 14 21:50:40 well, 212 on my desktop and it's behind... Aug 14 21:50:45 Oh yeah - 182-r7 Aug 14 21:51:14 pretty sure that's still udev source before it "merged" with systemd Aug 14 21:51:39 not to say the behavior doesn't change like my underwear... Aug 14 21:51:51 My system doesn't use systemd, so I assume it would have to be before that? Aug 14 21:52:28 Is there a forum or chat room that might have a lot of knowledge on udev? If I could figure out exactly where udev creates/deletes that file I could try and debug it Aug 14 21:54:16 my gentoo builds leave out systemd as well (just openrc stuff is fine) but udev has been assimilated afaik Aug 14 21:54:32 the rules are on your system Aug 14 21:54:39 khem: Thx. Using meta-java master but getting build errors in xerces-j-native. Anyone seen this? Aug 14 21:55:21 RP: I have consolidated Peter's and mine patches on top of master here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl Aug 14 21:56:26 I don't think it's an issue with the rules. It works fine for a while and then stops working randomly until I recreate my rootfs Aug 14 21:56:53 As far as I can tell the creation of /dev/sdx is built into udev as well Aug 14 21:57:12 it should be in the default rules Aug 14 21:57:33 use opkg/rpm/apt to list the rule files Aug 14 21:58:12 hbruce: what errors ? Aug 14 21:58:23 so you're plugging in a device, unmounting, change partitions, mkfs and remount? Aug 14 21:58:41 Oh, how do I do that? I've looked through the rule files in /etc/udev/rules.d but I don't see anything about creating /dev/sdx files Aug 14 21:59:25 When it breaks? All I do is reboot a few times with the drive inserted. Aug 14 21:59:52 opkg list-installed | grep udev (for package names) Aug 14 22:00:13 Although it seems to happen after I do a "system update" by copying a duplicate root filesystem from a USB drive onto my device Aug 14 22:00:18 opkg files udev (to list files in a package) Aug 14 22:00:37 there's another place for rules Aug 14 22:00:56 look in /lib/udev/rules.d/ Aug 14 22:01:16 RP: current master-next which you rebased few min ago is still missing one patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/musl&id=0e299ee5155c94f09a15430c091766cfb55bce68 Aug 14 22:01:19 that's for opkg packages anyway... Aug 14 22:01:40 I have dpkg, I'll look up the command Aug 14 22:01:49 60-persistent-storage.rules Aug 14 22:02:41 I'll take a look through there thanks Aug 14 22:03:49 As far as I can tell, the rules files don't change between when it works and when it doesn't Aug 14 22:05:02 Although I should verify that Aug 14 22:05:12 to be safe, if you change the partition table you should remove/reinsert the device or run partprobe Aug 14 22:05:31 the rules files don't change on their own... Aug 14 22:05:56 the stale device file is an artifact of udev not handling something very well Aug 14 22:06:34 something you're doing/not doing is my guess, or the device/reader is flakey Aug 14 22:07:18 The partition table is never changed. I do mount/unmount the drive and read data from it. At some point, I copy a duplicate root filesystem from the USB drive over top of my root filesystem and then reboot. It seems to work until another one or two reboots after that. Aug 14 22:07:38 I have an application running that monitors /dev/sda... I wonder if that is somehow preventing it from being deleted. Aug 14 22:07:51 maybe sync after untar and see if that helps Aug 14 22:08:09 I'll give that try thanks Aug 14 22:08:30 or might be flakey hardware/driver getting saturated during heavy i/o and taking a dump Aug 14 22:08:44 It could be. Once it Aug 14 22:09:26 Once it's broken though, the file /dev/sda is created on boot whether the drive is inserted or not. And the continues until I re-flash the root filesystem. Even if I delete the file manually and reboot it returns. Aug 14 22:10:29 it's stale so it's a real file there when udev starts (which it sees and won't create the device) Aug 14 22:11:23 I delete it and reboot, without ever inserting the drive, it gets created on boot again Aug 14 22:11:23 you could wipe /dev on boot/reboot but you'd need to provide/create /dev/{console,null,zero} at a minimum Aug 14 22:11:41 khem: thanks, added Aug 14 22:11:58 but it guarantee clean /dev startup Aug 14 22:11:58 Oh would I have to wipe all of /dev instead of just the one file? Aug 14 22:12:13 Ok I'll give that a try Aug 14 22:12:50 RP: cool. so once this goes into master, I will be able to announce availability of meta-musl https://github.com/kraj/meta-musl Aug 14 22:12:53 just the stale ones, although the problem might just make new stale ones... Aug 14 22:13:23 That's what happens. If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive. Aug 14 22:13:45 now *that* sounds really weird... Aug 14 22:14:11 does your build have a default device tarball? Aug 14 22:14:15 khem: there is quite a queue in master-next so its going to need an autobuilder run and so on Aug 14 22:14:54 rpi boots off /dev/mmcblk0 so i have no sda unless i plug something else in Aug 14 22:15:21 Same with me. Boot is from /dev/mmcblk0 and /dev/sda is only created when I plug in a USB drive Aug 14 22:15:24 if you have a /dev/sda with no physical device then something else is going on Aug 14 22:16:21 assuming this is accurate/correct: That's what happens. If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive. Aug 14 22:16:39 kmem: Java build error src/org/apache/html/dom/HTMLIFrameElementImpl.java (at line 28) Aug 14 22:16:41 RP: yes, true Aug 14 22:16:52 that should not happen with a default udev setup Aug 14 22:17:15 Yep that's what happens. USB drive is /dev/sda, but after a few reboots that file starts to appear even when the drive isn't inserted. Aug 14 22:17:30 khem: sorry got your handle wrong Aug 14 22:17:33 RP: I am going to work on glibc 2.20 now as a part of that I am planning on renaming eglibc recipes to be called glibc Aug 14 22:17:35 So my application thinks a USB drive is inserted when it actually isn't. Aug 14 22:17:51 minimal static devices are the three above, whether they get plopped there by initramfs or they're just static Aug 14 22:18:00 hbruce: thats ok you can use ashmem too :) I do android too Aug 14 22:18:27 hbruce: pastebin the full build log somewhere Aug 14 22:18:34 I never make /dev/sda static. At some point it starts getting created on boot. If I delete it and reboot it comes back again. Aug 14 22:18:46 So I'd like to figure out what's placing it there on boot. Aug 14 22:18:55 RP: that reminds me of glibc -> eglibc transition now in reverse order Aug 14 22:19:07 "after a few reboots" meaning the device was plugged in at least once and later you get a stale (normal) device/partition file in dev Aug 14 22:19:14 since we did not remove glibc provides I am hoping this to be simpler Aug 14 22:19:36 khem: yes, lets hope so. Did we get anywhere with configuration of glibc? Aug 14 22:19:50 Yep. After the device has been plugged in a few times, and the board is rebooted a few times, that file starts showing up even when it shouldn't. Aug 14 22:19:52 upstreaming ? Aug 14 22:19:55 khem: yes Aug 14 22:20:15 can you make it happen while you watch dmesg? Aug 14 22:20:16 nowhere yet I am thinking bring the port to 2.20 will help in that Aug 14 22:20:30 khem: ok Aug 14 22:20:48 seem like there should be a udev log entry that at least smells funny... Aug 14 22:20:51 so end of this month if all is ok I will propose it for 2.21 Aug 14 22:21:17 I've looked through the logs when it's working properly and when it isn't, but I can't seem to find any differences Aug 14 22:21:27 RP: after I have had good results with 2.20 on master that is Aug 14 22:21:37 It's a weird issue. I've been working on it for a few days now Aug 14 22:22:32 I'll look a bit more closely at my application - maybe it's creating the file somehow by accident. Aug 14 22:22:55 what usb hardware/drivers? using usb-gadget? otg? other? Aug 14 22:23:00 khem: sounds good Aug 14 22:23:17 theguy: strace your app Aug 14 22:23:33 should be clear whether it does or not Aug 14 22:24:21 It's an i.MX6, the freescale bsp supplied the drivers. I believe it's a USB host but I'd have to double check. Aug 14 22:25:34 sounds normal enough, notwithstanding you could've found an actual bug Aug 14 22:25:37 Actually once the problem starts, even if I never run the app, the file still appears on boot. Although the app could be starting the problem in the first place Aug 14 22:26:00 khem: Build output at http://pastebin.com/fr7ZDTYs Aug 14 22:26:14 I wonder! It feels like a bug, but there are many times where I think it's a bug and it turns out to be my code :/ Aug 14 22:26:20 if it's a stale file it will always be there unless /dev is mounted volatile Aug 14 22:26:43 Would udev give an error if it couldn't remove the file when the drive was removed? Aug 14 22:26:55 bug in your code/upstream bug, bug is abug... Aug 14 22:27:37 it should in theory Aug 14 22:28:01 not sure how quiet you can make it Aug 14 22:28:24 Do you know where I could look for that error? I've looked in /var/log/messages after setting the log priority to info but I see no mention of /dev/sda at all Aug 14 22:28:58 Oh sorry that's not true. I see mention of it but nothing to say when it is created/deleted Aug 14 22:28:59 can you determine for sure if it's just a stale file created once and subsequently ignored bu udev? Aug 14 22:29:39 If I do a "rm /dev/sda", it goes away. udev then works properly until I reboot, at which point /dev/sda magically appears again Aug 14 22:30:00 you should see the usual udev/usb device messages in dmesg and the kernel log Aug 14 22:30:25 it should not magically reappear on its own Aug 14 22:30:56 someone is putting it there, and that's not "typical" udev behavior Aug 14 22:31:03 I'll try and break it again and then look at the kernel logs after a reboot Aug 14 22:31:21 Yeah. I just can't figure out what's putting it there Aug 14 22:32:41 Just doing an update now, which should break it. And then I'll see if the logs mention it on reboot. Aug 14 22:35:21 okay, not that i've had a reason to look before, but the default is empty /dev dir is empty when not in a running system Aug 14 22:35:35 everybody's different... Aug 14 22:37:37 Ok I broke it again. I'll take a look at the log files. Aug 14 22:39:24 So dmesg | grep sda shows nothing, but the file is there Aug 14 22:39:40 I'll rm /dev/sda and reboot Aug 14 22:40:05 After reboot, /dev/sda is back. The drive is not inserted. Aug 14 22:42:13 I can't find anything that would be creating that file Aug 14 22:45:47 what gets it back to normal? cold boot? Aug 14 22:46:47 Cold boot doesn't work. I end up reflashing the SD card from scratch with a fresh root filesystem Aug 14 22:48:43 sync didn't help? Aug 14 22:49:25 are you preserving the proper permissions on what comes out of the tarball? Aug 14 22:49:40 Should I do a sync after removing /dev/sda? Aug 14 22:49:49 before Aug 14 22:49:59 Ok Aug 14 22:50:17 when sync returns everything is flushed Aug 14 22:50:34 Ok, so I'll do sync, then rm /dev/sda, then reboot Aug 14 22:50:49 so if it still pukes that would eliminate incomplete writes to the card Aug 14 22:51:08 Alright one sec Aug 14 22:51:43 Looks like the file still gets created on boot Aug 14 22:53:41 nerdboy thanks a lot for the help. I've got to head off now. Aug 14 22:53:56 But you've given me a bunch of things to look at so I'll investigate them further. Aug 14 22:54:26 don't forget to report back... Aug 14 22:54:53 Will do! I'm back tomorrow so I'll sign in here and give you an update Aug 14 22:55:17 ok Aug 14 22:55:28 Really appreciate it! Cheers Aug 14 22:58:47 * nerdboy kinda feels like the sales guy who sends people across the street for a better deal Aug 14 23:05:34 probably why i'm not a sales guy... Aug 15 00:59:22 hbruce: thats some sort of race condition can you do bitbake -ccleansstate gnujaf-native gnumail-native and rebuild Aug 15 00:59:53 I have seen this error when I used to do high parallel build -j30 with 30 tasts in parallel Aug 15 01:00:04 never got time to get to root of it **** ENDING LOGGING AT Fri Aug 15 03:00:00 2014