Tuesday, 2020-01-07

*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC00:14
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto00:16
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC00:24
*** camus <camus!~Instantbi@> has joined #yocto01:01
*** kaspter <kaspter!~Instantbi@> has quit IRC01:02
*** camus is now known as kaspter01:02
*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:44
*** yizhao <yizhao!~zhaoyi@> has quit IRC01:49
*** kaspter <kaspter!~Instantbi@> has quit IRC02:10
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:10
aehs29RP: This 4cb1b4b just caused a 0% match 0% complete on sstate :)03:45
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto05:50
*** iceaway <iceaway!~pelle@> has joined #yocto06:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:25
*** stuom1 <stuom1!3eecd81d@> has joined #yocto06:26
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto06:33
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:07
*** PinkSnake <PinkSnake!51ff1123@> has joined #yocto07:19
PinkSnakeHello 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 :(07:22
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has joined #yocto07:24
LetoThe2ndPinkSnake: undefined reference usually means that the linker can't find some library. so, check the dependencies, and their handling in the configure/make stages.07:27
PinkSnakeLetoThe2nd i think you are right and it's linked to https://github.com/opencv/opencv/commit/094615b2c56f31e3a1a0d42799c802ebd7dca383#diff-40c9b23a9a22bcb03bc88589672a45ea07:29
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:29
*** frsc <frsc!~frsc@2003:a:e7a:6200:b42c:b319:e9dc:c823> has joined #yocto07:29
*** stuom146 <stuom146!3eecd81d@> has joined #yocto07:29
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC07:30
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto07:31
*** stuom146 <stuom146!3eecd81d@> has quit IRC07:37
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC07:52
*** mckoan|away is now known as mckoan08:00
mckoangood morning08:00
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto08:03
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC08:06
LetoThe2ndmorning mckoan08:06
stuom1anybody know why 2020 irc logs are not available or when will they be?08:08
mckoanLetoThe2nd: Happy new year08:08
LetoThe2ndmckoan: hehe thanks.08:08
*** goliath <goliath!~goliath@> has joined #yocto08:13
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:47
*** iceaway <iceaway!~pelle@> has quit IRC08:48
*** jij <jij!jonashg@nat/axis/x-xlzlevzpfxtviawf> has quit IRC08:51
*** yann|work <yann|work!~yann@> has joined #yocto08:52
*** lfa <lfa!~lfa@> has joined #yocto08:53
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:01
*** Saur <Saur!pkj@nat/axis/x-bwwikyarrgvxumpg> has joined #yocto09:02
*** wertigon <wertigon!8addfa13@> has joined #yocto09:06
*** wertigon <wertigon!8addfa13@> has quit IRC09:08
RPaehs29: yes, soon back to normal though :)09:10
*** jij <jij!jonashg@nat/axis/x-sbamqywmwxoanajm> has joined #yocto09:11
*** wertigon <wertigon!8addfa13@> has joined #yocto09:13
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC09:18
aehs29RP: tell that to my CI setup haha09:25
aehs29RP: no actually it was good, I didnt know my plan B wasnt working so its good that Im aware of that now09:26
aehs29RP: btw, why is the AB not populating sstate.yp.org?09:28
RPaehs29: it should be...09:31
aehs29it says it was last update on 12-Dec-2019 17:3509:36
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto09:52
*** lfa_ <lfa_!~lfa@> has joined #yocto10:00
*** lfa_ <lfa_!~lfa@> has quit IRC10:05
RPaehs29: hmm, I wonder if that is just misleading :/10:19
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC10:23
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC10:29
*** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has quit IRC10:30
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto10:32
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto10:36
SaurRP: 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 r11:03
Saurecipes, it went back to normal.11:03
SaurRP: I am wondering if it has to do with the almost constantly running "Checking sstate mirror object availability" task.11:05
*** rburton <rburton!~rburton@> has joined #yocto11:22
*** falkb <falkb!91fdde45@> has joined #yocto11:25
falkbHi, 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?11:29
LetoThe2ndfalkb: tahts probably more like kernelversion/-configuration related than yocto specific11:30
LetoThe2ndbecause that sounds like one of the things that are there if the specific kernel in question supports it, and are not there if...11:30
falkbI'm programming with yocto linux and suspected it's a missing feature there11:30
LetoThe2ndi don't think yocto "misses a feature" there, its rather the kernel you use.11:31
LetoThe2ndhave you inspected /proc/config.gz to see if the v4l stuff is actually enabled?11:31
LetoThe2ndfalkb: 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.h11:42
*** berton <berton!~berton@> has joined #yocto11:43
*** berton <berton!~berton@> has quit IRC11:46
*** berton <berton!~berton@> has joined #yocto11:47
*** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has joined #yocto11:57
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC11:57
falkbLetoThe2nd: uh yeah, good hint about v4l2-subdev.h. Now I just need to find out how what the toplevel header is which includes that11:57
wertigonfalkb: Remember that Yocto Linux does not cover every conceivable use case and some kernel options are disabled by default.12:06
wertigonThough that might not be the issue here :)12:06
RPSaur: we have performance problems in the task migration code12:06
RPSaur: it could be the sstate mirror checks if those are slow but the code itself is also slow12:07
perdmannHi, i plan to use a parallel NAND memory. Is there a list which devices have good support?12:16
LetoThe2ndperdmann: kernel support applies :)12:19
perdmannis kernel and uboot support equal?12:22
perdmanni just found out that qspi nand's are "too new" :)12:22
falkb#include <linux/v4l2-subdev.h> does the job. Thanks Leto 2.12:22
LetoThe2ndperdmann: if in doubt, look at the eval kit of your desired SoC and just use whats there :)12:23
LetoThe2ndfalkb: have fun.12:23
perdmannhaha . Thats exactly what the NXP guy told me...12:23
LetoThe2ndperdmann: see, and i'm not even working for nxp.12:24
perdmannyou should ask them for your salary ;)  Anyway... really annoying to search for the "correct" memory12:25
LetoThe2ndperdmann: its just basically like this: "if you have to ask, then don't do any experiments""12:27
*** falkb65 <falkb65!91fdde45@> has joined #yocto12:32
falkb65perdmann: Which SoC do you use?12:32
*** falkb <falkb!91fdde45@> has quit IRC12:32
falkb65as 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 present12:34
LetoThe2ndfor raw nand flasch you always have to use a controller AFAIK12:35
Ad0hm "package packagegroup-core-ssh-dropbear-1.0-r1.all requires dropbear, but none of the providers can be installed12:36
Ad0IMAGE_FEATURES += "ssh-server-dropbear"12:36
Ad0I do this in my image recipe12:37
*** falkb65 is now known as falkb12:37
Ad0is it in conflict with packagegroup-core-boot ?12:38
LetoThe2ndAd0: can you proide the full error message in a pastebin?12:38
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC12:38
Ad0ok LetoThe2nd12:38
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto12:38
perdmann@falkb65 imx612:38
LetoThe2ndAd0: dropbear is usually completely unproblematic, so you are probably doing something "unconventional"12:39
perdmann@falkb65 parallel NAND "should" work. There is also a driver for that and it is an option for the eval board.12:39
LetoThe2ndfalkb: *badum-tsh*12:39
*** jij <jij!jonashg@nat/axis/x-sbamqywmwxoanajm> has quit IRC12:39
Ad0LetoThe2nd, https://pastebin.com/xQrbGPtm12:40
creichhi 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 why12:40
creichi tried to verify the nfs server setup by mounting the share from my local machine, which works so far12:41
creichon 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 '12:41
creichbut that occurs several times in a row, till the kernel stops trying12:42
*** jij <jij!jonashg@nat/axis/x-uqohogmlgpgvxjqp> has joined #yocto12:42
creichany ideas what else to check?12:42
LetoThe2ndAd0: what else is on the build besides that image?12:43
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC12:43
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto12:43
Ad0LetoThe2nd, you mean machine_features and so on ?12:44
LetoThe2ndAd0: i mean like, what did you all add in order to break it? :)12:44
Ad0I can post the image recipe12:44
LetoThe2ndAd0: have you maybe removed poky/meta?12:44
Ad0no it's all there12:45
Ad0it works without exactly dropbear12:45
Ad0maybe I have included conflicting stuff that prevents it ?12:45
LetoThe2ndAd0: openssh conflicts.12:45
Ad0I add those packages listed in the paste there , and I inherit core-image12:46
falkbperdmann: Which parallel driver do you mean? Do you have a web page about that?12:47
LetoThe2ndAd0: what happens if you build that image for a standard qemu?12:48
Ad0then what happens is that I have to wait forever :D12:48
Ad0${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-scripts12:48
Ad0that's the stuff I install in the image12:48
LetoThe2ndagain, i don't think the image is the problem12:49
Ad0ok. my distro inherits from MENDER_FULL which is a bunch of stuff as well.12:49
Ad0err mender-full.12:50
Ad0I don't think it's that either, just a feeling :)12:51
LetoThe2ndswap poky in and find out :)12:51
Ad0would openssl-bin create a conflic?12:51
Ad0poky instead of what?12:51
LetoThe2ndinstead of your distro12:51
Ad0DISTRO 'poky' not found. Please set a valid DISTRO in your local.conf12:54
LetoThe2ndsomething is really broken in your bblayers.conf12:54
LetoThe2ndso for the distro case, meta-poky is missing12:57
Ad0yeah I didn't need that for my own distro right?12:57
rburtonright meta-poky isn't required unless you're using poky12:57
SaurRP: Any hopes of improving the performance? Or you are still working on solving all the corner cases?12:57
RPSaur: There are local patches which help but also create new bugs12:58
LetoThe2ndRP: surely correct, but obviously the own distro as issues :)12:58
RPSaur: I spent most of my "vacation" trying to fix this stuff :(12:58
Ad0alright running again12:59
RPSaur: 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 distractions12:59
SaurRP: 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...13:00
RPSaur: Its like comparing apples and oranges. Enabling hashequiv adds new codepaths and they are slow13:01
RPSaur: 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 perform13:01
RPIt is slower but the reasons are complex :(13:02
RPwell, depends what reuse you get13:02
Ad00: openssl-native-1.1.1b-r0 do_install - 21s (pid 7883)13:02
Ad0 - why does it bother when I asked for dropbear13:02
Ad0oh sorry my mistake13:02
LetoThe2ndAd0: ssl != ssh13:02
Ad0I thought it said "ssh" haha.13:03
RPnative != target too13:03
Ad0that's what happens when you look too long on the same thing13:03
Ad0it seems to want to recompile everything13:03
SaurRP: 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?13:03
Ad0there goes the rest of my day I guess!13:04
RPSaur: correctness needs to come first. I think some speedup is possible13:04
*** falkb <falkb!91fdde45@> has left #yocto13:05
RPAd0: time to make the case to management for decent build resources? ;-)13:05
Ad0I will order an SSD13:05
RPor get some time to work on performance? :)13:06
* RP feels lonely on that battle13:06
Ad0currently 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 building13:06
RP"lets add all these features" "but they make X slower" "but new features, we need features"13:06
RPAd0: that is impressive :/13:07
Ad0I tried to build on azure VM with "decent" specs like "premium SSD" enough RAM etc, but it ran just as slow13:07
RPAd0: dedicated build hardware, old school without VMs and overhead ;-)13:07
SaurRP: Wish I could help you more there, but I am still not  fluent in the bitbake core...13:08
Ad0RP, amen :)13:08
RPSaur: best way to learn may be to pick a performance glitch and debug it and figure out how to improve13:08
SaurRP: 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...13:10
SaurRP: 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 sta13:18
Saurrting bitbake...13:18
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto13:21
RPSaur: 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 things13:22
RPSaur: at least in theory if the overhead is inotify, we don't need to do that again13:22
RPSaur: so it should be faster13:22
Ad0RP, what linux distro are you running :)13:23
Ad0or are you running something else perhaps?13:23
SaurRP: But if the bitbake server isn't resident, is there any reason for the inotify code at all?13:23
Saur(From a bitbake perspective.)13:23
RPSaur: 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 queues13:23
RPAd0: build server has ubuntu on it13:24
RPSaur: It was thought we'd switch to memres and do we want multiple different codepaths to maintain/test?13:24
RPSaur: history says multiple paths leads to problems13:25
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto13:27
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:31
SaurRP: 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.13:36
yoctiBug 13699: normal, Medium+, 3.2, richard.purdie, NEW , Prolonged recipe parsing times after removing tmp when the resident bitbake server is used13:36
Saur(Oops, late for a meeting, back in half an hour.)13:37
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto13:37
RPSaur: definitely looks significant...13:38
zeddiiRP: 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.13:42
RPzeddii: well done on finding a fix!13:43
RPzeddii: shame about upstream :(13:43
zeddiiIt’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.13:44
zeddiiI will come back to it again and write it up .. but I need to move on the recipes first.13:45
perdmannand rauc is also not working :)13:45
yoctiNew news from stackoverflow: Yocto load kernel module <https://stackoverflow.com/questions/59629344/yocto-load-kernel-module>13:47
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:48
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto13:51
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:58
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto14:02
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC14:07
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto14:12
tgamblinRP: 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?14:24
RPtgamblin: "layer index" ?14:25
tgamblinRP: well, what the current version tied to a recipe should be, e.g. libical 3.0.614:25
RPtgamblin: "layer index" usually means layers.openembedded.org14:26
*** ericch <ericch!~ericch@> has joined #yocto14:26
RPtgamblin: but the answer is no14:26
RPtgamblin: 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?14:27
RPtgamblin: I know there was one to work around it14:27
RP(that one is in -next)14:27
* RP forgets where we were at with these patches14:27
tgamblinRP: 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 silly14:28
tgamblinRP: 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 things14:28
RPtgamblin: ok, just checking I didn't miss something. We seemed closer to a root cause14:29
SaurRP: 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 testing14:30
Saurand 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.14:30
RPSaur: I really don't want to have multiple codepaths for something like this though14:34
SaurRP: 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...14:35
SaurAnd 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?14:36
RPSaur: 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 codepaths14:36
RPSaur: the plan was to support memres in all cases and have it as the default14:37
RPSaur: 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 cases14:37
SaurRP: 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?14:38
RPSaur: there should be a gain from it, all my testing suggests it should work14:38
RPSaur: there could well be some bug meaning that isn't realised at present, sure14:38
*** berton <berton!~berton@> has quit IRC14:38
perdmannis there a way to modify the build parameter (do_configure) in a recipe?14:40
rburtonperdmann: recipe using autotools?14:47
rburtonif so then EXTRA_OECONF as per https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-autotools14:48
perdmannactually i dont know what kind of buildsystem rauc is using14:53
perdmanni have to dig into it :D14:53
rburtonthe recipe will inherit a class, or hand-write its own do_configure14:53
rburtonhttps://layers.openembedded.org/layerindex/recipe/75303/ says autotools14:54
rburtonso EXTRA_OECONF14:54
*** berton <berton!~berton@> has joined #yocto14:54
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC14:59
perdmannoh maybe its another issue15:02
*** stuom1 <stuom1!3eecd81d@> has quit IRC15:03
*** berton_ <berton_!~berton@> has joined #yocto15:04
perdmannOk i see. I can add dbus or i can disable dbus support in rauc15:05
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto15:06
*** berton <berton!~berton@> has quit IRC15:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC15:07
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:09
*** goliath <goliath!~goliath@> has quit IRC15:28
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC15:31
*** vmeson <vmeson!~rmacleod@> has joined #yocto15:36
SaurRP: 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 time15:36
SaurI run bitbake -p, even if I do not touch anything...15:36
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto15:46
*** frsc <frsc!~frsc@2003:a:e7a:6200:b42c:b319:e9dc:c823> has quit IRC15:54
armpitYPTM - waiting for it to start15:57
armpitYPTM- armin is on15:58
RPSaur: sounds like there is something broken :(15:59
SaurRP: Yupp. I'm investigating it now...15:59
tlwoernerYPTM: tlwoerner is on16:01
vmesonYPTM: Randy MacLeod joined.16:02
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-sqrpkvipgserevmq> has quit IRC16:04
rburtonoh tech call16:05
*** sgw <sgw!~sgw@> has joined #yocto16:07
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto16:16
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC16:16
*** ericch <ericch!~ericch@> has quit IRC16:17
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:18
*** adelcast <adelcast!~adelcast@> has left #yocto16:20
*** adelcast <adelcast!~adelcast@> has joined #yocto16:21
vmesonpaul barker: Sandy is: Changqing Li <changqing.li@windriver.com>16:25
* vmeson wonders what paul's /nick is...16:26
zeddiivmeson: paulbarker16:26
tlwoernervmeson: paulbarker16:26
zeddiiquite the decoder ring I have :D16:26
vmesonhuh, I did try tab completion... oh well.16:26
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto16:26
rburtonneed to drop, got another call16:30
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC16:33
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto16:34
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto16:36
*** orzen <orzen!~orz@84-216-106-29.customers.ownit.se> has quit IRC16:38
*** yann|work <yann|work!~yann@> has quit IRC16:42
*** jwwww <jwwww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has quit IRC16:44
dreynaYPTM minutes: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH416:48
RPtlwoerner: no, https://lwn.net/Articles/804640/ ! :)16:50
* qschulz bookmarks this16:54
armpitthanks David16:58
*** jwwww <jwwww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto16:59
*** orzen <orzen!~orz@84-216-106-29.customers.ownit.se> has joined #yocto17:09
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:18
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC17:23
*** mckoan is now known as mckoan|away17:25
*** sgw <sgw!~sgw@> has quit IRC17:39
*** vineela <vineela!~vtummala@> has joined #yocto17:41
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto17:50
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:52
RPJPEW: 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 things18:00
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto18:00
JPEWRP: It's fine for now. I think we'd want a dedicated table column for it in the long run18:02
JPEWRP: 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 situ18:03
JPEWRP: Either way, proving it works is probably more important at this point :)18:03
SaurRP: 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 bitbake18:04
Saur is run, the modified sanity_info file from the last run triggers a new parsing...18:04
RPJPEW: that was my thinking...18:04
Saurtwo improvements*18:04
RPSaur: that sounds like a nice improvement, looking forward to that patch!18:05
SaurRP: Working on it. ;)18:05
RPSaur: I'd hoped it might be something "simple"18:06
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC18:07
SaurRP: Seems like it was. :)18:07
*** JaMa <JaMa!~martin@> has joined #yocto18:08
*** armpit <armpit!~armpit@2601:202:4180:a5c0:24ce:b2a3:bac9:47a9> has quit IRC18:10
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC18:10
*** armpit <armpit!~armpit@2601:202:4180:a5c0:fda8:efcd:67f0:45fb> has joined #yocto18:12
JaMaarmpit: 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)?18:16
JaMaor was it always 3 already released branches?18:16
*** armpit <armpit!~armpit@2601:202:4180:a5c0:fda8:efcd:67f0:45fb> has quit IRC18:17
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto18:18
RPJaMa: 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...18:25
JaMathe LTS policy?18:28
RPJaMa: its not just LTS18:29
JaMaI'm sorry I don't know what published policy you're talking about, I'll re-check the archives18:30
*** khem <khem!~khem@unaffiliated/khem> has quit IRC18:31
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto18:31
RPJaMa: Its the LTS wiki page but it applies to all stable releases in reality18:33
JaMa"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?18:36
*** sgw <sgw!~sgw@> has joined #yocto18:37
RPJaMa: under the new policy, yes. I think we probably carry warrior until the next release to have the policy overlap resolved18:38
RPthings are never simple :/18:38
JaMaok, and the old policy was 2 stable release + master or 3 released releases + master?18:42
JaMathe 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 supported18:45
khemI 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 said18:54
rburtonJaMa: finally had a play with a 2019 LG webOS TV last week.  They're nice, good work :)18:55
rburtonwhen our 10 year old sony dies i'll definitely get a LG18:56
rburtonunfortunately it isn't showing any signs of dying18:56
rburtonneed to get the kids to play the wii again18:56
* JaMa bought his first own personal TV for christmas and it was also a LG :)18:59
khemquite expensive way to get hands on webos :)19:00
JaMaThe Expanse from Amazon Video looks nice on it :)19:00
khemJaMa: is UI based on qt5 ? or is it fully chromium'ised19:01
JaMaboth is available, most webapps are written in Enact and run on chromium based webruntime19:02
khemis enact some js art ?19:04
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto19:07
khemah react based and there is enyo which is js based directly19:08
JaMaenyojs apps are being migrated to enactjs (https://enactjs.com/docs/developer-guide/migration/migrating-enyo-apps/)19:14
khemI see, enyo is then being deprecated ?19:16
*** rangergord <rangergord!~rangergor@modemcable186.198-70-69.static.videotron.ca> has quit IRC19:17
*** rangergord <rangergord!~rangergor@modemcable186.198-70-69.static.videotron.ca> has joined #yocto19:20
*** vineela <vineela!~vtummala@> has quit IRC19:27
SaurRP: There, two patches on the way to improve the performance during startup of bitbake. :)19:34
SaurRP: 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).19:38
RPSaur: That sounds like a great improvement. I wonder why the difference with zeus too19:41
SaurRP: You mean Zeus -> master? Yeah, haven't looked into that yet...19:41
khemRP: are there some iterator function introduced in master in this area ? that could slow down sets19:43
RPSaur: it would probably be worth looking into19:43
khemiterating over contents of sets is usually slower than lists19:44
RPkhem: we haven;t change much afaik19:44
khemmaster is 60s and zeus is 45 to 50s there is general slow down perhaps in different area19:47
khemwhich is added as it is19:47
khemthen the numbers looks ok19:48
khemmeaning this offset of 10-15 secs is there without the patches as well19:48
RPkhem: right, there look to be multiple issues19:49
JaMakhem: yes I think so19:54
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC20:08
SaurRP, 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. :(20:12
*** armpit <armpit!~armpit@> has joined #yocto20:15
RPSaur: can it be narrowed to some specific layer I wonder?20:26
SaurRP: I'm currently doing some tests with (some of) the OpenEmbedded layers added as well.20:27
RPSaur: cool, makes sense. These things can be "fun" to track down like this :/20:28
SaurRP: 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...20:30
SaurOk, with the patches applied the times are down to ~5.5 s with both zeus-22.0.0 and master...20:34
SaurHmm, 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...20:41
SaurHmm, scratch that. The result wasn't repeatable. :P20:45
armpitRP, my display name in groups.io is Armpit20:48
armpitthat is why its being sent out that way20:48
khemJaMa: I opened another pull, for one more patch to qt5-creator fix on musl/x8620:49
RParmpit: ok, fair enough. You just seemed surprised :)20:49
RPSaur: one downside to your second patch is encoding OE knowledge into bitbake :(20:53
SaurRP: Oh, sorry, didn't think of that.20:53
RPSaur: May be hard to generalise though :/20:53
*** camus <camus!~Instantbi@> has joined #yocto20:55
*** kaspter <kaspter!~Instantbi@> has quit IRC20:56
*** camus is now known as kaspter20:56
SaurRP: 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.20:59
*** d_thomas <d_thomas!d074ab12@> has joined #yocto21:00
* armpit changed display name21:01
armpitRP, did you want me to cleanup core stable/zeus-next to remove the valgrid  patch?21:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC21:03
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto21:03
RPSaur: yes, moving it could be an option21:03
RParmpit: if we're not planning to take it, it should be dropped...21:04
SaurRP: If it's ok to just move it (which I guess), then I can do that instead. Should be simple enough (I hope...)21:04
RPSaur: if you could take a look that would be good21:04
RPSaur: I like the idea in principle, hadn;t thought of that...21:04
RPSaur: moving is fine, just means some checks will rerun which is fine21:05
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto21:07
d_thomasI'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 the21:07
d_thomassoftware 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!21:07
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC21:08
ecdhed_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.21:09
ecdheI did build kgdb and get it to attach over serial but it was so difficult to get the information I wanted I gave up.21:10
d_thomasUnfortunately the error is "unable to handle kernel paging request at virtual address fffffffe" and the trace is just a hex dump.21:10
ecdheAhh, I've had a few of those.21:10
SaurRP: 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.21:11
d_thomasThe 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 file21:11
d_thomasSo I should be more clear, if I could translate "function entered at [<c04b2c44>] from [<c04b5948>]", I might have something useful21:12
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC21:15
RP d_thomas: the kernel symbol table may help with that?21:16
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:18
RPd_thomas: (System.map file)21:18
d_thomasRP: Would that be hanging around in the build somewhere?21:18
RPd_thomas: yes, kernel build directory and its packaged somewhere too21:19
* RP hasn't a build handy21:19
* RP is also going from rusty years old memories21:20
RPd_thomas: ksymoops is a script which can do the translations of an oops for you based on the files like System.map iirc21:21
d_thomasRP:  I found it, yeah, that helps.  Not granular enough to get me to the line, but I should be able to track the function calls21:21
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC21:22
RPd_thomas: with the offset you could get there with disassembly from objdump I guess21:23
RPfunction is a good start :)21:23
*** berton_ <berton_!~berton@> has quit IRC21:23
d_thomasRP: 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!21:24
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has quit IRC21:37
*** vmeson <vmeson!~rmacleod@> has quit IRC21:40
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC21:42
*** cengiz_io <cengiz_io!~cengiz_io@> has quit IRC21:46
*** cengiz_io <cengiz_io!~cengiz_io@> has joined #yocto21:46
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC21:47
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto21:48
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto21:55
*** tgamblin <tgamblin!~tgamblin@> has quit IRC22:08
d_thomasRP, I wasn't able to get ksymoops to build.  Trying to figure out a plan B with objdump22:11
SaurRP: 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.22:12
RPSaur: did you find a problem with other .lock or .log files?22:17
SaurRP: We have some .lock files in one of our layers that caused unnecessary notifications.22:18
RPSaur: I'm a little worried someone might put a .log or .lock file in SRC_URI :/22:19
RPYou really shouldn't be writing into layer directories...22:19
SaurRP: 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...22:21
Saur... that probably shouldn't be watched...22:21
RPSaur: right, it shouldn't be watching that22:22
RPSaur: I'd really like to understand why it is and fix that if we can22:23
RPSaur: I'm not trying to be awkward btw, I just want to ensure we fix the real problems22:23
RPSaur: Your looking into this is *much* appreciated22:23
roussinmIs it possible to use devtool with tarballs? Doesn't seems like it...22:26
SaurRP: 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.22:27
SaurRP: (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.)22:28
*** d_thomas <d_thomas!d074ab12@> has quit IRC22:31
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC22:34
SaurRP: 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.22:36
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto22:38
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto22:46
SaurRP: 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.22:55
*** vineela <vineela!~vtummala@> has joined #yocto22:56
*** rburton <rburton!~rburton@> has quit IRC23:05
RPSaur: I think I would do that somewhere else more isolated as changes there will have other ways of catching you out23:06
*** cpo <cpo!~cpo@helix.mybll.net> has quit IRC23:06
RPSaur: ah, great, now I read the last line :)23:06
*** cpo <cpo!~cpo@helix.mybll.net> has joined #yocto23:06
Saurcd -23:08
*** JaMa <JaMa!~martin@> has quit IRC23:41
*** kreyren[m] <kreyren[m]!~kreyrenm]@ip-86-49-115-152.net.upcbroadband.cz> has quit IRC23:42
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC23:44
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC23:46
*** kreyren[m] <kreyren[m]!~kreyrenm]@ip-86-49-115-152.net.upcbroadband.cz> has joined #yocto23:46
*** stacktrust <stacktrust!~stacktrus@cpe-104-162-194-186.nyc.res.rr.com> has quit IRC23:53
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto23:57

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!