**** BEGIN LOGGING AT Thu Feb 15 03:00:01 2018 Feb 15 07:36:14 New news from stackoverflow: Yocto Project usb sensor acces Feb 15 09:06:33 New news from stackoverflow: ERROR: packagename-0.1-r0 do_compile: Function failed: do_compile Feb 15 10:27:56 Hi, how to create a local string variable inside a bb file? I just want to do MY_DEST=/usr/local/blafoo and inside do_install() use this variable so that I don't have to type the path 10 times... Feb 15 10:37:34 kalpu: actually it should just work that way. Feb 15 11:47:34 hey guys! Any ideas on how to preconfigure Connman with some wifi ssids during Yocto build? FS-based configuration is painful, from what I get, so maybe there are some existing Yocto tricks for that? Feb 15 12:24:42 Hi there. I have a question regarding the build process of yocto. I hope this is a good place to ask? Feb 15 12:24:51 yes, why not Feb 15 12:26:26 Good! Then here it goes: I want to know what files are used an how they are used during the build process. Explicitly, if I run bitbake on a recipe, which files do get combined to build a .so, .a, or other file Feb 15 12:26:44 is there a quick way to keep track of that? Feb 15 12:28:33 Guest45950: thats actually kinda outside the scope of bibake, as it just starts the various sub-buildtasks Feb 15 12:29:37 you could use the generated logs to extract data, maybe Feb 15 12:31:16 LetoThe2nd: I attempted to generate maps with additional LDFLAGS, but this broke some build processes. And from the do_compile-logs it is somewhat hard to infer. Feb 15 12:31:53 (which is why I am asking) Feb 15 12:32:48 Guest45950: hm. in terms of, maps for debugging? Feb 15 12:35:23 LetoThe2nd: Maps in terms of makefile maps. They give a GNU linker mapping back that is supposed to show me which file and which function has been used to build some library Feb 15 12:35:50 Guest45950: wouldn't it be enough to patch the one recipe you're probably interested in? Feb 15 12:37:28 LetoThe2nd: It most likely would be, but whenever I would update to the next version I would have to add my patches again. Which is ok, but not necessarily what I want to do. Feb 15 12:38:26 Guest45950: well if its your own application recipe, you could certainly put that behind a distro feature or such. Feb 15 12:38:35 but i'm not aware of a generic solution. Feb 15 12:39:48 LetoThe2nd: well, generic would have been nice ;) but if there is no generic solution, I will have to patch until I can come up with a better idea. Feb 15 12:39:51 Thanks! Feb 15 12:40:45 Guest45950: good luck. you can still post that question to the oe-devel mailing list, i feel it could be interesting for others. Feb 15 13:21:05 Sehr gut Feb 15 13:27:15 kergoth: "we should use --unity with meson" you said. my testing of two recipes says that sources need to be written a bit carefully, both libepoxy and json-glib fail with it enabled Feb 15 13:27:48 what does --unity do? Feb 15 13:28:42 magically glues all the sources into a single compilation unit Feb 15 13:28:59 so faster and potentially better code Feb 15 13:29:18 caveat that its easy to write code which can't handle this and will fail to build Feb 15 13:38:56 rburton: yeah, it's like autotools make distcheck - no one ever runs it or is even aware of it Feb 15 13:39:35 unity is just an option though, so i'm fine with it not working everywhere Feb 15 13:39:40 distcheck, there's no excuse! Feb 15 13:54:18 does anybody know which recipe /var/lib/connman/settings belong to? and if it is created on-the-fly, how do I preset my yocto build to enable wifi by default? Feb 15 13:57:25 luneff: oe-pkg-util or whatsitcalled should be able to tell you. Feb 15 13:58:36 ERROR: Unable to find any package producing path /var/lib/connman/settings Feb 15 13:58:38 :-) Feb 15 13:59:09 Hi! Feb 15 13:59:24 Is there a way to build 2 different images in the same build directory? Feb 15 14:01:39 didil: um, whats the problem? bitbake image-a image-b ? Feb 15 14:01:56 RP: ping. I wanted your opinion on my kernel-devsrc plan. Feb 15 14:05:02 LetoThe2nd: I have 2 recipes compiling different code but adding the same conf files. I want to be able to build 2 differents images each with one of the recipes but I get a "check_data_file_clashes: Package package1 wants to install file but that fil is already provided by package package2" Feb 15 14:05:16 package1 isn't in the image file Feb 15 14:05:34 didil: um, thats actually not related at all to images. Feb 15 14:06:15 didil: you have two packages that try to install the same file to the image, its that simple. so they clash, bitbake doesn't know which one you actually want, and leaves it for you to sort it out. Feb 15 14:06:18 images shouldn't be totally separated? why image2 try to install package1? Feb 15 14:06:49 didil: presumably because the dependencies are telling it to Feb 15 14:07:33 didil: it has nothing to do with the image, at least not directly. Feb 15 14:08:23 Image1: https://paste.ofcode.org/kCB4xaYLUyFDyTNUrfTTcN, Image2: https://paste.ofcode.org/S7GbJ2FN9tJsuNX5a7kWyG Feb 15 14:08:51 bitbake udoo-image-vesta-lavorant shouldn't event try to deal with vesta-app or? Feb 15 14:09:07 didil: how should we know? Feb 15 14:09:42 simply because this isn't in the image file or at least removed by IMAGE_INSTA_remove Feb 15 14:10:26 didil: as we cannot tell what the specific packages pull in as dependencies, there is no way for us to tell. Feb 15 14:13:09 I had similiar problem. I tried to fork libvncserver recipe, and bitbake complained about all of them providing same libraries. Never figured out what to do here. One option was to use provider mechanism for that, so you select the proper recipe with local.conf and depend on some virtual recipe Feb 15 14:14:09 actually it looks like the preoper appraoch would not be to load a full blown image first and the reshape it, but pour the common parts into an include and then add as needed. Feb 15 14:16:51 There is not dependecies and not reason for "udoo-image-vesta-lavorant" to build "vesta-app" Feb 15 14:16:53 https://ibb.co/bFcLGS Feb 15 14:17:16 Maybe there is a bug in the cache? Feb 15 14:17:31 I tried bitbake -c cleanall vesta-app Feb 15 14:18:14 but it still builds the package Feb 15 14:19:30 i actually doubt that the dependency resolution mechanism is broken Feb 15 14:20:31 it doesn't work as expected anyway Feb 15 14:21:02 maybe pastebin the full error message, and not your abrigdged, redacted version calling things package1 and package2? Feb 15 14:21:18 vesta-app: package1 Feb 15 14:21:23 vesta-app-lavorant: package2 Feb 15 14:21:57 that is not what i said. Feb 15 14:22:12 the message is pretty huge Feb 15 14:22:26 this is to be clear Feb 15 14:22:49 *shrug* Feb 15 14:24:01 It's to big to be copied Feb 15 14:24:11 here is the end of the message: https://paste.ofcode.org/38b5Y865ipXGhpKCKWtUxHW Feb 15 14:25:54 didil: is that maybe a relatively old version of poky? so the installation sysroot could still clash? Feb 15 14:26:09 morty branch Feb 15 14:26:28 It starts with: https://paste.ofcode.org/ZdbfMTdW88Fkf5JB6j78k6 Feb 15 14:27:15 pre pyro you can have clashes in that form, IIRC Feb 15 14:27:55 pyro causes a lot of error messages Feb 15 14:28:20 I haven't tried to solve them yet Feb 15 14:29:06 It seems always painful to move forward Feb 15 14:29:15 chances are pretty high that those error messages actually point out a lot of implicit dependencies that just work out of pure luck at the moment Feb 15 14:29:31 with pyro we got recipe specific sysroots. Feb 15 14:29:44 ok Feb 15 14:33:31 i'll give it another chance Feb 15 14:34:34 didil: theres nothing bad with sticking to morty, its just that you use case does not apply then. you'll need two build directory, but still can share downloads and ssate. Feb 15 14:36:19 yes there is this option but I try to avoid that as much as possible Feb 15 14:37:40 New news from stackoverflow: Why is uboot ignoring mmcroot in uEnv.txt? Feb 15 15:06:31 rburton: yeah, i tested it too, it seems like it naïvely compiled the sources together, so namespace conflicts become a concern. despite the manual's advice, seems unlikely to pan out unless the project author specifically keeps it in mind Feb 15 15:06:44 or rather, includes them together / concatenates Feb 15 15:07:02 ugh, so tired, multiple days in a row of gloom Feb 15 15:24:47 seebs: if we can get an interactive debug session going today, that would be much appreciated (if you guide me in pinning down the problem :) Feb 15 15:24:54 RP: ^^^^ Feb 15 15:37:05 Anyone have luck building for a xilinx picozed on an avnet FMC V1? Feb 15 15:37:57 New news from stackoverflow: Why is uboot ignoring mmcroot in uEnv.txt? [on hold] Feb 15 16:08:03 New news from stackoverflow: Device (iMX6) is not available from external network Feb 15 16:25:37 it is terrible using yocto plugin projects in eclipse, the indexer does not work, all the great features of eclipse are negated by a cmake or autotools project but these are the only options for yocto plugin, great job Feb 15 16:26:48 zarzar: we know that there are issues, and just a couple of days ago there has been an official announcement that they will be addressed - the plugin was mostly unmaintained for a long time. Feb 15 16:27:16 help welcome! Feb 15 16:27:29 hehe yes. "send patches!" Feb 15 16:28:41 ok i can help, first rule, do not release anything to the public that is not fully implemented and thought through Feb 15 16:28:50 welcome Feb 15 16:29:22 I use Qt Creator and populate_sdk, works fine for me :-) Feb 15 16:29:30 zarzar: being frustrated is ok, moaning at people who do offer you free software and support is not. Feb 15 16:29:36 i'd rather hack up cdt projects than use the cmake or autotools versions, so no real need for the yocto plugin Feb 15 16:30:05 i don't think there should be free software because of these types of issues Feb 15 16:30:23 imo stop all open source Feb 15 16:30:23 that's plainly rude, isn't it? Feb 15 16:30:24 ah, i see. that type of discussion. Feb 15 16:30:40 * zeddii gets his ignore filter ready Feb 15 16:30:49 * LetoThe2nd gets his zeddii ready Feb 15 16:30:56 here's a free car, it doesn;t work right though, but your welcome Feb 15 16:30:58 lol Feb 15 16:31:37 phew Feb 15 16:32:32 * zeddii goes for food. at least I didn't have to blow a gasket there (see the car analogy continued ? ;) Feb 15 16:42:49 Hi everyone -- first time on this channel. Can I ask a pretty specific question about bitbake? Feb 15 16:43:02 zeddii: that guy comes here every few weeks to moan about the eclipse plugin Feb 15 16:43:06 droctothorpe: please do Feb 15 16:44:01 So we have a Yocto build server that we use to build about two dozen applications. We need discrete versions of each recipe for each environment. Feb 15 16:44:35 So for example, I need a -acceptance_.bb file and a -staging_.bb file Feb 15 16:45:12 That have subtle differences (mostly just pointing to separate branches of the source repo) Feb 15 16:45:33 I need a way for bitbake to resolve which one I want to bake Feb 15 16:45:59 In a way that preserves the resulting application folder on the eventual install such that it does NOT include environment Feb 15 16:46:47 So (1) the recipe should include the env, (2) it would be nice if the pkg included the env, but (3) the actual installation directory on the target box should NOT include the env Feb 15 16:46:57 Does that make sense? Feb 15 16:47:33 I've been experimenting with removing the env from PN in an install_prepend block, then adding it back in an install_append block with limited success Feb 15 16:47:59 and wound up somehow breaking the build server in the process, which according to my friend means that I'm a real developer now heh Feb 15 16:49:18 Our interim workaround has been to have separate branches for each environment but has been problematic for a number of reasons Feb 15 16:52:07 kanavin: hi! that might be possible. honestly if you can narrow it down a bit i can probably have a go at the thing. although i'd need to download and rebuild an oe-core setup again. Feb 15 16:52:14 for reasons i have not been keeping things in order. :( Feb 15 16:52:44 rburton: i think there's only one possible fix Feb 15 16:52:58 find out how to identify the account he runs as, and make sure the bugs are preserved when run by someone with that username Feb 15 16:53:03 it's the only way to be fair Feb 15 16:54:21 the other thing i could try is add a `mv` command to pkg_postinst that just removes the env from the pkg name Feb 15 16:54:32 pkg folder name I mean Feb 15 16:55:59 seebs: I looked into it a bit more. If I run the do_install script directly under the new pseudo it works as intended. things break down when pseudo is used to run bitbake-worker, so something is happening there, and it might not be possible to produce a standalone reproducer :( Feb 15 16:56:09 seebs: hence the idea with logs (see bug) Feb 15 16:57:27 seebs: I did narrow it down to a recipe that takes only a few minutes to build (and only once) (see bug :) Feb 15 17:01:00 okay, sounds like a thing i can pursue. is there a branch of oe-core i can/should check out to try this? Feb 15 17:01:18 ... wow, it's been a long time. what's the canonical repo i should be cloning from, if i'm not doing "grab internal WR source"? :P Feb 15 17:09:31 kanavin: ^^^ Feb 15 17:10:19 seebs: kanavin put a url in https://bugzilla.yoctoproject.org/show_bug.cgi?id=11996#c23 Feb 15 17:10:20 Bug 11996: normal, Medium+, 2.5 M3, seebs, IN PROGRESS REVIEW , pseudo: cannot use unnamed temporary files (O_TMPFILE) Feb 15 17:10:31 er c25... Feb 15 17:12:08 rburton: "Error: cannot register alternative arch to /usr/bin/arch since it is already registered to /bin/arch" - which patch causes that? Feb 15 17:12:57 RP: in meeting right now Feb 15 17:13:07 rburton: np Feb 15 17:13:15 I guess to simplify my question, given a recipe `Archivist-Staging_1.1.0` what do I need to put in the recipe to make sure that it installs to a folder named `Archivist` instead of `Archivist-Staging`? Feb 15 17:14:26 The recipe currently has no do_install block Feb 15 17:14:38 thx, i will attempt it Feb 15 17:14:49 droctothorpe: what do you mean by "installs" ? Feb 15 17:17:35 ... okay so it turns out i don't even have an oe-core dir on this machine, and i vaguely recall that there were two upstreams i could use for oe-core but i don't remember which one was which. Feb 15 17:17:53 it really has been a while since i attempted this, apparently. Feb 15 17:18:16 if you want a single clone.. clone poky Feb 15 17:18:28 if you want multiple clones, do bitbake, oe-core separately.. Feb 15 17:18:45 seebs: just clone the url I posted to the bug Feb 15 17:19:18 RP: when I install the pkg on my target machine Feb 15 17:19:19 ... i'm confused. "http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/pseudo-1.9.0"? i thought poky-contrib was a separate tree. Feb 15 17:19:56 RP: so when I run dpkg -i on the resulting package, I want the contents to be stored in a folder called `Archivist` not `Archivist-Staging` Feb 15 17:19:59 that is a sepeate tree.. all depends on if it's based on poky or oe-core (probably poky) Feb 15 17:20:11 so you can just clone it down as a single item and use it, if that is the rperoducer instructions Feb 15 17:20:35 i assume there is some kind of naive translation from cgit URLs to git URLs Feb 15 17:24:23 git://git.yoctoproject.org/poky-contrib --branch akanavin/pseudo-1.9.0 Feb 15 17:24:55 man it has been too long Feb 15 17:25:22 anyone who isn't intel need a programmer to do yocto-ish stuff? (there are Issues with me trying to work for intel due to layoff paperwork) Feb 15 17:29:28 seebs: so are you all sorted with pseudo reprodcer? I was on the phone, but now finished :) Feb 15 17:35:28 i don't know. i'm up to the point of "why do i need texinfo noooo my disk space come back disk space i just freed that space up" Feb 15 17:35:54 i was so pleased, i found an 8GB tarball which contained a bunch of stuff i didn't need and also something like 10 screenshots i could conceivably ever want again. Feb 15 17:36:03 now that space will hold texinfo Feb 15 17:41:21 okay i got the thing to happen! Feb 15 17:41:28 | got *at() syscall for unknown directory, fd 5 Feb 15 17:41:28 | unknown base path for fd 5, path sound Feb 15 17:41:34 there we go now i just have to figure out why Feb 15 17:41:43 my guess is it's because i'm not good enough and do not deserve to have nice things Feb 15 17:45:33 seebs: os-release/.../image directory is created with (rw------) permissions for some reason, I think these messages are a consequence of that, they're not in itself the problem Feb 15 17:47:06 okay, thanks. i have it happening, i can attempt to debug it. Feb 15 17:47:39 seebs: cheers Feb 15 17:47:48 thanks Feb 15 18:02:45 Is there a better way to extend an existing vendor machine definition than copying it? Feb 15 18:23:11 tgoodwin: if machine definition has include files, you can re-use those Feb 15 18:23:31 e.g. meta-intel builds on things defined in oe-core Feb 15 18:24:08 Right, I see that much. I'm thinking more like overriding the KERNEL_DEVICETREE from a kernel append recipe based on the existing machine name. Feb 15 18:24:30 Or is that an inappropriate way to go? Feb 15 18:24:50 tgoodwin: that kind of thing is over my head unfortunately :) Feb 15 18:27:21 kanavin: :) What I'm working through is pulling someone's patches to a kernel fork into modules, which require device tree changes to map them back to the target hardware. Right now we have our own -extended machine name. I'm figuring maybe there's a cleaner approach like simply including the layer that includes all the necessary changes, re-using the existing machine name(s). Feb 15 18:28:14 you could do that, but i'd suggest creating a new machine which includes/requires the other machine .conf and defines MACHINEOVERRIDES to include both. Feb 15 18:28:47 but yes, you could make a layer modify recipes based on the existing amchine name.. it's not ideal, though, and technically violates yocto compliance rules regarding layer behavior Feb 15 18:29:08 layers modifying behavior based on inclusion in bblayers rather than being opted-in is a no-no in general, unless there's no alternatives Feb 15 18:29:11 * kergoth shrugs Feb 15 18:29:17 kergoth: good to know... Feb 15 18:29:49 i.e. bsp layers should only modify recipes using their machine overrides, distro layers only with the distro override, etc Feb 15 18:59:50 ... i am rusty and have forgotten. how do i hint to bitbake to be less aggressive about parallel builds and/or make jobs? Feb 15 19:02:24 ... nevermind, it turns out i still remember how to use google Feb 15 19:07:49 i think i found the bug Feb 15 19:09:18 hmm. i found a thing of which i am suspicious, anyway. Feb 15 19:11:12 there's an fchmod() that specifies a mode assuming that the thing being created by an open() isn't a directory, which should be right I think. But it's a point at which I'm changing a mode to a mode that might have no execute bits... Feb 15 19:36:41 #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY) Feb 15 19:36:48 SO IT TURNS OUT Feb 15 19:36:59 "flags & O_TMPFILE" is not a valid test for "O_TMPFILE is set" Feb 15 19:40:41 so i might have a trivial fix for that, the problem was that opens with O_DIRECTORY were not getting logged because I mistakenly thought they were O_TMPFILE. Feb 15 19:50:26 yup, that's it, that fixes the 11996 thing more correctly. i will now see if i can get the epoll hang to happen. Feb 15 19:50:59 new patch is up in pseudo's master branch. it's really obvious, once you know that O_TMPFILE isn't a bit, why it was behaving so incredibly strangely. Feb 15 19:53:33 @kanavin, or @rp: what's the epoll hang look like? can i reproduce it on a tiny laptop or must i get a huge system with many cores? Feb 15 20:22:35 anyone have some hints about having a A/B partition scenario, specially about verfiying the new image prior to set it default ? Feb 15 20:23:40 rob_w: i'd say, look at mender.io Feb 15 20:24:13 yeah they should have some sophistaced way thx Feb 15 20:24:35 rob_w: actually their overview already sugegst sometihng like that :) Feb 15 20:25:03 a good suggestion, one would want to verfiy as much as possible somehow Feb 15 20:25:12 hello! I want to install grub-efi into the rootfs instead of grub, but i get conflict, since they contains the same files, how to i replace grub with grub-efi Feb 15 20:26:05 i was interested what people do after first booting the new image just before the final "GO" Feb 15 20:26:16 found an old patch which let you install both, but it doesnt work anymore Feb 15 20:26:51 zepto88: umm... remove grub, add grub-efi for it? or whats the exact problem if they clash and you have to choose one? Feb 15 20:27:33 feels like there only can be one grub to rule ;-) Feb 15 20:27:42 if you mean remove with IMAGE_INSTALL_removed it doesnt work Feb 15 20:27:57 _remove** Feb 15 20:28:22 i guess you want to find who pulls the wrong package in Feb 15 20:28:26 zepto88: 1) it is _remove, not _removed 2) why not construct your image the way you want it, instead of trying to beat an existing one into shape? Feb 15 20:29:03 i think it comes from a packagegroup in meta class core-image or something Feb 15 20:30:05 zepto88: thats exactly what i mean. why are you blindly pulling in stuff ("i think"... "or something") instead of just wrting down the image recipe the way you want it? Feb 15 20:30:34 wow, came for help. getting bashed, Feb 15 20:30:45 *sigh* Feb 15 20:30:55 *sigh* Feb 15 20:31:26 its really the latest en vogue nonsense here. "how do i beat this and this and this into shape, i so totally want to avoid my image properly". seen it like 5 times this week Feb 15 20:31:43 the only thing i include in my recipe is my own installer script, then inherit core-image Feb 15 20:32:13 'bout two months ago, it was "why can't we automagically have package repositories and runtime package management" Feb 15 20:32:59 dude, im just asking if there is a simple solution to removing grub Feb 15 20:34:04 and i'm saying that you are probably blindly puling in something. not exactly by the image necessarily. my gut feeling says, its the MACHINE/DISTRO combination Feb 15 20:34:33 * LetoThe2nd feels honoured by the bill and ted dudism :) Feb 15 20:35:22 im not blindly pulling anything, like i said, recipe is inherit core-image from the meta layer, install bash script into /etc/init.d Feb 15 20:35:39 maybe name your DISTRO and MACHINE? Feb 15 20:36:29 *shrug* Feb 15 21:28:21 is there a way to specify the location of where the .patch in a SRC_URI is applied to? Feb 15 21:28:48 ie. to a file in ${WORKDIR} instead of ${S} Feb 15 21:33:25 i should add that for recipes where ${S} is redefined to be something as like ${WORKDIR}/git Feb 15 21:37:01 What determines the cutoff between master & master-next.... it currently seems to have cut halfway through my IceCream patches.... not that it is wrong, just strange Feb 15 21:44:30 * armpit time to learn how to update a yocto kernel Feb 15 21:48:24 sum1: yes, there's a url parameter to control it Feb 15 21:48:54 JPEWhacker: not really that strange :) Feb 15 21:49:29 JPEWhacker: the first half only touch the icecream class which has no testing in our infrastructure, the second half will hit testing Feb 15 21:51:30 JPEWhacker: worst case this means some bits fail in testing and you need to rewrite the end part of the series but saves me processing the first pieces again Feb 15 21:53:06 i tried ;patchdir= but that didn't work. ;url= should work? Feb 15 21:53:32 rburton: its the busybox upgrade causing the arch thing. Dropped that, time and nfs-utils, retrying -next Feb 15 21:54:30 hmm, ;url=${WORKDIR} for the file://thing.patch line in SRC_URI didn't work either. Feb 15 21:54:42 did i misunderstand your answer? Feb 15 21:55:16 RP: Makes sense, thanks! Feb 15 21:55:17 yes, patchdir is a url parameter on the file:// url. i didn't mean "url" literally Feb 15 21:55:30 patchdir should work fine, if it's not doing so, you'll have to dig into that or report a bug Feb 15 21:56:57 hmm k, yeah i hve a file in ${WORKDIR} that i'm trying to patch but it states 'No file to patch' even with file://thing.patch;patchdir=${WORKDIR} Feb 15 21:57:30 patchdir may be relative to S, try patchdir=.. Feb 15 21:57:37 can't recall offhand, worth trying though Feb 15 21:57:56 do you know if that behavior is still valid for .bbappends? as in an recipe from another layer puts file in ${WORKDIR} and my bbappend does the patch Feb 15 21:58:12 i'm assuming it's the same behaviour Feb 15 21:58:24 i'll give that a shot, thanks! Feb 15 21:59:01 bbappend is basically like concatenation, they don't change the semantics of a variable Feb 15 21:59:11 bitbake doesn't care waht file happened to define or append to a variable like SRC_URI Feb 15 21:59:14 in the end it's just one string Feb 15 21:59:51 yeah that's what i assumed, the parsing bb step in yocto is basically collecting all bbs and bbappends so they execute as a single unit, ya? Feb 15 22:01:54 hmm..., ;patchdir=.. doesn't seem to work either, i'll play around with it a bit more and see if i can figure out what's going wrong Feb 15 22:02:29 make sure your striplevel is correct to, if the subdir in the path file needs to be adjusted (passed to patch as -p) Feb 15 22:02:33 s/to,/too,/ Feb 15 22:04:35 the patch was created using git diff --no-prefix and my understanding is that it should apply cleanly Feb 15 22:07:40 cleanly with -p0 that is Feb 15 22:13:39 looks like ;p=0 was not making it through, i redid the patch file without --no-prefix and the default -p1 found the right file Feb 15 22:24:14 Is there any neat way to debug: ERROR: ParseError at Feb 15 22:24:24 the bitbake -e seems to be too late....... Feb 15 22:27:29 sum1: the patch class obeys the 'patchlevel' parameter, not 'p' Feb 15 22:27:44 patchlevel or striplevel, one of the two Feb 15 22:27:50 going off the top of my head here, but it's not p= Feb 15 22:29:24 Is there a place to ask about using the yocto build system. why don't I see any user forums? Feb 15 22:29:25 fair enough, i'll chalk that up to my mistake. thanks for all your help kergoth! Feb 15 22:29:31 np Feb 15 22:41:54 Guest90704: this is a user forum Feb 15 22:42:00 Guest90704: there's also the mailing lists Feb 15 22:47:21 administering forum software is a pain and searchable mailing list indexes suit us better Feb 15 23:50:05 Guest90704: there is stackoverflow as well for questions **** ENDING LOGGING AT Fri Feb 16 03:00:01 2018