**** BEGIN LOGGING AT Thu May 03 03:00:01 2012 May 03 03:19:47 why is bitbake virtual/kernel -c compile -f still fetches old modules etc from sstate_cache? May 03 03:27:09 boosted PR and now it's fine May 03 07:10:11 hi, I seem to have an issue porting an image recipe from oe-classic to yocto 1.2: my recipe has a SRC_URI += "file://myfile.txt" in it; however yocto seems to immediately start with do_rootfs, and not execute a fetch step May 03 07:10:37 is this correct? if so what should I do to pull in a file in my image recipe May 03 07:13:11 <_tasslehoff_> I tested some stuff in oe-classic, and went from org.openembedded.dev to 2011.03-maintenance. that seems to have confused bitbake a bit. is there some cache I should clean when going backwards? May 03 07:16:11 _tasslehoff_: I found 2011.03 maintenance works best with bb 1.12.0, also I would suggest fully nuking TMPDIR and do a clean build May 03 07:17:45 <_tasslehoff_> eFfeM_work: using 1.12, and I guess you're right :) May 03 07:18:13 i always take the safe side, cpu cycles are cheap ;-) May 03 07:19:14 <_tasslehoff_> eFfeM_work: after I got my new work pc I agree. a couple of weeks back I would have cried if you told me to delete my TMPDIR May 03 07:20:34 :-), if you have something like i7 with plenty of ram it is quite ok; my (non-X) image builds from scratch in a less than an hour, most of the time being spent in gcc and libc May 03 07:20:41 never really bothered how do do a partian clean May 03 07:21:06 <_tasslehoff_> i7, 8gb ram and ssd now. May 03 07:22:24 that's quite nice, better than my system here (but we have a dedicated build server); at home I have i7 2600 with 6gb, still need to add an ssd May 03 07:41:20 hm, what is wrong if, when packaging an image, I get several of these: May 03 07:41:21 | rtld(GNU_HASH) is needed by busybox-1.19.4-r6.ppce300c3 May 03 07:41:30 this is a uclibc setup May 03 07:41:39 yocto 1.2 May 03 08:14:12 good morning May 03 08:43:25 morning mckoan, all May 03 08:58:16 khem: Wrt GCC multilib. The compiler (and it's libs like libgcc) could basically be installed anywhere. The interesting part is where do the runtime libs like libssp and libstdc++-v3 go to. It's not about consistency - it's up to the target to define that. And X86_64 Linux systems are supposed to have the libraries in lib64 (even though there are distros like debian who do not). Strictly speaking (with a GCC hat on) if you put your libs somewhere else you're not a May 03 08:58:16 X86_64 Linux system. However, OE want's it to be 'lib' and therefore patches MULTILIB_*. I did a very similar patch to the Linaro GCC. The difference is that it disables multilib at all (instead of setting the path for m32 and m64 libs to the same dir in case --enable-multilib is sepcified): http://git.linaro.org/gitweb?p=people/kwerner/meta-linaro.git;a=commitdiff;h=ba4a243dea9e9e9d4bddfa14af53eb6f7761a60b May 03 09:02:17 someone knows an alternative repo for this ? http://www.angstrom-distribution.org/unstable/sources/git_www.denx.de.git.u-boot.git_1.tar.gz May 03 09:04:52 morning all May 03 09:06:08 hi bluelightning, kenws May 03 09:11:30 mckoan: looks like a git tarball, if you know the hash you probably can get it from the u-boot git repo on denx.de May 03 09:11:32 khem: btw, did I thank you for your patches already? In case I did not: Thank you! I'll push them to meta-linaro master soon. Currently I'm focusing on getting the denzil branch with 4.6based toolchains to build for all the supported qemu targets. May 03 11:03:56 hi all May 03 12:12:36 I want to copy my oe-core and oe-classic download folders to our server and use it as a premirror. Is that a oneliner in my local.conf? May 03 12:27:07 hi May 03 12:27:40 someone use oe with toradex t20? May 03 12:33:42 silvio_: no May 03 13:19:35 :( May 03 13:19:57 i have a trouble with a patch someone could help me May 03 13:19:59 ? May 03 13:20:34 i use toradex patch and i have this error, what does it means? May 03 13:20:49 Hunk #1 FAILED at 1. May 03 13:20:50 1 out of 1 hunk FAILED -- saving rejects to file classes/mirrors.bbclass.rej May 03 13:22:05 silvio_: if the patch does not apply anymore then the class must have been updated May 03 13:22:57 check here http://cgit.openembedded.org/openembedded-core/log/meta/classes?qt=grep&q=mirror May 03 13:23:16 +s May 03 13:24:11 then hope that onlt the class has changed and the rest of the patches are still valid :) May 03 13:26:48 thanks May 03 13:46:37 khem: ping May 03 13:52:54 can anyone tell me the correct bitbake-command to create a flashable image for the NSLU2? (not the zImage and jffs but the complete image) the meta-nslu2 layer doesn't seem to come with the appropriate recipe May 03 13:57:02 dFence: nslu2-base-image or nslu2-linksys-image ? May 03 13:57:33 mckoan: nope May 03 13:58:03 mckoan: i found a recipe for slugimage, but I'm not sure whether the kernel and rootfs are enough May 03 13:59:25 oh... and I just found out that the kernel is too fat - great May 03 14:24:53 which layer contains devio? May 03 14:29:49 dFence, you probably need to build from OE-Classic --- as far as I know, nobody has ported/tested SlugOS on the new OE strucutre. May 03 14:30:35 mwester: khem / "Mike Westerhof" have ported it to the new structure, I only seem to be missing one layer that holds the image-recipes. May 03 14:30:42 hang on... brain loading May 03 14:31:01 You'll probably be missing a kernel patch too... May 03 14:31:16 gnaaaa really?! May 03 14:31:34 Yep, the new toolchain pukes on a syntax bug in the kenel. May 03 14:31:42 FCUK!!!! May 03 14:32:03 I have OE-Classic (latest stuff) building, but haven't committed any of the recent fixes. There hasn't been a lot of community interest. :( May 03 14:32:32 SlugOS 6 alpha --- so it may or may not work. May 03 14:33:03 What specifically are you looking to do? Perhaps there's an easier way to accomplish what you wish... May 03 14:35:50 mwester: well... consider me interested ;) I only need rudimentary functions though - CUPS being the most "fancy" one. would you recommend the slugos-branch or current master? May 03 14:36:02 The other alternative is to get the slugos-image recipies working with the NSLU2 layer in the new OE structure... I just haven't had time to mess with that (too much other stuff taking up all my personal time). May 03 14:36:45 but that wouldn't change anything about the kernel-hickup, wouldn't it? May 03 14:37:01 If you're interested in the packages, and not the core image, then just work off of the most recent SlugOS branch in the original GIT repo (OE-Classic) -- everythig should "just work"... May 03 14:37:33 If you're on that original branch, you'll also get the original toolchain, which isn't sensitive to that particular syntax error in the kernel sources. May 03 14:37:34 mwester: well, I do need a working image in the end ;) May 03 14:37:48 But you don't need to build it. May 03 14:38:00 mwester: I don't? May 03 14:38:40 Right, you would use the most recent binary SlugOS image, and build the packages you need for it -- which would be installed via ipkg/opkg, and not be part of the base image. May 03 14:39:26 The jump to the new OE will require a new image, but as long as you build packages from the original baseline that the oriingal image was built with, you don't need a new image. May 03 14:41:00 mwester: where can I find the 6x images? the latest ones I found are 5.3 (slugos-fimrware.net) May 03 14:43:27 mwester: dFence: iirc Khem is/was testing the meta-nslu2 layer on top of oe-core May 03 14:45:04 ant_work: I'm using the current poky-collection - it compiles fine together with the meta-nslu2 to the point where slugimage bitches that the kernel size is too large. so all I need is the proper recipe-name that generates the image with apex May 03 14:45:18 I guess we'll just have to wait for khem to enlighten us ;) May 03 14:45:33 well, about kernel-size just compress it with lzma May 03 14:46:14 ant_work: I assumed it's already compressed!? I don't like to fiddle around too much within BSP-layers May 03 14:46:36 actually here is a pure kernel .config editing May 03 14:46:46 hm? May 03 14:47:09 I mean you'll have only to fine-tune the kernel May 03 14:47:51 Sorry, called away -- I'm supposed to be at work. May 03 14:47:52 hi all May 03 14:48:06 mwester: hardly working? ;D May 03 14:48:21 Almost certainly the latest OE layer uses a more recent kernel, and needs to be config'd to fit (and work). May 03 14:48:50 Regarding the 6.0 images -- alpha's are not usually released. I can make one available, though. May 03 14:49:23 hey pb_ May 03 14:49:33 If you use the latest 5.x branch, you'll be able to build packages against that version of the base image. May 03 14:50:21 On the other hand, if you want to use the stuff that Khem has been maintaining, you're kind of on your own, since none of us (the NSLU2-Linux folks) have been actively testing the OE layers yet. May 03 14:51:09 mwester: once you'll do it, go straight to linux-yocto kernel May 03 14:51:22 mwester: I just raided khem's github-projects and found this: https://github.com/kraj/meta-slugos – will give it a shot May 03 14:51:24 it's easy to adapt the old defconfig + patchset May 03 14:51:32 at the beginning May 03 14:52:12 adapt = rename May 03 14:52:14 :) May 03 14:52:42 ant_work - I'll try that. Need to figure out if the linux-yocto kernel bb can be forced to build the IXP4XX kernel... May 03 14:53:18 The existing OE Classic recipe pulls various IXP4XX patches from the NSLU2 Linux SVN repo. May 03 14:53:42 I have done it with local patches but this shouldn't make ant difference May 03 14:53:43 (One would hope they're all upstream by now, but every kernel release seems to introduce something that needed to be patched. :( ) May 03 14:54:19 dFence: yes meta-nslu2 has got some testing May 03 14:54:31 I have build angstrom/slugos for it May 03 14:54:35 I get the impression that very few devices actually use the IXP processor... hence the kernel.org folks don't get enoough feedback during the rc build, etc. May 03 14:54:39 using oe-core structure May 03 14:54:51 but as mwester said its not official slugos May 03 14:55:02 the big bonus of linux-yocto kernels is they are maintained and upgraded, basically you nail down the config to the minmal fragments and the rest of the features are 'modular' May 03 14:55:03 I wanted mswester to take it over and maintain it May 03 14:55:07 khem: like I said, meta-nslu2 seems to compile fine - I'll just give the slugos-layer a shot May 03 14:55:15 sure May 03 14:55:19 Good morning, khem May 03 14:55:24 mwester: hello May 03 14:55:49 And I'm about ready to be able to do that. The house is nearing completion, so I'm about to get my computers out of storage again... May 03 14:56:00 yay good news May 03 14:56:00 (still building on a VM on my work computer) May 03 14:56:11 Living in a basement. May 03 14:56:19 yeah OE-core is consistent but might need more muscle May 03 14:56:40 mwester: I have not moved the layers to latest oe-core release yet May 03 14:57:24 btw if you're size-limited think about adding KERNEL_IMAGE_MAXSIZE_machine = "123456789" to the kernel recipe May 03 14:57:25 just for my general understanding – yocto branch:master == oe-core branch:master? May 03 14:57:41 I have to travel again this weekend and next week, but I should be ready to take over the leyers late next week. May 03 14:57:56 mwester: cool ok. by all means May 03 14:58:07 clone it over and once you host it let me know May 03 14:58:14 gotta go now May 03 14:58:21 Assuming my build machine boots; I pick it up thiis weekend, and should be moved into my new office by Wednesday... :) Sunlight! Window! What a concept! :D May 03 15:01:41 mh.. sunlight... that's where reality is from, right? May 03 15:05:00 need to disable the output on serial port used as console. On kernel used quiet parameter but can't remove the output from init scripts. Any idea ? May 03 15:07:00 nine_pt: check /etc/inittab May 03 15:07:38 (if you remove the line that enables the getty on ttyS0 you'll have no console whatsoever on your serial port) May 03 15:08:48 dFence: and the output from the init.d scripts ? that messages continue to appear ... is there a way to redirect to /dev/null or I have to edit all the scripts ? May 03 15:11:20 nine_pt: find the line that says "S:2345:respawn:/sbin/getty 115200 ttyS0" (or sth like that - important is the ttyS0 there won't be any output at all on the serial-port May 03 15:11:46 ... if you comment out that line May 03 15:12:47 I receive output with line commented ... May 03 15:12:58 I receive output with that line commented ... May 03 15:13:01 nine_pt: did you just comment it out or is it by default? May 03 15:13:33 dFence: I commented May 03 15:13:49 nine_pt: then reboot. if there's still output have another look at the kernel-arguments May 03 15:15:27 dFence: on the kernel parameters I have console=/dev/null May 03 15:15:36 should be fine then May 03 15:19:13 dFence: continue to don't work ... May 03 15:19:45 hm... strange May 03 15:19:58 paste your kernel-args May 03 15:22:59 dFence: all information on a pastebin: http://pastebin.com/5jKrxPaU May 03 15:26:56 aye... I'll be finding myself in a bewilderment... May 03 15:27:14 nine_pt: what distro? May 03 15:27:38 I am using poky May 03 15:28:19 dFence: to generate the image, don't know how I can tell you more info about it ... May 03 15:31:44 nine_pt: check the recipe for your machine, there should be a line "SERIAL_CONSOLE" – try commenting that one out May 03 15:37:19 you may add loglevel=3 instead of quiet and set two consoles (e.g. tty0 and ttyS0) the last being the master console May 03 15:37:39 "If no console device is specified, the first device found capable of May 03 15:37:39 acting as a system console will be used" May 03 15:38:38 ant_work: so enabling a virtual console in inittab before ttyS0 might do the trick? May 03 15:38:51 just changing kernel cmdline May 03 15:39:09 mh didn't know that one yet May 03 15:40:09 crap... "configure: error: the assembler must support TLS" (during building eglibc) – how do I get rid off that one?! May 03 15:40:18 I had another problem: wanted output on serial but not on screen May 03 15:42:13 ant_work: I remember spending a couple days getting the console to stfu on every interface but can't remember how I solved it right now May 03 15:42:28 iirc the output is sent to *all* consoles May 03 15:42:42 is just the input is on the master (and stderr) May 03 15:43:10 the trick was loglevel = 3 and kernel boot is very silent May 03 15:43:21 quiet corresponds to 4 iirc May 03 15:43:25 http://elinux.org/Debugging_by_printing#Log_Levels May 03 15:44:29 thanks for the headsup May 03 15:44:39 any ideas on my TLS-issue? May 03 15:51:28 what does config.log say? May 03 15:52:48 pb_: "checking for ARM TLS support... no" I figure it has something to do with the compiler-flags for the native gcc May 03 15:56:11 Is that what it actually says in config.log? May 03 15:56:24 (as opposed to log.do_configure or any other file) May 03 15:56:48 pb_: that's the crucial line bitbake returns in the error-traceback. let me see if it differs from the config.log May 03 16:00:49 where in the tmp folder would I find the subfolder for eglibc-initial? May 03 16:01:13 tmp/work/TARGET_OS/... May 03 16:02:07 pb_: ha, close! it was tmp-eglibc :D hang on May 03 16:04:40 pb_: yep, config.log also says "configure:37: error: the assembler must support TLS" May 03 16:04:50 Does it say anything else? May 03 16:04:58 however, I do see the message "armeb-oe-linux-gnueabi-gcc: error: unrecognized command line option '-mno-thumb'" quite often... May 03 16:05:49 pb_: here are the related messages: http://pastebin.com/HbWqwUP0 May 03 16:06:29 okay. so, yes, you need to either get a gcc that understands -mno-thumb, or remove that from your cflags. May 03 16:07:24 pb_: that's a vanilla oe-core; but would that cange anything regarding the TLS-issue? May 03 16:13:12 What MACHINE are you building for, qemuarm? May 03 16:13:26 pb_: nslu2 May 03 16:13:34 That's not in oe-core, is it? May 03 16:13:56 pb_: nope; distro is in meta-slugos and bsp is in meta-nslu2 (both maintained by khem) May 03 16:18:10 okay, so not a totally vanilla oe-core. does it work if you build for qemuarm without using the meta-nslu2 bsp? May 03 16:18:20 pb_: yep May 03 16:24:16 dFence: that error means its not finding the right binutils May 03 16:24:23 dFence: what steps did you try May 03 16:25:59 um, really? the error seems to be fairly explicitly a gcc one. May 03 16:26:57 khem: installed gcc-multilib nothing else so far May 03 16:27:41 khem: pb_ : fwiw I've noticed that building oe-core for collie (armv4/strongarm) somehow triggered ${ARM_INSTRUCTION_SET}" = "thumb" May 03 16:28:12 (kernel config tools detected a mismatch: ARM_THUMB y) May 03 16:28:33 so somehow the thumb thing has dark sides... May 03 16:36:42 mh on a different note, maybe something for mwester: how do I reset the slugos'd nslu to "factory settings"? I can't remember the IP i set 4 years ago May 03 16:41:35 pb_: eglibc configure pokes assembler with directives May 03 16:41:52 and if it can not get right answer it decides that binutils is too old May 03 16:43:05 I was responding to TLS-issue May 03 16:43:07 btw. May 03 16:44:59 ah I see May 03 16:45:15 gcc has switched to using marm instead of mno-thumb May 03 16:45:22 so you need to adjust the tune files May 03 16:45:57 dFence: grep for -mno-thumb in oe-core tree and replace it with -marm May 03 16:46:00 that should fix it May 03 16:47:04 khem: as usual - thanks a lot :) May 03 16:47:25 np May 03 16:47:46 ant_work: thats because thumb tuning have changed there meaning with tuning overhaul May 03 16:47:58 I had posted a patch to fix it but pb_ did not like it so much May 03 16:48:55 I just observed it doing a build roundup, I can't test collie May 03 16:51:06 khem: actually... if I can't get that mofo to talk to me the problem will solve itself, and tomorrow's newspapers will have a sighting of and unidentified flying object in them.. May 03 16:54:03 khem: all I found so far was "-mno-thumb-interwork" May 03 16:55:00 hmm May 03 16:55:35 khem: found it in meta-slugos/conf/distro/include/arm-thumb.inc May 03 16:58:03 khem: worked like a charm - I'm curious what bitbake's gonna throw at me next ;) May 03 17:00:06 oh I see May 03 17:00:10 send a patch if you will May 03 17:00:54 after the mailing-list got a little bitchy the last time... mh... let me think ;) May 03 17:00:58 prefix meta-slugos? May 03 17:01:17 or better: where to? since it's not the "official" oe-release May 03 17:07:39 dFence: you can submit a pull request through github too May 03 17:08:06 otherwise send to oe-devel prefixed with meta-slugos May 03 17:08:54 can anyone tell me how to reset the system-settings (or only IP) via redboot? May 03 17:10:28 dFence: fconfig May 03 17:11:05 keep pressing ENTER until you reach Gateway IP address: May 03 17:11:06 khem: unknown command May 03 17:11:18 hmmm May 03 17:11:22 redboot v1.92 May 03 17:13:13 help or something should list what it had May 03 17:13:18 meeting time May 03 17:30:52 * mwester wonders if he has commit rights to oe-core's repos... May 03 17:32:35 people aren't supposed to be pushing directly, whether we have access or not :) May 03 17:37:19 Ok... I rather suspected that. May 03 17:45:56 Did OE-Core just do a stable release? (If so, that would be a good basis for trying to get SlugOS working with the new OE stuff) May 03 18:11:17 mwester: yes release is called denzil May 03 18:11:33 mwester: my slugos setup is tracking an older revision May 03 18:11:40 but I can easily update I guess May 03 19:06:26 can you guys recommend an alternative to cups? I don't need rendering / rastering, I only need the queue handling May 03 19:19:49 khem by any chance any idea why I get this with a denzil uclibc image: May 03 19:19:50 |       rtld(GNU_HASH) is needed by libz1-1.2.6-r1.ppce300c3 May 03 19:19:50 This happens for various files May 03 19:20:25 uclibc does not seem to provide the rtld() whereas eglibc does May 03 19:45:30 khem: mwester: did you guys by any chance forget to include a telnet/ssh-server in the slugos-7.0 layer? ;D May 03 19:54:30 errrm... what's the default root password in poky? May 03 20:12:44 dFence: you should just zap_password May 03 20:12:55 khem: hm? May 03 20:13:32 see zap_root_password May 03 20:15:39 khem: in which recipe should I add it? May 03 20:15:49 khem: or is that local.conf? May 03 20:16:29 khem: btw, debug-tweaks are set in local.conf, yet passwd is not empty May 03 20:16:34 local.conf May 03 20:17:00 ROOTFS_POSTPROCESS_COMMAND += "zap_root_password" May 03 20:17:52 thx May 03 20:34:28 khem: it seems openssh didn't get the nopw-patch; where is it set that openssh is used instead of dropbear? May 03 20:34:57 well that patch is a hack anyway May 03 20:37:18 khem: where is it set that openssh is used instead of dropbear anyways? May 03 20:40:31 okay.... I can definitely say that the rootpw is zapped, but the ssh-server (not sure if openssh or dropbear) won't accept logins without pw May 03 20:51:10 yeah so go in on console May 03 20:51:16 and change that to some real pw May 03 20:51:30 khem: I have only network-access, no serial or whatsoever May 03 20:52:38 dFence: you can choose EXTRA_IMAGE_FEATURES_append_pn-slugos-image = " ssh-server-openssh" May 03 20:52:46 in local.conf May 03 20:52:55 that should get you openssh May 03 20:53:09 you have to remove dropbear from the image/task recipe May 03 20:53:23 khem: openssh is installed, I'd preferr dropbear; I just modified the task-recipe... May 03 20:53:36 k May 03 20:54:26 There was a reason we switched from dropbear to openssh... don't recall what it was, but it was painful and we didn't want to do it so it must have been important... May 03 20:54:46 khem: by removing openssh-sshd and openssh-keygen from RECOMMENDS_${PN} will dropbear be installed automatically? May 03 20:55:03 mwester: haven't any problems with dropbear whatsoever May 03 20:55:05 add that to recommends May 03 20:55:09 it wont I think May 03 20:55:38 actually you can use PACKAGE_GROUP way that I suggested above May 03 20:56:24 use ssh-server-dropbear May 03 21:00:03 done May 03 21:00:24 you can also do it in talk recipe May 03 21:05:55 khem: I'm planning on deploying the images on 3 different hardware-platforms. basic software will always be the same, 2 platforms will have little tweaks (X11 / no X11) – where would you recommend I'd put such settings in order for it to be easily "recycled"? May 03 21:08:32 dFence: have two images May 03 21:08:39 one with X and one without May 03 21:08:52 then create feeds for online updates May 03 21:08:54 you are set May 03 21:08:59 khem: k. btw: even with dropbear I still can't login May 03 21:09:05 yeah May 03 21:09:28 I always have console so I never cared May 03 21:09:36 since I could change the pw to something May 03 21:10:28 isn't there a way to set the default root-pw via local.conf?! May 03 21:10:34 another idea... I'll just supply a authorized_keys file with the image-recipe May 03 21:37:12 khem: don't ask me why, but dropbear is ignored when compiling the rootfs May 03 21:40:40 dFence: hmmm May 03 21:40:54 probably its not appearing in rdepends of image May 03 21:41:07 whats your image name May 03 21:41:08 khem: I added it manually May 03 21:41:12 slugos-image May 03 21:41:39 then this should work EXTRA_IMAGE_FEATURES_append_pn-slugos-image = " ssh-server-dropbear" May 03 21:42:30 khem: did that already May 03 21:42:36 hmm May 03 21:43:00 ok bitbake slugos-image -e > /tmp/xx and pastebin xx somewhere May 03 21:43:19 hang on May 03 21:50:48 khem: http://pastebin.com/3c70aPZn May 03 22:18:02 dFence: you need to fix the task May 03 22:18:42 khem: i just deleted the entire tmp-eglibc; should i pastebin the recipe? May 03 22:18:51 no May 03 22:22:02 dFence: add it to DISTRO_EXTRA_RDEPENDS May 03 22:22:12 instead of EXTRA_IMAGE_FEATURES May 03 22:22:29 we dont use EXTRA_IMAGE_FEATURES as much in slugos yet May 03 22:22:31 khem: still local.conf? May 03 22:22:50 you could do that yes May 04 02:26:03 anybody know if there is any support for firewire in OE? in particular, I am hoping to be able to use libdc1394 and libraw1394 May 04 02:27:14 my target platform is ARM **** ENDING LOGGING AT Fri May 04 02:59:59 2012