**** BEGIN LOGGING AT Wed Jan 25 02:59:56 2012 Jan 25 08:27:21 hi folks! Jan 25 08:29:53 i finally seen the console light on my h3600. invalid compressed format (err=1) is the lats message before the halt. so it cant find itself or something i assume and trys to unpack some garbage :) Jan 25 09:29:09 has someone an idea why do_fetch fails on a file allready downloaded? linux.kernel26_anoncvs.handhelds.org_K2-6-21-hh20_.tar.gz Jan 25 09:29:18 +done is here. Jan 25 09:29:41 NOTE: package linux-handhelds-2.6-2.6.21-hh20-r26: task do_fetch: Failed Jan 25 09:30:32 i allready fixed that in another oe env i built in i assume but dont know anynmore what i did Jan 25 09:34:31 mhm, somthing, like FORCE_MIRRORS or something like that. i am sure. but i just cant find the variable is set :) Jan 25 09:38:27 SOURCE_MIRROR_URL ?= "http://sources.openembedded.org/" Jan 25 09:38:33 this should be defaulted!!! Jan 25 09:38:49 or at least commented but in the local.conf Jan 25 09:43:41 ok, didnt help eithere :( Jan 25 09:43:44 wtf Jan 25 09:45:06 this is just strange. really no one an idea to force the do fetch to try with the mirror. or take it form downloads/ where it allready is? Jan 25 09:46:28 it doesnt even try to use the mirror, just the long dead handhelds.org cvs Jan 25 09:49:48 ok, i just modifie the bitbake file that points to that cvs then. looking threw the +1k variables used in OE does make me want to throw up Jan 25 09:56:48 SRC_URI = "${SOURCE_MIRROR_URL} doenst make it much better. i am loving it. Jan 25 09:56:57 hello i create a .ko file after bitbake virtual/kernel Jan 25 09:57:09 how to know if the .ko is inside the kernel ? Jan 25 09:57:35 good morning Jan 25 09:57:56 kay: did you build packages? Jan 25 09:58:24 kay: just look into the coresponding ipkg or whatewver packageformat you use Jan 25 09:58:58 ah i dunno how to explain Jan 25 09:59:35 kay: is there a kernel-modules whatever package beyon your build/tmp.../deploy/ directory ? Jan 25 10:00:00 er nope Jan 25 10:00:51 kay: what did you do? :) Jan 25 10:01:03 do u have time to listen to me? Jan 25 10:01:14 i am currently very lost in driver development really new to it Jan 25 10:01:15 kay: shure. Jan 25 10:01:25 i am a custom arm board Jan 25 10:01:40 i am currently developing a led driver for it Jan 25 10:01:50 i have the driver code Jan 25 10:02:02 kay__: i have no idea about that driver thingy. but i built some modules, packaged some packages in the past. not oe related, but its all the same :) Jan 25 10:02:03 its a custom driver Jan 25 10:02:33 what i am trying to ask is whether i did it correctly Jan 25 10:02:35 kay: what is you output format? a tarball? jffs2 image or what? Jan 25 10:02:49 its a intiramfs Jan 25 10:03:00 kay: well, you neednt to ask me if you could look for yourself Jan 25 10:03:23 yea i couldnt find it Jan 25 10:03:34 thats why wondering if anyone is here maybe can enlighten me Jan 25 10:04:28 kay__: well, if you cant find the initramdisk you may have not built in, and then there of course will not be "any" not just the one you are after, modules be in there :) Jan 25 10:05:08 maybe i explained further Jan 25 10:05:15 kay__: usually, this should end up in build/tmp.../deploy/images/ Jan 25 10:06:11 i have .ko inside my /work/.../drivers Jan 25 10:06:41 u know how to load the .ko inside my kernel? Jan 25 10:06:51 is there a way to check? Jan 25 10:08:14 kay__: what did you do? :) Jan 25 10:08:54 i insert my custom headers into my include Jan 25 10:09:07 then insert my driver code into my /drivers Jan 25 10:09:08 kay__: what target did you build. ? (bb) what options/commands(-c) did you issue if any? besides that you build a kernel i dont understand much Jan 25 10:09:22 bitbake virtual/kernel Jan 25 10:09:29 after i done all those Jan 25 10:09:34 i run virtual/kernel Jan 25 10:09:44 then a .ko file appear inside my /drivers Jan 25 10:09:59 .ko is a kernel module right Jan 25 10:10:04 kay: yes :) Jan 25 10:10:09 if yes then how to insert my module into my kernel Jan 25 10:10:19 kay: insmod or modprobe :) Jan 25 10:10:33 ah ok Jan 25 10:10:49 kay: sorry, i didnt understand what you ment in the first place. i havent thought that you never loaded a module :) Jan 25 10:11:10 so means even tho .ko is created it doesnt mean the module is loaded? Jan 25 10:11:44 ah no need sorry should be me saying sorry asking so many questions Jan 25 10:11:50 kay: http://tldp.org/HOWTO/Module-HOWTO/ Jan 25 10:12:18 kay: no problem :) but its very well documented. unlike the openembedded thingys :) Jan 25 10:12:44 yea i need to do everything using openembedded Jan 25 10:12:51 ok thanks i go research further Jan 25 10:12:53 thanks alot Jan 25 10:12:58 kay: have fun :) Jan 25 10:34:07 Hi. Can somebody explain criteria for package inclusion to OE-Core for me? Our customer requires to submit some recipes to Yocto/OE-core. Some of them were imported from the meta-OE and I don't know if such patches allowed. Jan 25 10:42:42 ant_work: hi Jan 25 10:43:36 good morning Jan 25 10:44:30 JaMa: I've checked and I don't have any kexecboot binary on host Jan 25 10:46:44 I know what causes it.. more info after lunch Jan 25 10:46:55 in short touch of /init :) Jan 25 10:47:03 heh Jan 25 10:47:19 I have a patch about that cpio images. Will send this evening Jan 25 10:48:14 hi Jan 25 10:48:28 i've been trying to customize a kernel Jan 25 10:48:52 running bitbake virtual/kernel -c configure will create a /git dir, with a bunch of source code in it Jan 25 10:49:25 i've modified things in there, but after running Jan 25 10:49:25 bitbake virtual/kernel Jan 25 10:49:25 everything gets deleted Jan 25 10:49:42 how can i make permanent changes? where should i edit? Jan 25 10:49:49 JaMa: I've added a function with a common check [ ! -L ${IMAGE_ROOTFS}/init ] before touch Jan 25 10:50:01 which at least let us build Jan 25 10:50:25 i haven't found documentation for starting with this. any tips? Jan 25 10:50:39 (i found some, but it did not explain these type of things) Jan 25 10:50:55 JaMa: i stepped over this too :) my quick hack was to copy kexecboot to /usb/bin on my dev system, so the link worked again Jan 25 10:51:20 rlrosa: once you've done menuconfig you just have to copy the resulting .config (or even the shrinked defconfig) Jan 25 10:51:48 in the recipe and provide that as defconfig Jan 25 10:52:33 JaMa: also kexecboot must be writeable by the user you build with. Jan 25 10:53:34 ant_work: ok, that would keep the kernel tweaks. i also want to modify a kernel module, to change i2c speed. this involves changing a couple lines in the corresponding code. how can i keep these type of changes? (is it correct to modify the code that shows up in tmp/....../git ? Jan 25 10:54:00 yes, you have to provide a diff and create a patch with that? Jan 25 10:54:44 as with defconfig, the patch must reside in the metadata Jan 25 10:55:02 more on that pls... Jan 25 10:55:31 look e.g. at http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-3.1 Jan 25 10:55:42 (i know how to generate a patch with git, not sure about the other part) Jan 25 10:55:44 ok Jan 25 10:56:19 JaMa: but a better fix would be to remove the '/init -> /usr/bin/kexecboot' link and set it to usr/bin/kexecboot Jan 25 10:56:39 ipaqlor: can you pls explain me what's happening? Jan 25 10:57:24 ant_work: well i built kexec 2 days ago, and it failed with the touch to /init error you mentioned. Jan 25 10:57:43 this is another story, is a change to image_types.bbclass Jan 25 10:57:55 I'm testing a patch as pointed above Jan 25 10:58:25 ant_work: ok, sorry, thought you nedded a fix :) Jan 25 10:58:36 the problem is that touch fails against symlinks Jan 25 10:58:54 modern touch have a '-h' option...but not in all distro Jan 25 10:59:05 ant_work: yes, if the builduser has no rights to touch the files linked by the link :) Jan 25 10:59:19 no, it's not a right problem Jan 25 10:59:24 is touch itself Jan 25 10:59:29 ant_work: at least thats what was happening here, so i made the one "wrong" link touchable :) Jan 25 11:00:33 ant_work: well, it worked here by the means i said. Jan 25 11:01:05 ant_work: a, the -h, yes, this is another thing. you are right. my ubuntu has no -h for example :) Jan 25 11:01:35 [ ! -L ${IMAGE_ROOTFS}/init ] seems having been accepted Jan 25 11:03:24 ant_work: do you know where the .config is stored? the kernel module i want to modify is in arch/arm/somefile.c. where should i put the patch? (i'm building angstrom for beagleboard (omap3)) Jan 25 11:06:12 rlrosa1: the patch should go in the recipe directory, maybe in a machine specific subdir (if it's only for one) Jan 25 11:06:50 and need to be added to SRC_URI in some way Jan 25 11:07:47 check any other kernel recipe with patches Jan 25 11:08:24 brb Jan 25 11:08:41 ant_work: ok, thanks Jan 25 11:13:05 ant_work: i found this meta-ti/recipes-kernel/linux/linux-omap-psp-2.6.32/beagleboard-xmc/ Jan 25 11:13:05 there are a bunch of patches in there, but they look auto-generated. if i add a patch in there, how do i tell bitbake to care about it? Jan 25 11:15:02 cu later Jan 25 11:16:28 morning all Jan 25 11:17:17 hi pb_ Jan 25 11:20:29 ant_work: ok, thanks Jan 25 11:25:48 ant_work: i have to leave now, i'll keep working on this later. your tips where very useful, pointed me in *some* direction (infinitely better than being completely lost) :) thank! Jan 25 11:46:57 hi i wondering any tried mounting nfs over a vmware? Jan 25 11:52:13 hi florian Jan 25 11:53:38 bah ..earthquake psycosis here Jan 25 12:07:23 it was only a 5.1 Jan 25 12:11:34 jekhor: broadly, if it's something that almost anyone building an embledded linux system would need and it's not machine-specific, it can be considered Jan 25 12:12:15 jekhor: what's the recipe? Jan 25 12:15:33 bluelightning, I sent patch series to oe-devel. Jan 25 12:16:40 jekhor: they should be sent to oe-core ML Jan 25 12:16:45 netcat, ebtables, pptp-linux Jan 25 12:16:51 hrrr.... Jan 25 12:17:16 and oe-classic is not meta-oe Jan 25 12:17:20 fix commit messages Jan 25 12:17:41 and when it's applied in oe-core send patches removing them in meta-oe Jan 25 12:18:00 If the recipes are already in meta-oe, is there any advantage to moving them? Jan 25 12:18:14 JaMa, this packages were imported from OE-classic, I don't send imported from meta-oe yet. Jan 25 12:18:21 apropos the patches themselves, note that LICENSE = "GPL" is no good. Jan 25 12:18:59 I thought that was a QA error actually, but I guess not. Jan 25 12:19:07 jekhor: JaMa: I suspect many of these are more suitable for meta-oe rather than oe-core Jan 25 12:19:18 jekhor: in fact libnfnetlink and postgres are already in meta-oe Jan 25 12:19:30 although your postgres is newer Jan 25 12:19:52 jekhor: ie postgresql is in meta-oe Jan 25 12:20:04 heh ;) Jan 25 12:20:47 I meshed in new OE-related things... Jan 25 12:22:12 JaMa: how is your issue related to the changes to image_types.bbclass? Jan 25 12:22:45 bluelightning, maybe, but I cannot find strong description of OE-core and meta-OE package inclusion criteria. Jan 25 12:22:50 ant_work: touch /init -> /usr/bin/kexecboot creates /usr/bin/kexecboot Jan 25 12:23:48 hm.. it's $D/init Jan 25 12:24:07 this should run on device then, isn't? Jan 25 12:24:40 jekhor: I appreciate this is not well-documented at the moment, sorry about that Jan 25 12:24:46 jekhor: agreed, there doesn't appear to be any well-articulated policy on this Jan 25 12:24:55 JaMa: isn't an exit status 1 needed for that? Jan 25 12:25:56 ant_work: no it's in run.do_rootfs so it's executed in do_rootfs :) Jan 25 12:26:30 ok, I need to better understand how you decide postinst is run on do_rotfs or on device :) Jan 25 12:26:34 ant_work: test for $D is usefull in postinst Jan 25 12:26:50 but this is the actual do_rootfs script which is executed only while doing rootfs Jan 25 12:26:53 yes, you showed me yesterday the example Jan 25 12:27:22 but example of postinst Jan 25 12:29:04 so why do you end up with $D = "" ? Jan 25 12:29:39 ahh... Jan 25 12:29:41 no it's right $D/init Jan 25 12:29:41 sorry Jan 25 12:29:46 touch Jan 25 12:29:48 but it points to /usr/bin/kexecboot Jan 25 12:30:26 so it touches right init in rootfs directory ($D), but creates /usr/bin/kexecboot in system /usr/bin Jan 25 12:30:53 not touching links (like you proposed) or using relative path to kexecboot will do Jan 25 12:31:27 or "touch -h", I guess Jan 25 12:31:31 I still haven't been to reprouce when I modified the cpio code Jan 25 12:31:36 need to check whether that is in POSIX though Jan 25 12:31:44 pb_: yes, using touch -h was painless Jan 25 12:32:34 ah, aout conformance Jan 25 12:32:45 pb_ is 'type' posix? Jan 25 12:32:56 I mean, there are two lines with: Jan 25 12:32:59 MAGE_CMD_cpio.xz = "type cpio >/dev/null; Jan 25 12:33:38 yes Jan 25 12:33:42 strangely for the _CPIO and CPIO.gz this 'type' is not needed Jan 25 12:33:55 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html#tag_20_136 Jan 25 12:34:02 only for the .xz and .lzma? no, too strange. Jan 25 12:34:38 as far I as understand this is a try to 'ignore' an eventual cpio command in path Jan 25 12:34:56 mm, that does seem weird Jan 25 12:34:58 who added that? Jan 25 12:35:09 comes from oe-classic, is very old Jan 25 12:35:27 again, only for the two latest cpio's Jan 25 12:35:52 at first I thought it's a bashism but isn't Jan 25 12:37:51 btw why is that touch needed? Jan 25 12:39:18 Darren added it in order to make the initramfs bootables (there must be an init unless you specify a rdinit iirc) Jan 25 12:39:34 his cpio's were missing it Jan 25 12:39:51 why didn't he add it to his cpio's? Jan 25 12:40:00 he..I tried :) Jan 25 12:40:14 I mean, is empty file really better then nothing? Jan 25 12:40:41 error about missing init is imho better then error about not executable init Jan 25 12:40:50 I can agree Jan 25 12:41:08 I tried to oppose some reasons but patch was committed Jan 25 12:41:20 so now we have to add some guards :/ Jan 25 12:42:39 amazing Jan 25 12:44:31 iirc if init fails control goes to /bin/sh Jan 25 12:45:07 "If rootfs does not contain an init program after the embedded cpio Jan 25 12:45:07 archive is extracted into it, the kernel will fall through to the older code Jan 25 12:45:07 to locate and mount a root partition, then exec some variant of /sbin/init Jan 25 12:45:07 out of that." Jan 25 13:25:28 i was still not able to boot anything but the handhelds.org images. not with 2.6.21 neithere with 2.6.29 kernel source. the console output stops after kernel decompression (done, booting the kerne.) Jan 25 13:31:10 hurgs, some 199 tasks to do, shouldnt hat git pulled oe-core :) Jan 25 13:35:39 as defconfig for the kernels i use org.handhelds.familiar/packages/linux/handhelds-sa-2.4.19-rmk6-pxa1-hh36.12/defconfig-ipaqsa as i havent found the config the kernel withing the 0.8.4 familiar images for the h3600 has been built Jan 25 13:35:49 ipaqlor: so, I guess you've at least verified it's not the kernel version Jan 25 13:36:07 bluelightning: i have verified that its any kernel i build. Jan 25 13:36:11 right Jan 25 13:36:31 FWIW my h3760 and serial cradle should be arriving any day now, I'll let you know what I find Jan 25 13:36:56 bluelightning: nice. you gonna have a lot of fun *g* Jan 25 13:37:18 <- that was that evil grin you dont see in direct sunlight Jan 25 13:37:19 well, at least I might be able to shed more light on the matter Jan 25 13:37:29 heh, I found my old h3600 yesterday. let me know if you get it working. Jan 25 13:37:50 pb_: sure :) Jan 25 13:37:55 bluelightning: well right now id say the buildsystem is completly broken for that platform :) Jan 25 13:38:12 and a bunch of other ipaqs for that matter. does meta-handheld have support for the newer ones? Jan 25 13:38:21 well, "newer". I guess none of them are all that new anymore. Jan 25 13:40:03 was there ever a working buildsystem? thats another question i am asking myself. since i never built it from source when it was "brand new tm" maybe it allways was a mess with many manual steps get it going? Jan 25 13:40:42 for familiar? no, there was never a properly integrated build system. Jan 25 13:41:11 familiar up to 0.7.x was semi-manually assembled. I think 0.8 was going to be built with oe but the wheels came off the handhelds.org wagon at about that time. Jan 25 13:41:14 pb_: i see. this clears up things a bit. Jan 25 13:41:33 pb_: actually it makes everything much clearer. Jan 25 13:42:47 openzaurus did have a buildroot-based system at about the same time so they were, in that sense, rather more advanced. Jan 25 13:43:12 the original concept for familiar was that it would be based on a debian-style model where individual developers built and uploaded binary packages into the feed repositories. Jan 25 13:43:25 (as opposed to doing a monolithic all-in-one build from a central source repository) Jan 25 13:43:31 ipaqlor: we did build working images for some machines with OE. I remember, I was there. :) Jan 25 13:43:41 ipaqlor: that was a long time ago though Jan 25 13:44:01 bluelightning: maybe you mix it up with some other machine :) Jan 25 13:44:31 ipaqlor: no, 0.8.4 was built with OE. (well, kind of a fork thereof, but it was still OE). Jan 25 13:45:17 bluelightning: well, with thig git magic. cant i just rollback to that date with openembedded and do that again? ;) Jan 25 13:47:26 bluelightning: wouldnt that be the point in the "backup" feature you mentioned? Jan 25 13:47:42 ipaqlor: the issue would be which date/revision to pick Jan 25 13:47:57 bluelightning: so the human factor strikes again Jan 25 13:48:15 ipaqlor: I mean, if you really wanted to reproduce familiar you should probably grab their fork of OE... of course that's a bit hard now that hh.org is gone Jan 25 13:48:26 hahahaha Jan 25 13:48:38 yeah, i deserve it, i know :) Jan 25 13:49:06 so, my suggestion if you aren't able to debug the issue directly yourself is to just be patient Jan 25 13:49:25 I'm on it, and Dmitry will hopefully be able to get a more up-to-date patchset Jan 25 13:49:45 but it could be that we hit a wall (of available time or knowledge), in which case you're on your own Jan 25 13:50:04 anyhows, it would have spared me godd 30 hours fiddeling, donwloading, compiling, with oe related stuff if someone in here would have told me that its not proven to be even possible to build for h3600 Jan 25 13:50:24 earlier :) Jan 25 13:50:56 er, perhaps I wasn't clear but I did mention you were resurrecting a machine that nobody had built for recently Jan 25 13:51:21 in any case, all is not lost, you just can't have something working now Jan 25 13:51:28 unless you can debug it yourself Jan 25 13:52:54 maintaining these old machines is quite a lot of work... Jan 25 13:53:59 I warmly suggest you to concentrate work on kernel Jan 25 13:54:15 having 3.x then userland is a breeze to fix Jan 25 13:54:20 today Jan 25 13:55:11 as for Zaurus, it would have been impossible to keep up with monthly udev updates and such changes Jan 25 13:56:28 ant_work: I hope Dmitry (Artamonow) will be able to help there Jan 25 13:56:30 well, but you could rollback to a piint where it built? or not Jan 25 13:56:55 ipaqlor: maybe, but then you may hit other problems Jan 25 13:56:58 i see no point in having the newest whatnots not working for a plattform Jan 25 13:57:30 ipaqlor: the issue being, since nobody ever did a familiar release for h3600 from OE directly (i.e. they used a fork) there's no specific point in the OE tree that is guaranteed to work for that machine Jan 25 13:57:33 i would mark "versions" that build for a plattform. Jan 25 13:57:52 ipaqlor: that's leaving aside any issues of host incompatibility in the intervening years Jan 25 13:57:58 like with a dummy commitmessage "zaurus support stops here" Jan 25 13:58:15 ipaqlor: nobody made a conscious decision to stop supporting these machines Jan 25 13:58:58 ipaqlor: people just drifted away... this is what happens with hobby projects, we didn't get paid to work on linux-on-iPAQs... Jan 25 13:58:59 bluelightning: no, but i would asume it was supported someday. which cant be proven right now. Jan 25 13:59:24 the proof is in the image, but the image was not produced from the recipes that we currently have access to Jan 25 13:59:37 :) Jan 25 13:59:52 ipaqlor: imagine I lost many months with kernel not booting on 32MB Zaurus.... xz decompression was too extreme and needed more RAM. Just this... Jan 25 14:01:38 ant_work: nice. i am looking forward to something like that. until now i have just bitbaked crap toigether instead of getting a glimpse into what the kernel dosenst like here. Jan 25 14:02:56 you should start with a silly initramfs and see it boot Jan 25 14:03:01 e.g. kexecboot Jan 25 14:03:08 then pass to userland Jan 25 14:03:38 the advantage being you need a minimal kernel, probably almost patch-less Jan 25 14:04:19 ant_work: well, a silly kernel that outputs something to console or display is the thing i am missing right now. so im with the kernel Jan 25 14:04:25 ideally you'd want a serialcable ;) Jan 25 14:04:59 using embedded initramfs youtake out one variable (rootfs) Jan 25 14:05:00 ant_work: guess what, i got one. since then i see the messages i posted above. Jan 25 14:05:19 hm, anyone an idea on how to fix this: I use inherit rm_work, my deliverable is a kernel with an initrd rootfs in it, but each time I restart the build it tries to generate the rootfs, which in then fails because I use a static device table which is removed before Jan 25 14:05:23 btw this is with oe classic Jan 25 14:05:35 ant_work: took me 1 1/2 hour to pickup and solder a db9 onto it, so that was more or less fun, but no progress through seralcable by now :) Jan 25 14:05:59 ipaqlor: enable full debug and earlyprintk Jan 25 14:06:09 you'll see something ;) Jan 25 14:06:22 Uncompressing Linux................................................................................... done, booting the kerne. Jan 25 14:06:49 ok, I was stuck before ;) Jan 25 14:06:54 last words. but its good, my firsttry didnt even managed to decompress ;) Jan 25 14:08:46 toolwise i think i am not missing much. maybe a jtag adapter. but i have a parallelport so this can be done too Jan 25 14:08:53 ah, well. if you have a serial cable then it's just a case of debugging why the kernel doesn't start. Jan 25 14:08:59 shouldn't need jtag or anything for that. Jan 25 14:09:03 pb_: smarty :) Jan 25 14:09:46 jtag only necessary if you have a severely broken bootloader, which clearly you don't here. Jan 25 14:09:50 pb_: well, lets see :) Jan 25 14:09:56 pb_: the things to come Jan 25 14:10:21 pb_: some broken mtd support, some wrong address, some bricked ipaq Jan 25 14:10:54 it's fairly hard to do. iirc, the bootldr leaves itself protected in flash, so you have to try moderately hard to ovverwrite it. Jan 25 14:11:10 hmm wondering any know what are the possible reason why i can tftp to my development pc with my arm board but i cant nfs Jan 25 14:11:19 I don't think I ever heard of anybody bricking an ipaq that way before. Jan 25 14:11:40 pb_: i am good with breaking things Jan 25 14:12:08 well, I'm sure you could do it if you try, but as I say it is hard to do it accidentally. Jan 25 14:13:27 Running task 162 of 199 ... Jan 25 14:13:29 argl Jan 25 14:13:45 just wanted to do a -c menuconfig.... Jan 25 14:15:34 i should not git pull oe-core i should not git pull oe-core i should not git pull oe-core :) Jan 25 14:18:49 kay__: is teh client allowed to access the share? ++ is exports setup properly? Jan 25 14:19:07 ya my board should be set up correct Jan 25 14:19:18 and my development pc exports set up correctly too :( Jan 25 14:19:58 kay__: so what does your nfsserver log? Jan 25 14:20:00 well, what goes wrong? Jan 25 14:20:16 is it because i am using vmware? Jan 25 14:20:46 i think its a network problem rather than nfs problem Jan 25 14:21:04 mount: RPC: Unable to send; errno = Network is unreachable Jan 25 14:24:26 kay__: have you verified that the nfsserver is working? Jan 25 14:24:41 how to verified if it is work Jan 25 14:24:52 i just start and restart Jan 25 14:24:55 looks fine Jan 25 14:25:07 that error wouldn't result from a non-working nfs server. Jan 25 14:25:17 where is the client getting its IP and routing data from, dhcp? Jan 25 14:25:42 if you're using kernel ip-autoconf, what does it print? Jan 25 14:25:46 kay: got portmap running? :) Jan 25 14:26:08 pb_: maybe Jan 25 14:26:39 pb?: but if kay__ has tftp working its no simple network issue either. Jan 25 14:26:44 maybe what? Jan 25 14:26:53 well, "network is unreachable" is a fairly specific diagnostic Jan 25 14:27:07 pb_: shure, but tftp is working too. Jan 25 14:27:07 if portmap wasn't running then you would get connection refused. Jan 25 14:27:15 tftp is working in uboot Jan 25 14:27:19 tftp is working with, presumably, a different client Jan 25 14:27:19 ok Jan 25 14:27:22 :) Jan 25 14:27:29 it sounds like he is using tftp from his bootloader and nfs from the kernel, or some such Jan 25 14:27:38 yes, ok, been there today Jan 25 14:27:43 ill communication Jan 25 14:27:44 but after i load my kernel into my board then nfs into my pc its not working Jan 25 14:27:45 and, if I had to guess, I would say that the kernel is getting its network settings wrong for some reason Jan 25 14:27:46 i stop here Jan 25 14:28:47 kay__: sorry, dont want to reenact the modprobe $somemodule incident... :) Jan 25 14:28:58 haha ipad its ok Jan 25 14:29:03 u are trying to help :) Jan 25 14:29:16 thats not helping much. i stop that from now on ;) Jan 25 14:29:21 appreciate it Jan 25 14:50:06 Is there any way to clean / rebuild userland sources without rebuilding cross compilers? Jan 25 15:12:56 So I tried making a graph with the graphviz output. I think I need a bigger PC. :) Jan 25 15:13:26 fullstop: hehehe :) which target? :) Jan 25 15:13:35 at91sam9 Jan 25 15:13:52 fullstop: sorry, i ment what recipe? Jan 25 15:13:58 Really, though, I'm just trying to figure out why it is building cairo, gtk etc. Jan 25 15:14:14 That was for my image recipe Jan 25 15:14:28 fullstop: ic. Jan 25 15:14:28 I am pretty sure that I've disabled everything which might require X or a gui.. Jan 25 15:14:37 so I turned to graphviz Jan 25 15:14:37 and Jan 25 15:14:40 wow Jan 25 15:14:58 I have a love/hate relationship with oe right now. Jan 25 15:15:18 fullstop: yeah, i guess many :) Jan 25 15:15:40 I did a cleanall.. which did exactly that. Purged cross compilers, the works. Jan 25 15:15:45 fullstop: you're better off using the depexp ui or reading the .dot files manually Jan 25 15:15:55 than trying to create a graph from it Jan 25 15:15:59 it'll be too large to make sense of anyway Jan 25 15:16:05 bitbake -u depexp -g foo Jan 25 15:16:14 X11 interface to browsing the dependencies Jan 25 15:16:14 I didn't expect the graph to be that large. :) Let me do the depexp once this build fails. Jan 25 15:17:07 kergoth`: I changed some of my preferred versions in my config, but it still tries to use the newer ones.. can I clean my sources without destroying my toolchain? Jan 25 15:18:16 not sure you're trying to accomplish there. if it's not using your preferred version, then something else is going on, cleaning won't do anything Jan 25 15:18:31 well, it depends on the behavior. what do you mean by 'tries to use the newer ones'? Jan 25 15:19:46 I mean that I build, let's say, cairo.. and it's trying to use a newer version of pixman even though I've told it to use an older version. Jan 25 15:20:03 and I'm certain that if I blow everything away that it will do the right thing. Jan 25 15:20:22 thats highly unlikely. bitbake doesn't "remember" preferences. if it's not building your preferred version, you have soemthing else going on Jan 25 15:20:28 run bitbake -e | grep PREFERRED_VERSION_foo= Jan 25 15:20:31 make sure its really what you think it is. Jan 25 15:20:44 its far more likely that your distro/machine is unconditionally setting it, blowing away your local preference Jan 25 15:20:56 mhm, i a searching for a kerneldebugging howto. like the most desireable debugging options, bootparameter like loglevel... such things, anyon a link? Jan 25 15:20:58 bitbake -s is invaluable for checking assumptions Jan 25 15:21:12 Let me look into it a bit. I'm really not doing anything unusual. Jan 25 15:22:16 More to the point, is there a way to clean everything except for my toolchain? Jan 25 15:22:31 you can clean a single recipe, or you can clean everything. that's it. Jan 25 15:22:38 :-( Jan 25 15:22:40 but that doesn't necessarily mean you have to rebuild the toolchain Jan 25 15:22:47 ? Jan 25 15:22:51 is this oe classic or oe-core/poky? Jan 25 15:23:08 angstrom/oe Jan 25 15:23:14 insufficient information. Jan 25 15:23:18 which I assume is classic :) Jan 25 15:23:21 angstrom with oe classic, or angstrom with oe-core? Jan 25 15:23:27 the angstrom scripts have branches to support both Jan 25 15:23:27 How can I tell? Jan 25 15:23:39 look in front of you. is there an openembedded directory, or an oe-core directory? Jan 25 16:07:45 now this is intersting. nand or mtd isnt enabled in hh for ages :) familiar-h63xx-build-HEAD-48747b0/org.handhelds.familiar the only thing i found. was running from cfcard :) i guess. Jan 25 16:08:30 and all the working old kernels i tried have no /proc/config.gz :) ... Jan 25 16:08:54 damn them every bit counters Jan 25 16:09:56 ipaqlor: so, if my memory serves, at one point angstrom developers decided they had had enough of people bricking their devices and decided to only support booting from CF/SD Jan 25 16:10:41 (well, I guess not so much bricking but being incapable of restoring windows CE after flashing linux) Jan 25 16:11:09 it wasn't a decision I particularly liked but I could at least understand wanting to avoid the support hassles Jan 25 16:11:56 AFAIR all it meant though was disabling jffs2 support in the kernel defconfig Jan 25 16:13:18 bluelightning: ic. Jan 25 16:14:36 someone doesnt like ipaqs Jan 25 16:15:13 even google doesnt like it, and exchanges it with ipod at will Jan 25 16:17:17 s/doesnt like it/optimized it out/ Jan 25 16:20:18 yippie!!! http://git.brokenpipe.de/cgi-bin/gitweb.cgi?p=stesie/ipaq-bitbake;a=blob;f=org.handhelds.familiar/packages/linux/handhelds-pxa-2.6-2.6.17/defconfig;h=e85ea1e1979044dc37e1a3fc728192b79c9872dd;hb=32afc36bc434584cd24e57f645fe170ed4d521cf Jan 25 16:26:37 ipaqlor: so that's a config for hx4700, that's not going to help you much Jan 25 16:27:08 interesting to see someone has a copy of the org.handhelds.familiar tree up though Jan 25 16:29:04 fwiw, http://pbcl.net/~pb/ipaqsa is the h3600 config file that I happen to have lying around in my home directory Jan 25 16:29:51 I think this is probably fairly close to what we had in familiar. Jan 25 16:31:31 pb_: thanks Jan 25 16:33:01 o no, what have i done. everything compiles again :(((( Jan 25 16:33:10 800 tasks Jan 25 16:33:15 i gone shoot myself Jan 25 16:33:46 what did you do? Jan 25 16:35:23 ok, i did 2 things, forst i did a git update, then i did a cleanall virtual/kernel, then a git clone git://git.openembedded.org/meta-handheld Jan 25 16:36:04 now i did a menuconfig, and now a buildall. and it seems to build the whole toolchain again Jan 25 16:36:41 and also oe-core pull Jan 25 16:38:03 was it trhe cleanall or the pull, i have no idea Jan 25 16:38:21 but this is hard Jan 25 16:38:46 hard to understand. Jan 25 16:38:52 wouldn't have been the cleanall Jan 25 16:39:10 what got updated when you did the oe-core pull? Jan 25 16:39:13 the cleanall on virtual kernl removed the wohle rest? Jan 25 16:39:22 i dont remember Jan 25 16:39:26 cleanall does a clean + source removal on a single recipe, afaik, thats it Jan 25 16:39:32 yes Jan 25 16:39:41 so no, that wouldn't have touched anything else Jan 25 16:39:52 ok, nice :) Jan 25 16:40:09 i guess this has not happened to anyone before me too? Jan 25 16:40:29 i must be a real specialist. Jan 25 16:41:04 ipaqlor: if recipes relating to the toolchain got updated, you bet they would need to be rebuilt... Jan 25 16:41:13 but i need more cpu cores to carry on like that. Jan 25 16:41:31 how do you do that? Jan 25 16:42:58 ipaqlor: I'm saying, if you did a git pull of oe-core and as a result updates to toolchain recipes were pulled down, then naturally bitbake would be building the new versions Jan 25 16:43:07 bluelightning: do you have your own parallel uinverse git repo and just check in and out what you like? Jan 25 16:43:18 ipaqlor: er, no... Jan 25 16:43:50 bluelightning: so what do you do if you would bake something in 5 minutes that doesnt get baked during the next hours ? Jan 25 16:44:01 i mean, how is the workflow ? Jan 25 16:44:02 if you don't want to risk having to build things, don't update. Jan 25 16:44:06 i am lost Jan 25 16:44:12 ipaqlor: what he said ^ Jan 25 16:44:20 kergoth: ok, so not updating is the way to go. Jan 25 16:44:25 right now you have nothing to gain by updating, no Jan 25 16:44:42 i update all the time, but 90% of the time i also don't care if my build takes an extra 20 minutes Jan 25 16:44:47 it depends on your requirements Jan 25 16:44:55 yeah, hadnt thought there where such big strutural changes during the last 3 days Jan 25 16:45:54 kergoth: a build environment i can build something i can use with is my only requirement. i am not there yet. Jan 25 16:46:37 but the buildenvironment itself is kind of kicking me in the ass all over again Jan 25 16:46:54 you're the one who pulled in the updates. if you don't want it to change, don't change it. it's that simple Jan 25 16:47:15 yes!, compiling binutils native for the 10th time or something within a week. i am the buildking! Jan 25 16:47:31 kergoth: well, now i am smarter :) Jan 25 16:49:18 can i somehow "pin" something in oe to make it not rebuilt ever ? Jan 25 16:50:00 I've made a recipe that makes an .so that is used by an application in my image. How can I make sure the .so is included in the image? I tried using RDEPENDS in the recipy, but that doesn work. Jan 25 16:50:07 also whats the difference between cleanall and clean ? Jan 25 16:53:21 mhm, ok, ill use fs snapshots. Jan 25 16:54:15 message to self: allways backup before git pull Jan 25 16:55:57 ipaqlor: you don't have to Jan 25 16:56:29 git is an scm, you can always back up to an old version Jan 25 16:56:38 ipaqlor: I would suggest a quick tutorial in how to use git, it's well worthwhile Jan 25 16:57:21 bluelightning: but i allready bitbaked Jan 25 16:58:10 bluelightning: you say i can say rollback. do a bitbake and nothing happened? that would be to good to be true. eg. i have to see to believe. Jan 25 16:59:21 hello? Jan 25 16:59:46 yes, you'd be able to do that. as bluelightning told you, read up on git Jan 25 17:00:17 yes, i dont believe it. we will see. Jan 25 17:01:00 not believing the people you're coming to for help isn't exactly logical. if you didn't think the folks in here knew better than you, you wouldn't be here Jan 25 17:02:25 kergoth: well, it isnt like i havent been told many things here that i by simple trial and error have proven to not be true. so what. in this case its not about what git can or cant do. Jan 25 17:03:07 quite right, in this case it's about your ignorance of what bitbake and oe do Jan 25 17:04:22 kergoth: it eats up massive amounts of cpu cycles and humand brainhours for shure :) Jan 25 17:09:33 yeah, we need to work on our docs some more Jan 25 17:15:10 the basic conzept in 24 lines would be a fair enough start for me. Jan 25 17:40:29 git reset --hard ORIG_HEAD may not have been the thing to do Jan 25 17:46:20 i am now at commit ac162df288f6d8f68c1764fad0ab2d33b9cee281 , bitbake core-image-minimal fails with: Jan 25 17:46:20 ERROR: No recipes available for: Jan 25 17:46:20 /DEVEL/oe-core/meta-openembedded/meta-oe/recipes-graphics/xorg-lib/pixman_0.24.2.bbappend Jan 25 17:46:20 ERROR: Command execution failed: Exited with 1 Jan 25 17:46:45 so, your meta-oe tree doesn't match your oe-core. Jan 25 17:46:57 If you are just trying to build a basic system then the easiest thing is probably to just turn off meta-oe. Jan 25 17:47:16 pb_: ok Jan 25 17:49:28 ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /DEVEL/oe-core/meta-handheld::/DEVEL/oe-core/meta-openembedded/meta-oe:/DEVEL/oe-core/meta-openembedded/meta-efl Jan 25 17:49:49 what have i done now Jan 25 17:49:57 nested your layers? Jan 25 17:50:20 usually better to have meta-openembedded outside oe-core Jan 25 17:50:32 muriani: i nested my what? Jan 25 17:50:44 your meta layers Jan 25 17:51:02 muriani: i did a git pull, and now a git reset, and then i removed meta-oe like pb suggested, and now this Jan 25 17:51:48 I think you may need to restart and re-pull stuff... Jan 25 17:51:54 hahahaha Jan 25 17:51:56 er, no Jan 25 17:51:57 hold on Jan 25 17:52:02 you've removed meta Jan 25 17:52:03 HARHARHAR Jan 25 17:52:12 INSANE Jan 25 17:52:13 put that back Jan 25 17:52:15 and remove meta-oe Jan 25 17:52:38 if that's what you want to do Jan 25 17:52:41 what's the content of your bblayers.conf? Jan 25 17:54:46 Here's my layer tree, for example Jan 25 17:54:47 http://pastebin.com/BzJvuudz Jan 25 17:55:43 and my bblayers Jan 25 17:55:45 http://pastebin.com/KGxbSm6T Jan 25 17:57:10 Granted, I have a lot of layers you wouldn't need there, but it's an example of something that works without such errors. Jan 25 18:00:48 Hi Hi, Happy Happy FUn people! Jan 25 18:01:05 lets do some fun compile :) Jan 25 18:01:46 this aint real is it? :) Jan 25 18:02:35 someone wants to compile kernel, first finnished gets to compile xorg! :) partey! Jan 25 18:03:50 i gonna paint my kernels blue, and the initrd green Jan 25 18:06:32 so, i have proven that reverting a git pull by doing a reset doenst necessary leave you with a usable oe buildenvironment. Jan 25 18:07:31 maybe do to the arangement of the meta-xxx folders, maybe because i did a bitbake after the pull and before the reset.... Jan 25 18:07:34 i dont know Jan 25 18:08:03 but now its even more broken as before where i would just have to compile some hundreds of packages aagain...and again... Jan 25 18:09:26 sounds like you backed up the version of your oe-core but didn't back up the version of meta-oe to match Jan 25 18:09:29 user error. Jan 25 18:09:41 kergoth: backup? Jan 25 18:09:55 back up, as in go backward, as in git reset Jan 25 18:09:58 i didn't say "backup" Jan 25 18:10:00 kergoth: what backup? i allready stated that i should have made a backup before the git pull. Jan 25 18:10:06 read what i say more thoroughly, or go back to english class Jan 25 18:12:40 kergoth: ok, misunderstanding. back up != backup , i know that now. regarding the othe repo, i try that. Jan 25 18:14:44 ipaqlor: the issue is that they're called layers for good reason, they layer on top of one another, hence they depend on one another. in this case, meta-oe is looking for a recent file that didn't exist in the older oe-core. if you revert it to match, this error should go away Jan 25 18:14:53 afaict anyway Jan 25 18:15:57 right. or just turn it off, as we discussed a few minutes ago. Jan 25 18:16:30 indeed Jan 25 18:17:14 pb_: i did that, i it throw many errors. after that i had some stron laugh attacks resulting from the suggesten to restart the whole thing from the start or something like that. Jan 25 18:17:27 what did you do, precisely? Jan 25 18:17:50 pb_: i removed the refernece in bblayers.conf Jan 25 18:18:23 and what did that leave you with in bblayers.conf? Jan 25 18:19:04 /DEVEL/oe-core/meta-openembedded/meta-oe \ Jan 25 18:19:04 /DEVEL/oe-core/meta-openembedded/meta-efl \ Jan 25 18:19:05 /DEVEL/oe-core/meta-handheld \ Jan 25 18:19:23 okay, so, er, which line did you remove? Jan 25 18:19:49 ../meta Jan 25 18:19:50 I think you might be confused about which layers are "meta-oe" and which are oe-core. Jan 25 18:20:00 right. that one is not meta-oe, it is oe-core. Jan 25 18:20:04 you right i am confused Jan 25 18:20:18 you want to keep meta, and meta-handheld. Jan 25 18:20:26 the two that have "meta-openembedded" in the name are meta-oe. Jan 25 18:20:41 (and those are the ones that you should remove) Jan 25 18:21:15 the naming of this stuff does suck Jan 25 18:21:16 whats ./meta ? than Jan 25 18:21:32 that's oe-core, to all intents and purposes Jan 25 18:23:19 pb_: ok Jan 25 18:23:50 oe-core/meta , meta-openembedded, meta-oe :) nice and easy Jan 25 18:24:03 yeah. like I say, the names do suck quite badly. Jan 25 18:24:28 pb_: i am desperatly searching for something i dont think it sucks here :( Jan 25 18:24:30 I think you have them in a slightly weird directory layou which doesn't help, but it is confusing at the best of times Jan 25 18:24:50 pb_: i did it cause i seen it somewhere to be the way to go Jan 25 18:25:09 with the meta-oe... directly below oe-core root Jan 25 18:25:27 fair enough. well, I think it will work fine like that, it just looks slightly weird. Jan 25 18:25:38 pb_: how do you do it? Jan 25 18:25:47 those secrecy is annoying Jan 25 18:26:01 but, to be honest, I don't quite understand why you are doing all this messing around with metadata anyway. clearly you can already build a kernel so it seems that you just need to debug it. Jan 25 18:26:08 what secrecy? Jan 25 18:26:32 pb_: like the filesystemlayout you use for wxample. Jan 25 18:27:46 pb_: well i thought i did not need to reinvent the whole thing. but i do need to. Jan 25 18:27:54 it seems Jan 25 18:28:06 for this is going on my nerves. Jan 25 18:28:20 i do this just for hobby :) Jan 25 18:28:24 I'm not quite sure where you get the idea of "secrecy" from. Jan 25 18:28:36 there are a ton of existing setups and layouts, nearly all of which are publically available. the fact that you haven't tried to find them or wanted to do it yourself doesn't make it a big secret Jan 25 18:28:43 If you had asked me for my filesystem layout I would have told you. You didn't ask, and I had no idea you wanted to know. Jan 25 18:28:57 I don't, as a rule, mention that spontaneously to anybody I talk to. Jan 25 18:29:08 pb_: true Jan 25 18:29:34 so, for what it's worth, I have an "oe" directory with subdirectories bitbake, oe-core, meta-micro and my own layers. Jan 25 18:29:39 I don't use meta-oe or meta-handheld. Jan 25 18:29:57 I also have another subdirectory under the same folder which I use to build in. Jan 25 18:31:03 pb_: makes sense. Jan 25 18:31:24 but, anyway, this is all beside the point. no amount of modifying layouts or pulling new bits from git is going to debug your kernel. I think you should just get on and do that, and stop worrying about the other stuff for the time being. Jan 25 18:31:54 * pb_ go home now Jan 25 18:32:18 pb_: well, thats what i was all about. but by pure idocy of mine, i happened to pull one time to often before getting into endless kernelcompiles.... Jan 25 18:32:32 pb_: then my buildsystem exploded Jan 25 18:33:35 ERROR: Could not inherit file classes/klibc.bbclass Jan 25 18:33:53 i trashed it Jan 25 18:34:06 Does anybody know if it's big difference when building on a SSD compared to a HDD? Jan 25 18:35:39 ipaqlor: right, that's probably why you needed meta-oe in there in the first place I guess Jan 25 18:37:48 bluelightning: ok Jan 25 18:42:15 also bitbake seems to "hang" with this error, cant even strg+c it Jan 25 18:44:07 has anyone a tip on a "ready made" corsscompiler toolchain for arm gnueabi? Jan 25 18:56:58 well, lets see how long it takes to build a kernel that boot on h3600 without the open embedded effect ;) Jan 25 18:57:31 bye folks. Jan 25 20:50:28 hi Jan 25 21:00:18 | arm-angstrom-linux-gnueabi-libtool: link: `/home/balister/src/git/oe-core/build/tmp-angstrom_2010_x-eglibc/sysroots/usrp-e1xx/usr/lib/libsystemd-login.la' is not a valid libtool archive Jan 25 21:00:33 does that error look familiar? Jan 25 23:08:09 khem, ping **** BEGIN LOGGING AT Wed Jan 25 23:56:08 2012 Jan 26 02:26:54 hi Jan 26 02:27:40 i'm working with a beagleboard. the default SD card comes with i2c-2 enabled. i've managed to bitbake console-image, and get another functional SD card, but it doesn't have i2c-2 in /dev Jan 26 02:28:29 it *does* have /dev/i2c-1 and 3, but 2 is missing (it's the one i need, since it's the one accessible on the expansion header Jan 26 02:28:46 how/what do i configure stuff to get i2c-2? Jan 26 02:28:52 #beagle Jan 26 02:31:08 kergoth`: thanks Jan 26 02:31:15 np Jan 26 02:31:40 it's of course somewhat on topic here, but given the question is hardware specific, you'll probably have better luck there Jan 26 02:32:28 sure, i'll give it a shot. Jan 26 02:32:29 i have a oe question. how do i know what recipes are used when running bitbake console-image? Jan 26 02:33:04 there are a couple ways. try bitbake -u depexp -g console-image Jan 26 02:33:12 gui dependency explorer Jan 26 02:34:10 alternatively, INHERIT += "buildhistory" in oe-core and INHERIT += "testlab" in oe classic, to get image creation to dump useful information about the built image, including what packages went in (not the recipes) and their sizes and the like Jan 26 02:34:17 depends on what your goal is, really Jan 26 02:35:03 sweet, there's tons of stuff in oe, the problem is knowing where to look! Jan 26 02:35:13 i want to know what defconfig i need to edit **** ENDING LOGGING AT Thu Jan 26 02:59:57 2012