**** BEGIN LOGGING AT Mon Jun 09 02:59:58 2014 Jun 09 07:11:03 good morning Jun 09 07:16:35 mckoan, morning Jun 09 07:40:20 mornin Jun 09 07:42:09 hi pompomJuice, kroon Jun 09 07:59:49 I need more advice Jun 09 08:00:08 nm Jun 09 08:19:59 I am having so much trouble Jun 09 08:20:55 my image recipy contains inherit sdcard_image. That is instead of inherit image Jun 09 08:21:03 inside this sdcard_image.bbclass Jun 09 08:21:16 I have echo's and bbnotes trying to debug the thing Jun 09 08:21:24 but they wont print anywhere Jun 09 08:22:36 also, somehow there is some sort of convention that turns IMAGE_CMD_sdimg () { ----> into -----> create_image.sdimg Jun 09 08:22:54 that script's output is unobtainable Jun 09 08:22:57 unless it fails Jun 09 08:42:26 morning all Jun 09 08:53:01 morning Jun 09 08:53:51 hi bluelightning, JaMa Jun 09 08:56:18 morning JaMa, mckoan Jun 09 09:12:23 gm Jun 09 09:12:53 morning woglinde Jun 09 09:17:35 hi woglinde, florian Jun 09 09:19:03 hi mckoan Jun 09 09:20:46 morning florian, woglinde Jun 09 09:21:37 morning bluelightning Jun 09 09:48:48 PART2_SIZE_CYL=$(expr ${PART2_SIZE} / ${CYLINDER_SIZE}) Jun 09 09:48:53 someone help plz Jun 09 09:49:08 is $(expr) part of bash or part of the python bitbake system? Jun 09 09:49:27 pompomJuice: bash Jun 09 09:49:39 I am at a loss Jun 09 09:49:52 DISK_SIZE_CYL=$(expr ${PART1_SIZE_CYL} + ${PART2_SIZE_CYL} + ${PART3_SIZE_CYL}) Jun 09 09:49:52 echo "sdcard image size = $(expr ${DISK_SIZE_CYL}*${CYLINDER_SIZE}/1024 ) kB, track size = ${TRACK_SIZE}, CYLINDER_SIZE = ${CYLINDER_SIZE}" Jun 09 09:49:58 I get syntax error on the second line Jun 09 09:50:02 but not the first Jun 09 09:50:06 I just cannot get this thing to work Jun 09 09:50:12 are all variables actually set? Jun 09 09:50:34 the output looks like ---- Jun 09 09:50:35 sdcard image size = kB, track size = 32256, CYLINDER_SIZE = 8225280 Jun 09 09:50:46 with syntax error messages around it Jun 09 09:51:03 the problem is that the logs suffer from race conditions Jun 09 09:51:19 I cant get the proper error messages because the logs chop eachother Jun 09 09:52:21 I just cant see where the problem is Jun 09 09:52:35 I am trying to debug my image creation process Jun 09 09:52:38 but I cant Jun 09 09:53:06 my suggestion to you would be to look at run.do_xyz i.e. the script that actually gets run for the task Jun 09 09:53:50 pompomJuice: right, check the run. in workdir (as already told...) Jun 09 09:54:16 kk Jun 09 09:54:51 then, about second line, it seems strange " kB," Jun 09 09:55:10 yea that is my text Jun 09 09:55:20 size = 14 kB Jun 09 09:55:54 ok I am so sorry Jun 09 09:55:59 the * needs to be excaped Jun 09 09:56:02 escaped Jun 09 09:56:08 omg Jun 09 09:56:11 such noob Jun 09 09:56:17 wasting your time with such bs Jun 09 12:35:21 if anyone had to venture any kind of a guess of changes made to the image creation process I would be very gratefull... Jun 09 12:35:35 something broke... something strange Jun 09 12:36:11 if I do the last steps manually it works, but if they are done via bitbake the images produced are corrupt Jun 09 12:36:41 and only one command is involved, dd Jun 09 12:37:17 I removed vmdk conversions and things... Jun 09 12:42:14 it basically comes down to this command---> dd if=${ROOTFS} of=${SDIMG} conv=notrunc seek=${PART2_OFFSET} bs=${SECTOR_SIZE} Jun 09 12:42:27 I print the variables, then run it manually... then it works Jun 09 12:42:43 and that is the last command that executes... Jun 09 12:43:10 and the process has been working for 3 years now Jun 09 12:43:15 1.6 broke it somehow Jun 09 12:46:04 maybe I should restart my VM Jun 09 12:50:12 pompomJuice: have you checked run.do_xxx ? Jun 09 12:52:13 checking... Jun 09 12:52:19 I have but let me check again to make sure Jun 09 12:52:33 pompomJuice: is it done via do_rootfs_postprocess? Jun 09 12:52:56 no Jun 09 12:53:06 but it feels like a concurrency issue with the creation of ext4 Jun 09 12:53:14 since if I do it afterwards it works Jun 09 12:53:23 im not sure how the thing works Jun 09 12:53:34 basically Jun 09 12:53:46 we have a file in classes called foo_sdcard_image.bbclass Jun 09 12:53:57 that we inherit instead if "inherit image" Jun 09 12:54:07 it's hard to think but maybe some new dd bug (coreutils was upgraded) ? Jun 09 12:54:20 this file contains a IMAGE_CMD_sdimg () that I believe is some form of convention Jun 09 12:54:36 that convention business is breaking since it is running ext4 and sdimage concurrently Jun 09 12:54:38 and it should not Jun 09 12:54:41 or it has started to Jun 09 12:55:01 it uses dd from the box? or does that dd come from sysroots? Jun 09 12:55:30 wasnt there work done in 1.6 for making image creation steps more parallelized Jun 09 12:55:39 ok Jun 09 12:55:42 then it is that Jun 09 12:55:47 what I am seeing is concurrency issue Jun 09 12:56:00 since I dont understand how the IMAGE_CMD_sdimg () { convention works Jun 09 12:56:17 something detects that string and puts it into a chain of commands Jun 09 12:56:52 and runs them in parallel Jun 09 12:57:01 that is my best guesss Jun 09 12:57:02 I guess you specify using http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_FSTYPES Jun 09 12:57:21 no Jun 09 12:57:29 let me check Jun 09 12:57:42 IMAGE_FSTYPES = "ext4" Jun 09 12:57:59 since there is noo native sdimage support as far as I understand Jun 09 12:58:50 as I said I think the way the achieved this sdimage/vmdk thing is broken now... they did it by declaring a custom sdimage.bbclass that inherits from image that has extra steps... Jun 09 12:59:14 these steps are run in paralel with the creation of ext4 Jun 09 12:59:28 which was not before Jun 09 12:59:35 since if I run the command afterwards it works Jun 09 12:59:59 if you want a reference of how one can do it you can look at https://github.com/Freescale/meta-fsl-arm/blob/master/classes/image_types_fsl.bbclass Jun 09 13:00:01 is there a way to specify that one image must be created after another? Jun 09 13:00:07 kk Jun 09 13:00:08 thanks Jun 09 13:00:11 I will check that out Jun 09 13:00:21 right now... Jun 09 13:00:28 don't know how well it fits your pattern, but they also generate a sdimg Jun 09 13:00:39 pompomJuice, https://github.com/Freescale/meta-fsl-arm/commit/3ebe4603e20668e0c038fb136404b580ee5be472 Jun 09 13:01:08 pompomJuice, perhaps you need to do something like that Jun 09 13:01:20 that looks promising Jun 09 13:01:23 let me try it Jun 09 13:42:06 The users, however, have to declare the image dependency using the IMAGE_TYPEDEP variable: Jun 09 13:42:06 Example: Jun 09 13:42:06 IMAGE_TYPEDEP_rpi-sdimg = "ext3" Jun 09 13:42:14 that does not work Jun 09 13:42:26 the other guy had a complicated dependency, I depend on ext4 Jun 09 13:43:08 nm Jun 09 13:43:09 it works Jun 09 13:44:18 thansk guys Jun 09 14:40:36 upgrade to 1.6 is a success Jun 09 14:40:41 thanks for all who helped me Jun 09 14:50:42 pompomJuice haha you figured out the most stuff yourself Jun 09 14:51:18 most of it Jun 09 14:51:31 but there were critical freebies Jun 09 14:51:36 like this last one Jun 09 14:52:10 1.5 - 1.6 was a joy compared to 1.3 - 1.5 Jun 09 14:52:20 1.3 -1.5 madness Jun 09 14:52:38 do you know any recipe suitable to test v4l2 in meta-openembedded? Jun 09 14:53:19 mckoan hm no cheese in there? Jun 09 14:53:22 or gshot? Jun 09 14:53:33 or just try the lowlevel v4l2 commands? Jun 09 14:53:36 ah I know one Jun 09 14:53:37 haha Jun 09 14:53:39 gstreamer Jun 09 14:54:06 woglinde: thx cheese_2.30.1.bb Jun 09 14:58:31 woglinde: I have to capture a still image Jun 09 15:00:30 mckoan possible with gstreamer too Jun 09 15:55:00 otavio: you submitted tufao. have you done anything useful with it? Jun 09 17:13:21 hm krb5 still broken Jun 09 17:13:23 fabo: we're using it for one project! Jun 09 17:13:25 :) Jun 09 17:14:53 hm is there a patch in patchwork for krb5? Jun 09 17:16:22 otavio: it's online? :) I'm pondering to use it for some projects Jun 09 17:16:36 No; closed app of customer Jun 09 17:16:48 JaMa: there? Jun 09 17:17:07 JaMa: I am working at making nativesdk usable for native apps Jun 09 17:17:07 hm patchwork search do not show something Jun 09 17:18:07 hm lets see if brokensep fixing it Jun 09 17:19:21 looks good Jun 09 17:22:10 hm icedtea 2.5 is out Jun 09 17:23:31 hm or just prepared Jun 09 17:56:07 :-) Jun 09 18:45:29 fabo: what are you intending to do? Jun 09 18:45:42 fabo: I have two guys using it so we may be able to help Jun 09 18:46:19 JaMa: I sent an e-mail to meta-oe ml about the issue; please take a look ... Jun 09 18:48:20 otavio, i have no problems running qt5-moc from the yocto-generated SDK here ... Jun 09 18:48:33 kroon: yes but for target Jun 09 18:48:40 kroon: this works like a charm Jun 09 18:48:51 kroon: I want to build tufao in nativesdk Jun 09 18:49:52 otavio, you're running qt5-moc on the target ? Jun 09 18:50:15 kroon: sorry, I mean to cross build it Jun 09 18:50:36 kroon: the native moc is ran fine for target packages Jun 09 18:50:56 kroon: please apply the patches and give it a try Jun 09 18:53:51 otavio, tufao is in meta-openembedded ? Jun 09 19:04:25 kroon: qt5 Jun 09 19:04:38 I sent three patches for it Jun 09 19:05:31 which are pending so apply them byhand and the one of the email Jun 09 19:05:32 otavio, ah Jun 09 19:05:38 so you have same env than I Jun 09 19:05:52 hm looks intressting Jun 09 19:06:14 otavio, ill give it a shot Jun 09 19:17:51 otavio: as you may know, we use jenkins as our build system and lava as the validation/testing system Jun 09 19:18:17 otavio: I'd like to write a web app to aggregate the build and the tests results Jun 09 19:18:34 fabo: ah ok Jun 09 19:18:44 fabo: nice; it does seem to be good for this Jun 09 19:19:34 /win 1 Jun 09 19:19:38 oops Jun 09 19:52:24 hi Jun 09 19:52:45 i see that the autobuilder for lsb-builds has the same warnings as my builds: https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/129/steps/BuildImages_1/logs/stdio Jun 09 19:52:53 "has relocations in .text" Jun 09 19:53:02 how come this warning exist? Jun 09 19:54:33 radhus: it's a known issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6104 Jun 09 19:57:18 ah great. i'll try to add any info i've got. i run a grsec-patched kernel which segfaults as early as on systemd due to executing non-permitted addresses (i guess text sections) Jun 09 20:47:06 bluelightning ping Jun 09 20:48:54 woglinde: pong Jun 09 20:50:13 hm I will short send patches with "The patch is sponsored by" according to http://lists.openembedded.org/pipermail/openembedded-core/2013-December/087190.html it should be okay Jun 09 20:50:35 I will mentioned the last word of richard in the cover letter Jun 09 20:51:15 sounds fine to me, although it shouldn't be contentious Jun 09 20:51:23 it's a good thing to ackowledge sponsors :) Jun 09 21:15:41 okay git-send-email works, now sending to the list Jun 09 21:23:49 heh Jun 09 21:23:58 he crofton Jun 09 21:24:01 We shoudl let companies pay to sponsor emails Jun 09 21:24:12 like sf **** ENDING LOGGING AT Tue Jun 10 02:59:59 2014