**** BEGIN LOGGING AT Mon Jan 09 03:00:00 2017 Jan 09 18:22:26 I'm having trouble getting through package_qa without a pile of warnings about locations for -dbg, -dev, etc. I've collected all lib*.so in FILES_${PN}-dev, and all lib*.so.* into FILES_${PN}, for example, but packaging ${PN} causes QA to complain about those versioned libraries being present. Are they not supposed to be included in the main package? Jan 09 18:53:16 eengie: try without changing packaging split? Jan 09 18:54:04 I'm not familiar with that one. Are you referring to INHIBIT_PACKAGE_DEBUG_SPLIT = "1"? Jan 09 18:56:57 hrw: previously I was getting around the error using INSANE_SKIP_${PN}-dbg += "libdir" so I was looking for an alternative, in that case. Jan 09 18:57:13 eengie: remove all FILES PACKAGES INSANE_SKIP INHIBIT_PACKAGE like vars Jan 09 19:10:09 that papers over the problem Jan 09 19:10:24 the real issue is that you need to check the packaging Jan 09 19:10:43 and ensure that the files are accounted for in correct FILES_package Jan 09 19:10:47 construct Jan 09 19:11:04 it seems this package is not using usual /usr/lib or /lib locations Jan 09 19:11:11 but something else Jan 09 19:27:34 khem: that's correct, it installs all of its assets within /usr/local/this_package/(bin, lib, etc.) Jan 09 19:29:00 because of that I've had to do some goofy stuff on the deploy side too, to ensure that files actually make the journey to sysroot...but that all works fine. It's basically just a packaging problem right now, and how it seems to not appreciate the offset into a separate space. Jan 09 20:24:58 Add ${exec_prefix}/local/bin etc. to FILES_${PN} Jan 09 20:25:32 and FILES_${PN}-dbg = "${exec_prefix}/local/bin/.debug/" Jan 09 20:25:35 etc. Jan 09 20:38:08 khem: yes, that's what I did. The issue was that when I would package things like my versioned libs into FILES_${PN}, QA would still complain (libdir) even though it probably shouldn.t Jan 09 20:38:26 shouldn't*... man, typos today... Jan 09 20:41:10 the libdir check doesn't account for /usr/local I don't think Jan 09 20:41:34 legit uses of /usr/local are extremely rare, hence no default support Jan 09 20:42:51 pretty much the whole point of /usr/local is for stuff the admin installs without the package manager, so i think the way we handle it is correct Jan 09 20:43:14 right Jan 09 20:43:15 Be that as it may, I was getting QA errors when doing things like FILES_${PN} += "${MY_OFFSET}/lib/lib*.so.*" that a library was found where it shouldn't be. Jan 09 20:43:26 yep Jan 09 20:43:47 I think you will need to use INSANE_SKIP to disable libdir test for your recipe in this case Jan 09 20:44:02 well, for the package since INSANE_SKIP is per package Jan 09 20:44:24 So therefore, given that MY_OFFSET is down /usr/local, I think we can say that libdir does check down /usr/local. Jan 09 20:44:44 Unless I'm misunderstanding your statement. Jan 09 20:46:50 The folks who developed this went to great lengths to all of their libraries, etc., within its own self-contained main sub directory, wherever the user feels like putting it. So where they want it in /usr/local/something is kind-of moot in a way. Is expectation that users wanting to lump all of their files together should stick them in /var ? Jan 09 20:48:06 (At this point, I retain that /usr/local/something offset mainly just to keep familiarity for users coming from a desktop distro install of the framework, but if I can reduce headaches in bitbake by picking some other /something offset, I'll do that.) Jan 09 21:01:06 no it does not Jan 09 21:01:41 so you need to write bunch of FILES_* statements Jan 09 21:21:34 I think at this point we're all talking past one another regarding libdir. At this point what I'm doing is FILES_${PN} += "/usr/local/my_offset/lib/lib*.so.*", for example, which fails QA for the sake of the libdir check. When you guys are saying "it" (assuming libdir QA check) doesn't check /usr/local, I'm having a hard time agreeing with you because the libdir check is clearly being applied to /usr/local/my_offset despite the fac Jan 09 21:22:40 (I say clearly, since, I'm getting the warning and the solution to silence it is using INSANE_SKIP.) Jan 09 21:23:33 yes, just remove the libdir warning with INSANE_SKIP and move on Jan 09 21:26:32 kergoth: is there a better location for bitbake's sake, to lump everything together and avoid all this? Jan 09 21:26:58 I don't understand the question. Lump which together? Jan 09 21:27:25 there's no "avoiding all this" without packaing things in standard locations. if you package in non-standard locations, you have to disable the qa check about locations. Jan 09 21:28:16 kergoth: I'm referring to how these folks generally deploy their whole framework (loads of packages) into a single directory and link against it there rather than distributing it across the standard locations like /lib, etc. Jan 09 21:28:55 create a bbclass, inherit it in the recipes in question Jan 09 21:29:02 what's what bbclasses are for, common bits amongst recipes Jan 09 21:30:13 And fair enough about the non-standard locations. Thanks for the explanation. I do have a few bbclasses for their framework elements, but didn't go so far as to add packaging as well until today. **** ENDING LOGGING AT Tue Jan 10 03:00:01 2017