**** BEGIN LOGGING AT Tue Jan 29 02:59:58 2013 Jan 29 09:20:12 hi everybody! I'm building for target nitrogen6x and I'm encountering this build issue: http://pastebin.com/A5SHcjpv Jan 29 09:22:04 The error is: linux/mxcfb.h:111:2: error: unknown type name 'uint' Jan 29 09:22:35 What's the best thing to do in this case? I'd like to fix the problem, not just workaround it... Jan 29 09:27:39 Hi, anyone in the known on how long before any reply once filled the form to register for the Yocto compatible program? Jan 29 10:53:57 holgerwrs: mine took months Jan 29 10:54:35 mckoan: ok, so its save to go on vacation than :D Jan 29 10:54:57 holgerwrs: and a couple of reminder :-D Jan 29 10:55:26 good morning (BTW) Jan 29 10:56:22 mckoan: reminders to whom, the webmaster, from whom I got the email. The email itself does not name any contact person Jan 29 10:57:24 and essential if the process needs reminders to be executed, that process is broken (2 my cents) Jan 29 10:59:09 so AGL (Automotive Grade Linux), anyone working on a Yocto layer already? Jan 29 11:01:11 holgerwrs: I guess yes, but not publicly Jan 29 11:01:17 holgerwrs: is there anything documented apart from "what tizen ivi is" yet? Jan 29 11:02:21 rburton: no, there isn't, and that's what I too got pointed to by Rudi Jan 29 11:03:22 AGL right now is just Tizen IVI because we need to get over the hurdle of building it. Jan 29 11:03:29 :D Jan 29 11:03:32 building *what*? :) Jan 29 11:03:42 Tizen IVI Jan 29 11:03:55 i thought they were building AGL :) Jan 29 11:05:11 I don't want to share the complete email I got :) Jan 29 11:07:03 holgerwrs: O.S. Systems has joined AGL as well and we intend to work in this as well Jan 29 11:08:21 otavio: so you setup a git repo (GitHub) already? something like meta-agl, or what plans do you have? Jan 29 11:09:34 holgerwrs: I did not yet Jan 29 11:09:53 holgerwrs: but we could try to find a common plan Jan 29 11:10:03 holgerwrs: and avoid duplicate it Jan 29 11:10:20 ok, will possibly than do so come next week / come vacation Jan 29 11:10:41 and share it Jan 29 11:10:46 GitHub okay for you? Jan 29 11:11:04 Sure; it is fine with me Jan 29 11:12:16 otavio: sounds like we have a plan already Jan 29 11:12:46 holgerwrs: good; in meanwhile I will set it in our Gerrit server Jan 29 11:13:05 holgerwrs: so when you guys are back we can share the work Jan 29 11:15:32 otvaio: ok, will fly out on vacation, have to get Internet setup there, so Feb. 4th I should be back online again, and start set things up Jan 29 11:16:15 holgerwrs: ok; ping me when you're back Jan 29 11:16:26 otavio: will do Jan 29 14:10:13 I am having a hard time to understand why the complemenary packages are including samba-locale in my image Jan 29 14:10:42 It seems oe-pkgutil is globing but I fail to understand how it works Jan 29 14:51:04 zeddii, any hints why I get the double dash in uImage--3.6+gitAU Jan 29 14:55:26 otavio: there was a recent change in master in that area Jan 29 14:55:31 otavio: to make it pull in less Jan 29 14:55:39 Crofton|work, I looked yesterday, you don't have a custom KERNEL_IMAGE_BASE_NAME defined, right ? Jan 29 15:01:35 right Jan 29 15:01:43 well I think right :) Jan 29 15:01:56 so it goes in that hole? Jan 29 15:03:59 yah. that's what is defining the name. KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" Jan 29 15:05:07 at least, that's my working theory, the variables get a bit ... circular. I had to delete my workdir, so my build I started this morning is still churning. Jan 29 15:05:34 ah, I have no PE Jan 29 15:06:25 I wondered about that. wanted to see one land on disk here as confirmation .. but I'm still waiting :) Jan 29 15:06:49 I'll know "soon" Jan 29 15:08:39 * zeddii is 310 of 506 towards his build Jan 29 15:13:17 RP: really? I will check it Jan 29 15:15:43 RP: does not seem related Jan 29 15:15:49 RP: but I think I work arounded it Jan 29 15:19:27 sorry to ask again: does anybody know what might be a good fix for this issue (I've already workarounded by using int, but I'm sure that's not a proper solution): http://pastebin.com/A5SHcjpv Jan 29 15:36:33 zeddii, after setting PE=) uImage-0-3.6+gitAUTOIN Jan 29 15:36:36 er 0 Jan 29 15:39:22 cool. I'm 594 of 598 towards seeing my own test. Jan 29 15:39:30 I thought PE would have had a 0 default. Jan 29 15:39:43 yeah Jan 29 15:39:53 this is from l-y-c Jan 29 15:40:38 yah. same as any package from that angle, i.e PR=0, PE=0 even if you don't set them. I'll have a closer look after my uImage drops onto disk. Jan 29 15:43:55 I'll check around also Jan 29 15:59:43 Song_Liu: YPTM: RP is there Jan 29 16:00:00 * rburton joining in a second, phone engaged Jan 29 16:00:11 YPTM: Scott Rifenbark joined the call Jan 29 16:00:17 belen joined the call Jan 29 16:00:33 YPTM: Bruce Ashfield on the call. Jan 29 16:00:34 YPTM: Tom Z on the call Jan 29 16:00:52 YPTM: Laurentiu Palcu joined Jan 29 16:01:03 YPTM: Corneliu joined Jan 29 16:01:18 YPTM: Mark is here.. Jan 29 16:01:21 YPTM: Björn is here Jan 29 16:01:22 YPTM: welcome to the technical team meeting, please let me know who's on the bridge. Thank you! Jan 29 16:01:26 YPTM: Kevin Strasser is on the call Jan 29 16:01:34 YTPM: Saul Here Jan 29 16:01:58 UK clearly is a black hole Jan 29 16:02:05 Song_Liu: Belen, Ross, Richard Jan 29 16:02:06 lol Jan 29 16:03:52 YPTM: jzhang's on the call Jan 29 16:04:25 YPTM: ross joined Jan 29 16:04:28 * nitink is on the call Jan 29 16:05:03 YPTM: bogdanm joined Jan 29 16:05:29 YPTM: Any opens? Jan 29 16:07:36 Open about this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2821 Jan 29 16:07:37 Bug 2821: normal, Medium, 1.4 M1, laurentiu.serban, NEEDINFO , libowl do_fetch error Jan 29 16:11:56 YPTM: Darren has joined Jan 29 16:21:31 I'm driving to OSU open source lab right now so cannot join the call today. Jan 29 16:25:45 new kernel manual url is http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html Jan 29 16:28:38 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2821 Jan 29 16:28:39 Bug 2821: normal, Medium, 1.4 M1, laurentiu.serban, NEEDINFO , libowl do_fetch error Jan 29 16:32:05 https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=504 Jan 29 16:35:56 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/incvartrack2 Jan 29 16:40:22 RP: I've seen the perl do_compile sometimes encounters "warning: jobserver unavailable: using -j1" which affects performance quite severely. haven't had time to investigate further though :-( Jan 29 16:41:37 RP -- one possibility with the per-file deps, if we're not already doing it, only run it on +x files.. Jan 29 16:41:49 since they're the only ones that are going to end up producing dependencies Jan 29 16:42:06 for the kernel, the .ko shouldn't necessarily be executable Jan 29 16:46:57 I agree Jan 29 16:48:30 tomz1, zeddii, nitink, shall we meet now? Jan 29 16:48:45 dvhart: ok Jan 29 16:48:46 Zagor: I've not noticed that on perl but I'm not sure I would see it in the logs :/ Jan 29 16:48:47 YPTM: thanks for joining the meeting. You have a nice day or evening. Jan 29 16:50:20 fray: I think we run on non +x due to things like perl/python modules Jan 29 16:50:33 fray: I suspect changing that would buy quite a speedup Jan 29 16:50:48 could be Jan 29 16:51:16 I just see a lot of overlap, and such.. I wish I had the time to document where I percieve the overlap to be and what is likely the fastest solution to this.. Jan 29 16:51:46 RP: I'll try to gather more info next time I see it. Gotta run now. Jan 29 16:52:04 the libs one is a big one to me.. Jan 29 16:52:15 fray: libs? Jan 29 16:52:19 tomz1, ugh, not accepting my passcode, says it can't hear me... trying again and again Jan 29 16:52:23 Hi all, I'm trying to pull in a JDK. I pulled in meta-java, meta-openembedded/meta-oe and openembedded-core/meta, and when I try to build my image it ties to build Pseudo and I get a failure Jan 29 16:52:26 I know the OE stuff works well, but so does the RPM stuff.. I wonder which is faster, and then could be translated to the 'other'.. Jan 29 16:52:48 it's also possible that everything rpmdeps does is something we could implement as part of core package processing in oe... Jan 29 16:52:50 ERROR: ExpansionError during parsing of .../maliit-framework_git.bb. Failure expanding variable gtk_immodule_cache_postinit. Jan 29 16:53:01 did I do something wrong? Jan 29 16:53:16 fray: honestly, the shlibs code in the packaging is rather clever and fast, its tuned for OE Jan 29 16:53:23 usually means you are missing a } or a ' or a " Jan 29 16:53:24 dvhart: no problems here with that, nitin and zeddii in ok Jan 29 16:53:39 dvhart: are you using the right number/pc Jan 29 16:54:01 RP, yes.. I suspect that it could do both purposes if adjusted.. since if I remember right it's a two step process... get the lib requirements from the executable, then map it to the oe-name Jan 29 16:54:14 RPM only cares about the actual requirements (sonames and versions) Jan 29 16:54:18 adalton: old oe-core? that was added in 1.3 Jan 29 16:54:49 rburton: hum, I pulled oe-core maybe last week? Let me see if there's an update Jan 29 16:55:09 The RPM version is slightly more exacting.. (specifically w/ the versions).. it's also needed if we want to be able tosupport installing external RPM packages.. (which I certainly do need) Jan 29 16:55:46 adalton: the class is gtk-immodules-cache Jan 29 16:55:59 * rburton -> kids Jan 29 16:56:10 but I agree completely.. this is a clear place to me that refactoring is needed, if only to eliminate redundant code paths.. but more likely will cause speed up if we can come up with some consistent rules.. Jan 29 16:56:17 I just did a git update and I still run into the problem. It says "NameError: name 'qemu_run_binary' is not defined Jan 29 16:56:26 hm Jan 29 16:56:27 (I'd also love it if the kernel modules deps could be added to our dependency structures.. I'm not sure if they are there or not right now) Jan 29 16:56:36 adalton: the qemu changes obviously we're tested well enough Jan 29 16:56:45 fray: they're already there Jan 29 16:57:06 adalton: that should be provided by qemu.bbclass Jan 29 16:57:09 but now i have to go Jan 29 16:57:09 I'll not be using that package, if I just blow it away for now I should be safe, no? Jan 29 16:57:13 ok.. last time I really looked (more then a year ago) something odd was happening there.. but it could have just been me.. ignore that then Jan 29 16:59:17 hum, removed the 'maliit' directory and ran into 'Failure expanding variable autotools_do_configure: ExpansionError: Failure expanding variable EXTRA_OECONF for gnome-icon-theme Jan 29 17:05:37 fray: I checked and we do generate kernel module deps Jan 29 17:05:55 ok.. ignore me then.. I've got to be thinking of somethinge lse Jan 29 17:17:23 anyone notice danny based images taking two IP addresses on the network? Jan 29 17:17:30 (or is it just me?) Jan 29 18:26:05 Autobuilders going offline. Jan 29 18:29:01 * mihai2 too Jan 29 18:29:07 :D Jan 29 18:45:11 HI all Jan 29 18:46:05 so I'm using poky-danny-8.0, but I want to use the meta-java layer, which depends on openembedded-core/meta and meta-openembedded/meta-oe Jan 29 18:46:32 Crofton|work, I'm heading out to a dentist appt, but I did confirm that my linux-yocto* builds also show the empty PE and hence "--" in the uImage names. I made a note to figure out why it isn't 0 .. Jan 29 18:46:56 If I leave in the ../meta layer that came with the yocto install, things from meta-openembedded fail because it picks up the wrong .bbclass Jan 29 18:47:26 but if I remove poky-danny-8.0/meta I get an error about using the wrong version of bitbake Jan 29 18:47:29 zeddii, have fun! Jan 29 18:47:36 1.17.0 is required and 1.16.0 was found Jan 29 18:47:44 thanks for checking, sounds like something we should get to the bottom of Jan 29 18:48:41 do I need to use the git version of yocto to use openembedded-core and meta-openembedded? Jan 29 18:49:22 adalton: use the appropriate branch on meta-openembedded repo Jan 29 18:49:41 there is danny branch Jan 29 18:49:48 ah Jan 29 18:49:54 ok, will take a look -- thanks Jan 29 18:54:47 Crofton|work, absolutely. I have it on my desk for tomorrow morning. and no, I won't have any fun :P Jan 29 18:55:14 my dentist gives me gas Jan 29 18:55:53 the xilinx git repo is refusing to speak to me Jan 29 18:56:04 I think I'll go ride my bike since today is spring Jan 29 18:59:04 khem: that seems to have done the trick -- thanks for the pointer. Jan 29 19:54:08 rburton: ping Jan 29 19:59:11 so, how are you supposed to SSH into a danny based debug-tweaks? All the passwords are blank, and doing ssh root@ip or ssh xuser@ip or ssh distcc@ip all prompt for passwords. Jan 29 19:59:55 ok, root is blank. Rest are unknown. Jan 29 20:01:39 jstashluk: yo Jan 29 20:40:00 sstate keeping ipk for every AUTOINC value? Jan 29 20:40:33 I have each .ipk file few times with different AUTOINC, e.g. each ncurses 7 times.. Jan 29 20:50:30 That's probably by design JaMa (or at least a side affect of intentional design) Jan 29 20:51:43 Autobuilders are back up. Jan 29 20:51:57 You can use sstate between different build setups, which can include different layers. With AUTOINC being used to identify (along with a number of other items) the files can sit side by side and rebuilds cut down. Jan 29 20:53:15 nm, was thinking a variable other than AUTOINC. Not sure why AUTOINC is included. INCPR is, though. Jan 29 20:58:35 blloyd: then each version should be in different sstate archive like e.g. populate-sysroot is Jan 29 20:58:39 this is bug not feature Jan 29 20:59:06 RP: ^ any idea? Jan 29 21:42:26 JaMa: I'd need a better description of exactly what is going on Jan 29 21:43:34 RP: I've noticed that my deploy dir is bigger and bigger Jan 29 21:43:58 RP: and when ncurses was being rebuilt I've checked that all "old" versions were removed Jan 29 21:44:07 but then installed again with sstate Jan 29 21:47:08 JaMa: ok, keep in mind I just came into this conversation and there is a lot of context seems to be missing. So you say different versions - you mean that AUTOINC is somehow increasing when it shouldn't? One package feed is seeing multiple different versions? Jan 29 21:48:24 ah, can you check http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/035116.html Jan 29 21:48:55 yes same sstate archive contains multiple .ipk files with different PR values Jan 29 21:50:13 JaMa: in the same sstate archive? Jan 29 21:50:27 JaMa: that is clearly a bug :/ Jan 29 21:50:31 yes Jan 29 21:50:39 not sure if caused by packagedata or PR service Jan 29 21:51:10 JaMa: Can you check whether this is the actual sstate tarball (.tgz file) or the manifest at fault? Jan 29 21:51:23 JaMa: I assume the files all exist? Jan 29 21:51:23 probably PR service, because packagedata is not there so long for me to have 10 revisions already Jan 29 21:51:38 yes files exist, checking .tgz Jan 29 21:53:44 yes in .tgz too Jan 29 21:54:03 and it got broken somewhere between Jan 2 and Jan 22 probably http://paste.debian.net/230247/ Jan 29 21:54:46 JaMa: This is with PR server? when did you start using that? Jan 29 21:55:14 JaMa: being in the .tgz gives a big hint as to where the problem might be Jan 29 21:55:52 in this build dir since LOCALCOUNT was removed from bitbake (that's when I've rebuilt that from scratch) Jan 29 21:56:10 2012-12-17 Jan 29 21:57:47 JaMa: I'm going to bet on http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/sstate.bbclass?id=be78e8190a38c8aff570ed7a3f93a531a296c37d Jan 29 21:58:43 heh gcc sstate archive is already on 250MB here Jan 29 21:58:54 except that it does rm -rf ${SSTATE_BUILDDIR} Jan 29 22:00:05 hmm doesn't look that dangerous on first look :) Jan 29 22:00:30 JaMa: somehow, corrupt data is making it into SSTATE_BUILDDIR which is why I'm suspicious Jan 29 22:00:54 JaMa: initially I was wondering if it was lying around there from a previous build - it never cleans the directory Jan 29 22:01:07 JaMa: however it does clean it afterwards Jan 29 22:01:52 JaMa: if you have the build handy, what is in ${WORKDIR}/deploy-ipks ? Jan 29 22:01:57 for say ncurses Jan 29 22:02:37 Ah, as far as I can tell, nothing ever cleans PKGWRITEDIRIPK Jan 29 22:03:56 so I get the error: Package gstreamer-fsl-0.10 was not found in the pkg-config search path. Jan 29 22:04:06 package is here: ./tmp/work/imx6qsabrelite-poky-linux-gnueabi/gst-fsl-plugin-3.0.1-r10.1/gst-fsl-plugins-3.0.1/gstreamer-fsl-0.10.pc Jan 29 22:04:17 how do I tell poky to move that to the right place? Jan 29 22:05:12 JaMa: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/incvartrack2&id=b485e97356ccee2bbf5e5f0bb5461d116277b629 Jan 29 22:05:20 JaMa: My guess is we need that Jan 29 22:05:48 jstashluk: in the do_install, install it to the right place Jan 29 22:06:09 jstashluk: the right place bing ${D}${libdir}/pkgconfig/ Jan 29 22:08:25 RP: ${WORKDIR}/deploy-ipks has the same multiple versions Jan 29 22:08:46 JaMa: it never gets cleaned if the task reruns Jan 29 22:09:05 RP: this commit is to test it and then similar change will be needed for deb/rpm, right? Jan 29 22:09:29 JaMa: correct Jan 29 22:09:45 RP: so in this case it's issue because I've disabled rm_work :) Jan 29 22:10:09 JaMa: That would expose it :) Jan 29 22:10:22 JaMa: its also the PR server since normally you'd only have one version Jan 29 22:11:25 true, do you have 2 more minutes for tricky issue? :) Jan 29 22:11:51 JaMa: I can try Jan 29 22:11:55 http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/035089.html Jan 29 22:12:15 JaMa: I saw that. I can give you a theory Jan 29 22:12:32 JaMa: I think this is one of the few cases where we directly package a directory with a large number of files Jan 29 22:12:56 well, install Jan 29 22:13:23 so you think that the back trace as printed is incorrect and OSError is from somewhere else? Jan 29 22:13:24 JaMa: I think the shear number of files in the root directory are overwhelming the shell command Jan 29 22:13:42 back trace is correct Jan 29 22:13:47 because for that exact tar command it's only one directory with 3 files Jan 29 22:14:20 but size is important, because I was building world-image without this issue after I've pruned oe-core to ~300 recipes Jan 29 22:15:06 which I did just to limit build-time needed for world-image but still really weird Jan 29 22:16:11 also please check that strace from followup e-mail, is it possible that python incorrectly interprets it as OSError with wrong message? Jan 29 22:18:39 JaMa: did you add some debugging? Jan 29 22:18:51 JaMa: I'm wondering how some of those lines get printed in the log Jan 29 22:24:03 JaMa: ah, you mention that at the top Jan 29 22:27:08 JaMa: It looks like something overflows and the trace looks right. I don't know why though, no real ideas. My theories don't stack up with your debug Jan 29 22:28:16 I'll add strace directly to that tar call (now I was using strace only from that shell) Jan 29 22:39:41 JaMa: That mystery close is interesting, that is why you wondered about pseudo? Jan 29 22:40:38 yes and same copytree code executed outside bitbake works fine too Jan 29 22:41:03 so it's not as simple as incorrect python implementation of something Jan 29 22:41:52 and I don't know what excatly pseudo does or can do, so I've included that in suspects Jan 29 22:46:47 JaMa: I wouldn't have expected pseudo to have been active in this case Jan 29 22:46:56 JaMa: that doesn't rule it out mind... Jan 29 22:47:15 JaMa: We probably need to reduce this down to some kind of test case Jan 29 22:48:47 yes world-image is not good one :) Jan 29 22:49:01 even with everything built I still get 5mins in preparing runqueue Jan 29 22:49:34 JaMa: I have tried to optimise that before, sounds like I need to revisit it Jan 29 22:50:18 runqueue? I'm kind of used to it taking a bit longer Jan 29 22:50:27 everything with world takes long :) Jan 29 22:50:41 and lot of space Jan 29 22:51:52 hopefully I'll implement kergoth's comments on world-image.bbclass soon to expose it more, but honestly I'm not sure if I understood him right (waiting for him to show up on IRC) Jan 29 22:52:42 have you seen his reply and can you share some of your thought on that? Jan 29 22:57:40 JaMa: I did see it but I don't remember the details offhand. I do remember agreeing with what he said though :/ Jan 29 23:03:10 I don't understand "map that to packages with pkgdata from the RecipeParsed", if there isn't way to share data between handler invocations Jan 29 23:10:17 is it intentional that bitbake -c devshell places you in the source directory and not the build directory? Jan 29 23:11:00 could someone explain to me what denzil and danny represent, and which branch I should be using? Jan 29 23:16:13 RP: hmm this looks very wrong http://paste.debian.net/230277/ (this is with your patch for deploy-ipk, but also with OEBasicHashLite..) Jan 29 23:16:45 notice message about ERROR message without ERROR message and wrong ERROR count in 2nd Jan 29 23:16:47 blloyd, yes.. the devshell puts you in source.. Jan 29 23:17:00 the idea is to make it easy to edit the source and generate a new patch -- or fix an existing patch --etc.. Jan 29 23:17:19 while you can manually compile/install etc.. that is a secondary use-case Jan 29 23:18:09 fetcher error is similar to #3250 Jan 29 23:19:22 ok, as a secondary use case don't want to change default behavior. But would adding a variable to the shell like RECIPE_BUILD_DIR=xyz be safe, along with a RECIPE_BUILD_SRC=zyx? It would make a cd $RECIPE_BUILD_DIR simple enough for that second use case. Jan 29 23:20:33 I don't know if it's easily availabe to you or not... but if it is, it'd likely be "B" in the environment.. Jan 29 23:20:37 S is the source, B is the build Jan 29 23:20:42 D is the destination (do_install) Jan 29 23:20:50 JaMa: that is very odd. It could find a sstate file but not its corresponding siginfo partner Jan 29 23:21:09 devshell seems to get massively cleaned. Neither of those are defined. Jan 29 23:22:38 I'm willing to do the fixup and patch so those get exported to the shell. Jan 29 23:22:44 for the few things I've worked with that have a differetn S and B.. It's never really been a problem for me though.. Jan 29 23:22:46 cd .. Jan 29 23:22:53 cd build_directory Jan 29 23:24:07 found a little problem with that. :( "inherit externalsrc" Jan 29 23:24:47 ok.. Jan 29 23:31:48 with externalsrc, the B and S directories have NO correlation. Jan 29 23:33:36 no, but the location of B is still the same as if inherit externalsrc was not used.. Jan 29 23:33:46 build/tmp/work/arch/recipe/... Jan 29 23:34:01 I don't doubt it would be useful to export S B and D to the devshell.. Jan 29 23:34:06 just that there are other ways to get to it Jan 29 23:43:43 true, there are other ways. But most get killed by the environment cleanup. :( Then it's manual typing of VERY long paths. Jan 29 23:44:19 (the only part of path the same between source and build in my case which drove this home for me was the leading /) Jan 29 23:47:31 hi, after I build the core-image-basic image and boot from the USB from target h/w, can't use "mount -t nfs xx.xx.xx.xx:/home nfshome" Jan 29 23:47:39 mount: wrong fs type, bad option, bad superblock on xx.xx.xx.xx:/home, Jan 29 23:47:40 missing codepage or helper program, or other error Jan 29 23:47:40 (for several filesystems (e.g. nfs, cifs) you might Jan 29 23:47:40 need a /sbin/mount. helper program) Jan 29 23:47:40 In some cases useful info is found in syslog - try Jan 29 23:47:40 dmesg | tail or so Jan 29 23:48:24 anyways, I'll put a patch together and send it to the mailing list for review once I can commit it to poky-contrib. Jan 29 23:50:00 eddy2win. Did you build nfs support into the image? Jan 29 23:50:06 in the yocto document said , a DISTRO_FEATURE "nfs: NFS client support (for mounting NFS exports on device)" Jan 29 23:50:08 how can I use it? Jan 29 23:50:37 add "DISTRO_FEATURE += nfs" in my local.conf? Jan 29 23:51:43 that should work. Jan 29 23:51:50 thanks Jan 29 23:51:54 but it's DISTRO_FEATURES += Jan 29 23:52:33 ok Jan 29 23:55:23 another question, I have a script "dailyclean.sh", I want it build into the target image in the /home/root directory, how can I do this? Jan 29 23:58:40 why in /home/root and not /usr/bin? But you can do whatever you want. Make a recipe, and in do_install copy it to the ${WHATEVERSYSROOTVARIABLEIS}/home/root. Probably make more sense to copy it to the ${D}/bin instead though. Jan 29 23:59:11 Ok, thanks blloyd Jan 30 00:06:09 I want to change the default "interfaces" file eth0 IP setting, have put a "netbase_5.0.bbappend" in "recipes-bsp/netbase" and "interfaces" in "reciptes-bsp/netbase/netbase/MACHINE" Jan 30 00:06:13 is this correct? Jan 30 00:09:00 is MACHINE is the name of the machine. Jan 30 00:11:17 and the .bbappend needs to prepend the netbase folder. I think it already has privisions to look for ${MACHINE}/interfaces, but haven't looked at netbase_5.0 myself. Jan 30 00:21:38 ok, can anyone point me to an easy way to add to a list via python? Jan 30 00:29:44 Jefro, we should consider some talks for FOSDEM Jan 30 00:31:33 https://fosdem.org/2013/schedule/track/cross_distro/ Jan 30 00:31:47 there seem to be a number of talks that cover things we do well :) Jan 30 01:44:05 hi, I have install the sdk in target , and want to build a kernel module project there, where can I find kernel source files to copy into target's /usr/src/kerenl/xxx Jan 30 01:44:17 kernel.org Jan 30 01:44:18 is that inside tmp/sysroots? Jan 30 01:45:09 if they exist on my local development host, then I can just copy from local lan Jan 30 01:45:52 does RDEPENDS from a recipe enforces the instalation of that package in a core-image? Jan 30 01:45:54 I use yocto-kernel Jan 30 01:46:06 or I need to use the EXTRA_IMAGE_INSTALL variable? Jan 30 01:57:58 eddy2win: try CORE_IMAGE_EXTRA_INSTALL += "linux-yocto-dev" Jan 30 01:59:14 for SDK, may need EXTRA_IMAGE_INSTALL += Jan 30 02:04:06 thanks Jan 30 02:11:28 how can I know what package can be used for "CORE_IMAGE_EXTRA_INSTALL += "?, can I list them on my local dev host? Jan 30 02:29:13 which package contains "ftp" cmd? Jan 30 02:43:56 probably ftp Jan 30 02:44:17 or does busybox provide a ftp command as well **** ENDING LOGGING AT Wed Jan 30 02:59:59 2013