**** BEGIN LOGGING AT Fri Sep 27 02:59:58 2013 Sep 27 06:57:40 good morning Sep 27 06:58:39 morning! Sep 27 07:22:10 Hi, I wrote my own recipe, it source had to be download from a svn, each time I update my revision number I modify the bbfile with the new revision number but it look like nothing append to my final image. Should I do something more to specify my update? Sep 27 07:26:28 TuTizz: did you add your package in the image? Sep 27 07:29:01 ndec, yes I did Sep 27 07:29:52 TuTizz: when you rebuilt your image after the REV update, does it actually re-fetch, and re-build your recipe? Sep 27 07:30:43 TuTizz: also, this is obvious, but you need to bitbake the image not the recipe when you update the REV. Sep 27 07:31:26 for a concret example, I moved my LICENSE.LGPL to a different folder and specify his new position with LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24" Sep 27 07:32:37 bitbake end with the same previous error and trying to find the file on the old position Sep 27 07:33:56 TuTizz: and you changed SRCREV too? Sep 27 07:34:59 :( I don't have any SRCREV Sep 27 07:35:45 how do you set PV? Sep 27 07:38:39 I believed that it was automatic Sep 27 07:40:16 TuTizz: no, it is not. Sep 27 07:40:42 in general if you get from svn or git, you need to add SRCREV (the revision) to PV. Sep 27 07:40:56 so that bitbake will detect when it needs to re-fetch from svn Sep 27 07:41:30 there are many example of SRCREV usage in tree. Sep 27 07:42:56 ok thank you ndec :) Sep 27 07:43:42 TuTizz: btw, you can to SRCREV="${AUTOREV}", in which case bitbake will automatically pick the last revision (or commit). Sep 27 07:44:08 by quering the svn (or git) repo when 'parsing' the recipes. Sep 27 07:44:38 ndec, I saw I can do it in my local.conf, can I do it in my recipe directly? Sep 27 07:45:07 you need to set PV in your recipe ,for sure. Sep 27 07:45:16 then SRCREV can either be in recipe or in a conf file. Sep 27 07:46:27 if you do it in a conf file, you need to do SRCREV_pn- = "xxx" Sep 27 07:56:55 morning all Sep 27 08:00:06 ndec, perfect that exactly what i want to do :) that works with SRCREV="${AUTOREV}" Sep 27 08:00:06 PV = "0.0.3" Sep 27 08:00:06 PR = "r0" Sep 27 08:00:33 On my first boot I'm getting a lot of these errors: ERROR: postinst /etc/rpm-postinsts/kernel-module-zte-ev failed. Sep 27 08:00:42 All related to kernel modules Sep 27 08:03:20 Seems like depmod/depmodwrapper aren't shipped with the image, what recipe provides these? Sep 27 08:41:54 Ah found out it needs "kmod" =) Sep 27 08:42:29 But I don't understand why it executes this on the first boot Sep 27 09:01:02 RagBal: have a look at your log.do_rootfs for the image, if they're running on first boot it means they failed to run during do_rootfs Sep 27 09:05:52 Ahhh ok, I didn't get a warning about it during the build Sep 27 09:45:34 do we have a recipe for sftp in dylan? is openssh-sftp the right choice? Sep 27 09:51:49 mckoan: it's what most people use AFAIK Sep 27 10:06:05 bluelightning: thx, and can openssh-sftp co-exist with dropbear? Sep 27 10:06:14 mckoan: yes Sep 27 10:06:41 bluelightning: fine thx Sep 27 10:07:55 bluelightning, install/tmp/rpm-tmp.651: line 6: depmodwrapper: command not found << is in the log, so it indeed can't install the rpms Sep 27 10:08:56 depmodwrapper is indeed not installed on my host system, it is Ubuntu 12.04 Sep 27 10:09:11 RagBal: it's not supposed to be on your host system, it's build by the build system Sep 27 10:09:47 Hmm, not by my build =( Sep 27 10:10:24 RagBal: can you please do bitbake -e your-image | grep ^DEPENDS= and tell me what the output is? Sep 27 10:11:07 DEPENDS="gzip-native qemuwrapper-cross depmodwrapper-cross" Sep 27 10:11:13 ok, so that bit is correct Sep 27 10:12:57 RagBal: you haven't been using the -b option have you? Sep 27 10:13:08 To build the image? Nope Sep 27 10:13:13 ok, just checking Sep 27 10:14:10 bluelightning, this is the image recipe I use Sep 27 10:14:13 http://pastebin.com/DiCBH8xe Sep 27 10:15:25 RagBal: if you change that "include" to "require" does it still work? Sep 27 10:16:17 bluelightning, yes it is building the image Sep 27 10:16:25 ok Sep 27 10:18:36 I want to create a new directory in /home/root how can I do? I tried install -d -m 755 ${D}/home/root/.debug but not sure Sep 27 10:18:49 (during a do_install() { } Sep 27 10:20:21 RagBal: if you look in the path given by this command, does it contain depmodwrapper-cross? : bitbake -e | grep ^STAGING_BINDIR_CROSS= Sep 27 10:20:37 RagBal: actually depmodwrapper not depmodwrapper-cross Sep 27 10:21:43 No such file or directory Sep 27 10:22:09 STAGING_BINDIR_CROSS="/ssd/yocto/projects/smarct335x/tmp/sysroots/smarct335x/usr/bin/crossscripts" Sep 27 10:22:15 Doesn't exist Sep 27 10:22:38 hmm Sep 27 10:27:19 =( Sep 27 10:34:38 RagBal: that directory ought to exist... is there anything unusual about this build? Sep 27 10:39:39 RagBal: are there any depmodwrapper-cross files under /ssd/yocto/projects/smarct335x/tmp/stamps/ ? Sep 27 10:45:47 the cross files are under host sysroot Sep 27 10:45:53 not in target Sep 27 10:46:26 smthg wrong there Sep 27 10:51:47 ant_work: bitbake -e depmodwrapper-cross | grep ^STAGING_BINDIR_CROSS= for MACHINE=qemux86 shows /path/to/tmp/sysroots/qemux86/usr/bin/crossscripts here Sep 27 10:52:07 and that directory does contain depmodwrapper (and a load of other scripts) Sep 27 10:55:39 I see, it isn't a typical -cross recipe Sep 27 10:56:08 I'm always thinking about toolchains and crosscompilers.. I'm biased, sry Sep 27 10:56:13 ok, np Sep 27 10:56:25 the recipe doesn't inherit cross Sep 27 10:56:42 so there isn't any magic with sysroots Sep 27 10:57:00 why is it called -cross btw? Sep 27 10:57:21 not entirely sure Sep 27 10:57:26 we do prefix it for multilib, FWIW Sep 27 10:59:03 well, without anything more to go on I'm not sure I can help.... Sep 27 11:03:26 bluelightning, sorry I was eating my lunch Sep 27 11:03:47 RagBal: sorry if I already asked previously, which branch is this? master/dylan/... ? Sep 27 11:03:52 Dylan Sep 27 11:04:17 I'm trying to build the BeagleBone Black kernel with Yocto Sep 27 11:04:46 RagBal: what do you have set for DISTRO? Sep 27 11:05:16 poky Sep 27 11:08:44 RagBal: so you're using meta-beagleboard ? Sep 27 11:09:59 No I'm a dirty boy, I copied the kernel recipe in my own layer Sep 27 11:10:11 ah ok Sep 27 11:10:14 any other modifications? Sep 27 11:10:28 A few patches to the kernel, but nothing strange Sep 27 11:10:38 It works fine with angstrom Sep 27 11:10:42 ok, it won't be an issue with the kernel recipe Sep 27 11:11:04 I'm not fond of my imge recipe Sep 27 11:11:15 Did you check the link I sent earlier? Sep 27 11:11:32 Perhaps I'm doing something wrong there Sep 27 11:19:30 RagBal: I did have a look at it; apart from the IMAGE_INSTALL the rest shouldn't be needed since you're including/requiring core-image-minimal recipe Sep 27 11:19:47 but that shouldn't cause the problem you're seeing Sep 27 11:20:03 Hm Sep 27 11:21:56 FWIW, I am running a dylan build here with your image recipe, but to be honest I don't expect it will reproduce the problem; we'll see Sep 27 11:22:06 RagBal: did you see my question above re stamps? Sep 27 11:24:23 ./smarct335x-poky-linux-gnueabi/depmodwrapper-cross <<< Yes Sep 27 11:24:42 And some task files Sep 27 11:25:04 ok, so it does think that it built Sep 27 11:25:17 which is what youd expect given that it apparently hasn't tried to build it Sep 27 11:25:47 you haven't used any scripts to delete parts of tmp/ or deleted any part of that by hand? Sep 27 11:26:05 Nope Sep 27 11:26:09 ok Sep 27 11:26:11 Wouldn't dare to taint it =) Sep 27 11:26:24 well I need to grab some food and I'll be back in a bit Sep 27 11:26:35 I can completely rebuild the entire thing Sep 27 11:26:45 one thing to try might be to move the tmp directory out of the way and then rebuild, yes Sep 27 11:26:54 Will do Sep 27 11:26:55 (move rather than delete so we still have it for reference) Sep 27 11:27:15 Roger, enjoy your food, and thanks so far Sep 27 11:53:28 rburton: hi ! I have my image working pretty good now, but I recently saw that it was still the libx11.rpm present in the installed packages. so my question is : how to remove a package from my image or how to know which package has needed it when built ? Sep 27 11:53:53 elbc: did you remove x11 from your distro features? Sep 27 11:54:03 yes Sep 27 11:54:13 then it didn't work as if you did, it will *refuse* to build libx11 Sep 27 11:54:27 run bitbake -e |grep DISTRO_FEATURES= Sep 27 11:56:12 rburton: no trace of x11 at all Sep 27 11:58:29 what's your evidence that libx11 is in your image? Sep 27 11:58:38 i.e. do you have /usr/lib/libX11.so.* Sep 27 11:59:03 rburton: I did gedit tmp/work/chiefriver-poky-linux/core-image-weston/1.0-r0/installed_pkgs.txt and I found libx11 in it Sep 27 12:00:10 check the rootfs too in that directory Sep 27 12:00:28 its possible that it found the packages hanging around from when you didn't have it enabled, and they got pulled in through recommends Sep 27 12:02:51 rburton: no traces at all of x11 in /usr/lib but there is in /media/sda1/usr/lib/ Sep 27 12:03:24 rburton: does it mean it is not efficient ? Sep 27 12:03:57 what? there's a /media/sda1/usr/lib path inside the rootfs? Sep 27 12:04:43 it seems to be yes Sep 27 12:05:06 well that's messed up Sep 27 12:05:15 rburton: ? Sep 27 12:05:33 rburton: sorry my english is not very good Sep 27 12:05:38 /media is for mounting media on, so it should be an empty directory in the rootfs Sep 27 12:05:57 rburton: oh sorry Sep 27 12:06:06 rburton: in the rootfs yes it is empty Sep 27 12:06:32 rburton: but when I do a find . -name "*x11*" or "*X11*" on my target Sep 27 12:06:46 right, so its picking up whatever you plugged in Sep 27 12:06:49 it founds some X11 file in /media/sda1/usr/lib/ Sep 27 12:07:05 rburton: sorry ? Sep 27 12:07:48 rburton: does it mean libx11 is not really installed ? Sep 27 12:09:14 if there's not a /usr/lib/libX11.so* in your target filesystem, then its not installed. Sep 27 12:09:29 rburton: ok ! thank you very much Sep 27 12:11:13 elbc: hm, are you booting from eg usb on a machine that has a different distro on the harddisk? Sep 27 12:11:14 RagBal: back Sep 27 12:11:34 bluelightning, the image is still building. Takes longggg Sep 27 12:11:50 (996 of 2336) Sep 27 12:11:59 RagBal: in your old tmp directory do you have work/smarct335x-poky-linux-gnueabi/depmodwrapper-cross/ ? Sep 27 12:12:19 Yep Sep 27 12:12:33 RagBal: ok, what does it have in it? Sep 27 12:13:33 Folders: "deploy-rpms depmodwrapper-1.0 image license-destdir package packages-split pkgdata pseudo sysroot-destdir temp" Sep 27 12:13:44 And a file depmodwrapper-cross.spec Sep 27 12:19:28 RagBal: ok, could you pastebin temp/log.do_populate_sysroot from there assuming that exists? Sep 27 12:23:05 bluelightning, http://pastebin.com/XvnV7HZb Sep 27 12:23:13 The logfile is dated yesterday Sep 27 12:25:28 RagBal: and presumably sysroot-destdir contains usr/bin/crossscripts/depmodwrapper ? Sep 27 12:27:35 Yes Sep 27 12:30:22 well, that is strange Sep 27 12:30:39 so it definitely did stage the file, and yet not only is it not there, the entire directory is missing Sep 27 12:32:46 In the new build the folder is created Sep 27 12:33:13 right... I think it was created in the previous build and somehow it was removed after that Sep 27 12:33:16 /ssd/yocto/projects/smarct335x/tmp/sysroots/smarct335x/usr/bin/crossscripts <<< that is Sep 27 12:33:18 I don't know how that could happen though Sep 27 12:33:30 Very weird indeed Sep 27 12:34:07 Perhaps I messed stuff up when I forgot to "inherit image" in the recipe yesterday Sep 27 12:34:47 I don't see how that could cause this Sep 27 12:35:10 if depmodwrapper hadn't been built at all it might have helped explain it, but it did build Sep 27 12:35:32 I did clean/cleansstate on the recipe Sep 27 12:39:15 ^_^ Sep 27 12:55:00 rburton: I have some build errors when trying to build libva-intel-driver : http://pastebin.com/94kAufbm (and I'm sure to know what is expected) Sep 27 12:55:14 (not sure sorry) Sep 27 12:56:29 nothing i've seen before, you'll have to debug that yourself. Sep 27 13:01:08 I have a simple recipe to copy grub.conf over to tmp/deploy/images/.. : http://pastebin.com/AQJPbeEH Sep 27 13:01:29 I used suggested by bluelightning do_deploy[nostamp] = "1" Sep 27 13:01:45 but 'bitbake grub-conf' just does not kick my do_deploy function Sep 27 13:01:55 I have to cleanall and then bitbake once again Sep 27 13:02:26 so basically do_deploy[nostamp] = "1" doesn't do what I would like it to do - kick off do_deploy function ALWAYS Sep 27 13:02:56 that is exactly what nostamp is supposed to do Sep 27 13:03:09 have you tried moving nostamp after the function definition? Sep 27 13:04:14 bluelightning, yes, I tried it does not change anything Sep 27 13:04:32 bluelightning: maybe I have some other settings in my layer wrong? like layer priorites, BBPATH, etc? Sep 27 13:05:25 ok, changing the order wouldn't help looking at examples we have Sep 27 13:05:36 nope, that wouldn't be able to influence this I don't think Sep 27 13:06:01 bluelightning: maybe it doesn't like the fact, that do_deploy is non-standard function, but manually added? Sep 27 13:06:28 Krz-: do_deploy isn't a "standard" function, everywhere it's used it's added in this manner Sep 27 13:07:03 rburton: ok thanks Sep 27 13:07:38 bluelightning: yeah, that's my point. greping for do_deploy[nostamp] in poky/ shows zero results Sep 27 13:07:56 typically we would not make that function nostamp Sep 27 13:08:03 that doesn't mean it shouldn't work though Sep 27 13:08:10 bluelightning: maybe nostamp works only for functions like install/compile/build which are standard functions Sep 27 13:08:22 no, I know that it works for any function Sep 27 13:08:29 bluelightning: ok Sep 27 13:09:51 bluelightning: I know Yocto can create somehow grub.conf as well. If that mechanism can put my grub.conf under tmp/deploy/images/... then I might switch to it Sep 27 13:10:07 bluelightning: I just need any working solution which will place valid grub.conf there Sep 27 13:12:23 Krz-: ok having just tried it, I can see what is going on Sep 27 13:13:17 Krz-: nostamp is working; however deploy.bbclass marks this as an sstate task so it tries to run it, sees that none of its inputs have changed and therefore just restores it from sstate-cache Sep 27 13:13:29 Krz-: why do you need this to run every time? Sep 27 13:14:33 bluelightning: it needs to be created everytime user builds an image, even after wipeing-out images/ directory Sep 27 13:16:24 Krz-: ok... well, unintentionally this recipe is both poking into DEPLOY_DIR and expecting sstate to manage files it puts there Sep 27 13:18:47 Krz-: so you have two choices, either change your do_deploy to put things in DEPLOYDIR (as defined by deploy.bbclass) instead of DEPLOY_DIR_IMAGE, or don't inherit deploy Sep 27 13:26:12 bluelightning: not inheriting deploy works perfect Sep 27 13:27:30 bluelightning, working perfectly now thank you! Sep 27 13:27:44 bluelightning, it's not giving the rpm installation during boot Sep 27 13:29:20 RagBal: I'm still confused about how it got into that state though Sep 27 14:42:03 hi all, i got error when use Linux-yocto-3.10 Sep 27 14:42:08 Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=standard/base,meta;name=machine,meta' Sep 27 14:42:33 with linux-yocto-3.8 it is ok Sep 27 14:43:01 does it mean failure from git server? Sep 27 14:51:10 vducuy: which machine are you building for? Sep 27 14:51:18 zeddii: ^ Sep 27 14:54:00 fetcher failure. smells like infrastructure on the servers. unless there's a bitbake error about branches missing, etc. Sep 27 14:58:42 can I change the order of evaluating variables from: myimage.bb my.conf files? Sep 27 15:02:02 ant_work: ping Sep 27 15:06:09 bluelighting: i tried my own machine and also beagleboard. Sep 27 15:06:15 the same problem Sep 27 15:22:48 jwessel: pong Sep 27 15:23:18 zeddii sent me your conf.tar.gz and I was going to have a look at the failure. Sep 27 15:23:30 I assume I Just have to build: linux-yocto-tiny-kexecboot ? Sep 27 15:23:46 yes Sep 27 15:24:32 ok. The build in progress in that case. I imagine we'll either use your patch or at least get to the stage where all the various cases work again. Sep 27 15:25:16 jwessel: I'm maybe retarded but cannot yet grasp the real issue with signed modules you have :) Sep 27 15:25:41 I doubt that. Sep 27 15:26:06 It is quite possible that the module singing is not working in the first place with the monolithic kernel. Sep 27 15:26:14 tbh I avoid signed mods like pest ;) Sep 27 15:26:46 It is not so much module signing as it is modversions being in use. Sep 27 15:27:00 This prevents the modules from loading if they are not the right ones for the kernel. Sep 27 15:27:02 jwessel: yes, sorry for the imprecision Sep 27 15:27:39 | /space/jw/yocto/oe-core/andrea/build/tmp-eglibc/work/c7x0-oe-linux-gnueabi/linux-yocto-tiny-kexecboot/3.10.11+gitAUTOINC+dad2b7e1ce_e1aa804148-r0/linux/scripts/gen_initramfs_list.sh: Cannot open 'initramfs.cpio.lzma' Sep 27 15:27:45 Is that the typical failure you see? Sep 27 15:28:09 yes, is the patch for kernel_do_configure() Sep 27 15:29:06 s/is/is solved by/ Sep 27 15:30:18 jwessel: I have tried the two steps builds but I didn't set INITRAMFS_IMAGE in local.conf. I just cannot do that, it would pollute any other kernel/image Sep 27 15:30:48 I believe you can set the INITRAMFS_IMAGE else where. Sep 27 15:32:24 jwessel: try to remove CONFIG_INITRAMFS_SOURCE from the config: the error would disappear but the image would not be embedded, not built Sep 27 15:32:44 (well, if youeven remove INITRAMFS_TASK ofc) Sep 27 15:35:13 Of course because the CONFIG_INITRAMFS_SOURCE is what causes it to merge the image in. Sep 27 15:36:15 I'll get back to you in a few hours. I plan to get to the bottom of this today, but also have some other things going on. Sep 27 15:36:31 well, it should be triggered by INITRAMFS_IMAGE_BUNDLE Sep 27 15:36:37 Now that I have the problem sitting on my desk as well as the other use cases, we should be able to make it work. Sep 27 15:37:01 jwessel: thx in advance Sep 27 15:37:53 I'm totally lost with fighting with IMAGE_FSTYPES = "live" declared inside image recipe. It is just not picked up even if bitbake myimage -e says it's there. Sep 27 15:38:00 Tried setting this inside python __anonymous inside the same image recipe - doesn't get picked up as well Sep 27 15:38:32 I just have two different images, and one must be "live ext3", second must be "cpio.lzma cpio.gz". Sep 27 15:38:37 Krz-: I had only ever used the IMAGE_FSTYPES += "live" in the local.conf Sep 27 15:39:02 it looks like live works only from conf file Sep 27 15:39:20 I have had all sorts of problems trying to build "live vmdk" for example. Sep 27 15:39:25 One completely pollutes the other. Sep 27 15:39:49 so it means either I build live for both images, or not at all :| Sep 27 15:40:13 I am not sure if you can set it in the image recipe or not. It was never entirely clear to me how this part of bitbake was intended to actually work. Sep 27 15:40:36 It might also be the case that the various inherits cause the breakage as well. Sep 27 15:41:21 whatever value of IMAGE_FSTYPES I set in myimage recipe: bitbake myimage -e shows correctly and builds wrongly Sep 27 15:41:22 I had always thought you could just set the as many fstypes as you want and get certain images. In reality I came to the conclusion of just using multiple build directories. Sep 27 15:41:50 jwessel: I guess we have INITRAMFS_FSTYPES for the same reason Sep 27 15:42:02 Krz-: Perhaps open a bug on it and send some mail to the list. I am not sure if it is a bug or "feature". Sep 27 15:43:57 zeddii: can we check if any problem at server site? tried and see no problem with linux-yocto-3.8 Sep 27 15:53:49 can I kick off 'live' image build other than by specyfing 'IMAGE_FSTYPES' ? Sep 27 15:54:02 like IMAGE_EXTRADEPENDS = "core-image-minimal-rootfs" ? Sep 27 15:57:26 FWIW, I just set IMAGE_FSTYPES += "tar.gz" in an image recipe on dylan and it worked Sep 27 15:57:32 just trying with live now Sep 27 15:59:44 vducuy, just a manual clone should test it. I just tried one and it looks to be cloning fine, with some throttling, but otherwise fine. Sep 27 16:00:02 bluelightning: all but live inside image recipe works for me Sep 27 16:00:14 Krz-: pls use IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" Sep 27 16:00:23 and define the latter in your machine.conf Sep 27 16:00:50 so i.e. the image will have only cpio's Sep 27 16:00:56 ant_work: my machine.conf applies to both images Sep 27 16:01:23 yes, but one image uses INITRAMFS_FSTYPES Sep 27 16:01:34 it works here Sep 27 16:01:49 well, right, the second image uses cpio.lzma and cpio.gz Sep 27 16:01:58 so I can do that for one image Sep 27 16:03:23 ant_work: but... does INITRAMFS_FSTYPES affect live image? since live image I need only in .cpio.gz version :) Sep 27 16:06:07 Krz-: in our machine conf we have INITRAMFS_FSTYPES ?= "cpio.gz cpio.lzma" and in our image IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" Sep 27 16:06:31 so if you want you can have an higher policy Sep 27 16:06:42 like defining in local.conf Sep 27 16:07:02 tbh I never tried 'live' as well ;) Sep 27 16:07:09 ant_work: I can always tweak in core-image-minimal... bbappend, so that's not a problem Sep 27 16:08:15 ah ha Sep 27 16:08:16 http://patches.openembedded.org/patch/16835/ Sep 27 16:13:57 back then the problem was 'live' and core-image-minimal-initramfs Sep 27 16:15:54 Krz-: I think I've figured out what might be going wrong - try moving the IMAGE_FSTYPES assignment above the "inherit image" or "inherit core-image" line in your image recipe Sep 27 16:15:57 ant_work: I have the patch for your use case. Sep 27 16:16:12 I'll send it shortly. I saw the problem right after we chatted but had to go to a meeting. Sep 27 16:16:20 thanks Sep 27 16:16:33 I just tested the patch and it worked, so perhaps you can give it a spin too. Sep 27 16:16:52 sure, in a couple of hours Sep 27 16:16:59 No worries. :-) Sep 27 16:17:16 jwessel: eh.. we have to hurry up or the merge windows will be closed :/ Sep 27 16:17:30 RP: ^^ ;) Sep 27 16:17:31 Well this is a regression. Sep 27 16:17:46 It would be fixed as a defect, with high priority, which is what I am doing. Sep 27 16:18:13 thx, it needs at least one autobuilder run says RP Sep 27 16:18:34 None of the autobuilders will hit this code, but what he said is also true. Sep 27 16:18:51 We simply don't have a test case for this in what the autobuilder line up executes. Sep 27 16:18:57 Or it would have been found already. Sep 27 16:19:00 I think we and zeddii are the only knoen users... Sep 27 16:19:30 oh, JaMa's autobuilder as well Sep 27 16:20:18 bluelightning: it's Krz here, moving IMAGE_FSTYPES above inherits works perfect Sep 27 16:20:45 righto, it was redefined by the include Sep 27 16:20:49 abc: ah ok... the way live images are implemented internally is kind of weird, so they are a bit special Sep 27 16:21:22 sry wrong windows Sep 27 16:23:23 * ant_work lured an arm-soc kernel to OE/Yocto today Sep 27 16:23:48 kernel-dev even Sep 27 16:24:08 what's the reward ?;) Sep 27 16:24:34 ant_work: The patch is sent to oe-core, thanks for sending the failure case to zeddii, who sent it to me. Sep 27 16:24:42 It made it very easy to diagnose how to fix it. Sep 27 16:25:07 ant_work: if he gets h3600 going on a modern kernel, I owe you both beers Sep 27 16:25:17 jwessel: did he send you the pic of the 20Mib kernel embedding core-image-base Sep 27 16:25:21 ? Sep 27 16:25:30 :D Sep 27 16:25:49 ant_work: No, I didn't see any pic's. Sep 27 16:27:49 bluelightning: he didn't know about kernel-tools Sep 27 16:28:11 ant_work: I'd settle for mainline as well Sep 27 16:28:29 upstream they are trying to unify: less kernels and devicetrees Sep 27 16:28:43 maybe he'll convert old PXA Sep 27 16:30:25 that would be neat too Sep 27 16:30:58 jwessel: one question about cpio compression: why do you need to handle it? Sep 27 16:31:20 ant_work: No idea. Someone on zeddii's team wrote that patch. Sep 27 16:31:32 old code could manage .gz and .lzma w/out issues Sep 27 16:31:36 I had to clean it up and make it work with the dependency stuff. Sep 27 16:31:58 If zeddii says it is not needed, lets dump it. I don't like keeping kruft. Sep 27 16:32:14 iirc RP asked about it as well Sep 27 16:32:43 Same answer was provided too. All my test cases passed with and without that part. Sep 27 16:33:22 ok, I'll test with and without once more Sep 27 16:33:46 heading home now, be back later Sep 27 16:51:34 Afternoon! Hopefully an easy question - I've added in an SPI flash MTD driver, seems to detect flash OK, /proc/mtd lists the partitions but yocto doesnt create /dev/mtdX for me. What's the standard way of going about creating hte mtd devnodes under yocto? Sep 27 18:21:24 One of our testers was verifying the PACKAGE_EXCLUDE functionality, and ended up removing the passwd and group files.. well needless to say other things in the system (post install scripts) started failing.. Sep 27 18:22:14 I'm guessing the right answer for this is that we need to check if a passwd/group file was installed (ROOTFS_POST_COMMAND_prepend?) Sep 27 18:22:27 and then print a nice error that hey you don't have a passwd/group file Sep 27 18:31:40 what does INSANE_SKIP do? Sep 27 18:32:28 it's in opencv recipe: INSANE_SKIP_python-opencv = "True" Sep 27 18:32:32 INSANE_SKIP_ will skip one or more sanity checks.. Sep 27 18:32:41 I don't think 'True' is valid Sep 27 18:33:03 not vaild in oe-core? Sep 27 18:33:18 it's all over the place in oe-classic... Sep 27 18:33:24 oe-core Sep 27 18:33:40 contents of INSANE_SKIP_ is which sanity checks to skip Sep 27 18:34:21 I think the union of: Sep 27 18:34:23 WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir xorg-driver-abi \ Sep 27 18:34:23 textrel already-stripped incompatible-license files-invalid \ Sep 27 18:34:24 installed-vs-shipped compile-host-path install-host-path \ Sep 27 18:34:24 pn-overrides infodir \ Sep 27 18:34:24 " Sep 27 18:34:24 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \ Sep 27 18:34:24 perms dep-cmp pkgvarcheck perm-config perm-line perm-link \ Sep 27 18:34:25 split-strip packages-list pkgv-undefined var-undefined \ Sep 27 18:34:25 version-going-backwards \ Sep 27 18:34:26 " Sep 27 18:34:26 is all of them Sep 27 19:13:03 basically I have it in opencv package and I have a problems with opencv Sep 27 19:13:12 it compiles, but the python module does not work Sep 27 19:14:00 when I do 'import cv' on target (uclibc) I receive symbol 'th_comment_query_count': can't resolve symbol in lib '/usr/lib/libtheoraenc.so.1' Sep 27 19:14:16 I checked libtheoraenc and it contains that symbol :( Sep 27 19:15:28 will see what INSANE_SKIP for opencv tries to hide Sep 27 19:24:47 Commented out whole INSANE_SKIP and builds fine. It's probably some leftover. Sep 27 19:34:36 So, I have painted myself into a shiny new corner. Sep 27 19:35:14 I'm working on updates to meta-sourcery, and to get around problems with not being able to compute HOST_PREFIX for multilibs outside of a recipe, I moved some setup stuff into a recipe. Sep 27 19:35:51 And long story short: If there's no sstate cache in sight, the dependency chain results in the extra little bits of code getting run, and all is well. But if the things which depend on this code are in cache, it doesn't get run. Sep 27 19:36:50 And I may be going about this the wrong way. But what I end up wanting is a way to say "if you even THINK about this recipe, then you must execute this code before you do it, whether you then end up building the recipe or using sstate stuff instead". And I don't know of one. Sep 27 19:37:29 (Reason it has to be in a recipe is that if you are not inside a parsed recipe, the multilib fixups for HOST_PREFIX aren't done, so you end up with -vendor- instead of -vendormllib32- in HOST_PREFIX.) Sep 27 20:12:24 zeddii: the fetch failure because my company internet policy blocked session that connect to linux-yocto-3.10 Sep 27 20:13:11 after fix the fetch in-progress now Sep 27 20:13:57 good news. my ran to completion here, so we are good to go. gotta love IT departments :) Sep 27 20:18:30 new policy need to "click" a button to continue for almost new web session.......so terrible for yocto likes development Sep 27 20:55:36 jwessel: ping Sep 27 21:05:31 he's been struggling to figure this out.. Sep 27 21:05:34 oops Sep 27 21:09:08 now I'll play with MODVERSIONS Sep 27 21:21:41 ant_home: With the way I changed things you won't have a problem with modversions. Sep 27 21:22:21 You'll only have a problem with modversions if you have kernel specific modules in the initramfs, in your case as far as I could tell you don't. Sep 27 21:22:42 I'm trying to build your usecase but 'old-style' Sep 27 21:23:07 Well you'll get the circular dependency issue then when you use the INITRAMFS_TASK Sep 27 21:23:34 well, no Sep 27 21:23:47 the container is another recipe Sep 27 21:24:21 The use case I have is building an initramfs for the same kernel I am booting (with kernel modules). Sep 27 21:24:38 Perhaps in your case you have a secondary kernel and hense no problem no dependency Sep 27 21:26:43 if you see my kernel recipes just requires a linux-yocto so it will be the same kernel Sep 27 21:27:46 What is the image showing me that you sent? Not sure what I am supposed to glean from it. Sep 27 21:27:55 and the external kernel doesn't build the modules but uses the ones in the image Sep 27 21:28:28 that you can embedd a full image and its virtual/kernel + modules in one pass w/out circular deps issues Sep 27 21:28:41 even old-style Sep 27 21:29:11 I'll make a change to the INITRAMFS config you sent me to test it. Sep 27 21:29:18 First I'll send a v2 patch. Sep 27 21:36:11 jwessel: casually I'm researching about "[RFC PATCH] Signed kexec support" Sep 27 21:37:04 so secureboot and enforced signing Sep 27 21:37:22 That isn't quite the same thing as MODVERS :-) Sep 27 21:37:24 FWIW Sep 27 21:37:40 heh, it's the same paranoia ;) Sep 27 21:39:11 Ah. so you cannot have a dependency loop in your configuration. You have no kernel modules! Sep 27 21:39:34 % grep =m tmp-eglibc/work/c7x0-oe-linux-gnueabi/linux-yocto-tiny-kexecboot/3.10.11+gitAUTOINC+dad2b7e1ce_e1aa804148-r0/linux-c7x0-tiny-build/.config Sep 27 21:39:39 Nada... Sep 27 21:41:52 If you take for example the qemux86-64 bsp it has some kernel modules. And if I add to the IMAGE_INSTALL += "kernel-module-bonding" for example Sep 27 21:42:28 It will implode because of the circular dependency of need the kernel to be built but waiting for the module from the kernel compile. Sep 27 21:42:38 That is why we have to "2nd stage it" Sep 27 21:43:10 Signing a kernel and the modules for a trusted OS however can be done in the 1st pass. Sep 27 21:43:24 Like in your case if you wanted to sign everything for what ever reason. Sep 27 21:43:59 At any rate, your use cases should no longer be broken once RP merges the patch. Sep 27 21:44:10 jwessel: I did understand that the first kernel has just to boot and mount the initramfs, init then loads the modules Sep 27 21:45:13 ant_home: Sure that will work fine for a single pass if klibc doesn't need the modules. Sep 27 21:45:28 that image doesn't use modules Sep 27 21:45:37