**** BEGIN LOGGING AT Wed Apr 08 02:59:59 2015 Apr 08 06:43:31 hi. does anyone have experience setting up icecream/icecc with yocto? it was super simple to enable and the farm is able to compile stuff, but some recipes keep failing due to missing headers (e.g. ncurses can't find stdlib.h). i'm guessing the build env is not sent properly. any ideas on how to debug/fix this? Apr 08 06:46:12 <_4urele_> carbn, i'm using a Black List Apr 08 06:46:14 <_4urele_> ... Apr 08 06:46:47 _4urele_: simply bl every failing recipe? Apr 08 06:48:19 that could work, but i fear there might be a ton of those packages Apr 08 06:53:55 <_4urele_> carbn, I have something like 15 to 20 packages, but it speeds up the process anyway ;), anyhow I thought it was just a matter of build-env generation script Apr 08 06:54:19 <_4urele_> carbn, as far as I saw you can tweak the script Apr 08 07:16:01 good morning Apr 08 07:58:34 <_4urele_> denix, hi, I'm working with meta-ti, building a pandaboard, my kernel fail at configure with "make: *** No rule to make target `oldconfig'. Stop." Apr 08 07:58:55 <_4urele_> i'm on yocto master and meta-ti master Apr 08 07:59:28 <_4urele_> (from yesterday) do you have any idea? Apr 08 08:05:53 When I try to build a PLX driver in YoCto I get EGLUT: failed to initialize native display Apr 08 08:06:34 Anybody know what to do with that? Seems like the fancy make file display they have built in is actally breaking the make process and its not even really needed Apr 08 08:06:47 cd / Apr 08 08:40:19 morning all Apr 08 08:54:45 <_4urele_> hi everyone, i'm using yocto with poky master branch and meta-ti master branch, I'm building for pandaboard. The build is failing at kernel (linux-omap4) do_configure... it says "make: *** No rule to make target `oldconfig'. Stop.", when I go in the build directory it is empty... Apr 08 08:55:02 <_4urele_> if anyone can help... I don't know what to do. Apr 08 08:55:52 <_4urele_> (I checked when the mke oldconfig is executed the PWD is "btmp/work/pandaboard-poky-linux-gnueabi/linux-omap4/3.4-r2a/uild" Apr 08 08:56:57 <_4urele_> I tried to do "cd ../git" it goes further and fail asking a "make mrproper" Apr 08 08:57:12 hmm Apr 08 08:57:49 it sounds like the recipe hasn't been updated for changes in master, but I'm honestly not sure what changes would need to be made... Apr 08 08:58:25 <_4urele_> thanks bluelightning maybe i could use an older commit Apr 08 08:58:45 I would imagine dizzy on both sides would be a safe choice Apr 08 09:00:26 denix: ^^^^ can you maybe tell the state of panda in meta-ti? Apr 08 09:02:38 given the maintenance state of panda altogether, i wouldn't be surprised if the recipes also had seen little love lately Apr 08 09:02:42 I have to admit I'm a bit bothered by this as it suggests there might be changes we should be documenting in the migration guide that we probably haven't Apr 08 09:15:32 many non-yocto kernels needs a simple fix: the S dir must be redefined Apr 08 09:15:49 (after S/B split) Apr 08 09:21:04 <_4urele_> bluelightning, LetoThe2nd, ant_work, thanks for adices, I will try dizzy branch (on poky as there is no dizzy for meta-ti) Apr 08 09:21:38 <_4urele_> ant_work, i will have a look at this S/B diretories maybe ;) Apr 08 09:52:09 hi all Apr 08 09:53:44 using the intel-core2-32 (meta-intel) with the DEFAULTTUNE changed to the "core2-64" in the local.conf is the appropriate option for the Atom N2550 ?? Apr 08 09:53:52 Hey Apr 08 09:54:37 Does anyone know nuts and bolts of EXTRA_USERS_PARAMS? Apr 08 09:54:50 So I'm using it to do a usermod Apr 08 09:57:31 but I've had to adapt shadow as in a read-only rootfs environment and shadow creates temp / lock files under /etc. Obv thing to do is make them under /var/lock as you should. However this gets cross compiled natively and shadow borks in the build process as it tries to resolve the /var/lock and these are symlinks in dev machine rootfs and when the build runs useradd (via pseudo) they resolve to non existant dirs on the dev machine... Apr 08 09:57:40 scratching my head as to the correct approach to fix Apr 08 10:00:09 is there a way to list all tasks invoked by populate_sdk? Apr 08 10:00:18 *usermod not add... Apr 08 10:19:17 Interesting - the perform_usermod works in the build if I hack shadow to use "/run/lock" not "/var/lock" i.e. the link target...? Surely symlinks should work with pseudo -R? Apr 08 10:43:59 Seems like a general thing with pseudo and anything that uses /tmp? Apr 08 11:02:21 ericbutters: bitbake -g ? Apr 08 11:04:03 bluelightning: yes, thanks Apr 08 11:48:03 I'm trying to understand how the autobuilder works... all of the builds seem to say they are from master-next but if I check the commit hash, it might not be in master-next? Apr 08 11:48:07 are these builds someone is running manually for their own branch? Apr 08 11:49:38 or again in english: is someone running these builds manually for their own branch? Apr 08 12:21:07 pidge: ^ Apr 08 12:22:22 hmm, no scponly in yocto/oe ? Apr 08 12:24:42 and/or rssh? Apr 08 12:27:01 jku: We don't automate the builds as the builds take a while and we need to be able to plan autobuilder usage a bit. The commit hash might not be in master-next as that branch can disappear in the middle of a build if RP decides to blow it away. Can I get an example? Apr 08 12:28:35 Hi ! I'm trying to build a kernel module for a custom machine. The conf works well for the qemux86 machine, but I can't figure why it doesn't with mine... (is fails with sysroots/mymachine/usr/src/kernel not found) Apr 08 12:28:48 rink_: I don't believe we have one no, but presumably it would be fairly easy to create a recipe for it Apr 08 12:29:04 bluelightning: alright, I'll dive into that when the need comes, thanks Apr 08 12:29:55 Is there any specific package/feature to enable to build custom kernel modules? Apr 08 12:36:07 CromFr: other than "inherit module", not really no... I assume you are basing your recipe on the one in meta-skeleton ? Apr 08 12:36:59 Hi guys. I encounter a strange issue with poky dizzy. For whatever reason the "pkg_postinst" functions are ignored completely. Is this a known issue? I tested on a dummy package following the instructions in the 1.7.1 manual. Apr 08 12:37:16 bluelightning: yes it's based on the meta skeleton, I just changed the name Apr 08 12:39:23 bluelightning: and it works well with the qemu machine :/ Apr 08 12:40:28 agherzan: no, not a known issue - rpm / deb / ipk ? when creating the image or when installing packages at runtime? Apr 08 12:40:49 rpm and deb at image creation bluelightning Apr 08 12:41:17 agherzan: anything in log.do_rootfs? Apr 08 12:41:28 pidge: ok, that explains it really -- similar commits did end up in master-next with different hashes Apr 08 12:41:29 CromFr: are you also using a custom kernel recipe? Apr 08 12:42:16 bluelightning: absolutely nothing of interest... Apr 08 12:42:54 agherzan: ok, would you mind filing a bug? Apr 08 12:44:28 bluelightning: I disabled recipes-kernel in my layer to be sure Apr 08 12:44:47 jku: yeah, that's what I figured. Apr 08 12:45:04 bluelightning: is there any way i can increase the log level in do_rootfs? Apr 08 12:45:26 i don't even see the respective package mentioned there Apr 08 12:46:50 agherzan: not that I know of Apr 08 12:47:14 agherzan: if the package is not mentioned it sounds like that might be where the problem lies - are you sure it's actually getting included in IMAGE_INSTALL? Apr 08 12:47:16 so there is no way to see the output of the post install script of a specific package? Apr 08 12:47:36 yes - i see it in installed_pkgs.txt Apr 08 12:47:38 hmm, there is some extra logging for those but I have never needed to enable it myself Apr 08 12:48:58 pidge: I was hoping there was an easy way to see if a patch I'm interested in has been through AB (or is currently building). Is that currently very difficult or am I missing something? Apr 08 12:49:08 E.g. currently I'd like to notice when the revised GLib upgrade patch is being built... Apr 08 12:49:17 CromFr: something must provide virtual/kernel, that's supposed to be what installs the files the module is currently not able to find Apr 08 12:51:51 jku: ergh.... hrmmmmm..... I don't think there is a good way to do that right now. Most everything that is in master has been through the AB at least once, however. Generally, things get run through in a master-next and then pulled. But not always. Apr 08 12:54:13 bluelightning: I set the PREFERRED_PROVIDER_virtual/kernel in the machine conf, and I the value is correct (using bitbake -e) Apr 08 12:54:34 bluelightning: hi Apr 08 12:54:50 CromFr: what version of the build system are you using? Apr 08 12:54:51 bluelightning: Here is the machine conf: https://git.thibautcharles.net/snippets/20 Apr 08 12:54:51 the context is that I have upgrade patches that depend on the new GLib -- should I just send them and mention in the message that they shouldn't be applied before GLib upgrade , or wait for GLib to appear in master? Apr 08 12:55:33 jku: I'd say it's fine to send them, just mention the dependency in the cover letter Apr 08 12:56:09 bluelightning: bitbake 1.24 with poky dizzy Apr 08 12:56:22 thanks, I 'll do that Apr 08 12:57:26 bluelightning: i'm sure it's something really stupid... Apr 08 12:59:20 bluelightning: how should i use the meta-intel for 64 bits (i.e. D2550) using the intel-core2-32 MACHINE? is it a good idea to use the DEFAULTTUNE to "core2-64" ?? Apr 08 13:00:13 CromFr: I'm not sure, but I'd be looking at whatever kernel recipe you are building and checking what files it has installed Apr 08 13:00:55 sm0ketst: intel-core2-32 is by definition 32-bit - AFAIK for 64-bit you should use intel-corei7-64 instead Apr 08 13:02:47 bluelightning: but according what BSP description says: "CPUs prior to the Silvermont core." for intel-core2-32 so.. ?? Apr 08 13:03:47 and D2550 is an 64b unit but Cedertrail (< silvermont) Apr 08 13:05:04 sm0ketst: ah right, cedartrail Apr 08 13:05:27 sm0ketst: unfortunately I'm not the best person to ask, you might want to post the question on the meta-intel mailing list Apr 08 13:05:51 bluelightning: ok thanks indeed, ill do Apr 08 13:06:39 bluelightning: ok thank you very much :) Apr 08 13:39:33 j Apr 08 13:54:00 Is there a way to append to a machine config like with bbappend? Apr 08 13:56:50 sm0ketst: I was suggesting the meta-intel mailing list, not the yocto mailing list ;) Apr 08 13:57:25 Cardoe: I'm afraid not... you can do machine-specific customisations from a custom distro config though Apr 08 13:57:36 (by using machine overrides) Apr 08 13:58:10 bluelightning: ok thanks. I'm trying to add another dts file to KERNEL_DEVICETREE and now I'm looking and maybe I can do that with a linux-kernel bbappend? Apr 08 13:58:25 Cardoe: should be possible yes Apr 08 13:59:10 bluelightning: awesome. Thanks. I guess I was approaching it wrong initially. Apr 08 13:59:49 Another question if you might know Apr 08 14:00:17 When using a kernel with an initramfs (e.g. core-image-minimal-initramfs) Apr 08 14:00:31 I'm getting Warning: Cannot create initial console Apr 08 14:01:07 I get no output from the init scripts Apr 08 14:01:14 hmm Apr 08 14:01:29 core-image-minimal is fine but I've obvious got a rootfs somewhere else. Apr 08 14:01:47 Atmel AT91SAM9G25 based board using their layer Apr 08 14:01:51 Booting with U-Boot Apr 08 14:02:05 not sure I'm afraid... Apr 08 14:02:05 I figure the initramfs that Yocto is building wants some extra kernel command line passed in Apr 08 14:02:19 No worries. It was a long shot. Apr 08 14:02:29 AFAICT that's not a message our scripts are writing out Apr 08 14:02:58 I believe its the kernel itself. Apr 08 14:03:06 I'm not sure I find it all over the internet. Apr 08 14:03:24 Fedora users used to run into it a lot when they made some changes to dracut Apr 08 14:17:16 bluelightning: you still around? i think i found out what i was doing wrong - but i don't know why Apr 08 14:17:28 agherzan: yep I'm here Apr 08 14:17:34 what did you find? Apr 08 14:17:43 i was using ${D} and not $D Apr 08 14:18:00 and this was actually creating the files in image dir of the package Apr 08 14:18:16 which is at least strange Apr 08 14:19:45 bluelightning: can you try on a dummy package too? is this an intended behavior? i hope not because is probably the most confusing one :) Apr 08 14:20:50 and we can kill people with this kind of easter eggs :) Apr 08 14:25:27 bluelightning: it seems this is actually intended and mentioned in the manual Apr 08 14:25:47 5.18.2. Post-Installation Scripts¶ Apr 08 14:25:52 oh, yes... Apr 08 14:26:14 it's not so much intentional as a side-effect of the two things having the same name :( Apr 08 14:26:30 in 1.8 we have added a QA check to catch this Apr 08 14:26:36 i get that - but why it was ran at install time? Apr 08 14:26:45 i was expecting to to be ran at all Apr 08 14:26:55 that's the confusing part... Apr 08 14:27:13 why was it run when sorry? Apr 08 14:27:34 uh no Apr 08 14:27:39 i get it now... Apr 08 14:27:41 postinsts are run at do_rootfs time with D set to the path to the rootfs, to give them the opportunity to run at image construction time if it's possible to do so (e..g scripts that create symlinks are entirely safe in that context). if they fail at that point, they're run on first boot instead Apr 08 14:27:49 it actually instals it in the package's image Apr 08 14:27:49 morning Apr 08 14:28:18 kergoth: thanks . I wish you morning was earlier a little :) Apr 08 14:28:27 thanks anyway Apr 08 14:28:32 heh :) Apr 08 14:30:50 kergoth: bluelightning would it make sense to add a warning at do_rootfs time when using ${D}? Apr 08 14:31:02 is there any case when ${D} is used at do_rootfs time? Apr 08 14:31:18 agherzan: the warning we've added is at packaging time for the recipe where the issue is Apr 08 14:31:20 you don't really understand how variable expansion works Apr 08 14:31:37 using ${D} in a postinst will get expanded tot eh full path to the ${D}/image directory of hta tpackage, when the package is emitted in do_package Apr 08 14:31:40 kergoth: might be true Apr 08 14:31:47 by do_rootfs time, the postinst has long had that value hardcoded Apr 08 14:31:57 er, ${WORKDIR}/image Apr 08 14:32:40 kergoth: actually it turned out it had been expanded by the time we wanted to look for it in the QA test as well, so we ended up just looking for the expanded value (which should never be in the postinstall script anyway) Apr 08 14:32:57 exactly my point Apr 08 14:33:08 so we already have a qa check for this case, sounds good to me Apr 08 14:33:19 in master/fido we do yes Apr 08 14:33:30 uh - that's why Apr 08 14:33:39 ok - that's fine then Apr 08 14:33:51 thanks once again Apr 08 14:34:01 np Apr 08 14:45:27 bluelightning: i managed to use populate_sdk, but it builds the cross compiler for the target again using my external toolchain. so is there a way not do build the tc again, just copy tell populate_sdk to copy from the external toolchain directory? Apr 08 14:46:19 ericbutters: at mentor, we just disable inclusion of the toolchain with it entirely, and assume anyone installing the sdk will have the external toolchain already, rather than attempting to redistribute the whole thing Apr 08 14:47:14 see https://github.com/MentorEmbedded/meta-mentor/commit/5217c34c7823d72034521f0b708785a18fb903f2 — basically we remove packagegroup-cross-canadian-${MACHINE} from TOOLCHAIN_HOST_TASK and add back in meta-environment-${MACHINE} Apr 08 14:53:34 kergoth: thanks! but can you please explain what meta-environment-${MACHINE} is? Apr 08 14:54:01 so i mean, what is the result of meta-environment-${MACHINE}? Apr 08 15:22:04 ericbutters: meta-environment provides the environment-setup script in the sdk which you source to set all your variables appropriately for the sdk. CC, CFLAGS, etc. it's important, so you want to keep it Apr 08 15:23:15 kergoth: okay i thought like this.. but good to know Apr 08 15:23:41 also if you leave it out, the sdk installer will hang and never return when it tries and fails to sed the environment-setup scrpt Apr 08 15:23:47 never got around to opening a bug on that.. Apr 08 15:23:56 :) Apr 08 15:24:27 we used to have the TOOLCHAIN_HOST_TASK adjustment in meta-sourcery, but i wasn't sure if it was something we always wanted done for the external toolchain, so left it in the distro config instead Apr 08 15:25:30 thanks Apr 08 15:26:16 np Apr 08 15:28:32 kergoth: i got one more question about that, i used your patch to don't ship a newly built tc, but when installing the sdk i get: SDK could not be set up. Relocate script unable to find ld-linux.so. Abort! Apr 08 15:28:46 the environment script seems to be okay with the path replaced. Apr 08 15:29:37 so the ld-linux.so is the one for the sdk machine?! -- how to get this back in? Apr 08 15:30:12 _4urele_, LetoThe2nd: the old panda-specific recipe wasn't updated with the latest kernel changes in oe-core - latest mainline and/or ti-staging should be used instead Apr 08 17:41:18 Is there a newer Firefox recipe, other than the version 10 in meta-browser? Apr 08 18:21:49 RP: have a chance to look at #7563 and #7564 yet? Apr 08 18:22:14 no rush, just checking status Apr 08 19:21:03 Hi, I would like to know if it is possible to create several packages from one single recipe with Yocto/OE? Apr 08 19:29:30 kido: see PACKAGES and FILES_* Apr 08 19:30:32 thanks! Apr 08 19:34:29 hello everyone, anyone here come from an openwrt environment? Apr 08 20:50:33 kergoth: I think I just merged them earlier today! Apr 08 20:50:56 (to master, too late for 1.8 but could be candidates for 1.8.1) Apr 08 20:52:40 kergoth: nicely tracked down btw, we really need to find a better way to remove some of the duplication in the sstate code paths :/ Apr 08 21:21:17 RP: ah! thanks :) Apr 08 21:21:32 agreed.. it works, though, and we usually have bigger fires to fight :) Apr 08 21:32:13 kergoth: that is all too true... Apr 08 23:43:57 is it reasonable to conclude that bitbake can only support one git:// URI in the SRC_URI list? Apr 08 23:44:24 I was hoping to somehow fetch multiple git repositories and assemble them in the source directory in do_unpack Apr 08 23:44:49 Basically to do what Google's gclient utility does for a build of pdfium Apr 08 23:58:08 bk_lsr: no, that's not true Apr 08 23:59:32 bk_lsr: you add a name to each url, and use that to specify SRCREV. as one example, see cross-localedef-native. specifically SRC_URI, SRCREV_*, and SRCREV_FORMAT. see also gstreamer1.0-omx and linux-yocto Apr 09 00:00:13 kergoth: thanks, i'll check those out Apr 09 00:10:27 kergoth: got it working. what i needed & couldn't find was the destsuffix param. thanks! Apr 09 00:10:36 ah, np Apr 09 02:31:21 Would someone have information on including a Windows version of QEMU in the nativesdk built including the mingw compiler? Apr 09 02:36:39 Guest66260, what do you mean? are you trying to do poky builds under mingw/cygwin? Apr 09 02:37:42 kergoth: yt? Apr 09 02:38:29 I have a requirement to use windows for building applications on top of the root file system. Apr 09 02:39:16 I want to build the SDK for windows including a version of QEMU that can run in windows using the poky image. Apr 09 02:40:08 the meta-mingw builds the GCC cross compiler for windows but I haven't found a way to get QEMU yet. Apr 09 02:40:30 just use the standard yocto sdk mechanisms with SDKMACHINE set to one of the sdkmachines provided by meta-mingw Apr 09 02:40:46 e.g. SDKMACHINE="i686-mingw32" bitbake -c populate_sdk core-image-base Apr 09 02:41:09 then if that doesn't already include qemu, which i think it does, at least for the qemu machines, you can always add nativesdk-qemu to TOOLCHAIN_HOST_TASK Apr 09 02:41:23 khem`: somewhat, whats up Apr 09 02:42:16 Hmmm. This is what I did and I didn't find a Windows based QEMU in the SDK output. Sorry I'm rather new to Yocto. Apr 09 02:45:27 kergoth: I am seeing one issue where I change S and sstate for do_install gets invalidated Apr 09 02:45:42 since in do_install I use ${S} Apr 09 02:45:51 now this change in S is due to externalsrc Apr 09 02:46:12 are there any good ways to avoid this invalidation ? Apr 09 02:46:20 not terribly surprising, not many of our path variables are excluded. just mos tof hte time it doesnt' matter, since it's including their unexpanded values, and those don't include full paths Apr 09 02:46:22 e.g. ${WORKDIR}/foo Apr 09 02:46:40 do_install[vardepsexclude] += "S" is probably your best bet Apr 09 02:47:16 My MACHINE is qemuarm and SDKMACHINE is X86_64-mingw32. Output is only the mingw toolchain, no QEMU. I have not done the TOOLCHAIN_HOST_TASK Apr 09 02:47:26 * kergoth rather liked his checksumming implementation better than the current one in some ways.. it checksummed expanded variables, but kept blacklisted variables as unexpanded Apr 09 02:47:32 Guest66260: output of *what*? Apr 09 02:47:38 you haven't said what your'e building Apr 09 02:47:55 Thanks for the suggestion. I will try it. Apr 09 02:48:06 the yocto sdk includes quite a lot more than just a toolchain, so it sounds like you're not building with -c populate_sdk Apr 09 02:49:32 Guest66260, wouldn't it just be easier to run a virtual machine of the poky SDK image? I'm not sure I'd trust mingw Apr 09 02:49:33 I thought it looked rather sparse. But I also thought I used -c. Guess I should re-run to make sure. Apr 09 02:50:25 It pains me to be in Windows but it's not really my call. Just trying to make the best of it. Apr 09 02:50:32 * kergoth shrugs, hasn't personally targeted mingw, but it should work just like other sdkmachines Apr 09 02:51:21 Guest66260, are you forced to do all the native compilation using mingw or can you simply run a linux virtual machine under windows? Apr 09 02:51:56 A VM does sound like it'd be a lot more pleasant, but not always an option Apr 09 02:54:59 Our formal build team can't use a Linux VM ... yet. Apr 09 02:55:58 I can use a VM but at the end of the day Windows still needs to get involved. We are pushing but it goes slow. Apr 09 02:57:28 * kergoth nods Apr 09 02:57:30 So I was just reviewing what I previously did. I actually ran bitbake -c populate_sdk core-image-minimal Apr 09 02:57:59 But I had thought that was referring to a minimal root file system, not SDK. Apr 09 02:58:29 I'm re-running now with core-image-base **** ENDING LOGGING AT Thu Apr 09 02:59:58 2015