**** BEGIN LOGGING AT Thu Sep 26 02:59:57 2019 Sep 26 07:14:34 JPEW: that does seem to have helped... Sep 26 08:05:02 New news from stackoverflow: YOCTO : How to add LIBSOC library to my Linux image Sep 26 08:17:00 jwessel: ping Sep 26 08:19:09 jwessel: I would like merge our patches but I don't have idea how to do it: I never did it before. Could you help me, please? Sep 26 08:35:07 New news from stackoverflow: How to run a shell script while compiling a recipe in Yocto || Node-red with Yocto Os Sep 26 08:53:30 alessioigor: apply both in your git tree, then "squash" them. I find "git rebase -i" helpful Sep 26 09:05:06 RP: Thanks for help. Could you suggest me how "squash" commit messages, please? How I should do with the two Signed-off-by? Sep 26 09:05:47 RP: rebase -i FTW Sep 26 09:13:38 alessioigor: edit the message so that it includes details for both commits and probably include both signoffs in this case (since I know which commits these are) Sep 26 09:13:50 alessioigor: you could just send both patches in series Sep 26 09:15:39 RP: I would prefer "squash" to avoid noise during a hypothetical bisect session. Sep 26 09:39:05 * alessioigor hopes to have done a good job squashing the two commits... Sep 26 09:40:28 alessioigor: fair enough Sep 26 09:40:38 RP: Thanks Sep 26 09:48:21 In our production boards, we want a root filesystem that we keep as small as possible, but a large data partition. I would prefer not to include this data partition in the .wic-image, as it does not make sense to write 15GB of nothing in production. Would it be sensible to instead have a script that runs at startup, which checks if the partition is there, and if not, creates and formats it on the fly? Sep 26 09:48:38 Is there any kind of support for this in Yocto/POky? Sep 26 09:49:58 Strange, I managed to have two simultaneus connections to freenode. No wonder my nickname was "busy". Sep 26 09:50:10 iceaway: that would just be a neatly written systemd unit Sep 26 09:50:38 probably with something like Before=mount.service or such Sep 26 09:51:24 LetoThe2nd: Sounds reasonable. Not using systemd at the moment though, but I guess a regular init script would work as well? Sep 26 09:51:25 or WantedBy=local-fs.target Sep 26 09:52:02 iceaway: whatever, it'd just advise to make sure it really runs and is checked before the usual mount mechanisms kick in Sep 26 09:52:19 LetoThe2nd: Yes will check that! Sep 26 09:52:22 THanks! Sep 26 10:05:21 New news from stackoverflow: yocto jetson nano image with nvidia sdk binaries: Unable to find file cuda-repo-ubuntu1604-10-0-local-10.0.326-410.108_1.0-1_amd64.deb || How to conditionally install and ship files in yocto bb recipe? New news from stackoverflow: Unable to stream RTSP from VLC on Yocto-based distribution Sep 26 11:35:35 New news from stackoverflow: How to fix error 501 while using yocto build tool? Sep 26 11:44:41 A very basic question for which I could not find a direct answer by googling. I'm trying to add cmake to my image. I've added "inherit cmake" to the app recipe, and "IMAGE_INSTALL_append = " cmake cmake-native"" to /build/conf/local.conf. When baking the image I'm getting an error: "console-image.bb rdepends upon non-existent task Sep 26 11:44:42 do_package_write_ipk in poky-thud/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb". If I remove the IMAGE_INSTALL_append directive, bitbake claims "cmake: command not found". Any advice would be appreciated =) Sep 26 11:47:10 vlo86: you are mixing up things. IMAGE_INSTALL += "cmake" adds cmake to the image. inherit cmake in a recipe says that this recipe need cmake for its build and install process. and thrid, adding cmake-native to IMAGE_INSTALL is outright wrong. Sep 26 11:48:25 So stating IMAGE_INSTALL_append = " cmake" should be enough in my local.conf? Sep 26 11:49:21 vlo86: to get cmake on the target, yes. not that cmake by itself is of much use on the target, and generally compiling in-target is ... meh.. but yes. Sep 26 11:51:10 Right, I guess my first problem was the "cmake: command not found" during bitbaking/cross-compiling my library. So I ended up trying to add cmake to my image to see whether that helps. Sep 26 11:51:41 vlo86: outright wrong that sounds, young padawan Sep 26 11:51:59 Learning all the time =) Sep 26 11:53:21 Whats the proper way to update an eSDK installation? Should I just rm the previous installation directory, and installing the new one? Sep 26 11:55:49 thomasd13 install the new SDK in the same path Sep 26 11:56:28 PinkSnake without removing the previous one before? Sep 26 11:56:48 thomasd13 The script will ask you if you want to :) Sep 26 11:57:01 just make a try ;) Sep 26 11:57:17 Cool ;) thank you Sep 26 12:06:22 Is there any sort of guide on adding a boring makefile shared library recipe? I've gone through the documentation and have my shared library building with -Wl,-soname= and that all seems to work. My library is libname.so.1.0 and do_compile creates a symlink from that to libname.so. During package qa, though, somehow the -dev package has libname.so as the shared library and not the symlink, causing the build to fail. Sep 26 12:06:50 I'm not trying to do rocket surgery here, it's a really simple makefile Sep 26 12:07:40 fullstop: simple makefiles are often rocket science, because they often break crosscompiling in awful ways Sep 26 12:08:10 LetoThe2nd: These particular makefiles, oddly enough, have _only_ been used to cross compile. Sep 26 12:08:14 fullstop: i'd say, look at the "adding a new recipe" section in the dev or ref manuel (can't remember which one), there is a makefile recipe example Sep 26 12:08:39 It's not building it for the wrong arch.. I'm just not understanding what yocto wants. Sep 26 12:08:56 fullstop: hence, look at the example :) Sep 26 12:09:27 If I remember correctly that example is for a binary and not a library, but I'll check again. Sep 26 12:11:51 Hi, i have a question regarding yocto 2.7 (Warrior). Sep 26 12:12:04 The mega-manual states under 24.9.11 "ADT Removed: The Yocto Project Eclipse IDE Plug-in is still supported and is not affected by this change." Sep 26 12:12:09 However under 24.15.2 it states: "Eclipse™ Support Removed". Sep 26 12:12:16 Which one is correct, or am i missinterpreting these statements? Sep 26 12:12:27 fullstop, I'd assume its the do_install that should create the symlink, no ? Sep 26 12:12:46 coretec I tried to work with Eclipse ADT - Got no success Sep 26 12:12:58 kroon: yes, it does, although I believe that it could happen at the end of do_compile as well. Sep 26 12:13:00 coretec: if in doubt, consider anything eclipse related as unsupported and nonfunctional Sep 26 12:13:43 coretec: there are reports now and then of people making it work, but do not *expect* it. officially, it has been deprecated. Sep 26 12:13:46 LetoThe2nd why is this the case ? I find this a very handy feature for some of my users. Sep 26 12:13:52 coretec: insert coin Sep 26 12:14:31 coretec: there have been many attempts to find somebody who actually maintains and supports it over the years, and all failed. hence, the emergency brake has been pulled. Sep 26 12:15:06 coretec which advantages does the ADT-plugin offer? Sep 26 12:15:16 This is probably important, and it's something that I don't understand: WARNING: libblock-1.0-r0 do_package: libname-dev-1.0 was registered as shlib provider for libname.so.1.0, changing it to libname-1.0 because it was built later Sep 26 12:15:22 @Leto Sep 26 12:15:37 LetoThe2nd: Thank you for the clarification Sep 26 12:15:44 coretec: yw. Sep 26 12:15:44 cat's out of the bag, package is actually called libblock, I was trying to keep that anonymous for some reason. Sep 26 12:17:45 thomasd13: Well my application developers seem to be unable to work without eclipse or any other full feature IDE :) Sep 26 12:18:29 coretec: then either hire sombody to make things work for them, or invest in training them to use other tools :) Sep 26 12:20:07 coretec I setup Eclipse in such a way that it works with eSDK together. For on target debugging, I wrote a script which deploys the executable on the target and start a gdbserver Sep 26 12:20:11 LetoThe2nd: Well yeah, guess i have to Sep 26 12:20:33 I don't know if this is enough or ADT offered more Sep 26 12:21:11 thomasd13: what do you mean by eSDK ? Sep 26 12:21:36 extensible sdk Sep 26 12:21:37 thomasd13: and i think ADT is also deprecated, its only the SDK now right Sep 26 12:24:58 okay, I think that I see what is going on. How do I keep .so files out of the -dev package? How does the build system know which files to put in -dev? Sep 26 12:25:28 fullstop: usually by setting FILES_${PN}-dev and FILES_${PN} accordingly Sep 26 12:25:47 fullstop: yet i'd say this means that the install stage of that lib is b0rk3d Sep 26 12:26:12 Well, the install stage is done entirely in do_install() since there is no "install" target in the makefile Sep 26 12:26:28 so if it's borked I've borked it myself Sep 26 12:26:33 fullstop: FILES_${PN} has libdir/*.so.* and FILES_${PN}-dev has libdir/*.so IIRC Sep 26 12:27:13 qschulz: are -dev packages supposed to have shared libraries in them? Sep 26 12:27:53 I think the point is PN has the shared library and -dev has the symlink .so to .so.x.y.z Sep 26 12:28:28 and PN does not have a symlink? Sep 26 12:28:45 SOLIBS, SOLIBSDEV, FILES_SOLIBSDEV is what is handling this Sep 26 12:29:05 well it can, but it can't be named lib*.so and not in libdir Sep 26 12:29:20 by default Sep 26 12:29:26 so confusing Sep 26 12:29:55 you could technically have N different versions of the same library on the system Sep 26 12:30:14 if all of them installed lib*.so symlink, Yocto wouldn't know which one to take Sep 26 12:30:22 got it Sep 26 12:31:09 maybe. :-) Sep 26 12:32:28 I created the symlink during the do_install phase but did not install it to libdir.. this built and packaged without warning/error, but the -dev package has no symlink. Sep 26 12:40:18 fullstop: could you explain again your issue then :)? Sep 26 12:40:37 haha, give me a second.. let me see if my latest change actually worked or not. Sep 26 12:40:57 I'm on warrior if this makes a difference Sep 26 12:41:26 okay, failed again. One second. Sep 26 12:43:27 okay, here's the recipe (somewhat made anonymous): https://pastebin.com/raw/Ku3kGuZC Sep 26 12:43:37 the FILES_ lines are new Sep 26 12:44:31 The makefile builds lib/libblock.so.1.0 in S, with the soname set correctly in the elf headers Sep 26 12:45:03 And, in short, I just want this thing to build so that I can use this library with other recipes. Sep 26 12:47:13 when I set FILES_${PN}-dev to include lib*.so the symlink is .. ignored? It ends up being the actual library and not a symlink. Sep 26 12:48:03 i just want a dollar for each time i hear "i jsut want ..." in here :) Sep 26 12:48:25 I'm coming from buildroot, so the GIT_VERSION thing isn't right just yet, it will eventually pop the git hash into the source. Sep 26 12:48:43 LetoThe2nd: everything is always supposed to be simple in people's mind :) (at least always in mine, and then it's not simple at all :D) Sep 26 12:48:57 LetoThe2nd: :-) Sep 26 12:49:09 I understand that it's not simple, but I also don't want it to be magic. Sep 26 12:49:22 fullstop: as usual bitbake -e is your friend Sep 26 12:49:33 fullstop: i guess things jsut are not what you think in reality Sep 26 12:49:59 Isn't that how learning works? Sep 26 12:50:05 fullstop: SOEXT=".so" is that expected? Sep 26 12:50:28 qschulz: let me see if that is still used. Sep 26 12:50:41 what I expect is that this line creates a libblock.so AND a libblock.so.x.y with SONAME= Sep 26 12:50:50 then, ln -s ${PN}.so.${PV} lib/${PN}.so is a noop Sep 26 12:50:55 It's not used by my makefile Sep 26 12:51:03 RP: Perhaps report_unihash should raise bb.fatal if the tid is not in self.setscenetasks? Sep 26 12:51:08 back up a sec.. Sep 26 12:51:40 oe_runmake should create libblock.so (symlink) and libbloxk.so.x.y, yes? Sep 26 12:52:01 does your Makefile create those? Sep 26 12:52:15 no. It creates libblock.so.x.y Sep 26 12:52:24 and I took care of the symlink in do_install Sep 26 12:52:38 but I can easily have the makefile create the symlink if that actually makes a difference. Sep 26 12:52:40 well, apparently not since it's not a symlink :D Sep 26 12:52:53 It is a symlink, though. Sep 26 12:53:14 15 Sep 26 08:41 libblock.so -> libblock.so.1.0 Sep 26 12:53:34 it's only when it's added to the -dev package when it is suddenly not. Sep 26 12:53:34 ah fuck Sep 26 12:53:44 what does install do on a symlink? Sep 26 12:53:51 seriously Sep 26 12:53:52 does it copy the symlink or the reference? Sep 26 12:54:12 let me do it manually and see Sep 26 12:54:43 the reference Sep 26 12:54:52 so I need to cp instead of install? Sep 26 12:55:48 not necessarily Sep 26 12:56:05 you can use ln to install the symlink directly in ${D} Sep 26 12:56:39 fyi, you might hit errors wrt to how symlinks are handled in Yocto. https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#migration-2.3-absolute-symlinks Sep 26 12:56:43 not everything will work Sep 26 12:58:15 from what I gather, ln -s ${PN}.so.${PV} ${D}{libdir}/${PN}.so should work Sep 26 12:58:42 (you don't need a '/' between ${D} and ${libdir} or ${includedir} btw :) Sep 26 12:59:19 https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf Sep 26 12:59:50 right, I had the absolute symlink error before, that's how I got this far. Sep 26 13:00:32 I have to say ${D}${libdir} doesn't look as nice as ${D}/${libdir} Sep 26 13:00:58 fullstop: matter of taste, I hate seeing paths in logs with two // :) Sep 26 13:01:14 :-) Sep 26 13:04:23 qschulz: LetoThe2nd: thanks for the help, it's behaving as expected now. Sep 26 13:04:30 thanks for putting up with me. :-) Sep 26 13:06:26 JPEW: just realised we have a problem with the way the mixin interacts with the OE-core class extension Sep 26 13:07:04 fullstop: ever considered using a proper build system instead of bare make? :) Sep 26 13:07:37 rburton: bah! I've used the same makefile for years now! Sep 26 13:08:05 well if its not a versioned library you don't need to install a symlink, its just that FILES* defaults to assuming versioned and symlinks Sep 26 13:08:12 as that's typical Sep 26 13:09:14 I understand now that I had two ways of getting past this. Three if you count changing from make. Sep 26 13:09:47 I have a love/hate relationship with cmake right now. Sep 26 13:10:12 easiest is to write a makefile that behaves like a typical library: install libfoo.so.1, libfoo.so symlink, etc. Sep 26 13:10:19 soname, version, etc. Sep 26 13:10:42 then if you do switch to a proper build system you can do it seamlessly, and everyone else who sees your library knows what to expect. Sep 26 13:11:15 if you want to keep it unversioned then https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries is useful Sep 26 13:12:05 thanks, rburton Sep 26 13:12:16 i endorse meson if you want to replace make ;) Sep 26 13:12:23 rburton: let me jump on the library train then :) Sep 26 13:13:30 JPEW: its a class inheritance order problem: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=d14ae9db270897bc8df7606b8c38277c7424caf3 Sep 26 13:13:59 rburton: we have recipe A with a binary which has NEEDED libasound.so but in recipe alsalib we have only libasound.so.x.y.z which is provided Sep 26 13:14:14 For me, this is the opposite as what's explained in the link you pasted, right? Sep 26 13:14:28 qschulz: that NEEDED is wrong Sep 26 13:14:34 how did that happen Sep 26 13:14:44 the linker will follow symlinks to get the full versioned name Sep 26 13:15:27 JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=709c6c1be4189853cea808b883ef1dd93700e96d is a bigger issue on how we handle this :/ Sep 26 13:15:46 JPEW: currently its writing out junk filenames, this fixes that but opens a new barrel of problems Sep 26 13:15:56 RP: oj? Sep 26 13:15:59 RP: oh? Sep 26 13:16:15 rburton: tell that to the ultra big corporation who sent us this binary, they do it for almost all their NEEDED :) Sep 26 13:16:28 they're idiots Sep 26 13:17:01 is it really? Sep 26 13:17:03 its a horrible way of avoiding version conflicts but assumes you'll have dev packages installed Sep 26 13:17:08 JPEW: should sigdata files show unihashes or task hashes? Sep 26 13:17:35 rburton: exactly, how is it handled normamlyl this kind of conflicts? Sep 26 13:17:57 closed source blob i presume? Sep 26 13:18:12 rburton: yes Sep 26 13:18:32 i'd start with 1) moan at vendor Sep 26 13:18:44 RP: Are you talking about the text dump of the hash contents? Unihash I would expect. Sep 26 13:18:44 i wonder if you can tweak the linkage Sep 26 13:19:06 What is the proper way for people providing binaries to avoid version conflicts? (I'm curious now :)) Sep 26 13:19:14 JPEW: right, but then the computed value and the actual hash don't match which is confusing Sep 26 13:20:00 qschulz: the binaries should have defined version needs. its not like libasound.so has been changing hugely over the years. Sep 26 13:20:09 RP: In the name of the file? Sep 26 13:20:29 JPEW: and/or its contents Sep 26 13:20:31 rburton: that would mean a binary per combination of NEEDED library versions right? Sep 26 13:20:50 qschulz: many libraries don't actually change their library version that much Sep 26 13:20:57 for this company, that is absolutely not scalable. Sep 26 13:22:22 zeddii: around? How long will we need to get that ppc fix in from stable? Sep 26 13:24:26 rburton: back to Yocto :) I could patchelf the thing in Yocto but it feels not right. Sep 26 13:25:23 rburton: I'm combing over the systemd.bbclass file regarding the nativesdk bug we've been discussing via email. I see a commit from khem last month that changed the way the do_install[postfuncs] to limit their use to target (not native) builds, but I'm not 100% on what the right fix would be to avoid effectively reverting what khem did Sep 26 13:26:21 tgamblin: run it for target and nativesdk? Sep 26 13:26:23 RP: The dependent task hashes in the sigdata are already unihash... I'd lean toward naming the sigdata with the unihash also. Perhaps there is a way we can make it easy to cross reference for users (symlinks or the like?) Sep 26 13:27:12 tgamblin: or reverse the logic: RMINITDIR_class-native = "" Sep 26 13:27:32 JPEW: we perhaps should write the unihash and the hash to the files Sep 26 13:28:56 rburton: the latter sounds cleaner. I'll have a look at that Sep 26 13:29:45 RP: Ya, that would work too.... those aren't ever actually hashed in their entirety correct (i.e. adding more things won't change the actual hashes)? Sep 26 13:30:41 JPEW: the data is pulled out so no, we're free to add data Sep 26 13:31:40 RP: I can work up a patch to do that if you want Sep 26 13:32:16 rburton: tgamblin I dont think extending it to anything besides target makes sense Sep 26 13:33:01 iirc, systemd isn't enabled in nativesdk distro features so that purge code would go and clean the files away, which is what we want Sep 26 13:33:03 are we shipping system services in nativesdk that should be run on sdk host ? Sep 26 13:33:33 there are recipes that ship service files that don't serve any purpose in a nativesdk Sep 26 13:33:45 and we can either 1) delete them in every recipe or 2) just make the class remove them Sep 26 13:34:36 JPEW: I think we need to look into that, the patches in -next show its fragile Sep 26 13:34:36 I see, ok I was thinking that we want to ship them which would be disaster Sep 26 13:34:56 JPEW: also can we please fix the module error when the hashserv connection fails? :) Sep 26 13:35:09 RP: Yes Sep 26 13:36:06 khem: my original patch was to have the dnf recipe remove them, but rburton pointed out that multiple recipes experience it, meaning a fix for the systemd.bbclass file instead Sep 26 13:36:19 rburton: so what we then do is enforce sysvinit for nativesdk always ? Sep 26 13:36:25 err, the dnf fix would add them, rather Sep 26 13:36:39 khem: there's no need for service files in nativesdk at all Sep 26 13:36:49 so i wouldn't be surprised if the init scripts are being deleted already Sep 26 13:37:54 JPEW: I did spot one other problem - the keys in unitaskhashes have the full paths in - which is why the eSDK ignores them Sep 26 13:38:36 rburton: yes thats what I thought but my only concern is that it starts accounting for hashes to rebuild nativesdk-llvm etc when DISTRO_FEATURE changes from sysvinit to systemd Sep 26 13:38:57 the distro features for nativesdk is tightly controlled Sep 26 13:39:13 DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr" Sep 26 13:39:13 DISTRO_FEATURES_NATIVESDK ?= "x11" Sep 26 13:39:40 so not sure how changing the features caused a rebuild of native code Sep 26 13:39:46 in that case I think add RMINITDIR_class-nativesdk = " rm_sysvinit_initddir rm_systemd_unitdir " Sep 26 13:40:22 JPEW: patch for that is ready for testing Sep 26 13:40:36 inverting the logic would enable it for cross classes as well so thats not good so lets be surgical Sep 26 13:41:30 Makes sense to me Sep 26 13:42:41 I'll test it then cc you guys on the patch Sep 26 13:47:12 thanks Sep 26 13:48:44 thanks for the clarification! Sep 26 13:52:22 tgamblin:I would like you to try a case where you replace systemd with sysvinit in DISTRO_FEATURES and see what all ends up rebuilding especially in nativesdk recipes Sep 26 13:52:42 typical case I have is nativesdk-clang Sep 26 13:52:54 maybe we shoud have a selftest for that Sep 26 13:53:06 does this cause it to rebuild Sep 26 13:53:08 toolchain shouldn't rebuild with distro feature changes Sep 26 13:53:39 it shouldn't but it did atleast the native case was causing clang-native to rebuild Sep 26 13:54:04 so now it would be prudent to check if this would now happen for nativesdk Sep 26 13:54:14 as well if we re-add the post funcs Sep 26 13:56:07 alright Sep 26 14:09:24 RP: I think I might set the hashserver timeout to 20 seconds by default for better user experience. Does that sounds OK? You might need to change it on the AB Sep 26 14:12:43 JPEW: yes, I'm ok with that Sep 26 15:11:14 hey, I've got a question - I need to add secondary (e.g. gid >= 1000) group "users" with bitbake, however after inheriting extrausers and adding GROUPADD_PARAM += "users" it creates group "users" with gid 100. Is there any way to explicitly tell extrausers to add group with some gid? Sep 26 15:12:02 you can specify int eh parameters to groupadd exactly what you want/need Sep 26 15:14:14 I believe you can do users -g 1000 Sep 26 15:14:40 thanks fray, checking it out right now - will report back :) Sep 26 15:15:55 i missed -g, and wrote "users 1000", probably that was it Sep 26 15:16:20 a few minutes for build and I'll get back Sep 26 15:24:28 why is ntp taking ages to compile and install? I gathered that it's doing a config.status --recheck in both tasks and it takes really an awfully big amount of time... why is this needed in the first place since it's done in configure? Sep 26 15:31:29 fray: unfortunately it didn't work - I'm on thud btw Sep 26 15:31:55 i've tried gid 1000 and 3000, no difference - cat /etc/group | grep users shows 100 :( Sep 26 15:33:56 however, when I run "groupadd users2 -g 3000" on the running system it works perfectly Sep 26 15:42:12 zeddii: around? Sep 26 15:42:45 qschulz: sounds like ntp is broken Sep 26 16:11:19 I'll receive a board with two type of CPU (a big Intel CPU and a little ARM cpu) soon. Is it possible to produce an image with both compilers? Sep 26 16:26:00 <__angelo> hi, i have a module built from yocto, in recipes-kernel/linux/mymodule.bb and would like to apply patch only for a certain version of kernel, is this possible ? Sep 26 16:31:41 __angelo, not easily. that's why out of tree modules can be problematic. best to just make the code check the version in the code and use the version #ifdefs Sep 26 16:37:10 but if you are inheriting (directly or indirectly) linux-kernel-base, it does have get_kernelversion_headers Sep 26 16:38:45 zeddii: got a second to talk about this ppc issue? Sep 26 16:39:20 i'm sitting in a conference room @ Linaro Connect, and will have to present a demo in a few minutes. but until they call on me, I'm here :D Sep 26 16:39:22 rburton: wdym? in general or on my local builds? Sep 26 16:40:19 RP is the ppc issue the fsl one that I saw bugzilla updates about ? Sep 26 16:40:24 zeddii: I see you replied in the bug Sep 26 16:40:32 zeddii: sorry, I'm behind now :) Sep 26 16:40:45 zeddii: that leaves the strace issue, did you get anywhere with that? Sep 26 16:41:21 not a solution, but I was interruped. I've talked to a few people about it here, so I have some ideas to try (I fly home tonight). Sep 26 16:42:01 zeddii: ok. These issues block M4 and M4 is next week which is why I'm asking questions Sep 26 16:42:32 I haven't been getting any optimistic feedback about a really quick solution, but I'll write something up ASAP. Sep 26 16:42:47 zeddii: thanks Sep 26 16:42:57 zeddii: meanwhile I'll get the stable updates tested Sep 26 16:43:30 is it correct that .bbappend files must be in the same directory as those .bb files that are appended Sep 26 16:43:38 litb: no Sep 26 16:43:48 i.e a recipes-extended/foo/foo.bb file can only be appended by a recipes-extended/foo/foo.bbappend ? Sep 26 16:43:54 somewhere I think I read that Sep 26 16:44:04 its wrong Sep 26 16:45:00 I wanted to do a appends/recipes-*/*/*.bbappend folder because I find it's clearer if one knows all appends are at a single place and not scattered around Sep 26 16:45:06 is this a good idea? Sep 26 16:45:18 RP: but since that issue is with the fsl board, we need to bump the SRCREVs for the reference boards, I didn't send that, but can .. I just can't boot them. Sep 26 16:45:23 but the patch is definitely in my tree. Sep 26 16:45:48 zeddii: if you could please, we should probably just bump and test they build... Sep 26 16:46:05 yup. my script can do it. So I'll do it and send it. Sep 26 16:46:17 the problem is that PAM's sshd and PAM's su file don't load the pam_limits.so . So I need a bbappend to modify those files before they get packaged Sep 26 16:46:19 zeddii: thanks Sep 26 16:47:55 litb, this is how I've done it in the past. Edited the components via a bbappend and make sure that bbappend only modifies if my custom distribution is enabled.. Sep 26 16:48:08 that conforms to the YP best practices and keeps things clearly as 'your' change Sep 26 16:48:26 I do wish we had a better way to handle those sort of configuration files, but I don't know of one at this point. Sep 26 16:53:04 fray, ah so far I'm not checking whether my distribution is enabled Sep 26 16:53:34 ya, so any user of your layer will get your change (unconditionally) which can cause issues and is not best practice.. Sep 26 16:53:45 What I usually do is something like.. (looking for an example) Sep 26 16:54:21 http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/tree/recipes-connectivity/openssh Sep 26 16:54:43 look at the openssh_8.%.bbappend .. it uses a system conditition to determine to active or not, which then pulls in nothing or openssl_fips.inc file Sep 26 16:54:50 in thi case, it's using just a variable.. Sep 26 16:55:04 but with your own distro, you could select on the distro name (part of the distro name) or a distro feature.. Sep 26 16:55:11 (or an override even) Sep 26 16:57:12 RP: sent. you'll see there are two patches. the fix we want is in with the v5.2.17, and I didn't want the reference boards ahead of qemu*, so I sent one to oe-core the other to yocto. but they are both 5.2.17 Sep 26 16:57:15 and have the fix Sep 26 17:00:22 fray, ah thanks Sep 26 17:00:30 I see that you put your override in a "normal" recipes-folder Sep 26 17:01:01 would you see it as bad idea to put all overrides below a "appends/" folder? (and put appends/ in BBFILES in the layer conf) Sep 26 17:01:39 that will work, but it makes it harder for somone new to come in and find the tiems.. if you use the same structure as the layer (recipes) you are appending, it's been easier to maintain in mye xperience.. Sep 26 17:01:44 I have seen cases where people do: Sep 26 17:01:57 recipes-.../recipe.bb and appends/recipe-.../recipe.bbappend Sep 26 17:02:19 so they've moved appends, but they keep the diretory structure.. but it's much more rare then the regular case Sep 26 17:02:37 ah I see. I'll stick with the regular rules then. Sep 26 17:02:57 * litb undoes his git mv .. Sep 26 17:03:04 there is another case BTW.. if you may be bbappending layers that are optional.. Sep 26 17:03:12 appending -to- layers.... Sep 26 17:03:18 you need to use a dynamic configuration for that Sep 26 17:03:43 https://github.com/WindRiver-OpenSourceLabs/wrlinux/tree/master-wr Sep 26 17:04:11 you can see the 'dynamic-layers' directory, under that is a directory per 'optional' layer.. and then regular structure under that Sep 26 17:04:25 https://github.com/WindRiver-OpenSourceLabs/wrlinux/blob/master-wr/conf/layer.conf Sep 26 17:04:32 that shows how to setuo the 'BBFILES_DYNAMIC' Sep 26 17:05:40 dynamic layers? head explodes. still need to look into that Sep 26 17:06:41 ya, in that (complex) example.. meta-gnome [gnome-layer] is optional.. but if it's there, the distro configures things in it Sep 26 17:07:02 nice! Sep 26 17:12:29 fray, this sentence in the manual appears to be broken: "Use the BBFILES_DYNAMIC variable to avoid .bbappend files whose corresponding .bb file is in a layer that attempts to modify other layers through .bbappend but does not want to introduce a hard dependency on those other layers." Sep 26 17:14:20 I think it should read "Use the BB_FILES_DYNAMIC variable to have a layer that attempts to modify other layers ... but does not want to introduce a hard dependency..." ? Sep 26 17:18:12 yes.. you should suggest that to the docs people Sep 26 17:19:32 litb: Send a patch please Sep 26 18:00:33 I've added samba to my build but I don't have winbind. Looking at samba_4.7.6.bb it looks like I should have a winbind.service and /sbin/winbindd etc. but nothing from FILES winbind seems to be present. Sep 26 18:00:35 http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb?h=sumo Sep 26 18:01:00 What am I missing/doing wrong? How do I make sure those get added to my image? Sep 26 18:11:31 emg: recipes can emit multiple binary packages. its up to you to install those packages in your imagew iwth IMAGE_INSTALL or equivalent. in this case, you'd need to install 'winbind', as that's what's in PACKAGES and referenced in FILES_ Sep 26 18:13:20 khem: I've been running into build failures trying to run that test on nativesdk-clang. I am seeing the failure in https://github.com/kraj/meta-clang/issues/162 on my local machine, even though I have the patch, but this may just be my build machine Sep 26 18:13:43 That being said, I tested with nativesdk-dnf with systemd and then sysvinit in DISTRO_FEATURES and did not see any rebuilds Sep 26 18:15:16 kergoth: when I add winbind to my RDEPENDS_${PN} = "... in my packagegroup... ^U I swear that I tried that and it didn't work and now here it's working. I'm beginning to doubt my sanity Sep 26 18:15:20 kergoth: thank you Sep 26 18:58:00 tgamblin:I thought I laid that monster to rest Sep 26 18:58:13 tgamblin:do you have multiple python installs on your machine Sep 26 18:58:27 it is a shortcomping in clang build I know Sep 26 18:58:52 khem: it could just be my build machine, not sure yet. I have python and python3 in /usr/bin Sep 26 19:04:55 Hm, wonder if anyone has looked into creating a script to automate merging a bbappend+filespath into the main recipe for upstream submissions Sep 26 19:06:00 I've thought about it, but couldn't figure out a way to do it in the cases where things were based on distro, machine or other flags.. Sep 26 19:11:21 khem: actually I have three versions installed Sep 26 19:26:04 Hmm, yeah, wouldn't be able to merge those. Need to brush up on the available functions in the recipetools and scriptools/utils modules Sep 26 19:46:22 nrossi: any idea on https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1078 (also happened as https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1076) Sep 26 19:47:56 JPEW: autobuilder hashequiv tests looked better again, just this selftest failure to fix now Sep 26 19:48:15 That one at least reproduces Sep 26 20:52:56 RP: what are these strace failures ? Sep 26 20:53:04 RP:are they new ? Sep 26 20:53:38 khem: 5.2 kernel Sep 26 20:54:02 I think the kernel API changes in 5.2 are biting us Sep 26 20:54:11 khem: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13556 and see the linked 13506 Sep 26 20:54:11 Bug 13556: normal, High, 2.8 M4, bruce.ashfield, NEW , [2.8 M3 RC1] strace failure in ptest Sep 26 20:54:14 changes to clock_t and time_t Sep 26 20:54:24 khem: its not that, its some specific freezer patches around ptrace Sep 26 20:56:14 RP: do you want to try https://github.com/strace/strace/releases/tag/v5.3 Sep 26 20:57:29 khem: if someone sends a patch, sure :) Sep 26 20:57:40 khem: I think we did test tip of git and it didn't help Sep 26 20:57:48 OK I can do that tell me how can I run the given self test alone Sep 26 20:57:53 oh Sep 26 20:58:06 khem: it should be in 13506 Sep 26 20:58:40 khem: the test would be to run qemux68-64-ptest on the branch with the upgarde Sep 26 20:58:54 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/81 Sep 26 20:59:22 khem: the tip of git was pre-release Sep 26 21:04:52 will need poky not oe-core right ? Sep 26 21:05:59 khem: right Sep 26 21:12:17 RP:preparing a patch and I will submit it via poky-contrib Sep 26 21:12:28 to AB Sep 26 21:12:34 on top of master-next lets see :) Sep 26 21:13:50 RP: one issue I am seeing is version-going-backwards when I switch from musl to glibc on some packagegroups, these packagesgroups have different packages being pulled based on which libc is in play Sep 26 21:14:21 RP: packagegroups are 'all' types but then we conditionalize them based on libc seems wrong to me Sep 26 21:15:41 khem: right, that is bad :( Sep 26 21:16:12 true allarch are very hard/rare Sep 26 21:19:38 JPEW: thanks for the patches :) Sep 26 21:20:19 RP: No problem. It was nice that they ended up being straight forward Sep 26 21:20:49 JPEW: yes, nice when that happens! Sep 26 21:21:01 I've probably angered some ancient god with that statement and untold wrath will befall me now :) Sep 26 21:21:06 JPEW: that selftest was simple when I finally understood what was wrong too Sep 26 21:21:36 RP: is there a way to address it ? Sep 26 21:21:43 JPEW: I think they've been angry with me for a month or two already ;-) Sep 26 21:22:06 JPEW: If you want insight into our next problem, the warnings on: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1087 :( Sep 26 21:22:11 some of oe AB I have musl world build and glibc world build share sstate and buildhistory Sep 26 21:22:28 JPEW: Ignore the nativesdk bit, its missing shadow which setscenes later Sep 26 21:22:53 khem: it won't hurt sstate its just saying you couldn't have a working shared package feed Sep 26 21:23:07 khem: making them non-all arch is probably the only solution Sep 26 21:23:26 RP: yeah which is logical I think Sep 26 21:24:34 my tweak/fixes in -next are a right mess. I think I have to sort them into sensible patches tomorrow... Sep 26 21:25:02 JPEW: current build is fun as its using hashequiv with larger code changes Sep 26 21:25:28 RP: Does it look like it's helping? Sep 26 21:26:08 JPEW: Its seems to be running quite quickly but hard to say :) Sep 26 21:26:35 JPEW: we need to enable reproducibile builds by default next to really start to make a difference Sep 26 21:27:11 RP: Ya, that would be awesome.... are there any images other than core-image-minimal and core-image-sato that the AB uses? Sep 26 21:27:47 JPEW: quite a few (full-cmdline, sato-sdk, -dev, weston and more) Sep 26 21:28:00 and world builds Sep 26 21:32:18 khem: FWIW we turned that test off on our buildhistory Sep 26 21:37:22 RP: you mean version-going-backward QA test ? Sep 26 21:37:26 khem: yes Sep 26 21:37:35 hmm maybe its a better option Sep 26 21:38:03 khem: its fine if you're maintaining a package feed but we're not and don't have the people to right now Sep 26 21:39:09 would you be open for patches to mark these packagegroups as non-all ? Sep 26 21:40:09 khem: how many are there? Sep 26 21:40:22 khem: I'm hoping its just one or two Sep 26 21:48:31 yes its os-release, packagegroup-core-tools-debug, packagegroup-core-standalone-sdk-target packagegroup-self-hosted Sep 26 21:49:02 that is more than I'd hoped :( Sep 26 21:50:00 khem: os-release doesn't look libc specific? Sep 26 21:51:21 khem: the others I don't mind changing after looking at them... Sep 26 22:14:58 RP: cool, os-release is also doing the switch back so maybe it has some dependency somehow ... I will hunt it down Sep 26 22:15:15 How is it going guys? I was wondering what is the best practice to modify a few drivers within recipes-kernel Sep 26 22:15:53 Specifically from meta-atmel. I can directly make changes, but I realize this is bad practice Sep 26 22:17:23 khem: it may be you've configured it to add a dependency? Is this with poky or nodistro or ??? Sep 26 22:41:10 RP: I know the problem is I define different DISTRO for musl Sep 26 22:41:25 and DISTRO is one of the elements in there for os-release Sep 26 22:41:26 khem: right, that would explain it Sep 26 22:41:43 that I think I need to address differently Sep 26 22:44:04 khem: reality is that you'd likely have different package feeds for glibc and musl so this may not be a problem for allarch Sep 26 22:44:31 * RP should sleep Sep 26 22:44:38 that is true though Sep 26 22:45:02 yes should I send a RESTful API cmd :) Sep 26 22:49:54 khem: :) **** ENDING LOGGING AT Fri Sep 27 02:59:57 2019