**** BEGIN LOGGING AT Fri Sep 13 02:59:57 2019 Sep 13 04:20:59 khem, thanks for the answer Sep 13 04:21:32 @khem, no other way? and also, can I keep the same machine name? Sep 13 04:59:43 gondor: usually machines might allow you to override some MACHINE_FEATURES but its best to have your own machine config Sep 13 05:00:25 and can't really keep the same machine name, can I? Sep 13 05:09:13 no it will be new name Sep 13 05:09:28 or you can make changes to BSP layer Sep 13 05:10:58 ok, thanks khem Sep 13 07:25:08 For the ones attending Yocto dev days, do you have any more information on track 1 vs track 2? Sep 13 07:31:40 qschulz: concerning friday? Sep 13 07:31:52 letothe2nd: yup! Sep 13 07:35:26 qschulz: Crofton|work certainly can tell in more detail, but i guess he's not around yet. afaics, track 1 - hackathon is like "feel the spirit, do awesome things". with a lot of like-mindeds around you so you can easily exchange, discuss code, all that. track 2 - oedem is certainly more political and group discussion. to get an idea, you might read the MoM of the last comparable day: ... Sep 13 07:35:32 ... https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk Sep 13 07:44:20 letothe2nd: ok great. I don't feel like I'm a beginner in yocto but I'm definitely way too far in terms of knowledge from being able to participate in a proper maintainer "summit" for the whole yocto project, hence my confusion on what I should attend. Sep 13 07:46:48 qschulz: it depends a bit on what you expect. if you want to talk about rather down-to-earth topics, code show-and-tell, face-to-face discussion, then i think its track 1. oedem is usually a large, moderated group discussion with no code involved. it can give you a very good overview on the political state of the project and the general direction things are going. Sep 13 07:47:00 letothe2nd: do you know if knowledgeable people will be around in track 1? Because I'm pretty sure I'll have very weird and quirky questions to ask :D Anyway, worst case scneraio, I can try to help people in track 1 with my limited knowledge, my questions are now just to satisfy my curiosity :) Sep 13 07:47:16 letothe2nd: ok, straight to track 1 then! Sep 13 07:47:36 (not that I'm not interested in track 2, just too early in my Yocto dev life :) ) Sep 13 07:48:27 qschulz: i am pretty certain that there will be knowledgeable people in track 1, and if none show up by themselves we will make sure some folks are around. Sep 13 07:49:14 letothe2nd: thanks for the help :) Sep 13 07:49:18 YW Sep 13 07:53:03 qschulz: I've heard a lot of people worried and confused about that. Sep 13 07:53:08 Crofton|work: ^ Sep 13 07:53:25 mckoan: well we actually expected it too! Sep 13 07:53:57 hence the explanation approach. mind if Crofton|work sayssomething that contradicts me, then he is always right :) Sep 13 07:56:26 mckoan: I think the confusion is that I don't really want a tutorial on how to use Yocto or training... I'm pretty confident I know enough from the small things which are generic enough to be in a training (enough in that I know where to look in the docs and where to ask on IRC :p). Workshop can mean a training/tutorial for me... I don't really want that :) Sep 13 07:57:24 but at the same time, I don't want to lose my time sleeping a maintainer summit where I can't participate because I don't understand 90% of the things said (well... ok, it has nothing to do with Yocto dev days, it happens to me for every conference I attended so far :p) Sep 13 07:57:41 (the worry of being in the wrong room) Sep 13 07:58:12 just do like me. sleep and have a drink. pretend you totally know stuff Sep 13 08:00:50 letothe2nd: ah the impostor syndrom... Sep 13 08:01:29 its only a syndrom if you *believe* that you don't have a clue ;P Sep 13 08:02:33 letothe2nd: true, then I think the drink is here to help forget you have no clue about what you're saying. I'll drink to that Sep 13 08:03:25 thats the spirit! Sep 13 09:14:12 New news from stackoverflow: Node.js error "invalid opcode ip" on Yocto(rocko) Sep 13 09:44:17 New news from stackoverflow: meta-java error while building yocto image Sep 13 10:14:48 "Day 2 of the event will consist of two tracks; a Workshop-Hackathon track, and a Maintainers Meeting track, and we need you to select which one you plan to attend. " Sep 13 10:14:51 BOTH! Sep 13 10:15:05 it's a tough call :-/ Sep 13 10:15:27 kanavin_: send your physical body to one, and your spirit to the other. Sep 13 10:15:50 and swap at lunch Sep 13 10:17:29 letothe2nd, I chose the OE maintainers track, if it's boring I can probably peek into the hackathon :) Sep 13 10:19:52 kanavin_: i'm at oedem too, because it fits my role way better. but of course we should have a couple of knowledgeable folks at the hackathon.... so i guess if everybody want to go for boring discussions, we might have to send a technically representative delegation Sep 13 10:28:36 Hello, I added my own systemd service with a my-service.bb to yocto, but my service does not start after booting. Sep 13 10:29:12 The .service and .sh file are located at the right directory but the service does not seem to be enabled Sep 13 10:29:52 It seems to me something like systemctl enable my-service is missing Sep 13 10:30:09 How do I do that in my .bb file? Sep 13 10:32:49 The .service is properly installed to /lib/systemd/system and also the my-service.sh is properly installed. Just the activation of the service needs to be done, so it seems to me. Sep 13 10:42:49 fbre: do you have something like SYSTEMD_SERVICE_${PN} += myservice.serivce in your recipe ? Sep 13 10:43:09 (you also need to inherit systemd) Sep 13 10:53:06 fbre: you almost certainly failed to inherit systemd Sep 13 10:53:06 fbre: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-systemd Sep 13 11:01:38 fbre: my intention is not to say RTFM, there are different pieces that could be missing in your puzzle and in the link everything is explained. If that does not fix it then something else's wrong and we can help :) Sep 13 11:04:44 yeah, there is SYSTEMD_SERVICE_${PN} = " my-service.service" in the .bb file, and also this one: inherit system.d Sep 13 11:05:02 uhm I mean: inherit systemd Sep 13 11:05:32 Thanks for the link, I will study it! Sep 13 11:06:36 Chaser: is it important to use "+=" instead of "="? Sep 13 11:14:30 New news from stackoverflow: Why does my lcd console turn off if I let the imx6 board stay idle for 10 minutes? Sep 13 11:23:22 kanavin_: cpio: ./icons/Adwaita/32x32/legacy/_inst.34160_: Cannot stat: No such file or directory Sep 13 11:23:42 kanavin_: was that the race that WR were seeing in adwaita that you suspected might be caused by your optimisatin? Sep 13 11:23:53 yes Sep 13 11:23:59 ab just did it Sep 13 11:28:02 your patch *looks* right Sep 13 11:29:24 rburton, yes. It ensures that all child processes are collected. Sep 13 11:30:13 ah, no Sep 13 11:30:18 make doesn't work like that Sep 13 11:30:34 you're missing another \ Sep 13 11:30:44 each *line* is a new shell Sep 13 11:31:13 right easy to fix Sep 13 11:31:26 goddamnit make Sep 13 11:32:44 kanavin_: minimal test: a makefile foo: sleep 5 &\nwait will complete straight away with the disowned Sep 13 11:32:56 with the sleep disowned Sep 13 11:33:05 shall fix Sep 13 11:33:22 wish vscode had a diff mode which let you interactively edit diffs Sep 13 11:34:04 rburton: greg k-h mode :P Sep 13 11:34:17 rburton, unless .ONESHELL is defined Sep 13 11:34:32 kroon: presumably that'sa gnu makeism? Sep 13 11:35:04 rburton, yeah, I'd guess so Sep 13 11:35:09 wish automake would notice gnu make and spit that out Sep 13 11:35:17 useful didnt know of that thanks Sep 13 11:40:09 rburton, oh that's a good catch, but make wtf. Also can adwaita move to meson already please. Sep 13 11:40:17 yes please Sep 13 11:40:32 trying to verify the hypothesis in the real world Sep 13 11:40:47 i guess nobody wants to migrate to meson because its likely going to be a pain :) Sep 13 11:41:21 rburton, yeah, as they currently have those shell fragments with a for loop in them Sep 13 11:42:01 if meson would preserve them as separate scripts, then there's no win really Sep 13 11:45:08 rburton, do you know of a "fast" way to extract the finalized bitbake environment variable values, like TMPDIR, without running "bitbake -e | grep ..." ? values from previous bitbake runs would be fine, disregarding any changes in files Sep 13 11:46:37 kroon: bb var is slightly faster Sep 13 11:46:53 https://github.com/rossburton/bb/blob/master/libexec/bb-var Sep 13 11:47:07 time bb var TMPDIR Sep 13 11:47:08 NOTE: Starting bitbake server... Sep 13 11:47:09 real 0m0.918s Sep 13 11:47:28 as it doesn't parse any recipes, just the config Sep 13 11:47:41 for *fast* use a persistant bitbake Sep 13 11:47:53 YMMV, not quite stable enough to be enabled by default Sep 13 11:48:07 Is an underscore a problem in the filename of the system service? Can the .bb file-handling stand that? Sep 13 11:48:09 rburton, ah, nice Sep 13 11:48:52 fbre: in pkgdata/.../runtime/[package] you'll be able to read the postinst generated, check that it is calling the sysctemctl properly Sep 13 11:50:47 kanavin_: phew, replicated the failure Sep 13 11:51:14 kanavin_: its all the encode-svg calls, they take time so make install quits but there's still 10+ encode tasks running Sep 13 11:52:16 rburton, right, but this actually generating a build error seems even more rare than the mythical glibc-locale thing Sep 13 11:52:24 yeah Sep 13 11:52:41 you need to hit the race between those still writing files and strip running over the same files Sep 13 11:52:58 like the pre-RSS rare race of trying to execute a binary that's still being written Sep 13 11:54:54 and the svg bits run early, so if i do make install of the entire tree they're always finished in time Sep 13 11:55:08 its only if i install a subfolder they outlive the makefile Sep 13 12:08:46 #I just updated my meta-layers per my modulle vendors recommendation (they hav Sep 13 12:08:56 argh... ignore that. Sep 13 12:10:02 I have a weird issue. After updating my meta-layers I now get this error when trying to bitbake an image: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid type name or missing support class Sep 13 12:11:05 There is however a IMAGE_CMD_sdcard defined in a .bbclass file in a layer which is in my bblayers.conf file Sep 13 12:11:38 did you inherit the class Sep 13 12:11:44 #Seems like bitbake cannot find it somehow? Sep 13 12:11:59 just because a class is on disk doesn't mean it gets used, unless you inherit it Sep 13 12:12:18 Hmm I have not checked, it's not any of my recipes, but I will have a peek at it right away. Sep 13 12:12:39 usual practise is to add it to IMAGE_CLASSES Sep 13 12:14:42 New news from stackoverflow: How to enable root logical volume in systemd-boot Sep 13 12:17:34 Seems like IMAGE_CLASSES has "image_types_fsl" appended to it, and that .bbclass has the IMAGE_CMD_sdcard functionin it. Sep 13 12:49:34 sometimes I change image options and it seems like it rebuilds more than I expect. Order does not matter in local.conf, yes? Sep 13 12:51:47 I can't really find an image viewer inside meta-openembedded since feh was dropped (aside from imagemagick, but that one is pretty heavy just to get that basic a viewer), did I miss something ? Sep 13 13:00:16 It seems like I have two classes called "image_types fsl" in different meta-layers, and only one of them has the IMAGE_CMD_sdcard function. Could it be that bitbake picks the "wrong" one? Can I tell bitbake which one I want? Sep 13 13:03:01 According to the mega-manual: "Also, the layer priority does not currently affect the precedence order of .conf or .bbclass files. Future versions of BitBake might address this." Sep 13 13:10:36 I could solve the issue by changing my bblayer.conf file, changing += to =+ for the layer that had the "correct" version of image_types_fsl. Sep 13 13:18:30 rburton: yes, pkgdata/.../runtime/[package] contains several scripts and one of them is called like my service, and when I look into the file I can see the call to systemctl enable my-service.service Sep 13 13:21:40 rburton: the if-condition for it is: if type systemctl >/dev/null 2>/dev/null; then What does it mean? Sep 13 13:23:08 Anyway I can't figure out why systemctl enable is obviously not called. Sep 13 13:50:07 WhyTF does yocto not create that symlink /etc/systemd/system/multi-user.target.wants/my-service.service to /lib/systemd/system/my-service.service ??? I'm nearly about to jump out my window :-D Sep 13 13:51:05 Maybe I should hack it in my .bb file under do_install() Sep 13 14:27:17 fbre: if it's being enabled with systemctl enable, I believe the link will be made down in /lib/systemd/system/multi-user.target.wants, and not in /etc/systemd/system Sep 13 14:41:35 smurray: thanx! How do I command to set a symlink in the .bb file? Sep 13 14:42:01 I just know install -d and install -m 0644 Sep 13 14:43:29 and when I try install -m 0644 it grumbles about multi-use.target.wants which "is not shipped" so the error message of bitbake says Sep 13 14:43:39 and when I try install -m 0644 it grumbles about multi-user.target.wants which "is not shipped" so the error message of bitbake says Sep 13 14:44:11 fbre: are you using the systemd bbclass? if so, it should be happening if you set SYSTEMD_SERVICE and have not set SYSTEMD_AUTO_ENABLE to "disable" Sep 13 14:46:03 thanks, I'll dig into this on Monday. See you all and thanks for your appreciated help! Sep 13 17:00:20 18 Sep 13 17:02:42 I found a case where yocto will have different result based on the order of a python dictionary Sep 13 17:02:54 wondering if anyone knows it's been fixed Sep 13 17:03:15 I'm on the thud branch Sep 13 17:03:59 The source of the issue is in package.bbclass, if you look at the code around the place where you see "match = p" Sep 13 17:04:25 The dependencies will change depending on the first shlib_provider in the dictionary, but the dictionary key order changes between runs Sep 13 17:07:29 this occurs when you have multiple shlib_providers for the same file Sep 13 17:11:30 based on the latest poky code looks like it hasn't been fixed Sep 13 17:16:47 marler8997: are we supposed to have 2+ shlib_providers for the same file? Sep 13 17:28:39 probably not Sep 13 17:29:01 but the problem is, if there is multiple shlib_providers, yocto won't detect any error and you'll end up getting a build that will change everytime you run it Sep 13 17:29:57 in my case, I have an so file that appears in both a runtime package and a -dbg package Sep 13 17:30:18 on some runs, it will take the dependency from the runtime package and other times it will take it from the -dbg package Sep 13 17:30:48 in the case where it takes it from the -dbg pacakge, I'll get an error much later in the build in do_package_qa from another recipe because it detects a runtime package depending on a -dbg package Sep 13 17:55:28 I see alot of ".so.#.#.#" files in *-dbg packages, but none of them have any shlib_providers...but in my recipe the -dbg package does have shlib providers...anyone have any idea why that could be? Sep 13 17:58:25 it should definitely be fixed, if possible, to at least be mroe deterministic, but a dbg package shouldn't include any shared libraries, only the split off debug info Sep 13 17:59:25 sorry if I sound naive on this...are you saying that the "*.so*" file I see in -dbg packages are not actually so files Sep 13 18:00:13 By the way I'm working on a fix here to detect this scenario: https://github.com/openembedded/openembedded-core/compare/master...marler8997:assertMultiShlibs Sep 13 18:00:16 that's right, yes Sep 13 18:00:25 they're not, which is whyt hehy're int he '.debug' folder Sep 13 18:01:00 gotcha, I'll have to read up on what these files actually are Sep 13 18:05:05 hmmm, I'm not immediately finding any info on what these files are...do you have any pointers on how I can read up on what these "*.so*" files in the .debug folders are? Sep 13 18:18:57 https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html Sep 13 18:46:02 Hah, success. The new hash equivalence server appears to be working, and is *much* faster! Sep 13 18:50:58 JPEW: woo Sep 13 18:51:00 what protocol etc? Sep 13 18:52:37 JSON over TCP for "slower" parts (eliminates the HTTP header overhead). There is also a "stream mode" when signature generation is looking up hashes which has even lower overhead. Sep 13 18:53:12 It also keeps the connection open instead of reopening it for each request Sep 13 19:00:35 nice Sep 13 19:14:01 kanavin_: your sdl bits fail on the ab https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/707/steps/8/logs/step2d Sep 13 20:44:49 who would I send this pull request to? Sep 13 20:44:54 https://github.com/openembedded/openembedded-core/compare/master...marler8997:assertMultiShlibs Sep 13 20:46:08 see the readme at https://github.com/openembedded/openembedded-core, which links to http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Sep 13 20:47:21 shoot, I'm behind a proxy and I've never submitted patches using send-mail before **** ENDING LOGGING AT Sat Sep 14 02:59:57 2019