**** BEGIN LOGGING AT Fri Sep 13 02:59:58 2013 Sep 13 06:57:24 good morning Sep 13 06:58:42 mckoan: morning... but where i its more aptly evening ;) Sep 13 07:01:47 raise your hand if it's midnight... **** BEGIN LOGGING AT Fri Sep 13 07:16:32 2013 Sep 13 07:24:14 Crofton|work: hello Sep 13 07:27:50 I don't know if you recall your conversation with cfo215 about Angstrom SDK issue on Ubuntu 12.04 LTS Sep 13 07:32:39 I have also built using this distro and got the same issue Sep 13 07:39:47 hi every one, I have got this issue : ERROR: QA Issue: nativesdk-dbus: Files/directories were installed but not shipped Sep 13 07:39:47 /run Sep 13 07:39:47 /run/dbus Sep 13 07:39:47 ERROR: QA run found fatal errors. Please consider fixing them. Sep 13 07:39:47 ERROR: Function failed: do_package_qa Sep 13 07:39:51 ERROR: Logfile of failure stored in: /sources/poky/buildQtX11toolchain/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-dbus/1.6.10-r6.0/temp/log.do_package.30355 Sep 13 07:39:54 ERROR: Task 1611 (virtual:nativesdk: /sources/poky/openembedded-core/meta/recipes-core/dbus/dbus_1.6.10.bb, do_package) failed with exit code '1'. Can someone help me please? Sep 13 07:40:36 Crofton|work: was there any solution in the end or it did not work on ubuntu ? Sep 13 07:40:52 TuTizz: if you don't care about the QA checking you can just disable the sanity checking of that package or all packages Sep 13 07:41:36 nrossi, should I do it in my local.conf? Sep 13 07:42:40 TuTizz: you should be able to yes, cant remember the variable off the top of my head something like INSANE_SKIP Sep 13 07:43:07 rburton: hi ! I come to you again because still want to port wayland_1.1.0 and weston 1.1.0 to 1.2.0, so I have two question : 1) is there a bug somewhere to put a patch if I found one ? 2) when trying to port wayland in 1.2.0 I got the following error : "wayland-scanner.m4.in: No such file or directory" and (virtual:native:/home/elebideau/ETest/yoctoOpenTizen_test/meta/recipes-graphics/wayland/wayland_1.2.0.bb, do_configure) failed Sep 13 07:43:14 nrossi, ok thanks, I will try to. Sep 13 07:43:28 rburton: thanks for you time again Sep 13 07:51:14 good morning Sep 13 07:52:06 bluelightning sry i had to leave so fast yesterday Sep 13 07:52:39 wfailla: np... I did test local fetching with a URL similar to yours, and it worked here Sep 13 07:52:55 wfailla: the odd thing is that your error showed git:/... instead of git:///... Sep 13 07:53:21 yes that is interesting Sep 13 07:53:39 i guessed that it was resolved somehow by bitbake Sep 13 07:54:53 to initialize the git repo i used "git init" i the dir is that enough ? or do i have to commit more than an initial commit? Sep 13 07:55:54 that was the first time i initialized a git repo so it could be a mistake i made there, too Sep 13 08:03:10 elbc_: so the wayland scanner stuff changed, you'll have to investigate and fix that. just send patches to the list, or file a bug, your choice. Sep 13 08:03:55 that was my question. no bug listed about this issue for the moment ? Sep 13 08:04:47 not yet Sep 13 08:04:58 ok, so where can i create a bug ? Sep 13 08:05:08 bugzilla.yoctoproject.org Sep 13 08:05:12 ok thanks Sep 13 08:22:45 wfailla: well to be a real test the repo should probably have something in it :) Sep 13 08:25:32 jes i have 3 files in there with there own commit ... it is only for testing how bitbake will name the binaries when using AUTOREV Sep 13 08:25:36 *yes Sep 13 08:26:47 elbc_: if you file a bug please cc ross.burton@intel.com Sep 13 08:28:46 ok no problem ! Sep 13 08:31:46 bluelightning i can not find any reference to how bitbake is naming its binaries in the yocto, openembeddet or oe-core documentation, can u point out a good manual where this is explained well? Sep 13 08:32:07 wfailla: sorry, what do you mean by binaries? Sep 13 08:33:04 the naming of the pkg.ipk or pkg.deb that bitbake "bakes" Sep 13 08:36:17 wfailla: I don't think that is documented anywhere Sep 13 08:36:55 wfailla: I don't think there's a central location where the output package name format is decided either; I believe it's in each specific package backend i.e. package_*.bbclass Sep 13 08:37:30 the variables for the individual pieces of the name that are involved are standard though - PKG, PKGE, PKGV, and PKGR Sep 13 08:37:40 well then i know what i need to look for Sep 13 08:37:50 (so these can be different to , PE, PV and PR) Sep 13 08:38:23 i saw those in the bitbake.conf ... so if i change them i can change he naming Sep 13 08:38:24 hi Sep 13 08:38:51 wfailla: to a degree yes; debian.bbclass changes PKG for library packages for example Sep 13 08:39:51 I've added line to my recipe do_install { install -v 0775 lib/*.so ${D}} but then build fails with: debugedit: canonicalization unexpectedly shrank by one character Sep 13 08:40:22 well i am using opkg maybe there is a opkg.bbclass Sep 13 08:40:38 wfailla: package_ipk.bbclass Sep 13 08:40:51 ok Sep 13 08:41:56 is that correct way of installing all libs or do I need to do it one by one? Sep 13 08:43:26 mbelisko: install to ${D}${libdir} Sep 13 08:43:42 otherwise you're installing to /libfoo.so Sep 13 08:44:58 rburton: destination was only example Sep 13 09:22:05 rburton: I think I'm I'm seeing the end but still one error : checking for GLU... no | checking for COLORD... no | checking for WCAP... yes | checking for rsvg-convert... no | checking for SETBACKLIGHT... yes | configure: Weston's native backend: drm-backend.so | checking for LCMS... no | /home/elebideau/ETest/yoctoOpenTizen_test/build-thinkpad/tmp/work/x86_64-poky-linux/weston/1.2.0-r0/weston-1.2.0/configure: line 16156: syntax error ne Sep 13 09:22:15 yntax error near unexpected token `'$(top_srcdir)/protocol'' | /home/elebideau/ETest/yoctoOpenTizen_test/build-thinkpad/tmp/work/x86_64-poky-linux/weston/1.2.0-r0/weston-1.2.0/configure: line 16156: `WAYLAND_SCANNER_RULES('$(top_srcdir)/protocol')' | Configure failed. The contents of all config.log files follows to aid debugging | ERROR: oe_runconf failed Sep 13 09:22:43 this line : | /home/elebideau/ETest/yoctoOpenTizen_test/build-thinkpad/tmp/work/x86_64-poky-linux/weston/1.2.0-r0/weston-1.2.0/configure: line 16156: syntax error near unexpected token `'$(top_srcdir)/protocol'' Sep 13 09:22:47 and this one : Sep 13 09:22:52 | /home/elebideau/ETest/yoctoOpenTizen_test/build-thinkpad/tmp/work/x86_64-poky-linux/weston/1.2.0-r0/weston-1.2.0/configure: line 16156: `WAYLAND_SCANNER_RULES('$(top_srcdir)/protocol')' Sep 13 09:23:15 wayland has built in 1.2 Sep 13 09:23:23 so there is just weston missing Sep 13 09:23:45 elbc_: wayland is probably meant to be installing a m4 file Sep 13 09:24:20 rburton: do you have suggestions ? Sep 13 09:25:08 elbc_: not without looking at the recipe and doing it myself, no Sep 13 09:25:30 do you want my weston recipe ? Sep 13 09:26:16 rburton: I'm still try to find a solution, I'll tell you if it's the case Sep 13 09:45:40 hi i have been trying to set the hostname of my distro by changing the hostname_pn-base-files variable but it dose not work Sep 13 09:46:54 Hey, does anyone here have a clue on how to go about troubleshooting issues with SSL? We have ca-certificates as part of our image, but after Amazon upgraded their certificate, we've been getting "Self-signed certificate" errors when trying to wget something from their servers. Sep 13 09:47:05 Anyone encounter something like this, and maybe have any hints at how to troubleshoot it? Sep 13 09:47:24 i have two layers in the one layer the variable is set to lng in the conf/distro/lng.conf file and in the other layer it is set in the conf/machine/router.conf Sep 13 09:48:55 th lng.conf contains a hostname_pn-base-files = "lng" and the router.conf contains a hostname_pn-base-files_append = "buffalo" Sep 13 09:49:23 when i execute bitbake core-image-lng -e it will set the hostname_pn in the correct way Sep 13 09:49:33 but the hostname it self is still LNG Sep 13 09:49:36 well lng Sep 13 09:50:42 Stygia: is this just a case of needing to use a newer upstream ca-certificates version? Sep 13 09:51:04 Stygia: just a thought, I don't have any specific experience with this kind of issue Sep 13 09:52:37 bluelightning, That could be, but it's being fetched from a debian source, and I am on debian, where things work. Though I _am_ on testing, an the link on stable. Sep 13 09:52:51 bluelightning, Hmm. How would I overwrite a specific URL in SRC_URI without overwriting the patch files included? Sep 13 09:53:11 I want to replace the link there with the one from sid, but I don't think I should just set SRC_URI again and take the patches out. Sep 13 09:53:40 Stygia: you can't really, you need to set the full SRC_URI again Sep 13 09:53:46 Then again... maybe I should if I"m gonna be using a new version, yea/ Sep 13 09:53:47 ? Sep 13 09:55:13 bluelightning, I'll try building it with the package from unstable instead of stable.:) Sep 13 09:55:55 bluelightning, Have been banging my head against this for ages, though... I know the certificate chain. I have all 3 certificates in the chain installed (Well except the lowest-level one but that's not how SSL works AFAIK), and they have the same link structure and md5sums. Sep 13 10:17:53 Hi, Sep 13 10:18:37 Have a question about linux-libc-headers Sep 13 10:19:55 I wrote own recipe which uses requires linux-libc-headers-yocto_git.bb Sep 13 10:20:28 I have set PREFERRED_PROVIDER_linux-libc-headers in machine conf Sep 13 10:21:18 This version is for specific git version and I want to create copies of this recipe and change the SRC_URI for other git branches Sep 13 10:21:33 however it doesn't find the branches when I compile the image Sep 13 10:21:45 * it doesnt find the branch which is set Sep 13 10:22:14 it says "preferred version xxxxxx of linux-libc-headers not available" Sep 13 10:22:27 but it is availabe . Why doesnt it see it? Sep 13 10:23:25 Can anybody give any tips on this? Sep 13 10:40:58 Guest42914: you probably have a stale git checkout based on the original recipes; try '-c cleanall' on the recipe so that it fetches the repo again Sep 13 10:45:37 tf : ok I try from scratch again Sep 13 10:45:40 also, unless you intend to / need to use two different versions of the headers, you would be better using a bbappend Sep 13 10:46:37 tf : The new libc-header .. is using my own git repo . And the copies will be set in different DISTRO files Sep 13 10:47:14 right Sep 13 10:47:37 if the repo url is different from the other repo url, then there is something not right in the recipe Sep 13 10:48:25 tf : the branch is the only thing that I define in the copies Sep 13 10:49:46 define how? Sep 13 10:57:42 Guest49245: Why do you need your own linux-libc-headers? That is never nornally a good sign :/ Sep 13 10:58:04 Guest42914: Sorry, ^^^ Sep 13 10:58:58 tf : SRC_URI = "git://git@xxx;protocol=ssh;branch=${BRANCH}" in first copy Sep 13 10:59:03 and then in copies... Sep 13 10:59:10 $BRANCH = ... Sep 13 10:59:45 RP: The linux-libc-headers is needed because some recipes need the linux headers for compilation Sep 13 11:00:06 Guest42914: You have your own special libc that needs extra headers? Sep 13 11:00:33 We have our own linux kernel Sep 13 11:00:55 Guest42914: Right, but not your own special C librbary? Sep 13 11:01:26 I guess not Sep 13 11:01:27 Guest42914: What you probably want to do is use the headers in STAGING_KERNEL_DIR Sep 13 11:01:57 RP: the libc is compiled before the kernle Sep 13 11:02:03 linux-libc-headers are meant for libc and if you change that you are making the whole system (anything compiled against libc machine specific) Sep 13 11:02:36 Guest42914: actually, libc and the kernel can compile at the same time, the kernel doesn't depend on libc Sep 13 11:02:55 ok, I dont fully understand it Sep 13 11:03:39 Guest49245: you should have a DEPENDS on virtual/kernel and use the headers in STAGING_KERNEL_DIR Sep 13 11:03:44 however, when I just use the STAGING_KERNEL_DIR, it doesnt copy the drivers *.h which we have created Sep 13 11:03:52 to the kernle Sep 13 11:04:07 Guest42914: then make copy them in the patches where you add the headers? Sep 13 11:05:20 In the kernel recipe I have adde an append to some function.. to copy those additions which we have done .. and that works... Sep 13 11:05:42 but is it a hack Sep 13 11:06:01 Guest42914: hack your kernel recipe, not the core libc headers ;-) Sep 13 11:07:16 RP: how can I know which order the compilation is done... libc ..kernel.. Sep 13 11:07:19 ? Sep 13 11:08:02 Guest42914: its done by dependencies. the kernel does not depend on libc, it just depends on the c compiler being available Sep 13 11:09:52 RP: and the c compiler needs one libc ;) Sep 13 11:10:09 RP: Guest42914: hi Sep 13 11:10:18 hi Sep 13 11:11:19 ant_work: no, the C compiler doesn't need a libc Sep 13 11:11:34 ant_work: for userspace compilation the C compiler needs a libc Sep 13 11:12:15 RP: gcc-glibc is a chicken-egg...as in Gentoo you have toreemerge both after glibc upgrade Sep 13 11:12:24 Guest42914: I'm going to propose this patch http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=5a15caa3921d218f178364dbafc7253cf7f67839 Sep 13 11:13:23 ant_work: Obviously I'm completely clueless how the toolchain builds having only written a lot of the modern bootstrap process ;-) Sep 13 11:18:15 RP: I don't know what Guest42914 is compiling (driver?) but there was this thread about installing headers Sep 13 11:18:17 https://lists.yoctoproject.org/pipermail/yocto/2013-September/018083.html Sep 13 11:19:28 ant_work: My comments stand, nobody should be needing to change this recipe. Sep 13 11:19:50 well, anyone wanting a custom libc is fine to do so but those people are exceedingly rare Sep 13 11:19:59 right Sep 13 11:20:20 in 99% of the cases you're fine compiling against sanitized headers Sep 13 11:20:21 ant_work: RP: I am compiling use space daemons libs some of which need linux headers Sep 13 11:20:43 *user Sep 13 11:21:06 Guest42914: I get that but you should get them from STAGING_KERNEL_DIR Sep 13 11:21:42 Guest42914: these userspace deamons/libs are specific to your kernel situation Sep 13 11:22:02 yes Sep 13 11:22:24 yep, the rest of userland has no use so don't touch linux-libc-headers :) Sep 13 11:27:53 RP: ant_work : ok . thx. I have to discuss this a bit before I do more. Sep 13 12:31:12 seebs: any idea about https://bugzilla.yoctoproject.org/show_bug.cgi?id=5132 ? Sep 13 12:31:13 Bug 5132: normal, Medium+, 1.5 M5, peter.seebach, NEW , pseudo: Different file attributes detected by buildhistory Sep 13 12:33:05 hi i am playing around with the prservice ... and i am wondering what is the 0+ in the beginning of the SRCPV for ? Sep 13 12:33:43 this seems to not change at all no madder what i do Sep 13 12:34:49 wfailla, Not sure what you mean, post the line in question here? Sep 13 12:35:12 opencapwap-dev_1.1.6+git0+c10709025da6b6dc6b016e0e922d8d5459944e42-r5.5.6.3.0_mips32-nf.ipk Sep 13 12:35:29 opencapwap-dev_1.1.6+git --> 0+ <-- c10709025da6b6dc6b016e0e922d8d5459944e42-r5.5.6.3.0_mips32-nf.ipk Sep 13 12:35:53 PV := "${PV}+git${SRCPV}" Sep 13 12:36:51 wfailla, Ah, hmm. Nope, sorry, no idea what that is. I've noted the same thing but not thought too much about it. Sep 13 12:37:58 i thought it might be the difference between the last used git revision and the one used now which would be a good thing but its not Sep 13 12:38:06 it just stays 0 Sep 13 12:46:35 wfailla: this number should auto-increment if SRCREV changes but only if you have enabled the PR service Sep 13 12:47:35 i have it enabled but somehow it dosenot change the number i will look into the .sql file in a sec after the build Sep 13 12:48:05 sry .sqlite3 Sep 13 12:50:46 oh yes now it works Sep 13 12:53:12 wfailla: ok great Sep 13 12:54:32 yes i had to test something else and had to stop testing th pr-serv and i got confused ... i will have to stop doing two things at once Sep 13 12:55:10 hi Sep 13 12:56:45 i've spent all the day trying to build Qt4.8.x using ltib and each time something went wrong (mouse not working using eglfs) or x11 not working at all with x11 build Sep 13 12:56:55 i'd like to have some of your insights please Sep 13 12:57:28 i'm using imx6 sabre auto board, and would like to build Qt 4.8.x on it, i was lost reading all the cute yocto documentation Sep 13 12:57:56 anyone knows or have previously read some papers regarding Qt build on imx6 board please ? Sep 13 13:09:18 Hi, im trying to add a .bb to a disc image, i can build the package using bitbake but when i try to build the image it says ERROR: Nothing RPROVIDES '-2.5.1' even though i added the package as just in the image recepie. What am i doing wrong? Sep 13 13:11:40 If i change the recipie from _2.5.1 to -2.5.1 it finds it but then the license file cant be found Sep 13 13:12:16 that sounds strange Sep 13 13:12:42 normally the recipe would be called _2.5.1, so changing that to - isn't the right way to fix this Sep 13 13:12:59 BjornArnelid: are you using master? Sep 13 13:14:56 I did change the names of the package files earlier, could it be temporary files messing it up? Sep 13 13:16:42 BjornArnelid: it would need to be mentioned somewhere in one of your recipes or configuration for that specific error to be happening Sep 13 13:17:33 BjornArnelid: do bitbake -e | less and search for -2.5.1 to see where it's coming in Sep 13 13:41:32 hi, in poky-tiny.conf the value of PREFERRED_PROVIDER_virtual/kernel in hardcoded. I was wondering where the configuration for the tiny kernel as since I don't see any definition for KMACHINE Sep 13 14:19:53 ERROR: Function failed: do_kernel_configme Sep 13 14:54:16 jwessel: I think I might have realised some of your problem with the memory resident bitbake Sep 13 14:54:24 thank u to everyone in this channel u were a big help to me Sep 13 14:54:30 RP: Which ones? Sep 13 14:54:33 jwessel: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=423c5592d86e72ad8ea117179b310b7acd13f34e might help Sep 13 14:54:37 I was building up a list. Sep 13 14:54:56 wfailla: np Sep 13 14:55:02 I have 3 problems Sep 13 14:55:08 jwessel: ok Sep 13 14:55:18 1) If you erase / move a recipe, the bitbake doesn't notice. Sep 13 14:55:31 2) bitbake -v -v doesn't give you anything Sep 13 14:55:49 3) With the real time logger code merged, I get timouts on parse start. Sep 13 14:56:10 So your change you mentioned, does that affect #1 ? Sep 13 14:56:11 jwessel: the patch about should help 1) Sep 13 14:56:20 s/about/above/ Sep 13 14:56:29 That was the one that was probably the worst. Sep 13 14:56:52 4) (found in my notes) is the that if you switch from one startup script to the other it is not a clean cut over. Sep 13 14:56:56 The log levels need to be set on the invocation that went into memory, the client isn't clever enough to change them itself yet Sep 13 14:57:13 We should likely test for the env and shutdown the server because the user experience is not very clean. Sep 13 14:57:21 so 2) can at least be understood Sep 13 14:57:37 jwessel: that sounds like a good idea, yes Sep 13 14:57:41 Oh I understand why it doesn't work, I am just compiling the list of what we need to do. Sep 13 14:58:02 As we talked at a different point this is about shaping it up so it can one day be the default. Sep 13 14:58:04 jwessel: right, I'm looking at these from an understanding perspective :) Sep 13 14:58:25 The only one I didn't understand why it was broken was the #3 Sep 13 14:58:39 I haven't had time to debug it as of yet. Sep 13 14:58:39 jwessel: right, you know more about #3 than me... Sep 13 14:59:34 I'll probably ask you some more about #3 after we can make head way on 1 & 2. Sep 13 14:59:49 This was a prioritized list ;-) Sep 13 15:00:02 ok, well try the patch above and see if that fixes #1 :) Sep 13 15:00:43 Where the priority was == to my personal as a developer Sep 13 15:01:09 Yes. I'll try it out after I finish up working over the UEFI series. That looks fairly promising. Sep 13 15:01:36 jwessel: I ran into it a short while ago whilst discussing webhob patches Sep 13 15:04:23 I made it most of the way through the typical activities I would use it for with the background bitbake. Sep 13 15:04:48 I am still need some help, I do not fix the "QA Issue: nativesdk-dbus: Files/directories were installed but not shipped /run /run/dbus" I found this on inet but I did not found where the patch is (http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39477), nrossi already tell me to look at INSANE_SKIP but I did not found what parameter I shoud take :(. Sep 13 15:05:37 jwessel: hopefully with a few tweaks we can get all the way through :) Sep 13 15:05:43 5) Auto port selection and writing it to a file will be needed too. Sep 13 15:05:59 The final problem I had hit was using multi instance builds. Sep 13 15:06:23 Because I literally just swapped out the init scripts and tried my builder as well. Sep 13 15:06:54 bitbake.lock might be a good place Sep 13 15:07:09 It fell over really fast, but this could be worked around with a call to python, perl or anything to obtain a port with SO_REUSE(or what ever) and then use that socket write it out and spin up. Sep 13 15:07:39 Another way around this would be, Sep 13 15:07:58 jwessel: yes, the hardcoded port is an issue, I'd forgotten about that. Was on my "to revisit later" list Sep 13 15:08:03 instead of: bitbake --server-only -t xmlrpc -B localhost:$port Sep 13 15:08:13 Do something like: bitbake --server-only -t xmlrpc -B localhost:AUTO Sep 13 15:08:20 and write out the file with the port number. Sep 13 15:08:22 jwessel: yes, exactly Sep 13 15:08:32 Then we can just complete the action in the init. Sep 13 15:09:05 I figure at some point you thought about most of this, but there was no formal TODO list. Sep 13 15:09:27 jwessel: right Sep 13 15:09:55 jwessel: all good feedback, thanks Sep 13 15:12:03 Thanks for making it possible to test it all. I'd say it is in general a major leap in the right direction. Sep 13 15:12:03 I still get the extra parse as well on the first go, but that appears to be a function of setting up the hob data, which I am not actually using. Sep 13 15:12:03 Down the road that is a possible optimization, but I'd rank that lower than anything else Sep 13 15:12:25 6) Stop the extra initial parse if you have a valid cache or building of the hob data unless it is the hob using the instance. Sep 13 15:25:33 [help] Can anyone help me: do_fetch(git) failed, how can I git clone manually? Sep 13 15:28:13 TonyHo: while you could clone manually, i think you should try to resolve the intial problem first, otherwise it might be painful to make a build without a working git fetcher. Sep 13 15:30:50 Just some of them failed Sep 13 15:30:53 damn, getting rm: invalid option -- ''' out of opkg-build in do_package_ipk. odd Sep 13 16:06:14 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Statushttps://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status#Milestone_4 Sep 13 16:07:04 can someone repost the release criteria link please? Sep 13 16:07:19 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status Sep 13 16:07:24 thx Sep 13 16:07:35 https://wiki.yoctoproject.org/wiki/WW36_-_2013-09-05_-_Full_Pass_Release_1.5_M4.rc3 Sep 13 16:08:54 sgw_, is that the release criteria link? Sep 13 16:29:42 dvhart: ping Sep 13 16:30:36 jwessel, afk for 5... brb Sep 13 16:31:04 dvhart: No worries, you can read this when you get back and comment then. Sep 13 16:31:29 I did a bunch more research after your comments about the 2048 block size. Sep 13 16:31:44 Turns out that there is more to it (there always is eh?). Sep 13 16:32:32 It is not the device, it is the rootfs. The real reason I was not able to hybrid boot is that we don't have Matthew Garrett's changes in our syslinux. Sep 13 16:33:01 There is a new function that was added to write a gpt table beyond the mb but less than the 20k where the ISO actually starts. Sep 13 16:33:10 beyond the mbr that is. Sep 13 16:33:58 Using the latest cdrtools + the latest syslinux (which upreved so I could get Mathew's changes). I have media that ISO boots on BIOS, ane EFI with a disk. Sep 13 16:34:15 AND my mega, mega buggy firmware. Sep 13 16:34:31 I still have to try this on the 64 bit target, but it looks very promising. Sep 13 16:36:47 AWESOME Sep 13 16:36:57 if it works on 32b, 64b should be a freebie Sep 13 16:38:46 Well you still have to make 2 iso's because the EFI loader is 32 or 64. Sep 13 16:39:05 And the kernel community has explicitly stated (which you probably know), that we aren't doing cross loading. Sep 13 16:39:25 meaning no 32efi loading 64 bit kernel etc... Sep 13 16:40:47 So your clues about 2048 are correct, but the real problem was the lack of the gpt table just after the MBR. Thankfully all our images are 2048 block size for the MSDOS so we are good. Sep 13 17:51:03 I am building my first Yocto build after the Quick Start guide. Sep 13 17:51:11 doing it for Raspberry Pi,, Sep 13 17:51:27 i have added the meta-raspberry pi layer in the poky directory Sep 13 17:51:38 and made appropriate changes in the localconf file Sep 13 17:51:57 but i get an error stating ERROR: OE-core's config sanity checker detected a potential misconfiguration. Sep 13 17:52:15 Please set a valid MACHINE in your local.conf or environment Sep 13 17:52:44 i am following the instructions as given in the README file of meta-raspberry file Sep 13 17:54:24 export MACHINE=whatever the rpi is called in oe? Sep 13 17:54:34 got it.... Sep 13 17:55:29 I made a typo in the conf/bbconf file, while adding the layer... The build has started as of now, Parsing recipies... will wait till it suceeds Sep 13 17:55:35 :) Sep 13 17:55:38 GeekGirl: are you using the minimal djwillis layer? Sep 13 18:02:12 GeekGirl: take a look here if you want a more full-featured xorg image and set of recipes... Sep 13 18:02:25 https://github.com/sarnold/meta-raspberrypi/wiki/Raspberry-Pi-Openbox-MPD-Image-Setup <= shameless plug Sep 13 18:03:13 plus it's fully tuned for hardfloat with no thumb Sep 13 18:17:59 yes mr_science i am using the djwillis layer... Sep 13 18:18:24 yeah will surely do look at that layer Sep 13 18:19:14 i am trying to figure my way around the layers as of now.. Sep 13 18:19:23 trying to take a grasp at things Sep 13 18:24:58 that's a fork of the original djwillis layer Sep 13 18:25:46 build setup is mostly the same, except for bblayers and local.conf Sep 13 18:26:31 i still need to make those available... Sep 13 18:27:30 so if you want to build my fork, you should ping me about the config files Sep 13 18:27:30 or nerdboy if it's after PDT working hours... Sep 13 18:29:21 okay... as of right now.. i wanna dif into the bbclass files and alll... my main interest is to develop Distro with my custom kernel, i am more interested into kernel hacking Sep 13 18:29:44 Next up: patching Xenomai onto the linux kernel and building a Distro out of it Sep 13 18:30:09 and maybe try LFS if my time permits Sep 13 19:22:45 dvhart: After a bit of battle I got the 64-bit ISO to boot as a disk on the EFI hardware. :-) Sep 13 19:23:23 most excellent Sep 13 19:23:27 congrats Sep 13 19:23:32 I had to make two minor tweaks to get the syslinux working again for the non EFI case, because they changed how ldlinux.c32 works. Sep 13 19:23:59 something you need to send up to hpa? Sep 13 19:24:08 No. This is to our recipe. Sep 13 19:24:22 We still had syslinux 4.x and they made this change in 5. Sep 13 19:24:32 I had to go all the way to 6 to get the gpt support. Sep 13 19:25:11 We have wanted to move syslinux along for a while, there just wasn't any real need until now Sep 13 19:25:36 Now that I have it working, I'll refactor the bootimg class a bit more to have only 2 invocations of the mkisofs instead of 3 because we only need two. Sep 13 19:26:11 I had to pull in syslinux as a hard depend to bootimg.bbclass because that is where isohybrid comes from. Sep 13 19:26:42 And we always need it now for hybrid because isohybrid is needed for the EFI only case just to write the gpt block. Sep 13 19:27:04 hybrid being defined as ISO optical OR as a disk boot. Sep 13 19:27:18 I'll send a new patch set later today. Sep 13 19:27:25 GeekGirl: what are trying to do exactly? ie, what do you want to do with your custom kernel? Sep 13 19:28:34 to be honest...i dont know... Intensions are totaly educational... maybe build a Quadcopter , i have a group of enthusiast building a quadcopter, i adviced them to use linux Sep 13 19:28:45 they are building it using arduino as of now.. Sep 13 19:28:55 they shall be using BBB to do the same soon Sep 13 19:30:36 then it depends on whether you want an optimized desktop build or a bare hardware "bringup" image Sep 13 19:31:41 the xorg image also has several console tools, etc, plus it's designed to be "lite", tuned, and with minimal card I/O Sep 13 19:32:45 i think it provides the most available resources with an X desktop of any of the pi distros i've tried Sep 13 19:33:15 it's even lighter/faster than the gentoo card i made Sep 13 19:33:17 jwessel, I'll watch for it Sep 13 19:34:23 it's up to you if you want to build it, but i'd at least make a card to compare to the others... Sep 13 19:53:50 first let me try the J willis one.. Sep 13 19:54:02 after that ill surely give your's a try Sep 13 19:54:26 My job doesnt allow me to work on this fulltime Sep 13 19:54:44 these are my weekend hobbies, Sep 13 19:55:25 I am also doing MSP430, arduino and Linux Device Driver Programming when my builds are underway Sep 13 19:57:49 * kergoth thinks itd be useful if vmlinux was deployed to DEPLOY_DIR_IMAGE, for debugging Sep 13 20:22:55 it looks like linux-yocto-3.4 sound.cfg got broken by last oe-core upgrade Sep 13 20:22:57 | `/home/jenkins/webos-ports/workspace/webos-ports/tmp-eglibc/work/qemux86-webos-linux/linux-yocto/1_3.4.59+gitAUTOINC+f36797c2df_ea977edd05-r4.5/linux/../sound.cfg' -> `/home/jenkins/webos-ports/workspace/webos-ports/tmp-eglibc/work/qemux86-webos-linux/linux-yocto/1_3.4.59+gitAUTOINC+f36797c2df_ea977edd05-r4.5/linux/meta/cfg/kernel-cache/cfg/sound.cfg' Sep 13 20:23:02 | cp: cannot create regular file `/home/jenkins/webos-ports/workspace/webos-ports/tmp-eglibc/work/qemux86-webos-linux/linux-yocto/1_3.4.59+gitAUTOINC+f36797c2df_ea977edd05-r4.5/linux/meta/cfg/kernel-cache/cfg/sound.cfg': No such file or directory Sep 13 20:34:42 I've found... looks like 4 bitbake bugs in the past 3 days Sep 13 20:34:51 this makes me sad Sep 13 20:35:51 if a build stops for somereason while a Git repo was being downloaded.. do_fetch Sep 13 20:36:16 and the next time i restart the build would the repo cloning would be started fresh or will it continue from where it left off Sep 13 20:39:24 git clones can't resume, with or without bitbake Sep 13 20:39:29 it's a git limitation Sep 13 20:41:32 so i will be downloading whole GBs of repo, even if i had just few MBs to clone before it failed Sep 13 20:42:31 well, i am building the image for Raspberry Pi, any idea how big the kernel repo would be, coz i have a Limited Internet Connection and i dont want to lose all my download credits Sep 13 20:44:02 * kergoth has no idea, sorry to say, don't own an rpi Sep 13 20:46:58 okay... Sep 13 20:47:39 GeekGirl: kernel repo is quite large, but on rpi the firmware repo is *giant* Sep 13 20:47:58 how big are we talking about with "giant" Sep 13 20:48:40 tbh, don't have a clone here Sep 13 20:48:46 (gave up...) Sep 13 20:49:08 oh i do Sep 13 20:49:27 sure would be nice if we could swing some sort of shallow clone support, nontrivial due to srcrev and the like though. would only work if srcrev matched up with the current branch head Sep 13 20:49:32 heh Sep 13 20:49:36 ok a repo cloned about 8 months ago was 700M Sep 13 20:50:41 GeekGirl: a git fetch on that old repo says it needs to get ... lots. Sep 13 20:50:46 Firmware or Kernel... Sep 13 20:50:48 oh, 1% done Sep 13 20:50:50 firmware Sep 13 20:51:00 WTF Sep 13 20:51:01 ? Sep 13 20:51:05 6% at 22mb Sep 13 20:51:22 lots of copies of the firmware, and kernel images too, iir Sep 13 20:51:22 oh.. Sep 13 20:51:22 thanks goodness Sep 13 20:51:39 i'd estimate you're talking around a gig Sep 13 20:51:55 kergoth: non-trivial but surely doable Sep 13 20:52:11 * kergoth nods Sep 13 20:52:16 just needs someone with the motivation :) Sep 13 20:52:21 ive restarted the build that was actually about to finish Sep 13 20:52:21 (not me) Sep 13 20:52:29 kergoth... :) Sep 13 20:52:37 woo, i think i fixed my prototype automatic python dependency code Sep 13 20:52:40 * kergoth sanity checks Sep 13 20:53:13 well a GIG is fine , I am getting good download speed as of right now.. Sep 13 20:53:22 already done with 600M of data Sep 13 20:53:27 oh nice Sep 13 20:53:31 rburton: you know what'll be awesome, when we can use the persistent bitbake server process to cache available providers, thereby letting us have bitbake provider tab completion in our shells Sep 13 20:53:47 GeekGirl: yeah stop moaning i'm only 90mb through the fetch! Sep 13 20:53:54 * kergoth chuckles Sep 13 20:54:03 kergoth: i know, can't wait :) Sep 13 20:54:11 rburton... hahahaha... Sep 13 20:54:21 I like mirroring upstream scm repositories. maybe i'm paranoid about source accessibility, but vanishing upstream sources make me sad Sep 13 20:54:25 * kergoth has a too large archive of these Sep 13 20:54:31 I stil dont know.. wether its due to the files left ftom the previous clone or not.. Sep 13 20:54:51 and 90 Mb in this short time.. thats great.. Sep 13 20:55:36 coz my country is badwidth challanged. 10MBps is the max ive got till now, in a Government R&D facility Sep 13 20:57:09 on another note... is there a way the common Download directory can be preserved? Sep 13 20:57:24 i mean i have all my precious repos there, all from Yocto builds Sep 13 20:57:30 my precious... Sep 13 20:57:36 :) Sep 13 20:57:38 GeekGirl: yes, you really want to share/don't delete that Sep 13 20:57:59 you can set DL_DIR to a common location, yeah. same for SSTATE_DIR. highly recommended on both counts Sep 13 20:58:10 already done that... Sep 13 20:58:17 and now i wanna protect them Sep 13 20:59:00 DL_DIR is around 4gigs Sep 13 20:59:05 move it outside of tmpdir and then you won't accidently delete it Sep 13 20:59:14 and sstate -cache is around 4 gigs too Sep 13 20:59:21 already done that again.. Sep 13 20:59:43 the download directory is nowhere near any commonly used directories Sep 13 20:59:50 its up in the file sytem heirarchy Sep 13 21:00:20 /home//Development/Embedded_Linux/downloads Sep 13 21:00:26 /home//Development/Embedded_Linux/sstate-cache Sep 13 21:00:34 and all builds take place inside Sep 13 21:00:54 /home//Development/Embedded_Linux/Yocto/ Sep 13 21:00:59 perfect Sep 13 21:01:40 So, I figured that shlibs, kernel modules, pkgconfig, etc all share a common pattern of determining what they provide in an isolated namespace, then mapping their depends to those provides in that namespace, and injecting this into rdepends, so for the python bits, I'm playing with common code to handle them all. https://github.com/kergoth/meta-package-auto-deps/blob/master/classes/package-auto-deps/pkg-config.bbclass is what one of the auto types loo Sep 13 21:02:53 * kergoth should send an RFC email before he spends too much more time on it, probably Sep 13 21:02:59 kergoth: yes :) Sep 13 21:03:01 g'night all Sep 13 21:03:05 night Sep 13 21:03:24 gnight.. Sep 13 21:05:04 @kergoth if the GIT cant resume clones... what happens to the objects that have already been cloned... Sep 13 21:05:22 my kernel repo was aroung 600M when it stopped Sep 13 21:05:27 i'm not sure. either they get removed when the failure occurs, or it overwrites them in the next attempt Sep 13 21:05:30 ah, must be teh latter then Sep 13 21:05:35 now its around 1.3G Sep 13 21:05:37 * kergoth shrugs, could ask in the git irc channel, #git Sep 13 21:05:49 yeah.. Sep 13 21:06:49 oops, my auto python deps code just caused a circular dependency.. Sep 13 21:06:52 * kergoth adds to todo Sep 13 21:10:06 i am python challenged as of now... mostly a C coder Sep 13 21:10:25 well, C only.. nothing else Sep 13 21:13:15 and i cant get myself aroung the GIT channel with their spam protection Sep 13 21:16:25 oh my! the firmware repo is a GIANT Sep 13 21:28:25 kergoth: you mentioned four bitbake bugs? Anything I should worry about? Sep 13 21:34:58 RP: mostly minor, I'll be opening bugzilla entries when i get a chance. the git fetcher runs premirrors even if we already have the mirror tarball. and if one of those premirrors is a git:// uri, and that fails, it removes the tarball, as it assumes all scm premirrors are fetching the tarball. its debatable that those are two related issues. you can't referenc e'd' from ${@} in a vardeps flag, thats another minor one. oh, BB_GENERATE_MIRROR_TARBALLS t Sep 13 21:35:08 i think there were one or two others, i have a list Sep 13 21:36:45 kergoth: ok, bugzilla entries sound good so we can track them Sep 13 21:37:04 * kergoth nods Sep 13 21:37:07 kergoth: to be honest I'm drowning at the moment but I'd hate to lose sight of anything important Sep 13 21:37:21 heh, understandable, imminent release after all Sep 13 21:37:43 kergoth: memory resident bitbake whilst a lovely idea is really showing the holes in cooker :/ Sep 13 21:38:06 heh, can't say i'm too surprised by that, we tend to have a lot of state floating around Sep 13 21:38:41 kergoth: indeed :/ Sep 13 21:39:04 kergoth: the sys.exit() calls are wonderful... Sep 13 21:39:52 last set of patches manage to safely kill two more. Not sure what to do with bb.fatal though Sep 13 21:40:40 raising a BBHandled exception there might work, need to look further Sep 13 21:40:45 kind of depends on context. what 'bb.fatal' means depends on where it's used, unfortunately. in a task, it means the task failed, in an event handler, it means we should halt further processing.. Sep 13 21:40:49 * kergoth nods Sep 13 21:58:06 RP: so finally the last commit to kernel.bbclass broke the easy way to embed a cpio :/ Sep 13 21:59:46 ant_home: :/ Sep 13 22:00:00 ant_home: how do we fix things then? Sep 13 22:00:39 I'm trying to understand how to adapt.. Sep 13 22:01:28 the copy of the cpio from deploy_dir to /usr was done in kernel_do_configure() Sep 13 22:02:25 now is done in another task which doesn't seem to be triggered, even in 'compat mode' setting INITRAMFS_TASK Sep 13 22:04:01 gen_initramfs_list.sh: Cannot open 'initramfs.cpio.lzma' Sep 13 22:04:01 | make[3]: *** [usr/initramfs_data.cpio.lzma] Error 1 Sep 13 22:05:02 addtask bundle_initramfs after do_compile Sep 13 22:05:19 ^^ so do_compile fails... Sep 13 22:16:57 RP: okay, it is done in two passes...I had to unset CONFIG_INITRAMFS_SOURCE="" because it is injected on second pass Sep 13 22:17:03 awkward Sep 13 22:39:07 Image built, up and running... loving Yocto even more day by day Sep 13 22:39:10 good night all Sep 13 22:39:20 and thanks kergoth and rburton Sep 13 23:31:49 RP: I'm back..but it is very late. I start to doubt about the python __anonymous, where DEPENDS is set Sep 13 23:32:32 seems like d.appendVarFlag does nothing ?? Sep 13 23:34:07 that sounds particularly unlikely, given we use appendVarFlag all over the place :) Sep 13 23:34:31 you and RP are the python masters ;) Sep 13 23:38:51 -do_configure[depends] += "${INITRAMFS_TASK}" Sep 13 23:39:05 + d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}') Sep 13 23:41:39 this is what's happened in kernel.bbclass Sep 13 23:42:31 yahwnn Sep 13 23:42:33 gn **** ENDING LOGGING AT Sat Sep 14 02:59:59 2013