**** BEGIN LOGGING AT Tue Jan 07 02:59:58 2020 Jan 07 03:45:21 RP: This 4cb1b4b just caused a 0% match 0% complete on sstate :) Jan 07 07:22:26 Hello guys! I have some trouble with a basic opencv code ( https://pastebin.com/XqqVUGkq ) -> I'm probably not good enought because I don't understand where the problem is :( Jan 07 07:27:41 PinkSnake: undefined reference usually means that the linker can't find some library. so, check the dependencies, and their handling in the configure/make stages. Jan 07 07:29:08 LetoThe2nd i think you are right and it's linked to https://github.com/opencv/opencv/commit/094615b2c56f31e3a1a0d42799c802ebd7dca383#diff-40c9b23a9a22bcb03bc88589672a45ea Jan 07 08:00:13 good morning Jan 07 08:06:53 morning mckoan Jan 07 08:08:06 anybody know why 2020 irc logs are not available or when will they be? Jan 07 08:08:09 LetoThe2nd: Happy new year Jan 07 08:08:19 mckoan: hehe thanks. Jan 07 09:10:48 aehs29: yes, soon back to normal though :) Jan 07 09:25:48 RP: tell that to my CI setup haha Jan 07 09:26:43 RP: no actually it was good, I didnt know my plan B wasnt working so its good that Im aware of that now Jan 07 09:28:20 RP: btw, why is the AB not populating sstate.yp.org? Jan 07 09:31:43 aehs29: it should be... Jan 07 09:36:31 it says it was last update on 12-Dec-2019 17:35 Jan 07 09:36:47 updated* Jan 07 10:19:22 aehs29: hmm, I wonder if that is just misleading :/ Jan 07 11:03:29 RP: I'm currently running a build where basically everything has to be rebuilt due to recent changes to Poky. I have hashserv enabled. I just experienced a weird behaviour: it seemed that a lot (all?) do_prepare_recipe_sysroot tasks for the target recipes were running almost sequentially. Instead of the expected 16 parallel threads, it seemed to run one or occasionally two or three tasks at once. Once it started on do_configure for the r Jan 07 11:03:29 ecipes, it went back to normal. Jan 07 11:05:26 RP: I am wondering if it has to do with the almost constantly running "Checking sstate mirror object availability" task. Jan 07 11:29:12 Hi, usr/include/linux/videodev2.h does not contain VIDIOC_SUBDEV_... stuff. I thought the kernel should support it. See here: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-subdev-g-selection.html#c.VIDIOC_SUBDEV_G_SELECTION Does Yocto not support VIDIOC_SUBDEV functionality? Jan 07 11:30:08 falkb: tahts probably more like kernelversion/-configuration related than yocto specific Jan 07 11:30:37 because that sounds like one of the things that are there if the specific kernel in question supports it, and are not there if... Jan 07 11:30:42 I'm programming with yocto linux and suspected it's a missing feature there Jan 07 11:31:24 i don't think yocto "misses a feature" there, its rather the kernel you use. Jan 07 11:31:56 have you inspected /proc/config.gz to see if the v4l stuff is actually enabled? Jan 07 11:42:44 falkb: nah, you're just looking at the wrong header: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/v4l2-subdev.h Jan 07 11:57:46 LetoThe2nd: uh yeah, good hint about v4l2-subdev.h. Now I just need to find out how what the toplevel header is which includes that Jan 07 12:06:21 falkb: Remember that Yocto Linux does not cover every conceivable use case and some kernel options are disabled by default. Jan 07 12:06:42 Though that might not be the issue here :) Jan 07 12:06:55 Saur: we have performance problems in the task migration code Jan 07 12:07:11 Saur: it could be the sstate mirror checks if those are slow but the code itself is also slow Jan 07 12:16:00 Hi, i plan to use a parallel NAND memory. Is there a list which devices have good support? Jan 07 12:19:04 perdmann: kernel support applies :) Jan 07 12:22:10 is kernel and uboot support equal? Jan 07 12:22:19 nope Jan 07 12:22:26 i just found out that qspi nand's are "too new" :) Jan 07 12:22:52 #include does the job. Thanks Leto 2. Jan 07 12:23:06 perdmann: if in doubt, look at the eval kit of your desired SoC and just use whats there :) Jan 07 12:23:19 falkb: have fun. Jan 07 12:23:37 haha . Thats exactly what the NXP guy told me... Jan 07 12:24:11 perdmann: see, and i'm not even working for nxp. Jan 07 12:25:55 you should ask them for your salary ;) Anyway... really annoying to search for the "correct" memory Jan 07 12:27:14 perdmann: its just basically like this: "if you have to ask, then don't do any experiments"" Jan 07 12:32:36 perdmann: Which SoC do you use? Jan 07 12:33:15 imx6 Jan 07 12:33:19 *badum-tsh* Jan 07 12:34:43 as far as I know the problem with i.MX is you need to access the NAND flash via the controller of the SoC but there is no NXP linux driver for it at present Jan 07 12:35:09 for raw nand flasch you always have to use a controller AFAIK Jan 07 12:36:37 hm "package packagegroup-core-ssh-dropbear-1.0-r1.all requires dropbear, but none of the providers can be installed Jan 07 12:36:37 " Jan 07 12:36:55 IMAGE_FEATURES += "ssh-server-dropbear" Jan 07 12:37:12 I do this in my image recipe Jan 07 12:38:00 is it in conflict with packagegroup-core-boot ? Jan 07 12:38:11 Ad0: can you proide the full error message in a pastebin? Jan 07 12:38:22 ok LetoThe2nd Jan 07 12:38:54 @falkb65 imx6 Jan 07 12:39:16 Ad0: dropbear is usually completely unproblematic, so you are probably doing something "unconventional" Jan 07 12:39:30 @falkb65 parallel NAND "should" work. There is also a driver for that and it is an option for the eval board. Jan 07 12:39:35 falkb: *badum-tsh* Jan 07 12:40:53 LetoThe2nd, https://pastebin.com/xQrbGPtm Jan 07 12:40:59 hi guys. i am trying to build a minimal rootfs and mount if via NFS. to do so, i try to follow the course matierial of bootlin.com.. for some reason, my kernel complains: 'Unable to mount root fs via NFS' and 'Cannot open root device "nfs" or unknown-block(2,0): error -6' and don't know why Jan 07 12:41:22 i tried to verify the nfs server setup by mounting the share from my local machine, which works so far Jan 07 12:41:37 on the host machine i also see the attempts of the target to mount my nfs share, which get's granted like: 'authenticated mount request from ' Jan 07 12:42:01 but that occurs several times in a row, till the kernel stops trying Jan 07 12:42:08 any ideas what else to check? Jan 07 12:43:13 Ad0: what else is on the build besides that image? Jan 07 12:44:14 LetoThe2nd, you mean machine_features and so on ? Jan 07 12:44:31 Ad0: i mean like, what did you all add in order to break it? :) Jan 07 12:44:41 hehe Jan 07 12:44:52 I can post the image recipe Jan 07 12:44:56 Ad0: have you maybe removed poky/meta? Jan 07 12:45:06 no it's all there Jan 07 12:45:10 it works without exactly dropbear Jan 07 12:45:31 maybe I have included conflicting stuff that prevents it ? Jan 07 12:45:50 Ad0: openssh conflicts. Jan 07 12:46:29 I add those packages listed in the paste there , and I inherit core-image Jan 07 12:47:39 perdmann: Which parallel driver do you mean? Do you have a web page about that? Jan 07 12:48:01 Ad0: what happens if you build that image for a standard qemu? Jan 07 12:48:13 then what happens is that I have to wait forever :D Jan 07 12:48:34 ${CORE_IMAGE_BASE_INSTALL} networkmanager bluez5 i2c-tools python-smbus bridge-utils hostapd dhcp-server iptables iotedge-cli iotedge-daemon curl tpm2-tools swtpm ibmswtpm2 tpm2-abrmd openssl-bin my-custom-scripts Jan 07 12:48:49 that's the stuff I install in the image Jan 07 12:49:06 again, i don't think the image is the problem Jan 07 12:49:54 ok. my distro inherits from MENDER_FULL which is a bunch of stuff as well. Jan 07 12:50:05 err mender-full. Jan 07 12:51:00 I don't think it's that either, just a feeling :) Jan 07 12:51:15 swap poky in and find out :) Jan 07 12:51:20 would openssl-bin create a conflic? Jan 07 12:51:41 poky instead of what? Jan 07 12:51:51 instead of your distro Jan 07 12:51:57 right Jan 07 12:54:20 hm Jan 07 12:54:21 DISTRO 'poky' not found. Please set a valid DISTRO in your local.conf Jan 07 12:54:34 something is really broken in your bblayers.conf Jan 07 12:55:28 yes Jan 07 12:56:28 https://pastebin.com/Ujcyvxrk Jan 07 12:57:06 so for the distro case, meta-poky is missing Jan 07 12:57:18 yeah I didn't need that for my own distro right? Jan 07 12:57:22 right meta-poky isn't required unless you're using poky Jan 07 12:57:31 RP: Any hopes of improving the performance? Or you are still working on solving all the corner cases? Jan 07 12:58:11 Saur: There are local patches which help but also create new bugs Jan 07 12:58:25 RP: surely correct, but obviously the own distro as issues :) Jan 07 12:58:28 Saur: I spent most of my "vacation" trying to fix this stuff :( Jan 07 12:59:13 alright running again Jan 07 12:59:47 Saur: Its quite depressing as everyone wants these features but I struggle to get time to look at it and get little help on all the other distractions Jan 07 13:00:27 RP: Have you done any measurements comparing total build times with and without the hash server? My trouble here is that it feels slower when looking at the cooker running, but I have no hard figures. And making comparative builds requires setting up parallel build environments including sstate cache etc, and I haven't taken that step yet... Jan 07 13:01:02 Saur: Its like comparing apples and oranges. Enabling hashequiv adds new codepaths and they are slow Jan 07 13:01:53 Saur: you've no doubt seen JPEW and I trying really hard to speed up the server and playing all kinds of tricks to make it perform Jan 07 13:02:21 It is slower but the reasons are complex :( Jan 07 13:02:31 well, depends what reuse you get Jan 07 13:02:43 0: openssl-native-1.1.1b-r0 do_install - 21s (pid 7883) Jan 07 13:02:43 - why does it bother when I asked for dropbear Jan 07 13:02:54 oh sorry my mistake Jan 07 13:02:58 Ad0: ssl != ssh Jan 07 13:03:03 I thought it said "ssh" haha. Jan 07 13:03:13 native != target too Jan 07 13:03:15 that's what happens when you look too long on the same thing Jan 07 13:03:49 it seems to want to recompile everything Jan 07 13:03:50 RP: Sure, but are they expected to remain slow, or are they slow because they are first and foremost implemented to be correct? If they are expected to remain slow, is the expectation that they will result in less rebuilds and thus win in the end? Jan 07 13:04:11 there goes the rest of my day I guess! Jan 07 13:04:35 Saur: correctness needs to come first. I think some speedup is possible Jan 07 13:05:35 Ad0: time to make the case to management for decent build resources? ;-) Jan 07 13:05:46 yes Jan 07 13:05:50 I will order an SSD Jan 07 13:06:05 or get some time to work on performance? :) Jan 07 13:06:17 * RP feels lonely on that battle Jan 07 13:06:37 currently I run it inside a VM on my XPS15 and it expanded the battery physically, rendering the trackpad unusuable because of the heat caused by the intense building Jan 07 13:06:44 "lets add all these features" "but they make X slower" "but new features, we need features" Jan 07 13:07:04 Ad0: that is impressive :/ Jan 07 13:07:08 haha Jan 07 13:07:33 I tried to build on azure VM with "decent" specs like "premium SSD" enough RAM etc, but it ran just as slow Jan 07 13:07:57 Ad0: dedicated build hardware, old school without VMs and overhead ;-) Jan 07 13:08:01 RP: Wish I could help you more there, but I am still not fluent in the bitbake core... Jan 07 13:08:04 RP, amen :) Jan 07 13:08:55 Saur: best way to learn may be to pick a performance glitch and debug it and figure out how to improve Jan 07 13:10:40 RP: I guess the hashserver feature seemed simple at first "if we generate the same output from two different sstates, we can reuse the result from the first and not have to rebuild the following tasks". Then came all the tiny little details... Jan 07 13:18:10 RP: Related to performance, but not to the hash server changes: what is the expected gain from having the bitbake server remain after a build? Is there any? The reason I ask is I did some measurements with and without the bitbake server, and the differences were almost not measurable. And when I then disabled the inotify code (which I assume should not be needed when the bitbake server is not resident), the performance gain is huge in sta Jan 07 13:18:10 rting bitbake... Jan 07 13:22:20 Saur: the main things we hit in startup time were parsing the base config and loading the caches. Mem res bitbake shouldn't need to do those things Jan 07 13:22:38 Saur: at least in theory if the overhead is inotify, we don't need to do that again Jan 07 13:22:47 Saur: so it should be faster Jan 07 13:23:10 RP, what linux distro are you running :) Jan 07 13:23:18 or are you running something else perhaps? Jan 07 13:23:20 RP: But if the bitbake server isn't resident, is there any reason for the inotify code at all? Jan 07 13:23:36 (From a bitbake perspective.) Jan 07 13:23:41 Saur: hashequiv mainly runs into problems as the setscene taskgraph runs "top down" and the normal tasks "bottom up" which means its a nightmare to migrate and switch tasks between the queues Jan 07 13:24:00 Ad0: build server has ubuntu on it Jan 07 13:24:27 kk Jan 07 13:24:28 Saur: It was thought we'd switch to memres and do we want multiple different codepaths to maintain/test? Jan 07 13:25:28 Saur: history says multiple paths leads to problems Jan 07 13:36:55 RP: Here are the measurements I did: https://pastebin.com/uGLPp1Kj (the extreme parsing times resulting from removing tmp while the resident bitbake server is used have been reported here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13699). This is with Poky + OpenEmbedded + our own layers, so about 4100 recipes. Jan 07 13:36:56 Bug 13699: normal, Medium+, 3.2, richard.purdie, NEW , Prolonged recipe parsing times after removing tmp when the resident bitbake server is used Jan 07 13:37:53 (Oops, late for a meeting, back in half an hour.) Jan 07 13:38:24 Saur: definitely looks significant... Jan 07 13:42:13 RP: after about 10 hours of reading and debugging mips VDSO page allocation and mapping .. I came up with a workaround for 5.4+, I’m moving onto generating a full 5.4 reference kernel and libc-headers. Upstream still doesn’t beleive me that they broke something, and I can’t explain it yet .. but I’ve had to move on. Jan 07 13:43:02 zeddii: well done on finding a fix! Jan 07 13:43:13 zeddii: shame about upstream :( Jan 07 13:44:32 It’s frustrating (on both counts), since clearly they broke it. but yah, I can tell you (and put in the commit) *exactly* what it is .. but both inspecting and diffing from working kernels just isn’t showing me what it is .. it’s pretty arcane. And since VDSO is a linked library, bolted onto the kernel image, things like “printk” don’t work, neither does panic(), so I’m left with very few debug tools. Jan 07 13:45:13 I will come back to it again and write it up .. but I need to move on the recipes first. Jan 07 13:45:35 and rauc is also not working :) Jan 07 13:47:53 New news from stackoverflow: Yocto load kernel module Jan 07 14:24:44 RP: have you noticed any instances of reproducible builds failing, but the offending package appears to be a different version than what the layer index suggests? Jan 07 14:25:24 tgamblin: "layer index" ? Jan 07 14:25:55 RP: well, what the current version tied to a recipe should be, e.g. libical 3.0.6 Jan 07 14:26:24 tgamblin: "layer index" usually means layers.openembedded.org Jan 07 14:26:44 tgamblin: but the answer is no Jan 07 14:27:23 tgamblin: I was looking at your patches. We still have "UNKNOWN" being mapped incorrectly in selftest builds. Was there a patch I missed to fix the underlying class issues? Jan 07 14:27:30 tgamblin: I know there was one to work around it Jan 07 14:27:51 (that one is in -next) Jan 07 14:27:57 * RP forgets where we were at with these patches Jan 07 14:28:24 RP: Right. I'm digging into reproducibility for that coreutils patch I submitted a while ago, and I saw something odd related to libical, but it's possible I've just done something silly Jan 07 14:28:51 RP: No, no fix for the class issues yet, it's still on my to-do list. After I submitted the workaround I started looking at the logrotate issue and a few other things Jan 07 14:29:14 tgamblin: ok, just checking I didn't miss something. We seemed closer to a root cause Jan 07 14:30:42 RP: What we wanted to see with those measurements was if the time needed to setup inotify was worth it to be able to have a resident server, and based on them I'd say no. So the initial suggestion was to skip setting up inotify if the bitbake server isn't configured to be resident, which should be trivial. However, it seems devtool relies on some of the inotifies when one runs devtool modify. A colleague of mine did some further testing Jan 07 14:30:42 and found that he could disable most of the inotifies to get almost all of the performance improvement and still have devtool (and oe-selftest) still functioning as expected. Jan 07 14:34:21 Saur: I really don't want to have multiple codepaths for something like this though Jan 07 14:35:39 RP: If the bitbake server isn't resident, is there any reason to setup the inotifies? Especially given that it takes considerable time to do so... Jan 07 14:36:43 And if there is very little gain to have the bitbake server resident (compared to the time it takes to setup the inotifies), is there any reason to support a resident server? Jan 07 14:36:46 Saur: you are missing my point. Having behaviour where bitbake does A if memres and B if not makes it fragile, it means the test matrix needs to be more complex and means potential behavioural differences between the codepaths Jan 07 14:37:37 Saur: the plan was to support memres in all cases and have it as the default Jan 07 14:37:59 Saur: sadly this has not happened yet. As far as I can see it still would make sense if we can get the time to spend on sorting the remaining small corner cases Jan 07 14:38:18 RP: Yes, but if it there is no real gain from it and only a considerable cost, isn't it better to not support it at all? Jan 07 14:38:40 Saur: there should be a gain from it, all my testing suggests it should work Jan 07 14:38:54 Saur: there could well be some bug meaning that isn't realised at present, sure Jan 07 14:40:21 is there a way to modify the build parameter (do_configure) in a recipe? Jan 07 14:47:28 perdmann: recipe using autotools? Jan 07 14:48:59 if so then EXTRA_OECONF as per https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-autotools Jan 07 14:53:00 actually i dont know what kind of buildsystem rauc is using Jan 07 14:53:08 i have to dig into it :D Jan 07 14:53:41 the recipe will inherit a class, or hand-write its own do_configure Jan 07 14:54:12 https://layers.openembedded.org/layerindex/recipe/75303/ says autotools Jan 07 14:54:18 so EXTRA_OECONF Jan 07 14:57:05 thanks Jan 07 15:02:15 oh maybe its another issue Jan 07 15:05:10 Ok i see. I can add dbus or i can disable dbus support in rauc Jan 07 15:36:32 RP: I've done some further analysis of the resident server, and there definitely seems to be something wrong. If I start from scratch and run bitbake -p, it takes ~23 s. If I then immediately rerun bitbake -p it takes 0.5 s. I can event build something and after that rerun bitbake -p and it still takes 0.5 s. However, if I touch some recipe and then run bitbake -p it takes ~23 s again, and after that it continues to take ~23 s every time Jan 07 15:36:32 I run bitbake -p, even if I do not touch anything... Jan 07 15:57:58 YPTM - waiting for it to start Jan 07 15:58:35 YPTM- armin is on Jan 07 15:59:15 Saur: sounds like there is something broken :( Jan 07 15:59:28 RP: Yupp. I'm investigating it now... Jan 07 16:01:18 YPTM: tlwoerner is on Jan 07 16:02:15 YPTM: Randy MacLeod joined. Jan 07 16:05:32 oh tech call Jan 07 16:25:45 paul barker: Sandy is: Changqing Li Jan 07 16:26:06 * vmeson wonders what paul's /nick is... Jan 07 16:26:25 vmeson: paulbarker Jan 07 16:26:38 vmeson: paulbarker Jan 07 16:26:41 oops Jan 07 16:26:44 quite the decoder ring I have :D Jan 07 16:26:47 huh, I did try tab completion... oh well. Jan 07 16:30:46 need to drop, got another call Jan 07 16:35:55 https://lwn.net/Articles/788626/ Jan 07 16:48:07 YPTM minutes: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4 Jan 07 16:50:35 tlwoerner: no, https://lwn.net/Articles/804640/ ! :) Jan 07 16:54:16 * qschulz bookmarks this Jan 07 16:58:54 thanks David Jan 07 18:00:18 JPEW: hope you didn't find what I did to the method stuff with hashserve too horrible. As I mentioned in the call, we can work on improving things Jan 07 18:02:11 RP: It's fine for now. I think we'd want a dedicated table column for it in the long run Jan 07 18:03:12 RP: I don't think it would be too hard to write an SQL query that populates the new column from the split method, so we might even be able to upgrade in situ Jan 07 18:03:54 RP: Either way, proving it works is probably more important at this point :) Jan 07 18:04:45 RP: After some debugging, I think I now have to improvements that should fix the problems we've been seeing related to inotifies. First of all, all the watched files are added to two lists. Turning them into sets reduces my 23 s to about 8 s. Further, the reason the resident bitbake server starts to reparse every time once I touch a file seems to be due to the sanity_info file. Since it is written during the parsing, the next time bitbake Jan 07 18:04:45 is run, the modified sanity_info file from the last run triggers a new parsing... Jan 07 18:04:45 JPEW: that was my thinking... Jan 07 18:04:53 two improvements* Jan 07 18:05:32 Saur: that sounds like a nice improvement, looking forward to that patch! Jan 07 18:05:52 RP: Working on it. ;) Jan 07 18:06:35 Saur: I'd hoped it might be something "simple" Jan 07 18:07:05 RP: Seems like it was. :) Jan 07 18:16:12 armpit: can you please clarify https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance "Typically, alongside the latest release the previous two releases are also maintained." if the latest release is current master, so maintained stable branches should now be just zeus and warrior (and thud just wasn't updated in wiki as ended)? Jan 07 18:16:36 or was it always 3 already released branches? Jan 07 18:25:36 JaMa: we've been waiting to publish the new release policy to figure out what this then means for the releases. That has now been published at least... Jan 07 18:28:54 the LTS policy? Jan 07 18:29:38 JaMa: its not just LTS Jan 07 18:30:42 I'm sorry I don't know what published policy you're talking about, I'll re-check the archives Jan 07 18:33:29 JaMa: Its the LTS wiki page but it applies to all stable releases in reality Jan 07 18:36:08 "Stable releases are maintained for seven months" so thud as well as warrior should be in community support on https://wiki.yoctoproject.org/wiki/Releases, right? Jan 07 18:38:26 JaMa: under the new policy, yes. I think we probably carry warrior until the next release to have the policy overlap resolved Jan 07 18:38:59 things are never simple :/ Jan 07 18:42:58 ok, and the old policy was 2 stable release + master or 3 released releases + master? Jan 07 18:45:51 the main question I'm trying to answer to someone is when thud support was supposed to end, I thought it was just 2 released releases, so just zeus and warrior and thud moving to community support when zeus is released, but "Typically, alongside the latest release the previous two releases are also maintained." sounds like _3_ last releases are supported Jan 07 18:54:36 I think thud should be in community support now that we have warrior and zeus, and there will be some carryover for them to transition into LTS process as RP said Jan 07 18:55:56 JaMa: finally had a play with a 2019 LG webOS TV last week. They're nice, good work :) Jan 07 18:56:13 when our 10 year old sony dies i'll definitely get a LG Jan 07 18:56:20 unfortunately it isn't showing any signs of dying Jan 07 18:56:25 need to get the kids to play the wii again Jan 07 18:59:32 * JaMa bought his first own personal TV for christmas and it was also a LG :) Jan 07 19:00:10 quite expensive way to get hands on webos :) Jan 07 19:00:13 The Expanse from Amazon Video looks nice on it :) Jan 07 19:01:12 JaMa: is UI based on qt5 ? or is it fully chromium'ised Jan 07 19:02:23 both is available, most webapps are written in Enact and run on chromium based webruntime Jan 07 19:04:50 is enact some js art ? Jan 07 19:08:01 ah react based and there is enyo which is js based directly Jan 07 19:14:51 enyojs apps are being migrated to enactjs (https://enactjs.com/docs/developer-guide/migration/migrating-enyo-apps/) Jan 07 19:16:18 I see, enyo is then being deprecated ? Jan 07 19:34:32 RP: There, two patches on the way to improve the performance during startup of bitbake. :) Jan 07 19:38:37 RP: I made some more measurements. With my patches applied, the time to do devtool modify on a simple recipe went from 45-50 s to 16-18 s with Warrior and Zeus. For master the times went from 60 s to 30 s (with or without the hash server enabled). So a nice improvement overall (even though the times for master are double those for Warrior/Zeus, which I had not expected). Jan 07 19:41:18 Saur: That sounds like a great improvement. I wonder why the difference with zeus too Jan 07 19:41:52 RP: You mean Zeus -> master? Yeah, haven't looked into that yet... Jan 07 19:43:16 RP: are there some iterator function introduced in master in this area ? that could slow down sets Jan 07 19:43:55 Saur: it would probably be worth looking into Jan 07 19:44:18 iterating over contents of sets is usually slower than lists Jan 07 19:44:52 khem: we haven;t change much afaik Jan 07 19:47:38 master is 60s and zeus is 45 to 50s there is general slow down perhaps in different area Jan 07 19:47:59 which is added as it is Jan 07 19:48:07 then the numbers looks ok Jan 07 19:48:41 meaning this offset of 10-15 secs is there without the patches as well Jan 07 19:49:33 khem: right, there look to be multiple issues Jan 07 19:54:15 khem: yes I think so Jan 07 20:12:46 RP, khem: i just made a quick check. If I do devtool modify on a recipe with only meta and meta-poky, I cannot see any real time difference between zeus-22.0.0 and master (5.2 s in both cases), which will make it hard to do any kind of bisection since that is near impossible with all the layers enabled. :( Jan 07 20:26:50 Saur: can it be narrowed to some specific layer I wonder? Jan 07 20:27:38 RP: I'm currently doing some tests with (some of) the OpenEmbedded layers added as well. Jan 07 20:28:20 Saur: cool, makes sense. These things can be "fun" to track down like this :/ Jan 07 20:30:11 RP: With meta-oe added the times seems to go from 8 s to 32 s (without my patches applied) from zeus-22.0.0 to master... Jan 07 20:34:38 Ok, with the patches applied the times are down to ~5.5 s with both zeus-22.0.0 and master... Jan 07 20:41:27 Hmm, ok. If I add meta-filesystems, meta-networking, meta-python and meta-webserver as well, I finally see a difference between zeus-22.0.0 and master (with my patches applied), from 8 s to 25 s. Ok, more data needed... Jan 07 20:45:00 Hmm, scratch that. The result wasn't repeatable. :P Jan 07 20:48:20 RP, my display name in groups.io is Armpit Jan 07 20:48:49 that is why its being sent out that way Jan 07 20:49:08 JaMa: I opened another pull, for one more patch to qt5-creator fix on musl/x86 Jan 07 20:49:11 armpit: ok, fair enough. You just seemed surprised :) Jan 07 20:53:11 Saur: one downside to your second patch is encoding OE knowledge into bitbake :( Jan 07 20:53:33 RP: Oh, sorry, didn't think of that. Jan 07 20:53:58 Saur: May be hard to generalise though :/ Jan 07 20:59:15 RP: Would moving the sanity_info file be an option (to, e.g., cache)? It's not really a .conf file anyway... There should not be any watcher for the cache directory I believe. Jan 07 21:01:36 * armpit changed display name Jan 07 21:02:06 RP, did you want me to cleanup core stable/zeus-next to remove the valgrid patch? Jan 07 21:03:41 Saur: yes, moving it could be an option Jan 07 21:04:08 armpit: if we're not planning to take it, it should be dropped... Jan 07 21:04:16 RP: If it's ok to just move it (which I guess), then I can do that instead. Should be simple enough (I hope...) Jan 07 21:04:33 Saur: if you could take a look that would be good Jan 07 21:04:53 Saur: I like the idea in principle, hadn;t thought of that... Jan 07 21:05:57 Saur: moving is fine, just means some checks will rerun which is fine Jan 07 21:07:40 I'm dealing with a kernel oops right now (caused when two development kits from the same vendor are connected). I'm trying to following directions like this (https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0) so I can provide more information and dig into the issue myself. Unfortunately I'm finding it difficult to configure the Jan 07 21:07:41 software image I'm building with Yocto to support the debugging. Is there documentation for how to set up kernel debugging on the device? Or would I be better pulling logs off the device and debugging them on the build machine? Just looking for some advice here, thanks! Jan 07 21:09:10 d_thomas: I'm not great at kernel debugging... sometimes the stack trace is shallow enough that you can tell what's going on, but as an embedded guy I've learned a log by putting kprintfs() in placing I'm interested in. Jan 07 21:10:23 I did build kgdb and get it to attach over serial but it was so difficult to get the information I wanted I gave up. Jan 07 21:10:25 Unfortunately the error is "unable to handle kernel paging request at virtual address fffffffe" and the trace is just a hex dump. Jan 07 21:10:36 Ahh, I've had a few of those. Jan 07 21:11:04 RP: Ok, good. Only drawback (for me) is that it's mentioned in the manual, so I'll need to send a separate patch for that. Jan 07 21:11:10 The only bright side is that I know the exact kernel config change I made to enable the problem and all the source is in one file Jan 07 21:12:51 So I should be more clear, if I could translate "function entered at [] from []", I might have something useful Jan 07 21:16:02 d_thomas: the kernel symbol table may help with that? Jan 07 21:18:08 d_thomas: (System.map file) Jan 07 21:18:30 RP: Would that be hanging around in the build somewhere? Jan 07 21:19:31 d_thomas: yes, kernel build directory and its packaged somewhere too Jan 07 21:19:42 * RP hasn't a build handy Jan 07 21:20:15 * RP is also going from rusty years old memories Jan 07 21:21:35 d_thomas: ksymoops is a script which can do the translations of an oops for you based on the files like System.map iirc Jan 07 21:21:41 RP: I found it, yeah, that helps. Not granular enough to get me to the line, but I should be able to track the function calls Jan 07 21:23:03 d_thomas: with the offset you could get there with disassembly from objdump I guess Jan 07 21:23:27 function is a good start :) Jan 07 21:24:06 RP: ksymoops looks like a lot of help. If I can just pull the oops info and parse it against info from the build machine that would be perfect. And a lot faster than building a custom image with all the debug tools included! Jan 07 22:11:33 RP, I wasn't able to get ksymoops to build. Trying to figure out a plan B with objdump Jan 07 22:12:43 RP: Ok, I sent two updated patches for bitbake, and another two for OE-Core now. I have a fifth patch for the manual, but I'll hold onto it until the other patches have been accepted. Jan 07 22:17:24 Saur: did you find a problem with other .lock or .log files? Jan 07 22:18:41 RP: We have some .lock files in one of our layers that caused unnecessary notifications. Jan 07 22:19:18 Saur: I'm a little worried someone might put a .log or .lock file in SRC_URI :/ Jan 07 22:19:52 You really shouldn't be writing into layer directories... Jan 07 22:21:06 RP: It's not. The .lock files are in tmp/somedir. The problem is that the way bitbake sets up notifications for directories of directories to catch possible future files, it is watching a lot... Jan 07 22:21:33 ... that probably shouldn't be watched... Jan 07 22:22:43 Saur: right, it shouldn't be watching that Jan 07 22:23:01 Saur: I'd really like to understand why it is and fix that if we can Jan 07 22:23:36 Saur: I'm not trying to be awkward btw, I just want to ensure we fix the real problems Jan 07 22:23:52 Saur: Your looking into this is *much* appreciated Jan 07 22:26:08 Is it possible to use devtool with tarballs? Doesn't seems like it... Jan 07 22:27:45 RP: Well, actually now that I think of it, it should it be watching files in that directory. There are .conf files that are generated on the fly and include'd into recipes in that directory, and when they are created they are protected using .lock files in the same directory. And because of the .conf files, bitbake watches the entire directory and thus is fooled by the modified .lock files. Jan 07 22:28:44 RP: (It is actually some of our oldest code, used to support migrating our old product configuration system that is based on kconfig to work with bitbake.) Jan 07 22:36:42 RP: If you have doubt about the .lock/.log files, then just skip that patch. I can modify our code so that the .lcok files are written in another directory or something that isn't watched. Jan 07 22:55:00 RP: I've fixed our code now to use a different directory for the .lock files than the .conf files, so just ignore the second patch. Jan 07 23:06:08 Saur: I think I would do that somewhere else more isolated as changes there will have other ways of catching you out Jan 07 23:06:31 Saur: ah, great, now I read the last line :) Jan 07 23:06:36 :) Jan 07 23:08:52 cd - Jan 08 00:10:11 RP: Found the problem with openssh seems to be related to nanosleep in seccomp Jan 08 00:10:27 RP: have fixed it for x86/arm Jan 08 00:10:36 khem: ah, interesting, good Jan 08 00:10:42 mips also fails so trying to see Jan 08 00:10:44 khem: did you see the mips boot issue? Jan 08 00:10:53 khem: that looked different :/ Jan 08 00:10:59 mips booted okay for me Jan 08 00:11:11 but it does show same ssh issue Jan 08 00:11:25 ssh worked on arm64/riscv64 Jan 08 00:11:42 but mips/mips64/arm/x86/x86_64 failed Jan 08 00:12:01 khem: does the fix make sense for an arch specific issue? Jan 08 00:14:19 RP: hee is the fix so far https://github.com/YoeDistro/openembedded-core/commit/20b9b4dfa3519a7e863737f980b6ab4e41ef92c5 Jan 08 00:14:49 yes I think it does, openssh/seccomp assumes same values for syscalls Jan 08 00:15:36 khem: right, yes Jan 08 00:16:08 debugging sshd is tricky to debug, I realized that I have to strace the child on connection request then I can see the syscall going bonkers Jan 08 00:16:32 ya.. debugging a tool designed to be difficult to intercept Jan 08 00:16:56 khem: I can imagine, nice work in tracking it down! :) Jan 08 00:17:17 RP: if I can get hold of mips piece then I will send another pull and see if we can drill more issues on glibc 2.31 Jan 08 00:18:37 khem: fair enough, happy to give it another run when it makes sense Jan 08 00:18:56 if anyone wants to fix that locked sig selftest failure btw... :) Jan 08 00:24:30 mips is glitching on clock_gettime64 hmm ok Jan 08 00:39:53 RP: mips is fixed :), I will try mips64 and ppc as well and see if it works there too Jan 08 00:40:07 if not then I guess will need to fix those too beforee next run Jan 08 00:40:50 khem: probably worth ensuring they're ok Jan 08 00:53:40 RP:yeah and its also latest SRCREV of glibc so that might have helped booting mips Jan 08 00:54:12 but I am also using gcc10 so I might have to check building mips with gcc9 Jan 08 00:54:41 RP: the logs you pointed to me were x86_64 only, can you point me to mips logs if you have links handy Jan 08 00:54:54 irc logs might have it too Jan 08 00:54:59 dont know Jan 08 01:52:40 RP: ssh patch is posted to ml as well as to https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/pu Jan 08 01:53:04 ppc/mips/mips64/x86/arm/x86_64 worked fine Jan 08 02:17:23 khem, so how am I supposed to pronounce your branch ? Jan 08 02:25:30 pee-you :) Jan 08 02:29:26 I think it was the git scm book where I learned it and have been using it for pull upstream request branch names Jan 08 02:30:28 * armpit time to head home Jan 08 02:30:37 I treat it as shortcut for 'publish' Jan 08 02:31:19 armpit: drive safe, if you are on foot, walk safe Jan 08 02:31:31 because I am on road Jan 08 02:31:34 too **** ENDING LOGGING AT Wed Jan 08 02:59:58 2020