**** BEGIN LOGGING AT Mon Mar 24 02:59:59 2014 Mar 24 04:19:22 anybody seen the alsa-lib nativesdk fail yet? Mar 24 04:19:32 configure: error: C compiler cannot create executables Mar 24 04:19:48 config.log says missing crt1.o and a bunch of other stuff Mar 24 08:32:23 good morning Mar 24 09:07:25 mckoan, all, morning Mar 24 09:16:04 Was hoping someone could tell me how to build a TI-gfx driver module together with the kernel modules in the virtual/kernel build Mar 24 09:16:09 the current solution does it afterwards Mar 24 09:16:20 its a hack Mar 24 09:16:24 and it is causing problems Mar 24 09:16:29 I want to do it right but I have no idea how Mar 24 09:25:45 mornin Mar 24 09:30:00 howdy Mar 24 09:30:10 Jin Mar 24 09:30:13 I need help Mar 24 09:30:50 need more understanding about how the kernel sysroots buildup works Mar 24 09:31:30 pompomJuice: I am not sure I can help you with the TI thing, never tried it, can only try to give you general hints Mar 24 09:31:38 no problems Mar 24 09:32:02 i.e. if you have those drivers as some sort of patch you could patch up your kernel (i.e. modify your kernel recipe) and setup the defconfig appropriately Mar 24 09:32:50 aah Mar 24 09:34:17 let me tell you how it is currently working Mar 24 09:34:22 currently we build the kernel Mar 24 09:34:33 but add a custom stem to isolte 3 scripts Mar 24 09:34:37 isolate Mar 24 09:34:40 meaning to back them up Mar 24 09:34:45 it seems the flos is Mar 24 09:34:47 build kernel Mar 24 09:34:50 build modules Mar 24 09:35:09 run genksyms etc. on modules Mar 24 09:36:09 do_install -> This step nukes those scripts that was necessary Mar 24 09:36:28 that is why there is an edit in kernel.bbclass that backs them up to ${D} Mar 24 09:36:36 ok so fart so good Mar 24 09:36:39 lol Mar 24 09:36:41 far*& Mar 24 09:36:43 far* Mar 24 09:36:49 :) Mar 24 09:36:51 now Mar 24 09:37:04 when building the TI modules Mar 24 09:37:13 TI clearly needs a sysroots with kernel headers etc Mar 24 09:37:24 to be more spesific Mar 24 09:37:46 that folder is build/sysroots/machine/... Mar 24 09:38:09 the genksyms ( and 3 other scripts) need to be inside that folder Mar 24 09:38:27 are those modules meant to be built outside the kernel tree? or are their build scripts expecting that you have to build them within the kernel tree? Mar 24 09:38:27 the problem is Mar 24 09:38:42 outside the kernel tree Mar 24 09:38:50 after the kernel has built Mar 24 09:39:08 They need to be inside the build Mar 24 09:39:13 but these are recipies themselves Mar 24 09:39:15 from TI Mar 24 09:39:24 donno how you would patch it into the kernel Mar 24 09:39:33 so Mar 24 09:39:36 back to the hack Mar 24 09:39:39 so the hack is Mar 24 09:39:50 isolate various scripts needed to make modules Mar 24 09:40:09 this is done in the do_install step Mar 24 09:40:16 to restore them though is a problem Mar 24 09:40:28 do_install does a make clean on the source tree Mar 24 09:40:47 then I copy them back to the source tree so that they can land inside sysroots Mar 24 09:40:54 pompomJuice: if those are already recipes then I'd probably wait for someone who is familiar with them, because what I came up with from the top of my head is probably not the way how this thing is supposed to be handled, allthough it could theoretically work but would probably be more effort for you Mar 24 09:40:56 now with old bitbake this worked Mar 24 09:41:23 but the new bitbake checks the files inside systoots for machine compatability Mar 24 09:41:42 and refuses to package those scripts inside the kernel "sysroots" Mar 24 09:42:08 I think you need to convert those recipes properly, I am sure there is a solution to handle these things in the new bitbake as well, but I do not know either, actually I'm currently converting my stuff from old to new as well Mar 24 09:42:48 morning all Mar 24 09:42:52 hi bluelightning Mar 24 09:42:57 hi Jin^eLD Mar 24 09:53:06 hmm, I am still struggling to create a recipe that would be automatically rebuilt eavh time bitbake is run... it worked fine with an older version but it seems I am hitting https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102 Is there any workaround? Mar 24 09:56:12 Jin^eLD: 4102 isn't quite about what you describe Mar 24 09:56:36 Jin^eLD: if you mean a specific task should run every time it is called, did you try nostamp on the task? Mar 24 09:56:54 bluelightning: not task, a full recipe... Mar 24 09:57:21 Jin^eLD: as far as bitbake is concerned it's always about individual tasks Mar 24 09:57:24 let me show you what I mean Mar 24 09:58:08 this is the working recipe from a 1.5 year old OE core https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/dS/meta-dss11-testing/recipes-core/images/dss11-image-version.bb Mar 24 09:58:40 idea here is that my build script dumps a certain version into auto.conf each time a new image is being built, this version is then later used in the UI in that image Mar 24 09:59:26 this recipe builds once with new bitbake, but will fail if I build it for another machine and then again for the other machine or something like that Mar 24 09:59:30 basically it stops working Mar 24 10:00:22 let me dig out the error message Mar 24 10:04:59 ok so it goes like that: build for machine 1 works, do again for machine 2 - works, then do once again for machine 1 - fails Mar 24 10:05:07 fails how? Mar 24 10:05:40 https://pastebin.mozilla.org/4666192 Mar 24 10:06:42 I tried out various things, I also tried setting do_compile and do_configure as nostamp and noexec and whatever (not sure if that would have helped) Mar 24 10:06:49 basically I am stuck Mar 24 10:07:07 this is because the recipe gets reparsed when functions are actually executed, and by then the PRINC value will have changed Mar 24 10:07:17 to be honest I would not implement this in this way - a much simpler method would be to have a function called from ROOTFS_POSTPROCESS_COMMAND which adds the file containing the version directly to the image Mar 24 10:09:23 bluelightning: I need it for live updates Mar 24 10:09:57 i.e. each deployment of live updates gets an own image version, so the image is available for flashing (thats where postprocess would work), but the update can also be installed live via ipk Mar 24 10:10:04 and the image version needs to be updated there as well Mar 24 10:10:37 it worked perfectly fine that way, actually my inspiration for the version file was an older angstrom recipe I think Mar 24 10:10:52 ok... well (a) do not set PRINC, set PV instead and (b) do not use DATETIME, use your DSS11_IMAGE_VERSION Mar 24 10:11:28 (do not use "int(DATETIME)" that is) Mar 24 10:11:29 bluelightning: the image version is a "marketing" version, i.e. it can be any text string not necessarily parsable for ipk Mar 24 10:11:49 that's why I can't set it directly as PV (hence the datetime thing) Mar 24 10:12:01 would datetime for PV work? Mar 24 10:12:07 well, I do not think datetime can work here Mar 24 10:12:26 because it can change during execution Mar 24 10:12:30 i.e. PV ="1.${@int(DATETIME)}" ? Mar 24 10:12:51 so its being reparsed on each task? Mar 24 10:13:37 yes, because the cache does not contain all variables for every recipe, just the ones bitbake needs to look up quickly Mar 24 10:13:39 if you must use something like this you could try BUILDNAME (which by default is set to DATETIME at the start of the build, and stays the same for the build) Mar 24 10:14:07 thanks, let me see if that works Mar 24 10:14:18 you don't need to int() it though Mar 24 10:14:45 and I would advise not using PRINC, use PV Mar 24 10:15:00 (or at the very least, PR directly) Mar 24 10:15:57 ok.. well the old recipe was created though some help on IRC :) I did not come up with that myself, I guess that was OK back then for the old bitbake Mar 24 10:16:03 do I need this PE thing at all? Mar 24 10:16:44 bluelightning: should BUILDNAME show up with bitbake -e ? I can't see it Mar 24 10:16:58 it may not Mar 24 10:17:25 you don't need PE unless you change PV in a way that means it doesn't increase from the last value and you wish to make sure the package upgrades from the last version properly Mar 24 10:18:12 ok, I think I can have a manual PV if I manage to handle autoincrements in PR Mar 24 10:23:23 bluelightning: ok the error is gone but.. it builds it for machine 1 and it does not rebuild it anymore for machine 2 Mar 24 10:25:53 it does always rebuild it for machine 1 though Mar 24 10:25:57 really weird Mar 24 10:26:01 I must be still missing something? Mar 24 10:26:47 Jin^eLD: you might as well set do_install[nostamp] = "1" Mar 24 10:27:12 also als 2ten parameter da den namen vom dss ipk von testing reinschmuggeln Mar 24 10:27:14 oops wrong window Mar 24 10:27:17 :) Mar 24 10:27:21 bluelightning: thanks, let me try that Mar 24 10:29:18 bluelightning: didn't help.. really puzzling Mar 24 10:29:29 I have no idea what could be wrong then Mar 24 10:29:42 let me try -DDD and see if it says something... Mar 24 10:29:51 bitbake runs through without an error but no ipk is being produced Mar 24 10:29:53 for machine 2 Mar 24 10:30:49 this recipe isn't really MACHINE_ARCH, so I don't think that's really correct Mar 24 10:32:20 bluelightning: well, MACHINE_ARCH ensures that the recipe from the build for this particular machine gets into the image... Mar 24 10:32:34 Jin^eLD: er, that alone does not do that Mar 24 10:32:56 dependencies and IMAGE_INSTALL are what do that Mar 24 10:34:35 bluelightning: no I mean, the scripts build the same distro for machine1 and then machine2, so there is a time gap Mar 24 10:34:46 meaning that machine2 would get a different image-version recipe PRwise, although its contents would be the same Mar 24 10:35:34 and since the output of a per-machine build is, apart from the ipk's, also a flashable image, I thought it'd be better if each machine gets the version package from it's own build Mar 24 10:35:36 if you know what I mean... Mar 24 10:36:34 https://pastebin.mozilla.org/ <- does that "could be accelerated" mean that it considers it already built? Mar 24 10:36:49 Jin^eLD: no, it just means it's an sstate task Mar 24 10:37:34 Jin^eLD: you execute bitbake twice though, right? that means two different values of BUILDNAME; so MACHINE shouldn't come into it as far as this recipe is concerned, the different value is already taken care of Mar 24 10:38:16 but I guess in terms of upgrade on the client... Mar 24 10:38:52 bluelightning: well thats the strange thing - I do execute bitbake twice so I expect BUILDNAME to change, I have no explanation why it is not sitting out the ipk for machine 2 Mar 24 10:39:05 I'll clean and try the other way around, i.e. first 2 then 1 and see if the behaviour is consistent Mar 24 10:44:07 hmm ok there must be something wrong related to my machine2 configuration... because even after cleaning it does not spit it out, although it showed that it was doing something, i.e. do_package task was run etc Mar 24 10:50:00 how is the package pulled in? Mar 24 10:50:38 it's a dependency in the image task recipe, i.e. in RDEPENDS Mar 24 10:51:27 in RDEPENDS? shouldn't it be in IMAGE_INSTALL? Mar 24 10:52:05 oh in a packagegroup recipe rather than an image recipe you mean? Mar 24 10:52:10 isn't IMAGE_INSTALL static stuff for image generation? remember, I need things to work with live updates too, yes its a pacakgegroup recipe Mar 24 10:52:34 yes, yes, it's a "task" recipe(in old terms) which inherits packagegroup and specifies dependencies for the image in RDEPENDS Mar 24 10:54:03 for live updates via the package manager it wouldn't make a difference whether it was referred to via the image or a packagegroup Mar 24 10:54:38 bluelightning: the "task" meta-recipe allows me to install new dependencies and remove old ones (via RCONFLICTS) dynamically Mar 24 10:55:32 i.e. I change the RDEPENDS as I need it to pull in other stuff and bump the PR for the packagegroup, and then these things will get pulled in live too Mar 24 10:55:52 Jin^eLD: sure, but in this case it does not matter Mar 24 10:56:07 you mean in the case of the image version? indeed Mar 24 10:56:35 but why do you suspect that the problem is it being in RDEPENDS? Mar 24 10:56:47 I mean, for runtime all that matters is that PV / PR of the version package has increased, and the package is installed, therefore a new version will be downloaded and installed Mar 24 10:56:57 the packagegroup is not involved in that part at all Mar 24 10:57:15 right.. right... but anyway, in my tests right now I was building the package directly Mar 24 10:57:25 i.e. bitbake digitalstrom-image-version Mar 24 10:57:32 so all this dependency stuff was not involved anyway? Mar 24 10:57:45 no I don't think RDEPENDS is an issue, I assumed you were setting that in the image recipe Mar 24 10:58:47 Jin^eLD: it doesn't help the on-target upgrade case (unless as you say you're replacing packages with other packages of different names, but you aren't for the digitalstrom-image-version package) Mar 24 10:59:50 bluelightning: yes for this exact case I'm not and I probably won't, for others I had to do it from time to time, but I think I have some sort of another issue... it refuses to spit out the ipk for one particular machine configuration while it works for the other machine, I am trying to figure out the difference.. because your BUILDNAME suggestion worked just perfectly for machine 1 Mar 24 11:00:10 Jin^eLD: right, so let's move on to that Mar 24 11:00:27 Jin^eLD: it may be worth trying cleaning the packagegroup recipe and trying again (purely as a test) Mar 24 11:00:39 -c cleansstate that is Mar 24 11:00:55 ok let me do that Mar 24 11:01:44 ..for both machines separately, right? Mar 24 11:01:55 let's stick to machine 2 for now Mar 24 11:03:11 ok Mar 24 11:10:41 cleansstate and then build the package again, right? Mar 24 11:11:47 Jin^eLD: correct Mar 24 11:12:21 interesting... no ipk is produced, but it was printing that it did run the pacakge_write_ipk task Mar 24 11:16:23 Jin^eLD: that's very odd - where are you looking for the ipk? Mar 24 11:17:24 in the deploy directory Mar 24 11:17:31 for machine1 I can see it, for machine2 - I don't Mar 24 11:17:57 that's odd indeed Mar 24 11:18:06 I wonder if I messed up somewhere and am not seeing it :) Mar 24 11:18:32 I can't really tell... Mar 24 11:18:49 I'll remove the whole build dir and start new Mar 24 11:19:10 Jin^eLD: could you just rename it? Mar 24 11:19:22 otherwise there will be no way to dig into it later if needed Mar 24 11:20:07 crap... I already removed :P Mar 24 11:21:26 and it was a good thing that I did... I think I might have some misconfiguration somewhere Mar 24 11:21:53 it did not recreate the build directory when I tried to build the version recipe Mar 24 11:21:58 let me recheck my confs Mar 24 11:54:41 Jin^eLD: so what did you find? Mar 24 11:54:59 I am testing my theory but it looks as I may have wasted your time, for which I am sorry :P Mar 24 11:55:18 I was logged in from two shells but had two same configurations on two different accounts Mar 24 11:55:27 so basically I was building on account 1 but looking for the ipk on account 2 :P Mar 24 11:55:31 which is really stupid Mar 24 11:55:51 so I bet it was working all along after I fixed the recipe with the BUILDNAME as you suggested Mar 24 11:56:09 I am still verifying, just takes a while because I nuked the old build directory Mar 24 12:04:19 Jin^eLD: ok, no problem Mar 24 12:04:44 thanks a lot for the help, I'll confirm it works once the build finishes Mar 24 13:32:50 bluelightning: ok, I can confirm now - your suggestion with BUILDNAME works perfectly, thanks a lot! Mar 24 13:36:10 Jin^eLD: ok, np Mar 24 16:44:40 yo Mar 24 16:59:36 koen: anstrom booted on my sama5d3_xplained :-) Mar 24 18:02:05 XorA: but boot was kernelless Mar 24 18:10:12 hrw: no, I added meta-atmel to sources/ Mar 24 18:10:32 XorA: screenshot lacked kernel version I meant ;d Mar 24 18:14:22 hrw: blame koen, default boot screen :-) 3.10+something Mar 24 18:14:43 Linux xora-sama5d3 3.10.0-custom #1 Mon Mar 24 15:30:59 GMT 2014 armv7l GNU/Linux Mar 24 18:15:06 +1 Mar 24 21:34:47 is there a bitbake or bb equivalent of "dpkg -S filename" meaning what package owns filename? Mar 24 21:35:05 that question doesn't really make a great deal of sense Mar 24 21:35:22 we don't know what files will be emitted into a given packge until the recipe has been built Mar 24 21:35:28 sure it does. I have a library that needs to be recompiled. What package do I need to recompile? Mar 24 21:35:42 so use the binary package manager on your device to check Mar 24 21:35:45 how you do that depends on the package manager Mar 24 21:35:51 ah, ok Mar 24 21:36:01 there *is* a command you can use on the build system side, assuming the package has been built Mar 24 21:36:02 alternatively, inspect the buildhistory information about your image, which lists what files and packages went into that image Mar 24 21:36:05 I was hoping to do it from the build machine Mar 24 21:36:46 ok, will try both of those. I just thought there might be some sort of introspection tool on the build side Mar 24 21:36:52 bitbake doesn't provide a great deal of functionality for poking at the results of a build, really. bitbake itself doesn't, but classes do emit data in a form you can look at Mar 24 21:37:08 try: oe-pkgdata-util find-path Mar 24 21:37:32 WARNING: /scratch/2014.05/sstate-reuse-3/build.u1204/tmp/sstate-control/manifest-x86_64-quilt-native.populate_sysroot not found Mar 24 21:37:37 bluelightning: any idea what this means? Mar 24 21:38:02 kergoth: no, sorry Mar 24 21:38:22 interesting, i'll have to play with oe-pkgdata-util more, i always forget it exists :) Mar 24 21:38:57 I'm getting so many sstate reuse problems recently. Seems like every other day I end up with a complete rebuild from scratch blocking progress on my tasks Mar 24 21:39:00 :| Mar 24 21:39:24 with oe-pkgdata-util you'll need to specify the path to the pkgdata directory for your machine, which will be tmp/sysroots//pkgdata Mar 24 21:39:58 kergoth: unfortunately with how the system works when we find a problem we have no way to avoid that Mar 24 21:40:10 a problem with how the signatures are calculated, that is Mar 24 21:40:27 there has been an awful lot of churn recently I know Mar 24 21:40:55 I do think we could improve how the signatures are calculated a bit. Some cases really bug me Mar 24 21:41:05 I sent a change just today which is going to change all do_populate_sysroot signatures unfortunately Mar 24 21:41:13 for example, if the structur eof a variable changes, e.g. an intermediate variable is removed, but the end result value doesn't, that changes the checksum Mar 24 21:41:23 which seems flawed to me Mar 24 21:41:43 kergoth: you can use vardepvalue to explicitly avoid that for situations where it makes sense Mar 24 21:41:48 true Mar 24 21:42:34 My oe-pkgdata-util only has "glob" and "read-value" as commands. Unfortunately "rpm --what-provides /usr/lib/libGAL.so" returned nothing on the target. So, I'm going to re-build my image and see if I can get a filelist. Mar 24 21:43:53 sr105: right, this option only went in in master for the next release Mar 24 21:44:09 bluelightning: ah, thanks Mar 24 21:44:33 Well, there's always grep (and friends). Mar 24 21:45:03 sr105: googling suggests that library is part of the GPU driver for imx6 Mar 24 21:45:20 shouldn't be too hard to find the recipe from meta-fsl-arm that's building that... Mar 24 21:45:33 yeah, I know it has something to do with that. I think I need to recompile the package for a change in the kernel. Mar 24 21:45:42 isn't the way to check for a file with rpm -qf or somesuch? admittedly its been a while since i used rpm much Mar 24 21:45:46 :) Mar 24 21:45:46 just was trying to id the recipe Mar 24 21:46:38 sr105: you shouldn't need to rebuild it, rebuilding the image should make it build that recipe automatically if it correctly has a dependency on the kernel Mar 24 21:47:49 it was just a shot in the dark. I've been switch back and forth between two machines that are nearly identical and I'm getting a segfault in the library that some googling identified as "most likely a library-kernel compile mismatch" Mar 24 21:47:51 Hmm, I wonder if I'm not always wiping my persistent data / cache when I should, when doing local testing. with the automatically spawned pr server, presumably I could have remnant automatic pr bumps floating around in one build but not another Mar 24 21:47:56 * kergoth ponders Mar 24 21:48:06 sr105: how very vague. good luck :) Mar 24 21:48:11 thanks Mar 24 21:48:14 :) Mar 24 21:48:47 catchsegv / gdb to trace it down more closely? Mar 24 21:49:46 sr105: btw, i was remembering correctly, rpm -qf /usr/lib/libGAL.so might have worked better, at least if it is properly package managed Mar 24 21:49:57 * kergoth heads home from the coffee shop Mar 24 21:50:07 That'll be next. Someone else had already posted a stderr log that is identical to mine and they had already done the tracing Mar 24 21:50:14 yep Mar 24 21:50:24 I was just about to say -qf found it. Mar 24 21:51:00 I started with --what-provides because rpm --help scrolled a couple of screens and it came before the query section Mar 24 22:04:49 it appears that my library, libGAL, is a binary deliverable. So, I guess I'll check the kernel. Mar 24 22:21:39 sr105: could consider reporting the issue to the meta-fsl-arm list, maybe they've run into it before, never know Mar 24 22:21:45 * kergoth shrugs Mar 24 22:22:25 I'm trying to exhuast google first. The kernel was given to me outside of any kind of OE build. I built the machine layer around it Mar 24 22:23:04 I just need to find the right patch for the kernel or binary gpu driver version to match my kernel, I think. **** ENDING LOGGING AT Tue Mar 25 02:59:58 2014