**** BEGIN LOGGING AT Tue Jun 04 02:59:59 2013 Jun 04 03:11:16 weird Jun 04 05:28:23 Any advice on web application frameworks with good support in OE? I use node now, but chose that because I could get something up and running without really learning it :) Jun 04 06:17:58 haven't really looked at that much... lighttpd does have cgi support for a few languages Jun 04 06:32:32 nerdboy: ok. perhaps I should just learn node properly :) Jun 04 06:32:38 | ls: cannot access /home/tasslehoff/src/angstrom-setup-scripts/build/tmp-angstrom_v2013_06-eglibc/pkgdata/*/runtime-reverse/kernel-3.2.28: No such file or directory Jun 04 06:33:29 I get ^ when I have set PREFERRED_PROVIDER_virtual/kernel = "linux-sakoman". Somehow it still tries to use stuff from linux-mainline_3.2.bb. Jun 04 06:35:57 where do you have it configured? Jun 04 06:36:39 in my machine.conf Jun 04 06:36:46 i have conf/machine/include/foo-default-providers.inc Jun 04 06:37:06 where foo is raspberrypi currently Jun 04 06:40:12 nerdboy: beagleboard sets it in beagleboard.conf, so I think that should work as well. the weird thing is that I get both 3.2.28 and 2.6.39 stuff in my rootfs. Jun 04 06:40:36 that's not correct... Jun 04 06:41:17 layer priority maybe? Jun 04 06:42:27 thinking about getting a beaglebone black Jun 04 06:58:38 layer priority shouldn't matter since I have specified machine. Jun 04 06:58:45 hear the bbb is fun :) Jun 04 07:50:16 good morning Jun 04 07:51:00 * florian wonders why mailman does not like him to be subscribed to oe-core but all other lists on the same server Jun 04 07:58:03 good morning everyone Jun 04 08:07:45 morning all Jun 04 08:09:53 morning Jun 04 08:10:36 hi bluelightning, it's been a while Jun 04 08:28:06 morning all Jun 04 08:29:17 hi erbo, apelete, silvio_l_ Jun 04 08:29:48 hi apelete , hi bluelightning Jun 04 08:35:49 good morning Jun 04 08:36:31 hi mckoan Jun 04 08:46:09 hi Jun 04 08:47:44 even after compile success, but i've changed the code and i want to recompile again Jun 04 08:47:58 what shld i run Jun 04 08:48:10 without changing the version Jun 04 08:48:13 pt: hi, do you mean you changed the code in the workdir for the recipe? Jun 04 08:48:30 morning all Jun 04 08:48:35 hi silviof Jun 04 08:48:52 ya Jun 04 08:49:05 and then again recompile Jun 04 08:50:26 some imx6-freescale user here? I have the same issue like here: http://www.mail-archive.com/meta-freescale@yoctoproject.org/msg00033.html Give it a solution for it? Jun 04 08:51:01 thereby no need to fetch code every time again Jun 04 08:51:47 pt: bitbake -c compile -f Jun 04 08:51:52 i tried bitbake -C compile Jun 04 08:52:05 but its nt taking the changes Jun 04 08:52:14 -f is for forcing Jun 04 08:53:13 ok, I can't figure this out. other than PREFERRED_PROVIDER_virtual/kernel, what decides which kernel recipes are used for my rootfs? I have set linux-sakoman/2.6.39, but also get 3.2.28-stuff in my rootfs. Jun 04 08:53:21 pt: -C compile recipename or -c compile -f recipename should work Jun 04 08:53:49 pt: assuming the build system of your recipe knows how to pick up the change you have made Jun 04 08:54:05 (or rather the build system of the software your recipe is building) Jun 04 08:55:38 tasslehoff: I would suggest using bitbake -e to inspect the actual value of PREFERRED_PROVIDER_virtual/kernel Jun 04 08:58:19 actually i've made error(on purpose) in the code, it should give compile error, but its nt Jun 04 08:59:08 about python2 vs. python3: bitbake tells me to use python2 . Even explicitely starting it with "python2 bitbake" wont do. Jun 04 08:59:42 is there a reason for this? isnt it possible to make a check for the python version and launch python again, as a subprocess? Jun 04 09:00:14 it just seems weird that bitbake can detect the python version, but cannot start the appropiate one on its own Jun 04 09:01:36 it is running from compile Jun 04 09:01:47 bt nt taking the changes Jun 04 09:03:05 bluelightning: that gives me linux-sakoman, and linux (mainline) 3.2 is not mentioned at all in the output. still it fails looking for kernel-3.2.28 stuff Jun 04 09:03:22 tasslehoff: what fails exactly? Jun 04 09:03:59 pt: I'd suggest you consult log.do_compile for the recipe Jun 04 09:04:39 dv_: we don't have any specific handling for that, no Jun 04 09:04:46 bluelightning: ls: cannot access /home/tasslehoff/src/angstrom-setup-scripts/build/tmp-angstrom_v2013_06-eglibc/pkgdata/*/runtime-reverse/kernel-3.2.28: No such file or directory Jun 04 09:04:55 dv_: I suspect it may have to do with different distros handling that differently Jun 04 09:05:30 tasslehoff: are you still using denzil? Jun 04 09:05:49 that sounds like a license.bbclass issue Jun 04 09:09:16 bluelightning: one other reason I was considering was that perhaps bitbake itself starts other tools that in turn require python 2 Jun 04 09:09:41 so this would mean that all of these calls need to be patched Jun 04 09:09:52 dv_: bitbake itself does require python 2, but yes I suspect we do call other things that might not be compatible Jun 04 09:10:03 dv_: RP_ has been working on the issue Jun 04 09:10:43 ah, cool. it does feel rather wrong when I do ln -sf /usr/bin/python2 /usr/bin/python on a system that by default uses python 3 :) Jun 04 09:12:12 bluelightning: no, dylan Jun 04 09:12:50 I have a well tested 2.6.39, so now I'm trying to build dylan but with my good old kernel. Jun 04 09:13:41 tasslehoff: ah ok# Jun 04 09:13:54 tasslehoff: so the trick would be figuring out where the reference to 3.2.28 is coming in Jun 04 09:14:30 bluelightning: yes. this build is from scratch. I deleted all the tmpdirs, sstates and caches I knew about Jun 04 09:14:41 tasslehoff: assuming this is a problem in license.bbclass, some judicious use of bb.warn would probably help narrow down the issue Jun 04 09:16:09 tasslehoff: hmm... looking at the code it does suggest that kernel-3.2.28 is listed as installed - is that reflected in the rootfs directory contents within the workdir for the image? Jun 04 09:18:22 bluelightning: yes. I have uImage-2.6.39 and uImage-3.2.28. Jun 04 09:18:57 bluelightning: and uImage is symlinked to uImage-3.2.28 Jun 04 09:19:46 tasslehoff: if you search for 3.2.28 in the output of bitbake -e do you find anything significant? Jun 04 09:20:13 bluelightning: nothing. Jun 04 09:20:43 log.do_compile is giving Shell function do_compile finished Jun 04 09:21:22 bluelightning: and beagleboard.conf is the only one I find that prefers 3.2.28. since I compile for a different machine, that should not matter. Jun 04 09:22:44 tasslehoff: presumably kernel-3.2.28 is listed in TMPDIR/deploy/licenses/imagename/package.manifest ? Jun 04 09:22:50 using qt4-x11-free I have a problem at runtime QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed Jun 04 09:23:10 Am I missing any option? Jun 04 09:23:33 mckoan: I looked into that, was unable to find a cause; my conclusion was to ignore it unless you are seeing actual i18n issues Jun 04 09:23:49 bluelightning: uh, ok thx Jun 04 09:25:00 pt: perhaps look at run.do_compile. Jun 04 09:25:10 pt: and see if it's running what you expect it to Jun 04 09:27:08 bluelightning: yes. Jun 04 09:27:35 ok, so the package manager is definitely reporting it as being installed... OK Jun 04 09:29:01 I can only imagine it is brought in as a dependency of something else; but then why doesn't the pkgdata exist? Jun 04 09:29:11 bluelightning: in recipes-kernel in my layer I have a bb for 2.6.39, and a bbappend for 3.2. do I need default_preference in one of them? Jun 04 09:30:19 tasslehoff: PREFERRED_* are stronger than DEFAULT_PREFERENCE so that should not be needed Jun 04 09:33:34 bluelightning: apart from deleting everything and rebuilding I have no ideas :) Jun 04 09:33:36 lunch now Jun 04 09:34:02 tasslehoff: did you build 3.2.28 previously? Jun 04 09:41:47 tasslehoff: if you do bitbake -D your-image | less can you see 3.2.28 referred to e.g. in "selecting xyz as PREFERRED_VERSION..." ? Jun 04 09:44:37 it is running oe_runmake Jun 04 09:46:17 pt: which should be running make with some arguments, correct? the details will be in that file... Jun 04 09:50:07 while recompiling its entering the src dir and leaving the src dir Jun 04 09:50:13 dng nothing else Jun 04 09:50:57 pt: so that's what make is reporting? Jun 04 09:51:03 but first timr when i compile, its compiling using libtool Jun 04 09:55:07 pt: I have to say, if do_compile running make, which it appears it is, and that is not doing anything in response to your changes, and you're definitely editing the files in the correct working directory ("bitbake -e recipename | grep ^WORKDIR=" will confirm that) then the problem is in the build system of the peice of software in question Jun 04 10:05:18 bluelightning: no, it seems to select only linux-sakoman Jun 04 10:12:10 tasslehoff: I'm a bit puzzled by the fact that you seem to have a symlink pointing to the 3.2.28 version then Jun 04 10:12:33 tasslehoff: because that would seem to indicate that that was built most recently Jun 04 10:25:50 bluelightning: I don't think I even had a linux-mainline folder in TMPDIR Jun 04 10:33:33 tasslehoff: it must have been built surely, or there wouldn't be a file in the deploy directory... ? Jun 04 10:34:42 bluelightning: you'd think so? :) Jun 04 10:35:27 bluelightning: I'll do another clean build now, this time *really* cleaning out. Jun 04 10:35:58 tasslehoff: the trouble with that is if there is a bug somewhere we'll never find it that way Jun 04 10:38:44 bluelightning: I remembered that too, after doing an rm -rf on TMPDIR. sorry. Jun 04 10:47:06 basically I should never have been able to put my working tree in this state with bitbake commands, I guess. Jun 04 10:55:27 is it related to bitbake folder? Jun 04 10:55:35 abt recompilation Jun 04 10:59:39 tasslehoff: normally from what you've described that shouldn't be able to happen, yes Jun 04 11:00:54 pt: did you check that you are editing the files in the right location as I mentioned above? Jun 04 11:13:21 bluelightning: gotta go. will report back when I find out if I can reproduce it. Jun 04 11:30:02 hi all Jun 04 11:36:58 hi Jun 04 11:38:42 its working in one build system and nt in another Jun 04 11:39:26 i have two build systems based on oe-core(base layer) Jun 04 11:39:48 the recompilation worked in one and nt in the other Jun 04 13:43:38 otavio: You use imx6? I have the same issue like this: http://www.mail-archive.com/meta-freescale@yoctoproject.org/msg00033.html with a third party board. Have you a solution for this problem? Jun 04 13:45:54 silviof: Yes; I use Jun 04 13:46:04 silviof: which board? which branch? Jun 04 13:48:16 otavio: i'm currently port my board to use oe and have currently nothing to share... but I use the xf86-video-imxfb-vivante from meta-fsl-arm. Jun 04 13:49:05 silviof: which branch? Jun 04 13:49:39 otavio: master-next Jun 04 13:49:47 otavio: on 990a6c0c5a0c4226e455b32d0bb7b61306ad97d5 Jun 04 13:49:51 silviof: For example, I fixed a segfault in Wandboard and it was related to kernel Jun 04 13:50:11 silviof: it might be galcore not being loaded Jun 04 13:50:19 silviof: does /dev/galcore exists? Jun 04 13:50:48 otavio: i need to boot my board - just a moment Jun 04 13:54:30 otavio: no it does not exists Jun 04 13:54:48 silviof: so, modprobe galcore Jun 04 13:54:51 otavio: what is the modul-name? Jun 04 13:54:53 ah Jun 04 13:54:55 thx Jun 04 13:55:38 otavio: :-) OK It's compile time Jun 04 13:58:02 silviof: add it builtin Jun 04 13:58:05 silviof: CONFIG_MXC_GPU_VIV=y Jun 04 13:58:10 silviof: don't rely in master-next please; it will be rebased today Jun 04 13:59:09 otavio: yea thx Jun 04 15:03:29 bluelightning: about QIconvCodec::convertFromUnicode I noticed that with qt4e we have a plenty of fonts in /usr/lib/fonts, but not with qt4-x11-free Jun 04 15:51:15 mckoan: I think that is intentional, fonts are provided with qt4e because Qt is in charge of the entire system, whereas fonts come via X with Qt/X11 **** BEGIN LOGGING AT Tue Jun 04 17:53:04 2013 **** BEGIN LOGGING AT Tue Jun 04 18:36:00 2013 Jun 04 19:13:52 * mwester catches up with IRC finally, after carefully removing a kitten from his router. Jun 04 19:42:27 BBQ isn't the best lunch to eat at your desk... Jun 04 19:42:41 just sayin' Jun 04 19:44:42 i hope you have a keyboard protector of some sort :) Jun 04 19:46:19 could use a moist towelette... Jun 04 19:53:35 is there a way to extract what SRCREV is currently being used for a package? my coworker seems to recall that you could call bitbake with a command to evaluate a string (ie. echo SRCREV) without actually building the package, but we can't remember or figure it out Jun 04 19:55:15 mbroadst: bitbake your_recipe -e |grep SRCREV= Jun 04 20:05:24 i usually need to check multiple SRC_REVs Jun 04 20:06:19 is there anything better than "find . -name \*bb -o -name \*inc | xargs grep SRC_REV" ? Jun 04 20:07:31 er, SRCREV... Jun 04 20:15:31 doubt it Jun 04 20:24:07 currently 29 AUTOREV git recipes in our custom recipe tree... Jun 04 20:26:03 heh Jun 04 20:26:12 * kergoth is not a big fan of autorev Jun 04 20:26:37 well, we're trying to be "agile" Jun 04 20:26:44 Fast Moving Target Ltd. Jun 04 20:27:08 for mentor's releases, we ship a stripped down copy of persist_data to prepopulate the ref map, so the customer can do BB_NO_NETWORK builds with sources we ship, no contacting upstream, even for autorev recipes Jun 04 20:27:14 makes it slightly less irritating, anyway Jun 04 20:27:48 in our case AUTOREV isn't too bad if it's controlled with some process Jun 04 20:27:55 * mwester generally doesn't like non-deterministic builds. Jun 04 20:28:01 kergoth: nice Jun 04 20:28:19 i also made some nice git verification scripts for post-build analysis Jun 04 20:28:48 creates a build report for all the "important" git recipes Jun 04 20:29:14 http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/recipes/meta/archive-release.bb#n248 ships it with our release artifacts, http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/restore-dumped-headrevs.bbclass restores the dump at ConfigParsed time if it exists Jun 04 20:29:18 mr_science: nice Jun 04 20:29:34 kergoth: sounds cool... Jun 04 20:29:37 mwester: yeah, lots of folks don't Jun 04 20:30:49 if you control what gets merged to the main build branches it works pretty well Jun 04 20:32:24 I prefer having devs point at local clones of git sources if they want to do the equivalent of AUTOREV, with an appropriate class Jun 04 20:32:28 personally Jun 04 20:32:38 the whole ls-remote at parse-time thing makes me sad Jun 04 20:32:42 heh Jun 04 20:32:58 yeah, it's bit us a few times on the nightly builds Jun 04 20:33:26 i'd do it a little different too if it was my choice... Jun 04 20:33:56 mostly i get to implement what people what, and oh, btw, that will be painful... Jun 04 20:34:13 * kergoth nods Jun 04 20:34:55 someday i really want to try doing a minimal oe/yocto build where everything is pulled from a git repository under my/our control, and possibly fetched ahead of time with submodules/repo/whatever Jun 04 20:34:59 no unpack/patch Jun 04 20:35:03 * kergoth Jun 04 20:35:08 still bugs me when a nightly build fails for such a trivial/transient reason Jun 04 20:35:53 sounds even cooler Jun 04 20:35:54 with AUTOREV it's understandable, but with tag=foo it's just sad Jun 04 20:36:16 kergoth: i'll help Jun 04 20:36:24 when you get it approved... Jun 04 20:44:31 * mr_science should pour a few more for kergoth, et al Jun 04 20:44:53 yocto/oe is *so* much better than arago/oe-classic... Jun 04 20:45:50 although some of the pain in the latter stuff is due to many wonky TI packages Jun 04 20:47:05 way more productive in general Jun 04 21:06:08 SyntaxError: EOL while scanning string literal Jun 04 21:06:14 i *hate* this error **** BEGIN LOGGING AT Tue Jun 04 23:42:28 2013 **** ENDING LOGGING AT Wed Jun 05 02:59:57 2013