**** BEGIN LOGGING AT Thu Nov 27 02:59:59 2014 Nov 27 04:15:33 Is there anyway to call patch_do_patch() from a plain (ie: shell) do_patch()? Nov 27 09:40:19 morning all Nov 27 10:02:34 I'm trying to make a recipe that splits an application into multiple packages Nov 27 10:03:13 I've tried part of it manually, by prepending names to PACKAGES, then making the necessary changes for that Nov 27 10:03:41 that seems to work, but now I want to split out more parts using do_split_packages Nov 27 10:04:25 AFAICT, I've done it like the manual says, by placing the call in python populate_packages_prepend() Nov 27 10:05:00 but no packages are generated, even though I can insert some debug print statements and see that there are additional package names in the PACKAGE variable Nov 27 10:05:10 any suggestions? Nov 27 10:06:54 presumably if PACKAGES is being set, the problem is FILES isn't... maybe the path/spec being specified tin the call doesn't match the installed files? Nov 27 10:10:36 How to hook static analysis tools like cppcheck, lint, Coverity to bitbbake builds? I'd like to fail builds if some checks fail, and run full analysis on whole bitbake based distro sources. Nov 27 10:11:01 bluelightning: At least for one of the packages, FILES_my-sub-package seems to be set Nov 27 10:15:16 hi, is it possible to have a psplash without progressbar? Nov 27 10:15:44 mckoan: I think the way to do that is to patch away the draw calls for the progress bar Nov 27 10:15:49 that's how I've done it Nov 27 10:16:30 simonl: thx, do you mean modify the psplash package? Nov 27 10:18:12 mckoan: yes, add a patch that removes the progress bar draw calls, it's in psplash.c around line 120-130 or something like that Nov 27 10:18:33 (use a .bbappend) Nov 27 10:19:40 simonl: ok, thx Nov 27 10:20:11 mckoan: np, glad to give something back for once :P Nov 27 10:22:28 mckoan: actually, for completeness I read my own patch wrong, it's around line 280 or so as well as line 115-ish :) Nov 27 10:23:51 mcfrisk: This answer is likely a little OT, but doesn't coverity charge by code base size to scan? Wouldn't want to scan an entire distro if so ;) Nov 27 10:29:18 simonl: that's what I hear too, but they also don't charge that much from open source code bases, that's what I hear. Also clang has a compiler wrapper static analysis tool. So I'm looking where to hook them in a yocto build env. Nov 27 10:34:02 mcfrisk: Yeah, it's not that I'm against it, I might even be interested in doing that if it's not too much work :) Nov 27 11:59:33 any more suggestions on my issue (posted ~2 hours ago)? Nov 27 12:06:15 oh, just spotted something, while the files added to the FILES_* variables by do_split_packages are there, they have the full patch on the host filesystem, while the other, manually specified files have the path on the target fs. That's gotta mean something. Nov 27 12:06:39 you could write a new task that changes CC to whatever the magic wrapper clang uses for static analysis and then re-executes the compile task Nov 27 12:07:06 simonl: FILES should contains target paths, so your recipe is doing something wrong Nov 27 12:09:04 rburton: here's my populate_packages_prepend: http://paste2.org/tEHEcxaP Nov 27 12:09:22 I don't know where the host-absolute path is coming from :/ Nov 27 12:11:00 simonl: ok Nov 27 12:14:02 simonl: possile that you've found a bug in the recursive mode. do you need it to recurse into subdirectories of root? Nov 27 12:16:08 rburton: Not really, but since there are separate subdirs, I'd need to loop myself. Nov 27 12:16:25 I actually tried that, but there was no change Nov 27 12:16:44 I know more now though, so I'll try that again Nov 27 12:23:36 rburton: Ok, with recursion off I get target paths, but still no packages Nov 27 12:23:57 starting to think this is a _really_ stupid mistake (except the recursion thing) Nov 27 12:28:21 can you share the recipe? Nov 27 12:28:43 but host paths when recursing seems to be a bug in that logic Nov 27 12:28:44 hey, is there any proper way to trigger a build by polling a git repo ? Nov 27 12:29:09 ccube: use whatever CI system you want, and make it call bitbake Nov 27 12:29:23 several people use jenkins Nov 27 12:29:25 oops, sorry. i am talking about yocto autobuilder Nov 27 12:30:28 in that case i'm not sure if there is support right now for that, but it cant be hard to do as buildbot can do that iirc Nov 27 12:31:25 I actually have a SingleBranchScheduler, which is supposed to do that, but it does not start building after i pushed something to the repo Nov 27 12:36:04 rburton: I'm not sure I can share the recipe :/ Nov 27 13:26:08 rburton: another symptom I assume: If I add one of the known package names that should be generated by do_split_packages to the PACKAGES variable manually, a package is built Nov 27 13:35:05 I have a problem building a linux kernel with Yocto - yesterday it was working, but i've setup a new VM with a fresh setup, and not the kernel doesn't want to build: http://pastebin.com/raw.php?i=BDmfcRWY Nov 27 13:35:17 anyone know what could cause this vmlinux invalid argument ? Nov 27 13:35:37 or just a hint in what direction I could check ;) Nov 27 13:39:16 acidfu: run with V=1 to see the command that is executed Nov 27 13:39:42 zecke, ok I'll try with that, thanks :) Nov 27 13:54:08 simonl: scrub all secret words and pastebin it? Nov 27 14:11:53 rburton: http://paste2.org/HgDEWzPm Nov 27 14:12:33 sorry about the copy-paste in there. I should fix that... Nov 27 14:18:36 It seems like the package isn't built if the name is added after the main-ui package in the variable. I vaguely remember order having some kind of significance, but not building a recipe at all seems a bit odd :) Nov 27 16:05:21 <_qwerty_> Hi I am trying to create a sd to boot with my beaglebone with core-minimal image but it doesn't work Nov 27 16:05:38 <_qwerty_> kernel stop on Start kernel Nov 27 16:05:48 <_qwerty_> this is my script to create sd http://pastebin.com/gt2jrg0f Nov 27 17:24:39 is it OK to ask about patches here? Nov 27 17:24:52 I decided to revisit my unmerged changes and "clean them up". Nov 27 17:25:06 but I would not like to run needless circles for obvious mistakes. Nov 27 17:30:35 point at patches and people available can review. remember that its the end of day for europe and america isn't going to be here Nov 27 17:30:42 so i'd wait until next week :) Nov 27 17:31:03 isn't it just Thursday? Nov 27 17:31:30 its thanksgiving Nov 27 17:31:41 it's thanksgiving Nov 27 17:31:57 in the upper left side of the world Nov 27 17:32:56 rburton: hmm? I thought you were from the uk Nov 27 17:33:02 i am Nov 27 17:33:06 and its half past five in the afternoon Nov 27 17:33:11 so i expect to be knocking off shortly Nov 27 17:33:33 rburton: sure, but why next week? Tomorrow is a working day in the UK, at least for us. Nov 27 17:33:40 sure Nov 27 17:34:06 so send mails now and anyone around can review Nov 27 17:34:18 sending me a patch means it joins my backlog of 186 mails Nov 27 17:34:55 rburton: you don't like having 187 emails to read? Nov 27 17:35:11 diego_r: this is gmail "conversations" so that's a lower-bound :/ Nov 27 17:35:38 lpapp: seriously, review by mail is great as its a persistent and asynchronous record :) Nov 27 17:38:53 rburton: I have never wanted to send you an email... I rather preferred to show it here. Nov 27 17:39:03 it is kind of annoying waiting one week on the mailing list and then get a nitpick. Nov 27 17:39:16 and do the whole submission process again if your change still applies, you still have it somewhere, etc. Nov 27 17:49:52 is it more effective to CC people? Nov 27 17:50:05 say, who commented on previous versions? Nov 27 17:58:43 lpapp: certainly can't hurt Nov 27 17:58:46 bbl Nov 27 18:00:10 JaMa: what is the reason for accepting cgdb in meta-oe that depends on gdb? Nov 27 18:00:19 should it not depend on gdb-cross instead, eventually? Nov 27 18:00:37 or was it meant for target? Nov 27 18:00:47 perhaps there is a need for separate cgdb-cross and cgdb recipes. Nov 27 18:01:15 I have a cross recipe also inheriting cross. Should I submit that? Nov 27 18:01:42 JaMa: http://paste.kde.org/p4k4z0aoj Nov 27 18:02:10 cgdb native would be way too heavy for my small board ^_^ Nov 27 18:17:23 JaMa: I guess the best would be to rework it similarly to the gdb and gdb-cross concept with all the .inc and all that. Nov 27 18:17:52 but I do not care that much ^_^ Nov 27 18:29:39 Is there a way to stop yocto from stuffing sources into -dbg specific -dbg packages? Nov 27 18:30:07 staylor_: yes Nov 27 18:32:02 lpapp: any pointers to how I could do that please? Nov 27 18:32:09 staylor_: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGE_DEBUG_SPLIT_STYLE Nov 27 18:32:19 lpapp: thanks! Nov 27 18:32:22 e.g. PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src" (assuming I understood your correctly) Nov 27 18:32:29 you* Nov 27 18:33:56 lpapp: Yeah that's exactly what I was looking for, thank you very much. Nov 27 18:35:13 np Nov 27 18:55:27 lpapp: I don't know the original intentions of cgdb recipe author, it can be useful on target, so it was accepted (nobody complained during the e-mail review) Nov 27 18:56:17 JaMa: yeah, I do not claim the opposite. With NFS or big flash, it is ok. Nov 27 18:57:19 JaMa: I have a ready-made version for cross, but I guess it would not be accepted because it is better to share stuff Nov 27 18:57:43 and usually it is not acceptable in my experience to do incremental improvements if you can step two in one go even if that takes more time, energy, etc. Nov 27 18:57:50 otherwise I would submit my recipe as is ... Nov 27 18:58:48 lpapp: by native you mean target, right? Nov 27 18:59:04 yes Nov 27 18:59:47 my above paste is working, it could be renamed to cgdb-cross*.bb, however, I think. Nov 27 19:00:07 it would be nice to share at least .inc file between target and cross version Nov 27 19:00:35 yes, that is ideal, but I cannot test the native version. Nov 27 19:00:47 and after such a refactoring, I would have to retest both variants, surely. Nov 27 19:00:58 you don't have to, if you don't change it by introducing .inc file :) Nov 27 19:01:35 if the target one still builds and looks the same in bitbake -e, I think it would be worth introducing the .inc file Nov 27 19:02:12 to be honest, I do not understand why the recipe authors need to take care. Nov 27 19:02:27 who else should care? Nov 27 19:02:32 I don't even plan to use it Nov 27 19:02:34 in an even more ideal world, you would write one recipe and the platform would take care of cross or target. Nov 27 19:02:41 ah Nov 27 19:02:53 and the platform would figure out with an option. Nov 27 19:03:05 so you would not need .inc + target + cross, just a merged .inc + both. Nov 27 19:03:11 by both, I mean just the generic parts. Nov 27 19:03:26 there is not so much to differ, although if one needs patches, etc, hmm, well, it could be different yeah. Nov 27 19:03:45 sadly in real world the cross isn't straightforward change from target recipe (in some cases) Nov 27 19:03:53 I do not understand the patch for the merged cgdb, but without that, it is pretty straightforward, only gdb -> gdb-cross change + inherit cross. Nov 27 19:04:19 yes I was wondering if BBCLASSEXTEND supports cross too Nov 27 19:04:24 okay, I will try to refactor my paste into .inc and cross tonight. Nov 27 19:04:31 but there isn't such example so I guess no, or not well tested Nov 27 19:05:32 need to leave home now, thanks, cya :) Nov 27 19:06:56 * JaMa too Nov 27 22:50:36 Hi all Nov 27 22:51:13 why with kernel built with yocto 1.7 freeze beaglebone on mmc Nov 27 22:51:21 reading uImage Nov 27 22:51:21 5068032 bytes read in 616 ms (7.8 MiB/s) Nov 27 22:51:21 Booting from mmc (uEnv.txt configuration) ... Nov 27 22:51:21 ## Booting kernel from Legacy Image at 80200000 ... Nov 27 22:51:21 Image Name: Linux-3.14.19-yocto-standard Nov 27 22:51:24 Image Type: ARM Linux Kernel Image (uncompressed) Nov 27 22:51:26 Data Size: 5067968 Bytes = 4.8 MiB Nov 27 22:51:28 Load Address: 80008000 Nov 27 22:51:30 Entry Point: 80008000 Nov 27 22:51:32 Verifying Checksum ... OK Nov 27 22:51:34 Loading Kernel Image ... OK Nov 27 22:51:36 OK Nov 27 22:51:38 Starting kernel ... **** ENDING LOGGING AT Fri Nov 28 02:59:58 2014