**** BEGIN LOGGING AT Wed Oct 17 03:00:00 2018 Oct 17 03:11:19 robbawebba: I dont recall specifically, but yes I think we used late assignment Oct 17 03:15:01 robbaweba: I think you can also PREFERRED_PROVIDER_virtual/kernel_yourmachinename="your-preference" from local.conf and that will work Oct 17 03:16:02 robbawebba: though thats pretty gross Oct 17 05:06:23 New news from stackoverflow: Yocto Rocko bitbake process reboot on Ubuntu Oct 17 10:04:49 rburton: bitbake datastore cache is broke for remove operations :( Oct 17 10:05:05 My patch to fix remove checksumming just proves it :( Oct 17 10:05:12 (and is also bust) Oct 17 10:06:49 RP: https://www.youtube.com/watch?v=_NdHySPJr8I Oct 17 10:07:01 (picking up the keyword) Oct 17 11:13:32 RP: doh Oct 17 11:16:36 ok question whats the best way to deal with our custoom package conflicting with a standard yocto package say nginx... we boothh include index.html and well... build ffails Oct 17 11:17:19 OutBackDingo: for config files, bbappend the yocto recipe to not install the file Oct 17 11:18:58 bonus points for patching the recipe to split out stuff like that so you can not install them, and sending the patch in Oct 17 11:23:09 rburton: ohhh goodie Oct 17 11:23:53 mcfrisk: i was thinking more a bbapend to overwrite / remove theirs and use ours Oct 17 11:24:10 OutBackDingo: yea, that works too Oct 17 11:24:52 since id prefer not to much with their tree as we have all metas setup as submodules Oct 17 11:25:30 yay, welcome to git submodule hell.. :) Oct 17 11:25:38 yupp Oct 17 11:26:47 rburton: I've put revised patches into -next, lets give those a try. Not the kind of changes I like making at this point in a release cycle :( Oct 17 11:33:16 thinks we should devices a high level DONT_INCLUDE REGEX local.conf DONT_INCLUDE=nginx/index.html whicvh basically says recipe nginx doont include file index.hhtml Oct 17 11:37:57 What is the right way to change the PATH for recipes? Oct 17 11:37:59 OutBackDingo: you can probably construct that relatively easy using a ROOTFS_POSTPROCESS_COMMAND Oct 17 11:41:22 Hi all. Is it possible to modify a default script which which generates the sdcard image to copy the rootfs file on single partition? Oct 17 11:41:37 LetoThe2nd: actually a good idea Oct 17 11:42:54 A problem is that the default script creates a two partitions: "boot" and "rootfs".. But I need to have an one partition with both 'boot stuff' and 'rootfs.ext3' file.. Oct 17 11:43:10 Is it possible? Oct 17 11:44:29 I need the rootfs.ext3 file placed on some single partition with the uImage, u-boot and other files.. Oct 17 11:46:16 F.e. this script: https://github.com/Freescale/meta-freescale/blob/pyro/classes/image_types_fsl.bbclass#L175 creates a two partitions... But I need in one... Oct 17 11:47:07 I'm writing recipe A. A depends on B-native (also mine). B-native installs some executables to a "non-standard" location(i.e. not ${bindir}) that A needs for its do_configure(). How can I add something to A Oct 17 11:47:13 I'm writing recipe A. A depends on B-native (also mine). B-native installs some executables to a "non-standard" location(i.e. not ${bindir}) that A needs for its do_configure(). How can I add something to A's PATH? Oct 17 11:48:45 jofr: by extending PATH :) Oct 17 11:50:10 rburton: Thanks! But is PATH a string or a list? Oct 17 11:50:27 standard $PATH, colon-separated string Oct 17 11:50:45 note that if the location is non-standard, its most likely not even in the sysroot Oct 17 11:50:59 Ahh. Ok :) Oct 17 11:51:00 only select bits of a package go into the sysroot, the stuff needed to build Oct 17 11:51:09 Yes. Oct 17 11:51:14 you can add more, SYSROOT_DIRS Oct 17 11:51:51 Ok Oct 17 11:52:50 What about environment variables? Can is just set them in my recipe like you mention with PATH? Or is there a predefined list of environment-variables (including "PATH") somewhere? Oct 17 11:53:22 if you put 'export' in front of a variable assignment, it gets exported Oct 17 11:54:40 Anywhere or in do_configure() specifically? Oct 17 11:56:39 I mean.. Is "export" a bitbake keyword? I seems to me that anything in do_whatervers() are basically just executed as shellscripts (from ${S}), so I assume I can do basically whatever shell-commands in there..? But what I'm thinking about is the rest of the recipe Oct 17 11:56:55 outside of functions, export is a bitbake keyword Oct 17 11:57:02 inside a shell function, its shell, so does what you'd expect Oct 17 11:58:02 Nice. Thanks! Oct 17 12:02:22 with COPY_LIC_DIRS=1 the files in /usr/share/common-licenses on target have the wrong owner, they're owned by the buildsystem user Oct 17 12:02:36 ernstp: urgh. bug please. Oct 17 12:02:38 I filed a bug about it, but in the meantime I'm trying to work around it Oct 17 12:02:43 ah ok, what #? Oct 17 12:03:01 the fix is most likely fairly simple, just a chown in the right place Oct 17 12:03:15 #12961 Oct 17 12:03:38 I guess not many people enable that flag Oct 17 12:04:05 added a FILESYSTEM_PERMS_TABLES with /usr/share/common-licenses 0755 root root true 0644 root root Oct 17 12:04:14 but that didn't take unfortunately Oct 17 12:06:06 They're a bit tricky perhaps because they're linked and not installed. Oct 17 12:06:10 yeah that's ugly Oct 17 12:06:20 the code should just copy Oct 17 12:06:25 i thought there was a better way of doing this anyway Oct 17 12:06:35 very much a microoptimization :-) Oct 17 12:07:32 ah, I guess I could just add a ROOTFS_POSTPROCESS_COMMAND to fix it for now Oct 17 12:07:40 well if you turn on LICENSE_CREATE_PACKAGE you get a PN-lic package for each package installed Oct 17 12:07:48 then you can use complementary packages to pull all those in Oct 17 12:08:04 i guess thats not great if a package has complex licensing Oct 17 12:08:27 a patch i'd positively review would replace the initial link with a copy so the ownership in the rootfs is right Oct 17 12:09:48 will that automatically fix it, even if that code is not running under fakeroot? Oct 17 12:10:08 (can you run python code under fakeroot?) Oct 17 12:10:25 hm Oct 17 12:10:39 its a rootfs postprocess Oct 17 12:10:43 yeah i dont like this code one bit :) Oct 17 12:12:08 :-) Oct 17 12:12:33 but then again, no one really likes to work on licensing stuff :-) Oct 17 12:12:43 fwiw, setting COMPLEMENTARY_GLOB[lic-pkgs] = '*-lic' and LICENSE_CREATE_PACKAGE="1" and IMAGE_FEATURES_append = " lic-pkgs" might be an interesting experiment Oct 17 12:13:09 add a new image feature, turn on license packages, install them Oct 17 12:13:55 from the LICENSE_CREATE_PACKAGE docs it sounded like you don't have to do anything special, it adds RRECOMMENDS Oct 17 12:14:52 so it does Oct 17 12:15:03 assuming you install PN Oct 17 12:15:30 well those are the licenses you should ship so... Oct 17 12:16:06 not if you have a package that breaks into PN and PN-foo but you only ship PN-foo Oct 17 12:34:40 right Oct 17 12:43:19 Hi, I'm trying to add libinih (meta-oe/recipes-support) to my SDK Oct 17 12:43:58 does anyone know how to handle this ? Oct 17 12:46:48 and also this package has ALLOW_EMPTY = 1 Oct 17 12:48:04 rokm: the simplest way is to have your image that you create the sdk for depend in it (e.g., IMAGE_INSTALL) Oct 17 12:49:13 but I need lib file and includes in SDK to use it in apps Oct 17 12:49:30 yeah, so what? Oct 17 12:49:55 the sdk matches the image. so if your image contains the lib, the sdk will include the lib and headers too Oct 17 12:50:52 ye but image contains lib and includes but when I look into SDK there are missing Oct 17 12:51:01 I use populate-sdk Oct 17 12:51:18 and even I have this on target Oct 17 12:51:35 I need them on SDK for cross-compilation Oct 17 12:51:59 yesyes, thats obivous. just saw that it is static lib only. hm, let me check Oct 17 12:52:16 that I asked about this ALLOW_EMPTY Oct 17 12:52:47 TOOLCHAIN_HOST_TASK_append also didn't help Oct 17 12:53:05 the allow_empty is not the problem. the problem is that the static lib probably is not packed into anything else too. Oct 17 12:53:17 :| Oct 17 12:53:39 also I tried BBCLASSEXTEND = nativesdk Oct 17 12:53:54 I think all what I found in the internet Oct 17 12:58:55 LetoThe2nd: So it there any solution for this ? Oct 17 12:58:55 rokm: probably the recipe is not specifying FILES_${PN} += "${libdir}/lib*.so.*" Oct 17 12:59:48 yep original recipe doesnt have this Oct 17 13:01:17 but I don't think that this will help in SDK issue Oct 17 13:01:20 mckoan: well the recipe explicitly states that its static only. so the question is a bit, was this intentional (because upstream means it that way) or just lazyness (because submitter likes only static, doesn't care about the rest) Oct 17 13:01:45 LetoThe2nd: indeed Oct 17 13:04:29 ok, upstream seems to be quite unmaintened, last commit 4 or 5 years ago, but definitively shared-capable Oct 17 13:04:31 LetoThe2nd: rokm: in fact it is creating only libinih.a, no .so Oct 17 13:05:35 probably one should remove the ALLOW_EMPTY, and pass some extra cmake arguments to build the shared version Oct 17 13:06:13 -> https://github.com/OSSystems/inih/blob/master/lib/CMakeLists.txt Oct 17 13:09:25 LetoThe2nd: you need to run cmake -D BUILD_SHARED_LIBS=y . Oct 17 13:09:39 [ 40%] Linking C shared library libinih.so Oct 17 13:11:27 rokm: please add this into the recipe EXTRA_OECMAKE = "-D BUILD_SHARED_LIBS=y" Oct 17 13:11:36 ok will try Oct 17 13:12:17 and remove the ALLOW_EMPTY Oct 17 13:18:53 NOTE: make -j 4 -D BUILD_SHARED_LIBS=y Oct 17 13:19:03 make: invalid option -- 'D' Oct 17 13:26:02 So my make doesn't support this Oct 17 13:26:53 your make? Oct 17 13:27:02 -w, --print-directory Print the current directory. Oct 17 13:27:13 make: invalid option -- 'D' Oct 17 13:27:35 yeah but that should not even get to make, its for cmake Oct 17 13:27:56 I run bitbake libinih Oct 17 13:28:10 rokm: did you set EXTRA_OEMAKE or EXTRA_OECMAKE? Oct 17 13:28:16 rburton: ++ Oct 17 13:29:04 rokm: as I said, you need to run cmake -D BUILD_SHARED_LIBS=y . Oct 17 13:29:09 rokm: and then make Oct 17 13:37:14 doing this from devshell -> OK Oct 17 13:40:32 from bitbake --> libinih-0.0+gitrAUTOINC+25078f7156-r3 do_package_qa: QA Issue: -dev package contains non-symlink .so: libinih-dev Oct 17 13:41:38 could this be related to missing FILES_${PN} += "${libdir}/lib*.so.*" ? Oct 17 13:42:37 rokm: you shouldn't need the FILES_${PN}, actually once the EXTRA_OECMAKE is working properly Oct 17 13:42:39 no, because thats the default Oct 17 13:51:02 So is there any parameter that will force to create symlink for this lib ? Oct 17 13:52:24 rokm: can you share your recipe? Oct 17 13:53:31 https://pastebin.com/5uQ1YGMx Oct 17 13:54:03 i suspect you have more than that Oct 17 13:54:21 only these which is in meta-oe Oct 17 13:54:32 original bb file Oct 17 13:54:54 rokm: what is this a .bbappend? Oct 17 13:55:15 rokm: not sure ALLOW_EMPTY_${PN} = "0" is correct, I'd remove the whole line Oct 17 13:56:09 thats because the recipe has ALLOW_EMPTY=1, because its wrong Oct 17 13:56:24 why are you passing ${S}/lib in extra_oecmake? Oct 17 13:56:37 because it needs path to sources Oct 17 13:56:44 without this i got error Oct 17 13:57:34 that's passed before EXTRA_OECMAKE though Oct 17 13:58:04 and is ${S} Oct 17 13:59:24 when I remove lib at the end i got this linux-gnueabi/libinih/0.0+gitrAUTOINC+25078f7156-r3/build/BUILD_SHARED_LIBS=y" does not exist. Oct 17 14:00:01 from devshell I also had to put lib/ at the end Oct 17 14:00:09 to be able to compile Oct 17 14:00:21 sounds like you need to remove the space between -D and BUILD_SHARED_LIBS Oct 17 14:00:56 because it thinks BUILD_SHARED_LIBS=y is a path Oct 17 14:01:08 (yay cmake, always worse than you imagine) Oct 17 14:02:07 If I have two packages foo and bar that both provide virtual/foobar, am I supposed to be able to do EXCLUDE_PACKAGES = "virtual/foobar", or must I do "EXCLUDE_PACKAGES = "foo bar"? Oct 17 14:02:36 latter Oct 17 14:02:39 got the same results -> -dev package contains non-symlink .so: libinih-dev Oct 17 14:02:40 We just upgraded to Sumo, and it seems the former worked with Rocko, but not with Sumo... Oct 17 14:02:58 it works witkout /lib at the end Oct 17 14:03:11 but the result is the same Oct 17 14:03:11 rokm: so guessing the cmake file is broken and the shared library isn't versioned Oct 17 14:03:16 which is bad form Oct 17 14:03:29 https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries Oct 17 14:08:54 I assume that it is not possible to fix this from recipe Oct 17 14:13:18 libinih is under "new bsd" So I think it will be faster, easier and legal that I will just compile it into my app Oct 17 14:13:39 anyway thanks for support Oct 17 14:32:53 rokm: the wiki page i linked to tells you how to work around Oct 17 14:37:48 Hi, i'm looking for some help with meta-qt5. I'd like to change default libs path (/usr/lib) to custom (/opt/lib) on the target. I've been trying for 2 days and still have problems with building (yocto-sumo). Oct 17 14:43:30 rokm: use this https://pastebin.com/whLCm0Jr Oct 17 15:13:34 mckoan: thanks I will try it Oct 17 15:14:33 mckoan: do_install will put libs on target which I dont need Oct 17 15:16:07 but now I hope thet there will not be a problem since so are generated Oct 17 15:20:41 rokm: good luck! Oct 17 15:21:20 rokm: I wonder how you can not to use libs.so on the target if your app is using them though Oct 17 15:23:03 hehe ;) now I have too, still had in mind .a lib Oct 17 15:49:52 Hi guys. Why I got: No IMAGE_CMD defined for IMAGE_FSTYPES entry ... mesage when I try to create an own image type? Oct 17 15:50:22 presumably because you didn't set IMAGE_CMD for your image type? Oct 17 15:50:26 IMAGE_CMD_yourtypename Oct 17 15:51:06 I have created a new class file "foo-image.bbclass" and put it to 'foo-layer/classes Oct 17 15:51:24 In this image I have added: IMAGE_CMD_foo() {} Oct 17 15:51:43 In this class-file I have added IMAGE_CMD_foo() {} Oct 17 15:52:44 And I have added to IMAGE_FSTYPES = "ext3 foo" Oct 17 15:53:18 Do I need to 'register' the 'foo' typename elsewhere? Oct 17 15:53:51 somewhere? Oct 17 15:54:39 you need to actually inherit foo-image Oct 17 15:54:51 just putting it in the folder doesn't do anything Oct 17 15:55:59 do you mean in my foo-image.bb file? Oct 17 15:57:01 Ahh... it work Oct 17 15:57:07 many thanks Oct 17 15:57:57 best to inherit it at a distro level so any image can use it Oct 17 16:03:41 rburton: Do you men via INHERIT += 'foo-image' inside of a *.conf file? Oct 17 16:04:07 kuzulis: presumably you have your own distro, as poky is an example. put it in that Oct 17 16:04:13 it being INHERIT, yes Oct 17 16:06:58 Now I got: Variable do_image contains tabs, please remove these Oct 17 16:07:07 but I don't see any tabs Oct 17 16:07:16 I use only spaces Oct 17 16:10:58 Maybe I need in: IMAGE_CLASSES += "foo-image" ? Oct 17 16:11:47 instead of inherit? Oct 17 16:17:40 What does this means: "Variable do_image contains tabs, please remove these " ? Oct 17 16:19:17 My foo-image.bbclass is simple: inherit image_types and IMAGE_CMD_foo () {} Oct 17 16:19:33 But I got an errors, related to tabs Oct 17 16:45:12 use bitbake -e yourimage to examine the actual final do_image task Oct 17 16:50:35 RP: just sent a patch to add PACKAGE_EXCLUDE to opkg backend. it replaces the previous warning patch. Oct 17 17:15:49 rburton: great, thanks Oct 17 17:16:02 kergoth: this remove change is proving to be a right pain to get working correctly :( Oct 17 17:50:08 Im writing a recipe for a shared library (libfoo) and a recipe to use that shared library (junk). My junk recipe give me a QA issue of "requres libfoo.so.0, but no providers found in RDEPENDS_junk". How might i fix this? Oct 17 18:00:50 it looks like it is examining /bin/junk, determining it needs libfoo.so.0, and complaining that it's not in rdepends. how might i fix this? Oct 17 18:02:04 add libfoo to the recipe DEPENDS to begin with. beyond that, it'll get added to RDEPENDS automatically if you link against it normally. if you dlopen it, you'll need to explicitly add libfoo to RDEPENDS_junk in the junk recipe Oct 17 18:03:30 i'm linking normally. I add libfoo to DEPENDS, I still get the QA issue Oct 17 18:04:03 the do_pcakage task examines all elf binaries and maps them to the recipes that provide them and adds them to rdepends for you Oct 17 18:04:29 so either it wasn't able to pick up that libfoo provides it, or wasnt able to pick up that junk needs it Oct 17 18:04:49 you can examine the shlibs directory in tmp Oct 17 18:04:58 or actually i think thats under sysroots now Oct 17 18:05:13 but that's how it maps elf shared libarries to the packages that provide them Oct 17 18:07:20 sysroots/blabla/pkgdata/runtime-rprovides/libfoo ? Oct 17 18:18:29 i think i found my problem. I didn't provide a libfoo.spec file in my libfoo recipe (I used pkgconfig in that recipe) Oct 17 18:19:01 bitbake doesn't care about .spec files, it's not used for shlibs at all Oct 17 18:20:09 uglyoldbob: quite possible that the library is built weirdly and doesn't conform to expected behaviour Oct 17 18:20:21 presumably you can't share the source? Oct 17 18:21:46 rburton: correct. it is built with autotools and generates pkgconfig data as well Oct 17 18:22:12 using libtool to build the library? Oct 17 18:22:53 yes. lib_LTLIBRARIES = libfoo.la Oct 17 18:23:13 weird :) Oct 17 18:23:48 if you read the log.do_package for both you'll see what it scans as the library provides, and then the library depends Oct 17 18:24:19 adding a libfoo.spec file in my libfoo source made the QA warnings in junk (user of libfoo) go away Oct 17 18:28:34 wait nevermind, i did a bitbake -c cleanall libfoo, and that apparently resolved my problem Oct 17 18:29:01 so just needed a rebuild Oct 17 18:29:07 weird, but works now i guess :) **** ENDING LOGGING AT Thu Oct 18 03:00:00 2018