**** BEGIN LOGGING AT Wed Aug 21 02:59:59 2013 Aug 21 07:41:10 http://paste.kde.org/~lpapp/p123e0cc2/ -> why am I getting this gtk doc fetching issue, especially when I have this in the downloads folder, already? git2_git.gnome.org.gtk-doc-stub.tar.gz Aug 21 07:41:14 hi Aug 21 07:45:22 lpapp: do you also have git2_git.gnome.org.gtk-doc-stub.tar.gz.done? Aug 21 07:45:34 erbo: yeah Aug 21 07:45:57 25135 git2_git.gnome.org.gtk-doc-stub.tar.gz Aug 21 07:45:58 and no error about the checksum being wrong? Aug 21 07:46:02 0 git2_git.gnome.org.gtk-doc-stub.tar.gz.done Aug 21 07:46:05 this .tar.gz is the 'tree' archive, not the package archive required to build the recipe, i believe. Aug 21 07:46:28 the fetcher first clone the tree and create a local archive, then it creates the package tarball from that. Aug 21 07:46:40 erbo: I do not see any checksum errors. Aug 21 07:46:47 next build, it fetches git updates (if any), recreate the tree tarball. Aug 21 07:47:06 do you have the tarball for that specific commit ID? Aug 21 07:47:14 what is a tree archive Aug 21 07:47:18 ndec: ok, so you need the git2/git.gnome.org.gtk-doc-stub/ and git2/git://git.gnome.org/gtk-doc-stub.done as well? Aug 21 07:47:41 minus the "git://" Aug 21 07:47:49 package tarball + the .git stuff ? Aug 21 07:47:57 lpapp: see my first comments above. Aug 21 07:48:10 ndec: I have not understood that. Aug 21 07:48:13 ok. Aug 21 07:48:21 bitbake keeps a local copy of the entire git tree. Aug 21 07:48:37 it then create the recipe tarball from that copy. Aug 21 07:48:52 is there an option for local.conf to override this behavior ? Aug 21 07:49:14 otherwise there is not much point in checking stuff out, especially which comes from git ... Aug 21 07:49:36 I would like it not to do any update at all. Aug 21 07:49:44 otherwise we would need to rely on upstream stuff. Aug 21 07:49:51 which can fail anytime blocking us. Aug 21 07:50:03 hmm. let me check. now i am a little confused. Aug 21 07:50:08 so what downloads we check in, should be the "final" until further notification. Aug 21 07:50:34 and and and ... poky releases should not use git anyway? Aug 21 07:50:37 or a fixed tag ? Aug 21 07:51:21 lpapp: I guess that if you leave the download folder untouched it should need to fetch the git on rebuilds, unless you use the git AUTOREV feature Aug 21 07:51:33 s/should/shouldn't Aug 21 07:51:39 erbo: I am just using upstream poky ... Aug 21 07:51:42 it should be reliable. Aug 21 07:51:51 and users should be able to avoid the dependency on upstream repositories ... Aug 21 07:52:12 and AFAIK poky does not like AUTOREV for stuff. Aug 21 07:52:26 lpapp: I agree, when it's fetched it shouldn't need access to the git until someone touches the build recipe to update SRCREV Aug 21 07:52:27 lpapp: it should fetch only if the commit ID (srcrev) has changed. Aug 21 07:52:37 (still no answer on the mailing list though why gtk-doc stuff is needed at all, especially from git!) Aug 21 07:52:56 well, how can I solve this? Aug 21 07:53:03 it has been blocking our CI for a while. Aug 21 07:54:10 can you clone the gtk-doc-stub manually on that machine? Aug 21 07:54:19 I could clone it ok from here Aug 21 07:54:24 it does not matter. Aug 21 07:54:35 I mean: 1) I do not have access 2) We should not fetch it Aug 21 07:55:30 no you shouldn't, but now something has gone wrong.. Aug 21 07:55:55 lpapp: is the error repeatable if you remove the gtk-doc-stub stuff from download? Aug 21 07:55:55 yeah, so I need to find a way to disable the fetch. Aug 21 07:56:14 erbo: no idea... that would require a commit Aug 21 07:56:27 I rather avoid any commit unless if necessary. Aug 21 07:56:31 would* Aug 21 07:56:46 bitbake -c cleansstate gtk-doc-stub ? Aug 21 07:56:59 erbo: it is only failing on the CI Aug 21 07:57:10 erbo: it had not failed locally before I committed. Aug 21 07:58:46 and I have no access to the CI, etc. Aug 21 07:59:35 lpapp: for the future, maybe something like this might help you. https://wiki.yoctoproject.org/wiki/How_do_I (the Q: How do I create my own source download mirror part) Aug 21 07:59:52 and for now? Aug 21 08:00:21 lpapp: I don't know, just trying to help out with what I can Aug 21 08:01:44 thanks.. I am just trying to find a workaround now not to block other people... Aug 21 08:02:43 lpapp: An ugly workaround to get going might be to create you own tarball + a bbappend that points to that instead of the upstream git Aug 21 08:03:21 but it's not nice, so I guess it depends on how bad you need it working right now Aug 21 08:08:14 erbo: very bad. :D Aug 21 08:10:05 erbo: for the local source mirror, do we need more than a webserver point to a folder containing those, and mapped to a local url? Aug 21 08:13:45 lpapp: I've never used it myself so I don't really know, but my understandning is that you either host them remote using a webserver or a local dir using a file:/// url in SOURCE_MIRROR_URL Aug 21 08:14:53 erbo: uh, oh. Aug 21 08:15:05 local will not make it work on the CI and the dev machines. Aug 21 08:15:16 webserver looks more reasonable to me. Aug 21 08:15:29 oh, actually I am wrong. Aug 21 08:15:41 you can put it somewhere in the repository, too, and then everyone has that set. Aug 21 08:16:02 but not sure if it is a good practice to check so much stuff into a repository rather than just scp'ing to somewhere. Aug 21 08:16:19 no, probably better scp and serve over http Aug 21 08:16:22 the documentation could shed a bit more light. :) Aug 21 08:16:38 erbo: yeah, but that means devs need to have access to the server. Aug 21 08:16:46 pretty much all of them. Aug 21 08:17:13 hmm, actually nope if only one is responsible for updating poky. Aug 21 08:25:57 lpapp: well, sorry about the confusion... i checked, and indeed with the git fetcher there is no tarball create the 'unpack' is directly done from the local git clone using git checkout. Aug 21 08:26:10 that still doesn't explain your problem. but wanted to clarify Aug 21 08:26:38 ok, thanks. So what is causing the issue then? Aug 21 08:27:02 it's quite confusing, since git and svn fetcher don't behave the same way. with svn, it would create a tarball package_.tar.gz, in downloads, then it would just untar it in WORKDIR. Aug 21 08:27:11 lpapp: not yet ;-) Aug 21 08:27:40 not yet what Aug 21 08:28:33 lpapp: do you have access to downloads folder? Aug 21 08:28:37 and can run cmd? Aug 21 08:28:39 inside Aug 21 08:29:17 looking at the code, my understanding is that the fetcher should 'fetch' only if the required commit is not yet in the local clone copy. Aug 21 08:29:19 ndec: server or local? Aug 21 08:29:45 where you get the failure Aug 21 08:30:10 wha cmd Aug 21 08:30:11 t Aug 21 08:30:39 lpapp: so when using git in SRC_URI, the fetcher will clone the git tree in downloads/git2/ Aug 21 08:31:08 then to get the source in tmp/work/ Aug 21 08:32:06 can you check in downloads/git2/git.gnome.org.gtk-doc-stub if you have the required commit (SRCREV)? Aug 21 08:34:23 lpapp: to check if a commit exist, bitbake will do " git log --pretty=oneline -n 1 " Aug 21 08:42:02 ndec: I guess that is fine locally, too, then as the same is on the server due to the check in. Aug 21 08:42:28 lpapp: i don't get that Aug 21 08:44:47 I have some questions about cross-posting to the lists, typical procedural questions but I don't want to get flamed. :-) Aug 21 08:45:13 I would like to cross-post to meta-ti and meta-ivi, is this considered an anti-pattern. TIA! Aug 21 08:46:14 ndec: downloads/git2/git.gnome.org.gtk-doc-stub is a folder. Aug 21 08:47:00 ndec: so what did you mean by "if you have the required commit (SRCREV)"? Aug 21 08:48:21 lpapp: to get the source to build the recipe, when using git, you need to have a git clone in download. so you have to be able to fetch that. Aug 21 08:48:26 the first time. Aug 21 08:48:49 ndec: I am not sure what you ask me to do. Aug 21 08:48:51 then when you clean/rebuild, bitbake won't fetch again, if the SRCREV (e.g. commit ID) hasn't changed. Aug 21 08:49:23 as I said before, it is a folder, a git repository in fact. Aug 21 08:49:27 it is not a bitbake recipe, whatsoever. Aug 21 08:49:33 accordingly, it has no SRCREV in. Aug 21 08:49:47 gtk-doc-stub? Aug 21 08:49:48 which makes me confused why you are talking about SRCREV inside a git repository. Aug 21 08:50:19 gtk-doc-stub fetches its sources from a git tree, according to SRC_URI in the .bb file. Aug 21 08:50:48 the .bb also specifies which version of the tree in the git it uses. that's SRCREV. Aug 21 08:51:12 to get you the source, bitbake will clone (git clone) SRC_URI tree in downloads/git2 Aug 21 08:51:29 then it will checkout the SRVREV commit from that 'local' clone into $WORKDIR. Aug 21 08:51:45 so what you are basically asking is to check the SRVREV in the gtk-doc-stub bitbake recipe Aug 21 08:51:55 and see if that presents in the gtk stub doc build folder. Aug 21 08:52:17 well, based on your error, you must not even have a build folder yet for gtk-doc-stub. Aug 21 08:52:25 since it failed in the fetch. Aug 21 08:53:00 no, I mean download Aug 21 08:53:04 lpapp: do you have downloads/git2/git.gnome.org.gtk-doc-stub Aug 21 08:53:09 yes, see above. Aug 21 08:53:17 and do you have the commit mentioned in the .bb in that clone. Aug 21 08:53:27 ah, Aug 21 08:55:03 morning all Aug 21 08:55:26 ndec: SRCREV = "3dfd0a09de696ec8c544762747f8a0f77153622e" Aug 21 08:55:49 git show 3dfd0a09de696ec8c544762747f8a0f77153622e Aug 21 08:55:50 fatal: bad object 3dfd0a09de696ec8c544762747f8a0f77153622e Aug 21 08:56:12 ok that explains why it tries to fetch from network at least. Aug 21 08:56:28 why does it ? Aug 21 08:56:45 because the 'requested' commit id does not exist in the local clone, the local clone needs to be updated. Aug 21 08:56:46 why does it contain a non-existing SRCREV anyway? Aug 21 08:56:57 when it is cloning an existing that should be present locally, yeah? Aug 21 08:57:07 it might be an old clone. Aug 21 08:57:14 that was clone before the object was pushed. Aug 21 08:57:42 gtk-doc-stub hasn't been touched for ages, so i'd be curious to see what head is in that clone Aug 21 08:57:51 the gtk-doc-stub recipe hasn't been touched since 2012-07-28 :/ Aug 21 08:57:56 hmpf Aug 21 08:57:56 lpapp: in my case, it exists: $ git log --oneline -1 3dfd0a09de696ec8c544762747f8a0f77153622 Aug 21 08:57:56 3dfd0a0 Import introspection stub machinery too Aug 21 08:58:03 that folder is actually in our git tree Aug 21 08:58:08 so git show will get the wrong stuff Aug 21 08:58:09 lpapp: aah Aug 21 08:58:20 bummer. Aug 21 08:58:25 how can I get the local git stuff? Aug 21 08:58:37 i.e. nested git repository. Aug 21 08:58:44 i don't think you can have download managed as a git tree, since bitbake relies on being able to run git commands too. Aug 21 08:58:55 someone seeing gcc-cross-initial failures since last oe-core upgrade? | /OE/oe-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/gcc/builtins.c:843:65: error: 'STACK_SAVEAREA_MODE' was not declared in this scope Aug 21 08:59:20 lpapp: its a bare clone, so maybe it can't auto-detect it Aug 21 08:59:44 ndec: it is not the download managed as a git tree, but the whole poky. Aug 21 08:59:52 ndec: with our custom layer, etc. Aug 21 09:00:04 is download inside that tree? Aug 21 09:00:05 it is a perfectly valid use case to manage addition under git just like poky is managed under git. Aug 21 09:00:10 yes, of course. Aug 21 09:00:24 build/downloads is inside the poky root after all. Aug 21 09:01:22 lpapp: you can try "git --git-dir=. show" inside downloads/git2/git.gnome.org.gtk-doc-stub Aug 21 09:01:48 git --git-dir=. show 3dfd0a09de696ec8c544762747f8a0f77153622e Aug 21 09:01:49 that should force it to consider the current directory as the git directory as the autodetect isn't working Aug 21 09:01:56 fatal: Not a git repository: '.' Aug 21 09:02:25 not even with full path. Aug 21 09:02:37 this is what i get Aug 21 09:02:44 ross@melchett ~/Yocto/downloads/git2 Aug 21 09:02:46 $ git --git-dir=git.gnome.org.gtk-doc-stub show Aug 21 09:02:48 commit 3dfd0a09de696ec8c544762747f8a0f77153622e Aug 21 09:02:50 ... Aug 21 09:02:58 ok, that is not working for me. Aug 21 09:03:15 so what you have there isn't actually a clone Aug 21 09:03:24 it --version Aug 21 09:03:25 git version 1.8.3.4 Aug 21 09:03:29 rburton: i don't think you can clone a git, inside another git that easily. Aug 21 09:03:51 rburton: yes, true. Aug 21 09:03:52 ndec: i suspect git will auto-ignore some files that are important Aug 21 09:04:03 rburton: there is no .git/ whatsoever. Aug 21 09:04:13 git.gnome.org.gtk-doc-stub $ ls Aug 21 09:04:14 HEAD config description hooks info objects packed-refs Aug 21 09:04:15 yes, it would auto ignore the entire .git ;-) Aug 21 09:04:23 ndec: bare clones don't have .git/ Aug 21 09:04:36 lpapp: $ la Aug 21 09:04:39 branches config description FETCH_HEAD HEAD hooks info objects packed-refs refs Aug 21 09:04:43 right. Aug 21 09:04:47 you mean ls -a? Aug 21 09:04:49 no branches, no refs Aug 21 09:04:51 nothing more, I checked. Aug 21 09:04:58 only . and .. Aug 21 09:05:22 but how does --git-dir work for you then anyway? Aug 21 09:05:27 you have made a manual checkout or what? Aug 21 09:05:56 lpapp: you're missing the branches and refs directories Aug 21 09:06:03 so its only half a git clone you've got Aug 21 09:06:26 rburton: half a git clone ? Aug 21 09:06:33 but why would that work locally, and not remotely ? Aug 21 09:06:59 rburton: just did a quick try, it should work in fact. i could add a bare tree in another top level tree. Aug 21 09:07:07 lpapp: no idea. what i can tell you is that i've got more files in my working fetch of gtk-doc-stub than you have in your broken one Aug 21 09:07:45 rburton: argh. but when cloning that test tree, it removed the branches and heads dirs... Aug 21 09:08:18 refs and branches i meant. Aug 21 09:09:13 lpapp: i think the short answer, is that git can't have 'bare tree' embedded inside a top level tree. Aug 21 09:09:58 by making a top level tree with all the poky stuff, that breaks the internal behavior of the bitbake git fetcher which is expected to create git clone in downloads. Aug 21 09:10:20 ndec: looks like you guys would need to find a solution for this use case at some point ... Aug 21 09:10:48 ndec: also, are you sure git really does not support that? Aug 21 09:11:10 ndec: oh, and just for reference, the same way, denzil has just worked fine. Aug 21 09:11:29 i just tried, and was able to reproduce your issue. Aug 21 09:11:30 ndec: so what made poky break this Aug 21 09:11:34 with git i mean Aug 21 09:11:41 denzil has not used git fetcher? Aug 21 09:12:02 i think the fetcher has changed indeed. to allow the WORKDIR to be a 'git' tree. Aug 21 09:12:21 meh, bah, doh, gosh, uh, oh, huh, what, ok. :) Aug 21 09:12:41 so it is yet another regression. Aug 21 09:12:58 any quick workaround? Aug 21 09:13:16 or the people can only be unblocked by series investment for dylan? Aug 21 09:13:38 serious* Aug 21 09:14:10 it is very painful to update two releases ahead apparently. Aug 21 09:14:17 I think the migration path should be done smoother. Aug 21 09:14:36 I had a bunch of issues already, and then this again. Aug 21 09:14:40 lpapp: i'll repeat my advice from a few weeks ago - putting downloads/ into git will really hurt you, even if it worked Aug 21 09:14:51 in six months time you'll have a *giant* git repository Aug 21 09:15:19 rburton: 621 MB Aug 21 09:15:23 on a few TB server. Aug 21 09:15:43 >>> 621/10000000 Aug 21 09:15:43 0 Aug 21 09:15:43 >>> Aug 21 09:15:48 just with 1 TB Aug 21 09:15:58 lpapp: for every client who wants to clone that repo Aug 21 09:16:12 and fwiw, my downloads/ is 22G Aug 21 09:16:28 i really wouldn't want that directory to be in the same git repo as my layer Aug 21 09:16:39 right, so >>> 621/500000 Aug 21 09:16:40 0 Aug 21 09:16:40 >>> Aug 21 09:16:48 500 GB locally. Aug 21 09:16:56 (on one disk, does not count the other) Aug 21 09:17:33 looking at diffs between dylan and denzil, i have some doubts it used to work with denzil... that code hasn't chnaged. Aug 21 09:17:35 rburton: even the whole build dir, not the downloads, is much less here than 22 GB. Aug 21 09:17:57 ndec: we have never had any issues with this on denzil. Aug 21 09:18:12 then, maybe the previous suggestion is not valid about this not supposed to work. Aug 21 09:18:18 and the root cause may be something else. Aug 21 09:18:37 but it has definitely worked on denzil off-hand. Aug 21 09:18:49 lpapp: it might depends on how you manage your download 'git tree' too. Aug 21 09:18:58 ? Aug 21 09:19:11 how do you add/commit stuff in your tree. Aug 21 09:19:17 denzil: du -sh downloads/ Aug 21 09:19:18 261M downloads/ Aug 21 09:19:24 ndec: not sure what you mean. Aug 21 09:19:50 rburton: I am sure your download is not containing only image-core-minimal ... Aug 21 09:19:59 perhaps some very hefty stuff even perhaps the result of more builds. Aug 21 09:20:07 when a build is done, there are new files in downloads. so i guess you have to commit these files for the next build Aug 21 09:20:18 ndec: ? Aug 21 09:20:31 nevermind. Aug 21 09:20:55 ndec: downloads were checked as is after the successful local build. Aug 21 09:20:58 in* Aug 21 09:21:18 without any tinkering. Aug 21 09:21:42 you should compare the checkout of your tree on the server. it is missing files, even before you run bitbake. i don't see how this can be a denzil vs dylan issue Aug 21 09:22:19 I am not sure what you mean. Aug 21 09:22:21 your tree on your CI server is different from your local tree where you did your commit. Aug 21 09:22:22 it is not missing any files. Aug 21 09:22:25 it is the same as locally. Aug 21 09:22:29 and local works just fine. Aug 21 09:22:30 no. Aug 21 09:22:43 yep Aug 21 09:22:47 locally you must have these 'refs' an branches folder which are missing on the server. Aug 21 09:22:56 no Aug 21 09:22:59 in downloads/git2/.. Aug 21 09:23:05 it is the local stuff not having it, and working fine. Aug 21 09:23:34 because you don't start with a clean env, and the sources are from sstate? Aug 21 09:23:51 or already unpacked Aug 21 09:23:54 I always start with clean state. Aug 21 09:23:59 especially before checking in. Aug 21 09:24:43 oh, btw, and the server seems to have branches and refs. Aug 21 09:25:40 SRCREV is present in that bare clone. Aug 21 09:27:00 perhaps I did some half-baked check in, I will double check again. Aug 21 09:27:30 it is a mess when you need to use another machine with ssh to log in to be able to build Poky, and then you end up having few machines around, and you need to make sure everything is always sync'ed up Aug 21 09:27:39 it would be a lot easier if stuff just worked out of the box on arch. ;) Aug 21 09:30:23 oh, hmm, I actually have an idea what went haywire! Aug 21 09:30:35 I got a push feedback from git about a few thousand files Aug 21 09:30:44 it was a warning... maybe git cannot handle 4-5.000 files? Aug 21 09:30:52 and several files were left out accordingly? Aug 21 09:33:34 ndec: git add that-gtk-doc-stuff-dir does not seem to add branches and refs. Aug 21 09:34:09 is that a correct behavior? We do not have anything like that in .gitignore, whatsoever. Aug 21 09:36:39 lpapp: i am sorry. need to get back to (my) work. i recommend you carefully check how 'sub' git are handled in your CI. if you need to understand what bitbake does with git, check out bitbake/lib/bb/fetcher/git.py. Aug 21 09:37:08 my feeling is that your issue is related to download being in a git tree already. Aug 21 09:37:44 actually the issue is this: Aug 21 09:38:07 scp -r A.B.C.D:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/git.gnome.org.gtk-doc-stub/branches ./downloads/git2/git.gnome.org.gtk-doc-stub/ Aug 21 09:38:10 which gives no result. Aug 21 09:38:13 why is that? Aug 21 09:38:30 -> /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/git.gnome.org.gtk-doc-stub/branches presents on the server. Is it because it is an empty folder? Aug 21 09:38:39 then who cares about branches and refs if they are empty? Aug 21 09:39:13 at least, branches is empty. Aug 21 09:40:30 yeah, scp does not copy empty folders, which is really empty for gtk doc stub. Aug 21 09:41:52 oh, git needs those for operate even if they are empty. Aug 21 09:42:01 but git add actually does not add empty folders to the repository. Aug 21 10:10:19 hmm, would the bare git clone be necessary also for local mirrors? Aug 21 10:10:25 or there, we would only have the tarballs? Aug 21 10:13:22 Hey, is anyone here monitoring the oe-develop mailing list/on the general development team? I made a patch commit, and I _think_ I did it right, but I would love for someone to say "Yup, that looks right" before I try and commit the rest of the recipes I wrote. Aug 21 10:14:23 Stygia: yes, a few people. Aug 21 10:15:16 lpapp, Alright, I send a patch to the list today, 'libtaint-util-perl: added', would you care to check if it looks right? :) Once I"m sure I"m doing it right I have like 100 recipes I could push up. Aug 21 10:17:26 Stygia: hm, what list was that sent to? Aug 21 10:17:48 Stygia: openembedded-devel@lists.openembedded.org is the list for most non-oe-core patches Aug 21 10:17:57 rburton, yes, I'm pretty sure this is where I send it. Aug 21 10:18:32 rburton, Ah wait, shit, I send it to core. Fuck me, just a sec Aug 21 10:18:40 rburton, Now I send it to openembedded-devel@ Aug 21 10:18:56 * rburton looks at oe-core again Aug 21 10:19:03 .. sorry. I just execute things from my bash history too damn often. Usually it only bothers me and nobody else. Aug 21 10:19:52 :) Aug 21 10:20:47 rburton, I'm used to just being me and my boss, my mental routine isn't geared to think, my typo will affect other people. Aug 21 10:21:26 rburton, Anyway... If this looks right/is formatted properly/etc I'll be sending up a ton of patches soon. Aug 21 10:23:01 Stygia: feel free to pastebin the patch first if you want to get a quick review Aug 21 10:23:56 rburton, I did actually, bluelightening told me the patch itself looks right, but git send-email gave me some complaints about encoding so I put off actually pushing it to today (And today #git told me the server would decode the headers either way). So I am pretty sure it should be right. Aug 21 10:24:59 rburton, Just want to be sure I didn't screw it up somehow before I spam the mailing list with 50+ patches over a few days. :P Aug 21 10:27:03 Stygia: are you subscribed to the mailing list? Aug 21 10:27:28 Stygia: encoding warnings aren't generally a problem Aug 21 10:27:33 but i suspect you're in the moderation queue Aug 21 10:28:30 rburton, I'm pretty sure I am. Aug 21 10:28:41 rburton, Quite possible. I have made a commit or two that was misformatted... Aug 21 10:29:04 rburton, But for reference this is the patch: http://pastebin.com/cRh6CpBB Aug 21 10:29:28 Stygia: is your git author email you used when sending the patch the same as the email you subscribed with? Aug 21 10:29:43 Stygia: looks good to me :) Aug 21 10:29:54 Stygia: PATCHBOMB Aug 21 10:30:51 I'm pretty sure, yes, erp@movis.dk Aug 21 11:02:06 hi when i Define iamge_fstype as cpio.gz, will that be a rootfs? I want to make a system with only a kernel(vmlinuz) file an a gpio.gz file with rootfs and all stuff to boot the hole system in an tmpfs, so i can update the system with a new gpio.gz file while its running, is this possible? What Features i will need ? Aug 21 11:03:52 currently i have a custom Image required from core-image-minimal with IMAGE_FSTYPES +=cpio.gz, but on bootprocess looks like in the cpio.gz gets not loaded, it tells me that failed to execute /init Aug 21 11:04:39 i use follow lines in syslinux.cfg Aug 21 11:04:48 KERNEL /vmlinuz Aug 21 11:04:48 APPEND initrd=/core-image-minimal-mrec-dev-iei-pv-d525-20130821103541.rootfs.cpio.gz rootfs=/dev/ram0 console=tty0 Aug 21 11:05:22 sorry for asking prbly this dumb question, but iam quite a linux n00b =) Aug 21 11:06:07 daBONDi_work, I'm pretty sure cpio isn't a rootfs, I think you need the *.rootfs.tar.gz file Aug 21 11:07:02 prbly i need a initrd Image with rootfs Included, thats what iam reading, but don't know how to do that in an yocto bb Aug 21 11:07:04 :/ Aug 21 11:09:12 daBONDi_work, Initrd is an init ram fs, not a root fs as such. Aug 21 11:10:02 daBONDi_work, to boot just from the init ram fs, you need the cpio and initramfs files. Aug 21 11:10:54 daBONDi_work, Updating while running, though, I am not sure about. We use the initramfs ourselves, but only to decrypt our data partition and boot the actual OS... Aug 21 11:12:37 so i need to make something like core-minimal-image-initramfs Aug 21 11:12:49 and appanend in syslinux another initrd file Aug 21 11:12:56 with the rootfs.cpio Aug 21 11:13:22 daBONDi_work, Hmm. I'm not expert, so don't rely on just my saying so, but that does sound about right. Aug 21 11:13:44 some bootloaders are supposed to be able to chain multiple initramfs Aug 21 11:13:48 http://gentoo-en.vfose.ru/wiki/Talk:Initramfs#multiple_initramfs Aug 21 11:13:51 my intention is to make a system booting into ram Aug 21 11:14:30 what will surely work is embedding a cpio in a first kernel and while booting the kernel add another initrd= Aug 21 11:15:15 I've tested it, 2 cpio stacked Aug 21 11:15:28 looks like grub can do it Aug 21 11:15:57 but prbly iam to dumb i need more learning on the linux boot process :-) Aug 21 11:16:13 I'm gonna add my vote as say ant_work is right here, that would work, it's exactly what we do to start up our temporary initrd. Aug 21 11:16:21 Not 100% if you can hotswap that, though, but still. Aug 21 11:16:42 currently we using debirf for the system Aug 21 11:16:54 it builds a debian system to run in ram Aug 21 11:17:06 but customization is a pain in the ass :-) Aug 21 11:17:44 so i was hoping yocto can built that to, but with the superb bitbake engine Aug 21 11:19:07 if it can give any idea, see how we do for a linux-as-bootloader (kexec) specific initramfs inmplementation Aug 21 11:19:07 daBONDi_work, I'm not 100% _exactly_ how, but I'm pretty damn sure you can do that, yea. Aug 21 11:19:15 http://kexecboot.org/documentation/crosscompiling/oe-yocto Aug 21 11:20:30 i found the kexec thing also, prbly should look again and try to understand it completly :-) Aug 21 11:21:24 in that case kexecboot is the init process Aug 21 11:21:31 you can customize as you want Aug 21 11:29:25 rburton, How will I know if my patch gets accepted, I'll presumably see some emails on the list saying that such-and-such a patch was accepted? Aug 21 11:29:40 rburton, Probably a silly question, but I've never contributed anything to an open source project before, so. Aug 21 11:29:43 Stygia: there's a changelog sent weekly, or just watch the repo Aug 21 11:30:05 we don't do "thanks your patch has been merged" mails as that would be incredibly tiresome to send :( Aug 21 11:30:26 rburton, Hmm alright, fair enough. I suppose I"ll just go about spamming you with patches, then, and see at the end of the week. Aug 21 11:30:49 Stygia: just checking but you're aware of the meta-perl layer that was discussed on oe-devel? Aug 21 11:31:11 * rburton can't recall who was in that thread Aug 21 11:33:46 rburton, Yes. Aug 21 11:33:56 rburton, I am trying to commit these patches to meta-perl in oe-devel Aug 21 11:34:19 rburton, I made two commits there, for libcarp-perl and libtaint-util-perl Aug 21 11:34:27 rburton, in... meta-perl/recipes-perl/ Aug 21 11:34:41 rburton, under meta-openembedded. Aug 21 11:34:43 cool Aug 21 11:40:34 :) Aug 21 11:41:07 meta-perl lives! IT LIVES! MWHAHAHAHAHAHA. Aug 21 11:42:20 rburton, Hah. Aug 21 11:42:25 I'll make it live, whether it wants to or not. Aug 21 11:42:40 I have like 100+ recipes for CPAN modules... and I'm not gonna let them just sit and only be used by us. Too much damn effort went into this. Aug 21 11:43:12 :) Aug 21 11:43:49 Plus from the selfish perspective it looks great on a resume. Aug 21 11:43:50 * zibri plans to make heavy use of it for my personal projects :) Aug 21 11:45:13 Oh fantastic. Do you need any of them urgently? I still need to clean up the naming and RDEPENDS properly, I'd prioritize anything someone was actually likely to use soonish. Aug 21 11:45:36 zibri, If it's on metacpan I probably have a recipe for it at this point... dependencies are intense there. Aug 21 11:45:50 no, nothing right now. but thanks! i'll let you know :) Aug 21 11:46:14 at least i'll double check so that i'm not duplicating your efforts! Aug 21 11:46:36 zibri, Oh yea, don't go making any cpan recipes anytime soon. :P I'm almost bound to have it at this point. Aug 21 11:46:46 zibri, Although I was lazy with DEPENDS so I'll have to clean up before I commit. Aug 21 11:52:54 perl -pe -i 's/.*/w00t!/' /etc/motd :D Aug 21 11:53:28 jeremiah: don't tell me you have a notification when someone mentions perl in a channel? :) Aug 21 11:53:50 erbo: hits erbo with the camel book Aug 21 11:54:19 jeremiah, Heh. I actually have that right here. Aug 21 11:54:27 Fun story... the camel is actually scrapped off. Aug 21 11:54:32 lol! Aug 21 11:54:38 Now _that_ is heavy use Aug 21 11:54:42 embrace the camel Aug 21 11:54:42 Because I bunked with muslims and its "Shirk" (polytheism) to pray in the same room as a picture of an animal. Aug 21 11:54:43 I actually have a perl book with a camel on it.. I was reading it one day and it started making sense, then I realized I was holding it upside down :/ Aug 21 11:54:55 Stygia: Ah, wow. Aug 21 11:54:57 So... not the camel on my camel book has no face. Aug 21 11:55:00 *now Aug 21 11:55:13 Like an old painting of Muhammad, kinda hilarious. Aug 21 11:55:15 so, rather than moving the precious book you patched it? =) Aug 21 11:55:41 erbo: I think you're thinking of the lama book Aug 21 11:56:29 hi, do I need to define a do_compile function even though I would just do the regular make in a subfolder? Aug 21 11:56:34 B4gder, Yea it's just the cover, not like the picture of the camel matters at all. Aug 21 11:56:50 lpapp, You should probably have the do_compile function doing that, it's what it's for Aug 21 11:57:07 Stygia: why? running "make" is pretty common. Aug 21 11:57:22 lpapp, Well, the idea of using the recipes is to not have to do it manually. Aug 21 11:57:34 lpapp, If you're gonna manually cd there and make, why use a recipe? Aug 21 11:57:48 base.bbclass defines a simple oe_runmake Aug 21 11:57:50 Stygia: you are not following. Aug 21 11:57:55 lpapp, Possible. Aug 21 11:58:12 Stygia: I do use a recipe, but why would everyone start adding the regular "make" for manual execution? Aug 21 11:58:12 defines a simple do_compile calling oe_runmake* Aug 21 11:58:33 for execution* Aug 21 12:00:36 lpapp: simplest do_compile () { Aug 21 12:00:36 ${CC} ${CFLAGS} ${LDFLAGS} foo.c -o foo Aug 21 12:00:36 } Aug 21 12:00:48 lpapp: have a look at the default do_compile in base.bbclass Aug 21 12:05:23 ant_work: as I said, it is about make, not ${CC}, i.e. we use Makefiles. Aug 21 12:06:44 rburton: so basically I need to create a do_compile if you want something more advanced then make, like stepping into the src folder? Aug 21 12:07:33 lpapp: yeah, do_compile() { oe_runmake -C src} Aug 21 12:07:40 lpapp, You should be able to set the WORKDIR variable for that. If I understand your question right, no, you can just require the proper class, instead of using do_compile and make, if all you want to do is 'make'. Aug 21 12:07:51 rburton, Couldn't he just set WORKDIR and import the maker class? Aug 21 12:08:14 autotools/automake IIRC. Aug 21 12:08:49 Stygia: presumably there's something in the top-level that's useful, even if its license files Aug 21 12:09:35 rburton, Ah, hmm, right. That would prelude that unless you love ../ Aug 21 12:10:03 i'd find it clearer to use make -C Aug 21 12:10:06 lpapp, Well you'd probably need to do make -C src, then, unless you simply want a flat 'fake' Aug 21 12:10:09 rburton, Yea exactly. Aug 21 12:10:22 Having relative paths all over the place is confusing. Aug 21 12:10:31 but this is a one-line do_compile function Aug 21 12:11:09 rburton: thanks. Aug 21 12:22:14 lpapp: if you just need to pass extra parameters to make, you don't need to create do_compile, instead, you can do EXTRA_OEMAKE += "-C src". the base do_compile uses this variable. Aug 21 12:22:30 Hmm. If I need to add a configuration line to php.ini (or any system config file), where is the right place to do that? In the image recipe? Aug 21 12:23:00 I have an image, and I need to add the browscap directive to php.ini... wondered what the right way to do that is. Aug 21 12:25:00 ndec: I prefer the inline version. Aug 21 12:25:59 I would lean towards writing my own php.ini, adding it to the PHP recipe, and then writing that out? Aug 21 12:30:09 i have build failures on syslinux: http://codepad.org/rh1sVIbU, "gcc: error: unrecognized command line option '-malign-labels=0'" (MACHINE="nuc" (x86_64)). somebody recognizes this? Aug 21 12:31:40 (on master of poky, meta-intel) Aug 21 12:44:58 why am I getting unpack issues for such a line? SRC_URI = "file://foo.xz \ Aug 21 12:45:08 and foo.xz is in $packageroot/foo Aug 21 12:47:12 lpapp: shouldn't it be do_fecth that failed it it couldn't find the file? Aug 21 12:47:23 no more details in the error msg? Aug 21 12:48:02 ERROR: Function failed: Unpack failure for URL: 'file://foo.xz'. Aug 21 12:48:44 xz -dc /path/to/foo.xz | tar x --no-same-owner -f - failed with return value 2 Aug 21 12:49:08 xz: /path/to/foo.xz: File format not recognized Aug 21 12:49:18 | tar: This does not look like a tar archive Aug 21 12:49:18 | tar: Exiting with failure status due to previous errors Aug 21 12:49:55 oopsie, corrupted file as it seems, bizarro. Aug 21 12:50:00 hmm, maybe it expects a tar.xz and not .xz Aug 21 12:51:44 erbo: mayhaps ... Aug 21 12:52:21 it sure looked like it piped the output to tar atleast :) Aug 21 12:54:14 rburton: -C src will not work Aug 21 12:54:32 it apparently needs the version folder first something like 0.1-r0 Aug 21 12:55:15 or WORKDIR or something Aug 21 12:55:20 lpapp: it starts in $S Aug 21 12:55:37 make: *** src: No such file or directory. Stop. Aug 21 12:56:11 I do have such a folder. Aug 21 12:56:17 so why is make asserting? Aug 21 12:59:15 maybe your default S is bad? Aug 21 12:59:28 have a look in the work directory Aug 21 12:59:35 ? Aug 21 13:00:04 S defaults to $WORKDIR/$PN-$PV Aug 21 13:00:20 if that isn't where your sources appeared, set S to where they are Aug 21 13:00:32 I am not sure what you mean. Aug 21 13:00:51 ./tmp/work/armv5te-polatis-linux-gnueabi/oxcopenflowagent/0.1-r0/ Aug 21 13:00:57 oops, wrong content Aug 21 13:01:17 ./tmp/work/bar/foo/0.1-r0 -> that is the source folder where "src" should be found. Aug 21 13:01:33 work, so your S isn't right Aug 21 13:01:46 set S to where the sources ended up Aug 21 13:01:57 the default assumes you've a tarball which expands to foo-0.1 Aug 21 13:04:31 why don't I have that folder name? Aug 21 13:04:39 I mean by default. Aug 21 13:04:44 because your sources didn't extract like that Aug 21 13:05:24 unpack simply extracts the tarballs it put into WORKDIR Aug 21 13:05:42 and the default is to assume that one of them used PN-PV as a directory Aug 21 13:05:49 if that isn't the case, then you need to set S Aug 21 13:06:23 not sure I follow. Aug 21 13:06:34 I have got the 0.1-r0 stuff instead of foo foo-0.1, why? Aug 21 13:06:42 that has not much to do with the compression. Aug 21 13:06:51 that's workdir, where your SRC_URI contents got dropped Aug 21 13:06:54 I mean... my uncompressed content should reside in that folder. Aug 21 13:06:58 unpack happens and extracts everything Aug 21 13:07:57 if the tarball didn't unpack into a PN-PV directory, then you need to set S to point to where it did unpack Aug 21 13:08:06 ie maybe the directory isn't versioned Aug 21 13:08:35 so basically I need to use prefix when archiving with git. Aug 21 13:08:54 IMO, Yocto could do this right by default. Aug 21 13:09:03 define "right" Aug 21 13:09:07 there is no "right" Aug 21 13:09:12 create ${PN}-{PV} Aug 21 13:09:15 and then what? Aug 21 13:09:19 you've an empty directory Aug 21 13:09:23 and then get it working off-hand? Aug 21 13:09:28 as your sources when somewhere else Aug 21 13:09:41 ? Aug 21 13:09:49 yes, if you're using git-archive, it makes sense to use --prefix and use name-version/ Aug 21 13:09:51 no, the sources should be uncompressed into that by Yocto. Aug 21 13:10:01 if there is no prefix inside the archive. Aug 21 13:10:10 define no prefix Aug 21 13:10:16 what if there are files and directories? Aug 21 13:10:19 ? Aug 21 13:10:36 the default of S=PN-PV works for 99% of software in yocto Aug 21 13:11:20 yeah, but apparently release guys have to do it manually. Aug 21 13:11:29 rather than not using prefix, and yocto adding them by default. Aug 21 13:11:40 tell the people making tarballs to use --prefix Aug 21 13:11:43 this is already coded into the recipe name after all, so it would not be hard. Aug 21 13:11:49 every tarball since the mid-70s starts with a directory Aug 21 13:11:59 so yours should too Aug 21 13:12:50 erm, it is not about what it should. Aug 21 13:12:55 Yocto could have a fallback. Aug 21 13:12:59 when it is not, it is adding that. Aug 21 13:13:09 or at least warning, whatever. Aug 21 13:13:12 or both, actually. Aug 21 13:13:33 we can add a warning that S doesn't exist Aug 21 13:13:41 you probably had that in the logs already Aug 21 13:13:52 no, that is an error Aug 21 13:14:04 what I am saying there should be no error at all for simply missing prefices. Aug 21 13:14:04 it used to be auto-created which did confuse people, because you didn't get errors Aug 21 13:14:12 warning Aug 21 13:14:16 not error. Aug 21 13:14:24 if you skip a warning, you are on your own ... Aug 21 13:14:28 so what is confusion in there? :) Aug 21 13:17:54 rburton: does that make sense? Aug 21 13:35:46 hmm, if a makefile for a software contains this line right at the beginning: CC = gcc Aug 21 13:36:02 will Yocto use the cross compiler supplied, i.e. can it override that somehow? Aug 21 13:36:12 or that is a bad practice from the software author? Aug 21 13:36:40 thats bad practise Aug 21 13:36:43 "However, an explicit assignment in the makefile, or with a command argument, overrides the environment." Aug 21 13:36:46 says the make manual Aug 21 13:37:03 I think we use make -e don't we? Aug 21 13:37:20 so we force our environment to override the makefile Aug 21 13:37:27 oh, do we? Aug 21 13:37:52 so we do! Aug 21 13:37:53 oe_runmake does that yes. Aug 21 13:37:54 yes, we do. Aug 21 13:38:11 learn something new every day ;) Aug 21 13:38:39 lpapp: it should get overridden by the cross compiler then Aug 21 13:38:51 bitbake.conf: EXTRA_OEMAKE = "-e MAKEFLAGS=" Aug 21 13:39:15 another good reason to use oe_runmake instead of make directly Aug 21 13:39:32 however -e is not recursively passed by make. so if you have a top level makefile that 'recurses' , -e is lost. Aug 21 13:40:54 that pretty much ruins the point then doesn't it? Aug 21 13:41:12 yes... Aug 21 13:41:28 i was just debugging an issue about that last friday... Aug 21 13:41:47 that's when i noticed. Aug 21 13:41:53 meh Aug 21 13:42:02 limitation for doing the right thing in there is? Aug 21 13:42:23 lpapp: probably along the lines of "posix make says its isn't preserved" Aug 21 13:43:03 hand-rolling a build system using raw makefiles is so much effort Aug 21 13:43:10 so what is the right practice? Not have CC line at all? Note, I have not written Makefiles by hand the last 5-6 years Aug 21 13:43:25 have been mostly using qmake, cmake, and a bit of autotools before. Aug 21 13:43:32 where I do not need to care so much about all this. Aug 21 13:43:49 rburton: yeah, that is where I agree. Aug 21 13:44:00 IMHO, we should use cmake, but that is not a discussion for today. Aug 21 13:44:15 lpapp: shame, that's a perfectly reasonably solution Aug 21 13:44:46 so what is the right GNU Makefile practice? Aug 21 13:46:37 rburton: well, i think the '-e' is lost because we also set MAKEFLAGS= Aug 21 13:46:51 otherwise the -e would be recursively used. Aug 21 13:47:16 lpapp: well, are you recursing? the defaults may just work. Aug 21 13:47:26 rburton: yes Aug 21 13:47:51 I am recursing. Aug 21 13:48:52 you could change EXTRA_OEMAKE not -e only, to see. Aug 21 13:48:57 i haven't tried that yet. Aug 21 13:49:06 i am not sure why we do MAKEFLAGS= Aug 21 13:49:58 rburton: we can adjust the software easily though if needed... it was not written by me. Aug 21 13:50:36 lpapp: try changing that assignment to CC?=gcc Aug 21 13:50:52 then the environment variable might take priority Aug 21 13:51:00 been a while since i've written a real makefile :( Aug 21 13:51:14 but a quick test says that should work Aug 21 13:51:37 note that CC already has a default in make, of "cc", which will also work so you don't even need to set CC Aug 21 13:51:45 its a default variable, there's loads of those Aug 21 14:00:23 rburton: ok, so just remove. Aug 21 14:00:35 Hey, we're having a weird (if relatively minor) issue with our boxes, and I wondered if anyone here'd seen anything similar. Aug 21 14:00:51 When we update our box's system image, we (right now) SCP an image over and reboot the box via SSH. Aug 21 14:01:13 However, we're frequently seeing that the box just "hangs" on the login screen instead of rebooting, until someone presses enter or something on the keyboard plugged into it. Aug 21 14:01:31 Immediately, I can't put my finger on what would cause behaviour like this, seeing as how it does reboot as soon as we "touch" it. Aug 21 14:01:36 Anyone here seen something like this before? Aug 21 14:02:23 Stygia: stupid usb power management? Aug 21 14:02:46 x86 kernels until a few days ago enabled usb power management, which was Bad Aug 21 14:02:56 rburton, I'm not sure? I'm not sure exactly how that would impact it. The reboot command is clearly "in there" somewhere since it triggers once we touch it. Aug 21 14:03:20 rburton, Hmm. I've honestly no idea. Aug 21 14:03:31 rburton, Sometimes it works, this time it did it right away. Sometimes it hangs. Aug 21 14:03:41 rburton, But, your suggestion would be trying a 3.10-ish kernel? Aug 21 14:04:33 rburton, Out of curiosity, why would you suspect USB power management of having to do with this? We plug in a USB thing that gives it power, but only when flashing, other than that we use a regular power input. Aug 21 14:04:44 Stygia: is the keyboard usb? Aug 21 14:05:19 i've just seen keyboards acting odd when autosuspend was enabled Aug 21 14:05:30 but unless you're running linux-yocto on x86, it should be disabled Aug 21 14:15:44 I'd like to add Qt4 from meta-oe to my distro each time I build it, and looking at the docs it looks as if IMAGE_INSTALL_append = " " is how I'm supposed to do it. I'm uncertain of the syntax though... do I just put "qt4" in or do I use the bb package name "qt4-embedded_4.8.3" (bb file is qt4-embedded_4.8.3.bb). Aug 21 14:18:44 cfo215: qt4? Aug 21 14:19:09 cfo215: any reason why not getting qt5 with meta-qt5? Aug 21 14:19:33 lpapp: I'm more familiar with qt4. Aug 21 14:19:44 cfo215: yeah, but it is getting dead end. Aug 21 14:20:02 maybe there will be one more "last" bugfix release, but that is pretty much it. Aug 21 14:20:19 qt 5.2 feature freeze is less than a month ahead. Aug 21 14:20:57 lpapp: does qt5 have better support of embedded linux with LCD and touchscreen. I'm not using a "Desktop", just want to boot into my Qt app. Aug 21 14:21:21 cfo215: yes, of course. Aug 21 14:22:51 lpapp: is meta-qt5 supported in "dev" builds; i.e. if I want to create a tool-chain build? Aug 21 14:23:08 cfo215: ? Aug 21 14:25:06 when I build "Angstrom" for instance, one of my recipes allows me to build a tool chain. e.g. it creates a file system with INCLUDE populated with the header files for all the installed software and add the cross-comipler for the target system. Aug 21 14:26:11 lpapp: I'll add meta-qt5 to my mix and see what happens ;) Aug 21 14:26:54 cfo215: sorry, but I am not sure what you mean. Apparently, this explanation is not clear for me. Aug 21 14:27:19 how is a toolchain build related to qt5? Aug 21 14:27:31 toolchain build is happening way before a software like qt5 as that is the first in the queue. Aug 21 14:28:22 i think cfo215 means a 'SDK' that includes the toolchain and all the libs/headers Aug 21 14:28:26 lpapp: no worries. I'm just learning this whole process. I'm more used to ./configure; make; make install... Aug 21 14:28:42 i haven't tried for QT5, but several people have complained that SDK wasn't working, i believe. Aug 21 14:28:48 ndec:lpapp: that is exactly what I mean. Aug 21 14:28:53 yeah, bluelightning claimed that SDK was not working. Aug 21 14:29:08 cfo215: so you might be out of luck with that... Aug 21 14:29:24 I have no idea what an SDK creation means though on the yocto level. Aug 21 14:29:25 ndec:lpapp: which is why I was looking to use qt4.. :) Aug 21 14:29:32 sure. Aug 21 14:29:47 cfo215: well, how about looking into the issue, and see if it is easy to fix? Aug 21 14:29:49 ndec:lpapp: I don't need to be on the "bleading-edge" for my app. Aug 21 14:29:59 qt4 is really dead end, and no one should use it for new projects. Aug 21 14:30:38 cfo215: it is more than just not bleeding edge. Aug 21 14:30:46 effectively, you are not getting any fixes anymore. Aug 21 14:30:52 except a very few still sneaking in. Aug 21 14:30:54 lpapp: I don't think I really have the skills for that. Aug 21 14:31:17 cfo215: well, if it is qt related, I can help. If it is yocto related, others can help in here. Aug 21 14:31:43 I would help fixing it, but I do not even know why an SDK is needed. Aug 21 14:31:49 or what it is supposed to provide. Aug 21 14:31:56 you can already build a library by adding a recipe. Aug 21 14:31:57 lpapp: ic, i'll try qt5 and see what happens. May as well jump into the pool. Aug 21 14:32:02 what more does an sdk provide? Aug 21 14:33:15 lpap: the build paths; libraries; etc. conveniently bundled into a 'source'able environment file. just makes development for a platform easier. Aug 21 14:34:27 lpapp: that way when your developing you just source the environment and your compiles know where everything is. Aug 21 14:35:12 lpapp:ndec: thanks for your input. I value it. Aug 21 14:35:26 np. Aug 21 14:41:04 cfo215: I would say, let us fix the qt5 stuff unless it is a terrible pain. :) Aug 21 14:41:20 qt4 is sooo much dead that it is only worth considering if there are headaches not doing so. Aug 21 14:41:41 not doing the qt5 stuff, that is. Aug 21 14:42:21 lpapp: I certainly couldn't fix it. ;) Aug 21 14:43:01 cfo215: never know if you do not try. Aug 21 14:43:50 lpapp: I don't know what "qt 5.2 feature freeze is less than a month ahead." that means exactly.. but I think its related to git somehow. Aug 21 14:44:17 cfo215: iirc the 20th of september is the feature freeze for 5.2 Aug 21 14:44:23 cfo215: 5.1.1 is soon out. Aug 21 14:44:27 lpapp: true that! Aug 21 14:44:28 5.0 was out last December. Aug 21 14:45:31 lpapp: i don't think adding the QT5 sdk 'stuff' in meta-qt5 is trivial. that's my feeling. of course nothing is impossible, i just think one need to be quite used to OE to work on that. Aug 21 14:46:07 ndec: we will see. Aug 21 14:46:26 note that if you do it, i will use it ;-) since i need it too! Aug 21 14:46:40 ndec: that's certainly not me! I'm still trying to add qt4 to my build. I get ERROR: Required build target 'console-image' has no buildable providers. Aug 21 14:46:43 Missing or unbuildable dependency chain was: ['console-image', 'qt4-embedded_4.8.3'] Aug 21 14:46:46 ndec: well, I do not care that much about something I do not even understand what it is for. Aug 21 14:46:51 but I am happy to help with qt5 in general. Aug 21 14:47:14 lpapp: I may just be calling on you for that... Aug 21 14:48:15 I tried IMAGE_INSTALL_append += "qt4" and IMAGE_INSTALL_append += "qt4-embedded_4.8.3" in my local.conf with similar results Aug 21 14:57:55 lpap: another newb question: where do I clone meta-qt5? in the top-level source dir or in meta-openembedded or someplace else? Aug 21 14:58:16 cfo215: where you want ;-) Aug 21 14:58:18 cfo215: up to you, I do it next to the other layers. Aug 21 14:58:32 you just need to put the right path in bblayer.conf Aug 21 14:58:34 cfo215: but I know some people here do this right outside poky, so not next to the poky layers. Aug 21 14:59:20 ndec:lpapp: thanks, that may have answered my other problem... forgot to update bblayer.conf for qt4. Aug 21 14:59:37 that should help indeed. Aug 21 15:01:10 ndec: as I said that I noticed that my lastest try at adding qt4 was working. I changed IMAGE_INSTALL_append += "qt4-embedded_4.8.3" to IMAGE_INSTALL_append += "qt4-embedded" in my local.conf Aug 21 15:02:34 ndec: no change to bblayers.conf. Bitbake "just" found it... though I think it's supposed too... lol Aug 21 15:03:01 I wonder if anyone can provide me a link to this SDK stuff Aug 21 15:03:06 to read a more upon it. Aug 21 15:03:16 cfo215: no, cloning a layer won't automagically add it to your builds. if you want to use the layer, it has to be added to bblayers. of course, qt4 doesn't reuqire meta-qt5 Aug 21 15:04:22 lpapp: from high level http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html Aug 21 15:04:50 the 'SDK' is a 'standalone' installer that contains the cross compiler, qemu, and all 'dev' files for all packages. Aug 21 15:04:51 kergoth: thanks, I understood that bit. I'm haven't bolted down a Qt version yet, but I'm still leaning on Qt4 because of the plethora of code out there for it. Aug 21 15:05:07 lpapp: you generally create the SDK with bitbake -c populate_sdk Aug 21 15:05:23 and you get it in tmp/deploy/sdk Aug 21 15:05:33 ndec: thaks for that tip... writing it down... Aug 21 15:05:42 ndec: I have read that manual, but apparently it did not make it clear for me. Aug 21 15:05:58 you can then redistribute to others that can build applications against your image without needing to use OE. Aug 21 15:06:16 ndec: isn't the cross compiler built by core-image-minimal anyways? Aug 21 15:06:40 yes. but the 'SDK' is relocatable. e.g. you can install it on a nother PC. Aug 21 15:06:46 and why cannot a qt5 image just work without the need to use OE? Aug 21 15:07:09 how is the toolchain not relocatable? Aug 21 15:07:49 in terms of hard coded path. Aug 21 15:08:00 ? Aug 21 15:10:01 the toolchain as it's built in tmp/sysroot cannot be 'exported' onto another PC. Aug 21 15:10:13 the 'SDK' with -c populate_sdk allows you to do that. Aug 21 15:10:32 the output of that command is a tarball that contains the toolchain, .h files, .so files, ... Aug 21 15:10:44 i am not sure what you don't understand. Aug 21 15:13:04 ndec: actually, all that should work out of the box. Aug 21 15:13:11 without a dedicated sdk option imho. Aug 21 15:14:30 the toolchain should be relocatable, and also, the files should just be used in a description file with the relevant sections, like LIBRARIES = ... HEADERS = ... Aug 21 15:14:46 it is not something that sounds complex for end user in an ideal world. Aug 21 16:31:28 lpapp: The difference is that the SDKMACHINE you set doesn't have to be the machine type you're building on and you get a nice easy to install file Aug 21 16:33:04 that should just work out of the box with the right architecture. Aug 21 16:33:36 and all it would take, again with an ideal design, is to write a description. Aug 21 16:37:00 tw Aug 21 16:40:24 rburton: ? Aug 21 16:42:22 wrong window! Aug 21 16:59:00 yow, weren't kidding about the parse slowdown with server mode :) Aug 21 16:59:04 brings back memories Aug 21 17:03:16 haha Aug 21 17:03:27 does it print "we recommend you install psyco"? Aug 21 17:49:25 does yocto support beaglebone out of the box or just beagleboard(-xm)? Aug 21 17:51:54 the bits provided by TI support both. see the meta-ti and meta-beagleboard layers Aug 21 18:15:25 I will totally get meta-sourcery working with multilibs and everything. Any minute now. Surely, this will be the last bug I have to remove before my test builds complete on all the targets I care about. Aug 21 18:17:18 ... why is there a Dutch sailor waving to me as his ghostly ship passes? I feel concerned. Aug 21 18:17:33 kergoth: I added the meta-ti layer and updated my local.conf and bblayers.conf but get an error message when bitbaking. http://pastebin.com/cTAFT9xT Aug 21 18:18:44 cfo215: what branch are you using? Aug 21 18:18:47 cfo215: make sure your branches are matched up between layers (e.g. don't try to use a master branch layer with a dylan branch poky/oe-core, or vice versa) Aug 21 18:19:32 denix:kergoth: dylan Aug 21 18:19:34 ? Aug 21 18:19:50 dylan is a yocto release, version 1.4, afaik Aug 21 18:20:48 cfo215: dylan has mesa-9.0.2 Aug 21 18:20:58 hi everyone Aug 21 18:21:22 cfo215: so, error about mesa-9.1.6 means you are not using matching branches Aug 21 18:21:46 ndec: why is it difficult to fix the qt5 sdk stuff? Aug 21 18:21:49 I'm trying to add google snappy into yocto, compilation/installation/rpm-creation were all successful. But when I include it into my core-image-lsb, it shows me error in do_rootfs like this: Aug 21 18:22:07 | | 528:Installing libsnappy1 ######################################## [ 44%] | Traceback (most recent call last): | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/pm.py", line 312, in __call__ | self._process_rpmout() | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/pm. Aug 21 18:22:10 denix: thanks I'm really a newbie here. Aug 21 18:22:18 can anyone help me out? Aug 21 18:22:54 and don't know how to match what to what. Is that documented somewhere? Aug 21 18:24:26 cfo215: what is your base - is it poky or is it oe-core + some distro? in either case the branch of the base determines what other layers should use. if it's master, then other layers should use master. if it's dylan, then same for other layers Aug 21 18:25:12 denix: I followed the "Quick Start" from yocto-project. So gussing it's poky. Aug 21 18:25:30 cfo215: what is the issue? Aug 21 18:26:36 lpapp: I'm trying to switch to yocoto/poky instead of angstrom since it seems better supportd. I added the meta-ti layer and updated my local.conf and bblayers.conf but get an error message when bitbaking. http://pastebin.com/cTAFT9xT Aug 21 18:27:04 cfo215: if it says 1.4 in the name, then it's dylan. you need to clone corresponding branches of additional layers Aug 21 18:28:05 cfo215: specifically, switch your meta-ti clone to dylan, instead of master Aug 21 18:28:09 denix: sorry a little vague on git: I use "git clone -b " when doing that? Aug 21 18:28:17 cfo215: core-image-minimal should not have any relation to your meta-ti Aug 21 18:28:46 lpapp: i added it to my bblayers.conf Aug 21 18:29:07 cfo215: cause of the toolchain or what do you use from there? Aug 21 18:29:45 cfo215: yes, or use git checkout later Aug 21 18:30:13 denix: thanks... I was just consulting the man page for git... Aug 21 18:34:15 nobody knows my question? Where should I ask? Aug 21 18:37:30 reeve: You might want to paste the output to something like pastebin, because the part you pasted doesn't seem to be the whole thing? Aug 21 18:38:13 seebs: the other thing just look normal Aug 21 18:38:22 seebs: let me try to paste more Aug 21 18:38:35 I would recommend not pasting long output in IRC. Aug 21 18:38:45 Mostly people overlook it, or have trouble reading it. Aug 21 18:38:57 just a little bit more, you can tell what I said Aug 21 18:39:12 But basically, that looked like a single line from an error message that would normally be 20+ lines. Aug 21 18:39:18 or what's your suggestion? should I ask the question in mailing list? Aug 21 18:39:43 Hey guys. Aug 21 18:39:44 in fact on my screen that's 34 liens, let me paste line by line Aug 21 18:39:48 My suggestion would be to grab the entire log from that line on, and post it to something like gist or pastebin, and post a URL in channel. Aug 21 18:39:53 34 lines is too much for IRC. Aug 21 18:40:02 I just received the summary email of recent changes, but I don't see my patches (the two I submitted properly formatted and named in there). Aug 21 18:40:04 Does that mean they got rejected? Aug 21 18:40:07 sorry, 4 lines Aug 21 18:40:12 | Traceback (most recent call last): Aug 21 18:40:20 | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/pm.py", line 312, in __call__ Aug 21 18:40:28 self._process_rpmout() Aug 21 18:40:40 | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/pm.py", line 297, in _process_rpmout | output = self.rpmout.read() Aug 21 18:40:51 | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/codecs.py", line 477, in read | newchars, decodedbytes = self.decode(data, self.errors) Aug 21 18:41:00 | UnicodeDecodeError: 'ascii' codec can't decode byte 0xa1 in position 740: ordinal not in range(128) Aug 21 18:41:33 Stygia: if there was no reply, and they weren't merged, more likely someone missed reviewing them at all, or hasn't had time to address them. this is fairly common in open source projects. you can always resend them with [resend] or similar in the subject line, but at times you just have to wait. how long as it been since yours were posted? Aug 21 18:41:39 * kergoth shrugs Aug 21 18:41:44 seebs: it's a traceback from codec.py, complaining about ascii ... Aug 21 18:41:54 Huh. That's a fascinating one. Some string, somewhere, which is expected to be all ASCII characters, has an 0xa1 in it. Aug 21 18:41:58 Which is indeed out of range. Aug 21 18:42:31 this is google's snappy package ... Aug 21 18:42:50 kergoth, Alright, fair enough. Aug 21 18:42:53 kergoth, And hah... like a day or two. Aug 21 18:43:02 ah, yeah, might just have to wait a bit longer :) Aug 21 18:43:15 kergoth, And, further, I probably got on some list that means I require moderation approval because I submitted 2-3 patches incorrectly. Aug 21 18:43:31 Alright, fair enough. Thanks, I just wondered if I could/should keep submitting my recipes. Aug 21 18:45:35 kergoth: thanks for your help... cd meta-ti; git checkout dylan; cooking with gas now! Aug 21 18:46:40 cfo215: glad to hear it Aug 21 18:49:36 I think everything takes time to approve. I think my fairly simple and well-liked "set -e" patches took a couple-few months, due to a combination of various people's vacation schedules, higher priority tasks, and so on. Aug 21 18:50:32 seebs, Hmm alright. Well fair enough. Aug 21 18:50:43 These are new recipes, though, so I'm hoping it'll go in fairly soon. Aug 21 18:50:57 Because I have like 100+ recipes to commit. :P Wouldn't want to clog the queue too much. Aug 21 18:52:01 * Crofton|work wonders what you are doing that stygia could find 100 recipes we do not have Aug 21 18:52:29 Stygia: where are you submitting them? which layer? Aug 21 18:52:53 getting a recipe into oe-core is non-trivial, only highly prevalent, key, core stuff is supposed to be going in there Aug 21 18:53:02 Due to a humorous miscommunication, it turns out it's the first chapter of last year's revised Betty Crocker. Later we will realize that meta-delicious-cookies was the key to Yocto's long-term commercial success. Aug 21 18:54:10 meta-openembedded Aug 21 18:54:19 the new meta-perl layer. Aug 21 18:54:32 I have most of the stuff from metacpan as recipes here with me. Aug 21 18:56:19 ahh, cool Aug 21 18:56:31 ah Aug 21 18:57:11 Stygia: unless you sent some I'm not seeing, all of the ones you sent to the oe-devel list the other day had problems Aug 21 18:57:33 meta-combanitoric: This layer contains the set of all valid C programs which do not use line continuation, have no external dependencies, and are under ten lines long. Aug 21 18:58:23 heh Aug 21 18:58:44 there are still a huge (and growing) number of layers on github that aren't in the index :( Aug 21 18:59:01 PATCH [0/aleph-0] ... Aug 21 18:59:32 meta-paradox: Contains recipes unsuitable for inclusion in any layer intended for use with oe-core. Aug 21 19:01:32 bluelightning, Yea, I know. But I send two more that were formatted/named properly and with the correct (I think) metadata? Aug 21 19:03:12 Stygia: which ones were those? can you find them in http://lists.openembedded.org/pipermail/openembedded-devel/2013-August/thread.html ? Aug 21 19:03:21 bluelightning, libtaint-util-perl/libtaint-util-perl_0.08.bb: http://pastebin.com/NKNDeZef Aug 21 19:04:09 bluelightning, Hmm. Nope, I can't. Only the broken ones. Aug 21 19:04:43 Stygia: looks like they never made it to the list in that case Aug 21 19:05:08 bluelightning, Hmm alright. I didn't get banned or something for pushing broken patches, did I? Aug 21 19:05:37 no, we wouldn't have done that... too many of us would have gotten banned by now :D Aug 21 19:05:56 I don't think yocto would be well served by a community consisting only of people who never submit patches. :) Aug 21 19:06:10 Heh. Aug 21 19:06:19 Well alright, weird, I was sure I'd pushed them. But alright, I will push them again, then. Aug 21 19:07:22 At one point, we had a couple of months during which something somewhere in an IT department had decided that *some* outgoing mail to the oe-core list would be silently dropped without bounce messages, but mostly it was fine. Only affected us, I think, but there was a period during which maybe 5-10% of attempts to send patches to the list just sort of evaporated. Aug 21 19:08:44 Hmm I think it's fine, all the shitty/broken patches I did submit were shown on the list just fine. :P Aug 21 19:11:05 is there a meta-qt4 or meta-qt5 layer in yocto? I only found meta-qt3 Aug 21 19:12:07 http://layers.openembedded.org/layerindex/ Aug 21 19:12:08 maybe looking in the wrong spot... Aug 21 19:12:12 click on layers Aug 21 19:12:15 click in text box, type qt, hit enter Aug 21 19:12:17 :) Aug 21 19:12:34 kergoth: thanks Aug 21 19:12:43 not all yocto compatible layers are hosted at yoctoproject.org, so best to use the layer index there Aug 21 19:15:29 kergoth: I really do appreciate all the help. Someday I won't be such a newb Aug 21 19:16:29 Hmm. I don't think that worked. Aug 21 19:16:55 At least my commit still doesn't appear on the list bluelightning linked. Aug 21 19:17:29 Sometimes there is a delay. Aug 21 19:17:33 I added each recipe, used git commit -s, added a commit message (with a summary on the top line), then used this command: git send-email --to=openembedded-devel@lists.openembedded.org --confirm=always -M -1 Aug 21 19:17:45 I've had messages that really did go through not show up for a couple-few hours. Aug 21 19:18:06 Weird. Email is usually pretty instant. Aug 21 19:18:11 But fair enough, then. Aug 21 19:18:24 I was just wondering if something was broken in my approach or setup of git. Aug 21 19:26:11 stygia: you set up postfix? you can have a look with "postqueue -p" (as root) to view any queued up mails. Aug 21 19:26:33 or /var/log/mail.log Aug 21 19:27:25 zibri, I'm pretty sure I did, I did push the other broken commits. But I'll have a look. Aug 21 19:27:48 Ah, hmm. They say connection timed out. Aug 21 19:28:15 I'll have a look, thanks zibri Aug 21 19:28:17 you could try "telnet mail.openembedded.org 25". in sweden a lot of isps filters port 25 Aug 21 19:29:24 if you can connect, you can continue investigate any local configuration issues. otherwise that's the probable culprit Aug 21 19:29:24 zibri, I'm not Swedish? Aug 21 19:29:30 no, but i am. Aug 21 19:29:59 zibri, Jævlå svænsa Aug 21 19:30:00 just saying, it's like that here. probably elsewhere as well. Aug 21 19:30:08 :) Aug 21 19:30:12 Heh. Aug 21 19:30:29 Hmm does give me 'no route to host' Aug 21 19:35:33 i have issues building syslinux for meta-intel's nuc, both on master and dylan. (different error messages, at least some variation) :-(. on dylan, i get: "error: CPU you selected does not support x86-64 instruction set" (The compiler command includes -march=i386) Aug 21 19:36:12 http://codepad.org/wa8WRB7R Aug 21 19:36:51 on master, i got issues at roughly the same point, with errors about -malign-labels=0 not being a valid flag Aug 21 19:37:30 http://codepad.org/rh1sVIbU <-- this one is from the master build Aug 21 19:37:45 any ideas what i'm doing wrong? Aug 21 20:00:16 Hmm. Aug 21 20:00:48 One thing that occasionally bites people in various ways is that x86 systems will occasionally want a given thing built specifically for x86 or x86_64, but by default we build a compiler that only supports one of those. Aug 21 20:01:47 If you're specifying -march=i386, and getting an error about x86-64 instruction set, that sort of implies that something generated x86-64 instructions or code, or asked for them. Not sure what, without more context. Assembler error? Aug 21 20:06:47 unfortunately, i don't have any more context than those pastes. afaict, the only usage of -malign-traps=0 in syslinux seems to be falling back when the build system doesn't think the compiler has support for -falign-traps=0. Aug 21 21:06:37 Hi guys! Anyone expert on yocto kernel configuration that can help me? Aug 21 21:07:45 added a kernel config fragment to my layer, re-did the image, but the change has not gone through to the deploy directory Aug 21 21:10:26 hey cfo215, know anything about kernel config development? Aug 21 21:17:58 brm: not really. I'm just getting started with this stuff. I have painfully learned how to setup my environment to build stuff though. With a lot of help from people here. Aug 21 21:21:12 you could try http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/kconfig.html for starters Aug 21 21:32:35 brm: did the change make it into the .config file in the build dir under the workdir for the kernel recipe? Aug 21 21:33:15 Got an error building core-image-minimal. Error: qtbase-native not found in the base feeds (beaglebone armv7a-vfp-neon armv7a-vfp armv7a armv6-vfp armv6 armv5e-vfp armv5e armv5-vfp armv5 armv4 arm noarch any all). Aug 21 21:33:17 | ERROR: Function failed: do_rootfs (see /media/toshiba-usb3/work/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.3354 for further information) Aug 21 21:33:19 ERROR: Task 7 (/media/toshiba-usb3/work/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1'http://pastebin.com/qrRQEc46 Aug 21 21:34:43 cfo215: that sounds like you added qtbase-native to IMAGE_INSTALL, which wouldn't be correct Aug 21 21:36:11 bluelightning: IMAGE_INSTALL_append += " qtbase qtbase-native" .. was added to local.conf. What is the proper way? Aug 21 21:37:33 seebs: stepped out for a while. Is there anything you could hint me to resolev the problem? Aug 21 21:38:19 Nothing obvious. Is this package in one of the normal layers, or is it local? It seems like the sort of thing that would get run into fairly often if it were in the core layers. Aug 21 21:41:34 cfo215: qtbase-native isn't a package to be installed into the image; it's a recipe providing tools/libs to run on the build host Aug 21 21:41:53 cfo215: I suspect you just want qtbase there Aug 21 21:43:05 blueligtning: yes. I just need to be able to run my home-built qt apps on the beaglebone. I took out the IMA... line and the image built w/o errors. Not sure if Qt got in there yet. Haven't had time to look. Aug 21 21:43:33 cfo215: if you took out qtbase as well, then I suspect it won't have Aug 21 21:44:18 bluelightning: i did take it out. I'll put it back in... won't be long. Aug 21 21:45:00 seebs: this is a package I'm trying to add into my own layer, but really nothing special Aug 21 21:46:19 seebs: this is the link to the package https://code.google.com/p/snappy/, has anyone added it successfully? Aug 21 21:47:49 I haven't heard of it before, so I don't know. I'm not sure where in the process this is failing, but I guess the first thing I'd probably do is look through any text associated with this for instances of 0xa1, or whatever that value was. If a description is including that character, maybe edit that. Aug 21 21:50:54 enh? it seems the error was from extraction rpm script, meaning the created rpm has corrupted value? Aug 21 21:55:15 bluelightning: the new image is 20.8 MB compared to 2.9 MB w/o qtbase... so I'm guessing qt is in there somewhere. Aug 21 21:55:28 cfo215: heh Aug 21 21:56:44 zenlinux: Hi, can you extend http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html to explicitly say that BSP layer shouldn't change metadata for other MACHINEs (i.e. describe that MACHINE overrides have to be used for each assignment/append and MACHINE subdirectories for files used from SRC_URI)? It's hard to explain this to some people and having link to some well written documentation would help a lot, thanks Aug 21 21:57:17 JaMa, you're looking for other "other" Scott, scottrif Aug 21 21:57:33 zenlinux: ah sorry Aug 21 21:57:37 no prob :) Aug 21 21:58:04 man, I can't form a coherent sentence myself Aug 21 21:58:56 scot: are you right scott for this task? ^^^ :) Aug 21 21:59:40 Scott Rifenbark's nick is scottrif. He's in Europe IIRC so it may be late for him. Aug 21 22:00:11 OK, I'll check bugzilla anyway Aug 21 22:00:19 your best bet is to make the request on the yocto ML or bugzill Aug 21 22:00:21 a Aug 21 22:02:34 bluelightning: ./usr/lib/libQt* is in there. I'm a happy camper today!.... now onto building the sdk... if I recall the command is bitbake -c populate_sdk console-image Aug 21 22:03:16 cfo215: :) Aug 21 22:03:41 cfo215: not sure whether anyone's implemented the SDK for qt5 yet, last I checked nobody had Aug 21 22:05:11 bluelightning: I think I just verified that... :( ERROR: Nothing PROVIDES 'core-image' Aug 21 22:05:42 cfo215: I think that's a mistake in your command line, at least out of the box there is nothing called "core-image" Aug 21 22:06:15 no recipe, at least Aug 21 22:06:51 bluelightning: bitbake -c populate_sdk core-image-minimal is working... so far, so good... Aug 21 22:23:33 bluelightning: Sorry had to leave for a bit. I had a look in the work directory and can't even find a .cinfig!! Aug 21 22:23:54 oops .config Aug 21 22:26:23 the config fragment made it into the work directory, but don't know if it made the .config, as I can't find it Aug 21 22:26:51 .config is in the source tree, not workdir Aug 21 22:27:42 oh, where abouts? in the git folder? Aug 21 22:28:29 yep Aug 21 22:28:32 kergoth: depends, at least linux-yocto uses a separate directory to build in Aug 21 22:28:37 true Aug 21 22:28:41 thanks, will have a look Aug 21 22:28:46 bitbake -e | grep '^B=' might be the best bet :) Aug 21 22:28:52 bitbake -e virtual/kernel that is Aug 21 22:30:08 my kernel is linux-mainline Aug 21 22:31:52 ends up: "/home/bmentink/beagleboard_black/build/tmp/work/beaglebone-poky-linux-gnueabi/linux-mainline/3.8.13-r23a/git" Aug 21 22:32:09 yep, thats .config will be after do_configure runs Aug 21 22:33:16 my change did not get into the .config there Aug 21 22:34:10 er, actually... if you're using linux-mainline, I'm not sure you'll have config fragment support Aug 21 22:34:29 I have no idea what i have done wrong with my fragment Aug 21 22:35:01 oh, so I have to make the change to what to get it to stick? Aug 21 22:35:23 without config fragment support you will need to supply a full defconfig Aug 21 22:35:36 do I put it into defconfig in that directory Aug 21 22:36:23 or can I put the defconfig file in my layer Aug 21 22:36:51 it would go in the same place as any file your kernel recipe needed to reference (and you'll need to point to it in SRC_URI) Aug 21 22:37:07 alternatively you can change your kernel recipe to be like meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Aug 21 22:37:19 that provides config fragment support Aug 21 22:38:31 so just pich the portions that do the fragment support? Aug 21 22:40:08 I think you'll have to pretty much take the whole thing Aug 21 22:40:57 but the difference with linux-yocto is you can point to your own standard source tree (or the mainline kernel source tree) rather than split source/meta branches that linux-yocto requires Aug 21 22:41:35 I'd question that recipe naming. imo "linux-yocto" implies said source/meta branching Aug 21 22:41:38 heh Aug 21 22:42:01 perhaps, but there was no config fragment functionality before linux-yocto either :) Aug 21 22:42:18 at least not that I am aware of Aug 21 22:42:34 I am out of my depth here .. Aug 21 22:43:20 brm: have you had a look at this manual? http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Aug 21 22:44:07 brm: that should cover the basics Aug 21 22:44:13 yep have, still struggling .. Aug 21 22:44:44 most of the examples there assume linux-yocto kernel not mainline Aug 21 22:45:13 so a lot of the commands don't work Aug 21 22:45:21 brm: start with linux-yocto-custom; apart from the bits that talk about split meta branches, the rest is equally applicable to linux-yocto-custom Aug 21 22:45:43 linux-yocto-custom is covered under 2.4. Working With Your Own Sources Aug 21 22:46:59 kergoth, I sent you a pull request for that meta-sourcery stuff. It's probably still got bugs, but it's far enough along that I don't feel totally awful inflicting it on someone. Aug 21 22:49:17 so I have to use a different kernel? The BBB receipe has to use linux-mainline as all the BBB patches are on that kernel Aug 21 22:49:36 brm: no, you can point to the exact same source and use the same patches Aug 21 22:50:01 brm: you can use the same SRC_URI line Aug 21 22:51:24 ok, got it thanks .... Aug 21 22:52:07 going for lunch now, thanks for your help ;-) Aug 21 22:52:43 seebs: cool, thanks, will likely take a look at it tomorrow Aug 21 22:52:55 'k. Aug 21 22:53:19 I'm on vacation Friday through a week from Monday, and probably won't check work email. Aug 21 22:53:44 k Aug 21 22:53:50 Might be around this channel, though, because my freenode IRC is on the client I use for personal chats anyway. Aug 21 22:55:20 * kergoth nods, same Aug 21 23:35:33 is mark hatle here? Aug 22 00:26:30 bozojoe: mark is fray Aug 22 00:45:50 anyone from intel or windriver here? Aug 22 00:45:57 I deny everything. Aug 22 00:46:04 lol Aug 22 00:46:35 i'm a MCG guy from intel... trying to find out about yocto inside the company Aug 22 00:47:02 i've asked in our kernel mailing list but haven't heard anything yet Aug 22 00:55:29 any use of yocto on android targets here? **** ENDING LOGGING AT Thu Aug 22 02:59:58 2013