| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 00:14 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 00:16 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 00:24 | |
| *** camus <camus!~Instantbi@222.67.188.181> has joined #yocto | 01:01 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has quit IRC | 01:02 | |
| *** camus is now known as kaspter | 01:02 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:44 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 01:49 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 02:10 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto | 02:10 | |
| aehs29 | RP: This 4cb1b4b just caused a 0% match 0% complete on sstate :) | 03:45 |
|---|---|---|
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 05:50 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 06:06 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:25 | |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 06:26 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:33 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:07 | |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto | 07:19 | |
| PinkSnake | 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 :( | 07:22 |
| *** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has joined #yocto | 07:24 | |
| LetoThe2nd | 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. | 07:27 |
| PinkSnake | LetoThe2nd i think you are right and it's linked to https://github.com/opencv/opencv/commit/094615b2c56f31e3a1a0d42799c802ebd7dca383#diff-40c9b23a9a22bcb03bc88589672a45ea | 07:29 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:29 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:b42c:b319:e9dc:c823> has joined #yocto | 07:29 | |
| *** stuom146 <stuom146!3eecd81d@62.236.216.29> has joined #yocto | 07:29 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:30 | |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto | 07:31 | |
| *** stuom146 <stuom146!3eecd81d@62.236.216.29> has quit IRC | 07:37 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 07:52 | |
| *** mckoan|away is now known as mckoan | 08:00 | |
| mckoan | good morning | 08:00 |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 08:03 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 08:06 | |
| LetoThe2nd | morning mckoan | 08:06 |
| stuom1 | anybody know why 2020 irc logs are not available or when will they be? | 08:08 |
| mckoan | LetoThe2nd: Happy new year | 08:08 |
| LetoThe2nd | mckoan: hehe thanks. | 08:08 |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:13 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:47 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC | 08:48 | |
| *** jij <jij!jonashg@nat/axis/x-xlzlevzpfxtviawf> has quit IRC | 08:51 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 08:52 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:53 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 09:01 | |
| *** Saur <Saur!pkj@nat/axis/x-bwwikyarrgvxumpg> has joined #yocto | 09:02 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has joined #yocto | 09:06 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has quit IRC | 09:08 | |
| RP | aehs29: yes, soon back to normal though :) | 09:10 |
| *** jij <jij!jonashg@nat/axis/x-sbamqywmwxoanajm> has joined #yocto | 09:11 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has joined #yocto | 09:13 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 09:18 | |
| aehs29 | RP: tell that to my CI setup haha | 09:25 |
| aehs29 | RP: no actually it was good, I didnt know my plan B wasnt working so its good that Im aware of that now | 09:26 |
| aehs29 | RP: btw, why is the AB not populating sstate.yp.org? | 09:28 |
| RP | aehs29: it should be... | 09:31 |
| aehs29 | it says it was last update on 12-Dec-2019 17:35 | 09:36 |
| aehs29 | updated* | 09:36 |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto | 09:52 | |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto | 10:00 | |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has quit IRC | 10:05 | |
| RP | aehs29: hmm, I wonder if that is just misleading :/ | 10:19 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has quit IRC | 10:23 | |
| *** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC | 10:29 | |
| *** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has quit IRC | 10:30 | |
| *** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto | 10:32 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 10:36 | |
| Saur | 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 | 11:03 |
| Saur | ecipes, it went back to normal. | 11:03 |
| Saur | RP: I am wondering if it has to do with the almost constantly running "Checking sstate mirror object availability" task. | 11:05 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 11:22 | |
| *** falkb <falkb!91fdde45@145.253.222.69> has joined #yocto | 11:25 | |
| falkb | 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? | 11:29 |
| LetoThe2nd | falkb: tahts probably more like kernelversion/-configuration related than yocto specific | 11:30 |
| LetoThe2nd | because 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 |
| falkb | I'm programming with yocto linux and suspected it's a missing feature there | 11:30 |
| LetoThe2nd | i don't think yocto "misses a feature" there, its rather the kernel you use. | 11:31 |
| LetoThe2nd | have you inspected /proc/config.gz to see if the v4l stuff is actually enabled? | 11:31 |
| LetoThe2nd | 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 | 11:42 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:43 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:46 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:47 | |
| *** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has joined #yocto | 11:57 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 11:57 | |
| falkb | 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 | 11:57 |
| wertigon | falkb: Remember that Yocto Linux does not cover every conceivable use case and some kernel options are disabled by default. | 12:06 |
| wertigon | Though that might not be the issue here :) | 12:06 |
| RP | Saur: we have performance problems in the task migration code | 12:06 |
| RP | Saur: it could be the sstate mirror checks if those are slow but the code itself is also slow | 12:07 |
| perdmann | Hi, i plan to use a parallel NAND memory. Is there a list which devices have good support? | 12:16 |
| LetoThe2nd | perdmann: kernel support applies :) | 12:19 |
| perdmann | is kernel and uboot support equal? | 12:22 |
| LetoThe2nd | nope | 12:22 |
| perdmann | i 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 |
| LetoThe2nd | perdmann: if in doubt, look at the eval kit of your desired SoC and just use whats there :) | 12:23 |
| LetoThe2nd | falkb: have fun. | 12:23 |
| perdmann | haha . Thats exactly what the NXP guy told me... | 12:23 |
| LetoThe2nd | perdmann: see, and i'm not even working for nxp. | 12:24 |
| perdmann | you should ask them for your salary ;) Anyway... really annoying to search for the "correct" memory | 12:25 |
| LetoThe2nd | perdmann: its just basically like this: "if you have to ask, then don't do any experiments"" | 12:27 |
| *** falkb65 <falkb65!91fdde45@145.253.222.69> has joined #yocto | 12:32 | |
| falkb65 | perdmann: Which SoC do you use? | 12:32 |
| *** falkb <falkb!91fdde45@145.253.222.69> has quit IRC | 12:32 | |
| LetoThe2nd | imx6 | 12:33 |
| LetoThe2nd | *badum-tsh* | 12:33 |
| falkb65 | 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 | 12:34 |
| LetoThe2nd | for raw nand flasch you always have to use a controller AFAIK | 12:35 |
| Ad0 | hm "package packagegroup-core-ssh-dropbear-1.0-r1.all requires dropbear, but none of the providers can be installed | 12:36 |
| Ad0 | " | 12:36 |
| Ad0 | IMAGE_FEATURES += "ssh-server-dropbear" | 12:36 |
| Ad0 | I do this in my image recipe | 12:37 |
| *** falkb65 is now known as falkb | 12:37 | |
| Ad0 | is it in conflict with packagegroup-core-boot ? | 12:38 |
| LetoThe2nd | Ad0: 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 IRC | 12:38 | |
| Ad0 | ok LetoThe2nd | 12:38 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 12:38 | |
| perdmann | @falkb65 imx6 | 12:38 |
| LetoThe2nd | Ad0: 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 |
| LetoThe2nd | falkb: *badum-tsh* | 12:39 |
| *** jij <jij!jonashg@nat/axis/x-sbamqywmwxoanajm> has quit IRC | 12:39 | |
| Ad0 | LetoThe2nd, https://pastebin.com/xQrbGPtm | 12:40 |
| creich | 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 | 12:40 |
| creich | i tried to verify the nfs server setup by mounting the share from my local machine, which works so far | 12:41 |
| creich | 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 ' | 12:41 |
| creich | but that occurs several times in a row, till the kernel stops trying | 12:42 |
| *** jij <jij!jonashg@nat/axis/x-uqohogmlgpgvxjqp> has joined #yocto | 12:42 | |
| creich | any ideas what else to check? | 12:42 |
| LetoThe2nd | Ad0: 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 IRC | 12:43 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 12:43 | |
| Ad0 | LetoThe2nd, you mean machine_features and so on ? | 12:44 |
| LetoThe2nd | Ad0: i mean like, what did you all add in order to break it? :) | 12:44 |
| Ad0 | hehe | 12:44 |
| Ad0 | I can post the image recipe | 12:44 |
| LetoThe2nd | Ad0: have you maybe removed poky/meta? | 12:44 |
| Ad0 | no it's all there | 12:45 |
| Ad0 | it works without exactly dropbear | 12:45 |
| Ad0 | maybe I have included conflicting stuff that prevents it ? | 12:45 |
| LetoThe2nd | Ad0: openssh conflicts. | 12:45 |
| Ad0 | I add those packages listed in the paste there , and I inherit core-image | 12:46 |
| falkb | perdmann: Which parallel driver do you mean? Do you have a web page about that? | 12:47 |
| LetoThe2nd | Ad0: what happens if you build that image for a standard qemu? | 12:48 |
| Ad0 | then what happens is that I have to wait forever :D | 12: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-scripts | 12:48 |
| Ad0 | that's the stuff I install in the image | 12:48 |
| LetoThe2nd | again, i don't think the image is the problem | 12:49 |
| Ad0 | ok. my distro inherits from MENDER_FULL which is a bunch of stuff as well. | 12:49 |
| Ad0 | err mender-full. | 12:50 |
| Ad0 | I don't think it's that either, just a feeling :) | 12:51 |
| LetoThe2nd | swap poky in and find out :) | 12:51 |
| Ad0 | would openssl-bin create a conflic? | 12:51 |
| Ad0 | poky instead of what? | 12:51 |
| LetoThe2nd | instead of your distro | 12:51 |
| Ad0 | right | 12:51 |
| Ad0 | hm | 12:54 |
| Ad0 | DISTRO 'poky' not found. Please set a valid DISTRO in your local.conf | 12:54 |
| LetoThe2nd | something is really broken in your bblayers.conf | 12:54 |
| Ad0 | yes | 12:55 |
| Ad0 | https://pastebin.com/Ujcyvxrk | 12:56 |
| LetoThe2nd | so for the distro case, meta-poky is missing | 12:57 |
| Ad0 | yeah I didn't need that for my own distro right? | 12:57 |
| rburton | right meta-poky isn't required unless you're using poky | 12:57 |
| Saur | RP: Any hopes of improving the performance? Or you are still working on solving all the corner cases? | 12:57 |
| RP | Saur: There are local patches which help but also create new bugs | 12:58 |
| LetoThe2nd | RP: surely correct, but obviously the own distro as issues :) | 12:58 |
| RP | Saur: I spent most of my "vacation" trying to fix this stuff :( | 12:58 |
| Ad0 | alright running again | 12:59 |
| RP | 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 | 12:59 |
| Saur | 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... | 13:00 |
| RP | Saur: Its like comparing apples and oranges. Enabling hashequiv adds new codepaths and they are slow | 13:01 |
| RP | 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 | 13:01 |
| RP | It is slower but the reasons are complex :( | 13:02 |
| RP | well, depends what reuse you get | 13:02 |
| Ad0 | 0: openssl-native-1.1.1b-r0 do_install - 21s (pid 7883) | 13:02 |
| Ad0 | - why does it bother when I asked for dropbear | 13:02 |
| Ad0 | oh sorry my mistake | 13:02 |
| LetoThe2nd | Ad0: ssl != ssh | 13:02 |
| Ad0 | I thought it said "ssh" haha. | 13:03 |
| RP | native != target too | 13:03 |
| Ad0 | that's what happens when you look too long on the same thing | 13:03 |
| Ad0 | it seems to want to recompile everything | 13:03 |
| Saur | 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? | 13:03 |
| Ad0 | there goes the rest of my day I guess! | 13:04 |
| RP | Saur: correctness needs to come first. I think some speedup is possible | 13:04 |
| *** falkb <falkb!91fdde45@145.253.222.69> has left #yocto | 13:05 | |
| RP | Ad0: time to make the case to management for decent build resources? ;-) | 13:05 |
| Ad0 | yes | 13:05 |
| Ad0 | I will order an SSD | 13:05 |
| RP | or get some time to work on performance? :) | 13:06 |
| * RP feels lonely on that battle | 13:06 | |
| Ad0 | 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 | 13:06 |
| RP | "lets add all these features" "but they make X slower" "but new features, we need features" | 13:06 |
| RP | Ad0: that is impressive :/ | 13:07 |
| Ad0 | haha | 13:07 |
| Ad0 | I tried to build on azure VM with "decent" specs like "premium SSD" enough RAM etc, but it ran just as slow | 13:07 |
| RP | Ad0: dedicated build hardware, old school without VMs and overhead ;-) | 13:07 |
| Saur | RP: Wish I could help you more there, but I am still not fluent in the bitbake core... | 13:08 |
| Ad0 | RP, amen :) | 13:08 |
| RP | Saur: best way to learn may be to pick a performance glitch and debug it and figure out how to improve | 13:08 |
| Saur | 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... | 13:10 |
| Saur | 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 | 13:18 |
| Saur | rting bitbake... | 13:18 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 13:21 | |
| RP | 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 | 13:22 |
| RP | Saur: at least in theory if the overhead is inotify, we don't need to do that again | 13:22 |
| RP | Saur: so it should be faster | 13:22 |
| Ad0 | RP, what linux distro are you running :) | 13:23 |
| Ad0 | or are you running something else perhaps? | 13:23 |
| Saur | RP: 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 |
| RP | 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 | 13:23 |
| RP | Ad0: build server has ubuntu on it | 13:24 |
| Ad0 | kk | 13:24 |
| RP | Saur: It was thought we'd switch to memres and do we want multiple different codepaths to maintain/test? | 13:24 |
| RP | Saur: history says multiple paths leads to problems | 13:25 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 13:27 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:31 | |
| Saur | 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. | 13:36 |
| yocti | Bug 13699: normal, Medium+, 3.2, richard.purdie, NEW , Prolonged recipe parsing times after removing tmp when the resident bitbake server is used | 13:36 |
| Saur | (Oops, late for a meeting, back in half an hour.) | 13:37 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 13:37 | |
| RP | Saur: definitely looks significant... | 13:38 |
| zeddii | 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. | 13:42 |
| RP | zeddii: well done on finding a fix! | 13:43 |
| RP | zeddii: shame about upstream :( | 13:43 |
| zeddii | 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. | 13:44 |
| zeddii | I will come back to it again and write it up .. but I need to move on the recipes first. | 13:45 |
| perdmann | and rauc is also not working :) | 13:45 |
| yocti | New 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 IRC | 13:48 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 13:51 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:58 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 14:02 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:07 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 14:12 | |
| tgamblin | 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? | 14:24 |
| RP | tgamblin: "layer index" ? | 14:25 |
| tgamblin | RP: well, what the current version tied to a recipe should be, e.g. libical 3.0.6 | 14:25 |
| RP | tgamblin: "layer index" usually means layers.openembedded.org | 14:26 |
| *** ericch <ericch!~ericch@172.58.231.251> has joined #yocto | 14:26 | |
| RP | tgamblin: but the answer is no | 14:26 |
| RP | 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? | 14:27 |
| RP | tgamblin: I know there was one to work around it | 14:27 |
| RP | (that one is in -next) | 14:27 |
| * RP forgets where we were at with these patches | 14:27 | |
| tgamblin | 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 | 14:28 |
| tgamblin | 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 | 14:28 |
| RP | tgamblin: ok, just checking I didn't miss something. We seemed closer to a root cause | 14:29 |
| Saur | 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 | 14:30 |
| Saur | 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. | 14:30 |
| RP | Saur: I really don't want to have multiple codepaths for something like this though | 14:34 |
| Saur | 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... | 14:35 |
| Saur | 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? | 14:36 |
| RP | 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 | 14:36 |
| RP | Saur: the plan was to support memres in all cases and have it as the default | 14:37 |
| RP | 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 | 14:37 |
| Saur | 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? | 14:38 |
| RP | Saur: there should be a gain from it, all my testing suggests it should work | 14:38 |
| RP | Saur: there could well be some bug meaning that isn't realised at present, sure | 14:38 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 14:38 | |
| perdmann | is there a way to modify the build parameter (do_configure) in a recipe? | 14:40 |
| rburton | perdmann: recipe using autotools? | 14:47 |
| rburton | if so then EXTRA_OECONF as per https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-autotools | 14:48 |
| perdmann | actually i dont know what kind of buildsystem rauc is using | 14:53 |
| perdmann | i have to dig into it :D | 14:53 |
| rburton | the recipe will inherit a class, or hand-write its own do_configure | 14:53 |
| rburton | https://layers.openembedded.org/layerindex/recipe/75303/ says autotools | 14:54 |
| rburton | so EXTRA_OECONF | 14:54 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 14:54 | |
| perdmann | thanks | 14:57 |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 14:59 | |
| perdmann | oh maybe its another issue | 15:02 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 15:03 | |
| *** berton_ <berton_!~berton@189.103.49.163> has joined #yocto | 15:04 | |
| perdmann | Ok i see. I can add dbus or i can disable dbus support in rauc | 15:05 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 15:06 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 15:06 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 15:07 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:09 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 15:28 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 15:31 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 15:36 | |
| Saur | 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 | 15:36 |
| Saur | I 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 #yocto | 15:46 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:b42c:b319:e9dc:c823> has quit IRC | 15:54 | |
| armpit | YPTM - waiting for it to start | 15:57 |
| armpit | YPTM- armin is on | 15:58 |
| RP | Saur: sounds like there is something broken :( | 15:59 |
| Saur | RP: Yupp. I'm investigating it now... | 15:59 |
| tlwoerner | YPTM: tlwoerner is on | 16:01 |
| vmeson | YPTM: Randy MacLeod joined. | 16:02 |
| *** griffinp <griffinp!griffinp@gateway/shell/linaro/x-sqrpkvipgserevmq> has quit IRC | 16:04 | |
| rburton | oh tech call | 16:05 |
| *** sgw <sgw!~sgw@192.55.55.39> has joined #yocto | 16:07 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:16 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 16:16 | |
| *** ericch <ericch!~ericch@172.58.231.251> has quit IRC | 16:17 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:18 | |
| *** adelcast <adelcast!~adelcast@130.164.62.221> has left #yocto | 16:20 | |
| *** adelcast <adelcast!~adelcast@130.164.62.221> has joined #yocto | 16:21 | |
| vmeson | paul barker: Sandy is: Changqing Li <changqing.li@windriver.com> | 16:25 |
| * vmeson wonders what paul's /nick is... | 16:26 | |
| zeddii | vmeson: paulbarker | 16:26 |
| tlwoerner | vmeson: paulbarker | 16:26 |
| tlwoerner | oops | 16:26 |
| zeddii | quite the decoder ring I have :D | 16:26 |
| vmeson | huh, I did try tab completion... oh well. | 16:26 |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 16:26 | |
| rburton | need to drop, got another call | 16:30 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 16:33 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 16:34 | |
| tlwoerner | https://lwn.net/Articles/788626/ | 16:35 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 16:36 | |
| *** orzen <orzen!~orz@84-216-106-29.customers.ownit.se> has quit IRC | 16:38 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 16:42 | |
| *** jwwww <jwwww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has quit IRC | 16:44 | |
| dreyna | YPTM minutes: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4 | 16:48 |
| RP | tlwoerner: no, https://lwn.net/Articles/804640/ ! :) | 16:50 |
| * qschulz bookmarks this | 16:54 | |
| armpit | thanks David | 16:58 |
| *** jwwww <jwwww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto | 16:59 | |
| *** orzen <orzen!~orz@84-216-106-29.customers.ownit.se> has joined #yocto | 17:09 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 17:18 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 17:23 | |
| *** mckoan is now known as mckoan|away | 17:25 | |
| *** sgw <sgw!~sgw@192.55.55.39> has quit IRC | 17:39 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 17:41 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 17:50 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:52 | |
| RP | 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 | 18:00 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 18:00 | |
| JPEW | RP: It's fine for now. I think we'd want a dedicated table column for it in the long run | 18:02 |
| JPEW | 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 | 18:03 |
| JPEW | RP: Either way, proving it works is probably more important at this point :) | 18:03 |
| Saur | 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 | 18:04 |
| Saur | is run, the modified sanity_info file from the last run triggers a new parsing... | 18:04 |
| RP | JPEW: that was my thinking... | 18:04 |
| Saur | two improvements* | 18:04 |
| RP | Saur: that sounds like a nice improvement, looking forward to that patch! | 18:05 |
| Saur | RP: Working on it. ;) | 18:05 |
| RP | Saur: I'd hoped it might be something "simple" | 18:06 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 18:07 | |
| Saur | RP: Seems like it was. :) | 18:07 |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 18:08 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:24ce:b2a3:bac9:47a9> has quit IRC | 18:10 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 18:10 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:fda8:efcd:67f0:45fb> has joined #yocto | 18:12 | |
| JaMa | 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)? | 18:16 |
| JaMa | or was it always 3 already released branches? | 18:16 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:fda8:efcd:67f0:45fb> has quit IRC | 18:17 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 18:18 | |
| RP | 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... | 18:25 |
| JaMa | the LTS policy? | 18:28 |
| RP | JaMa: its not just LTS | 18:29 |
| JaMa | I'm sorry I don't know what published policy you're talking about, I'll re-check the archives | 18:30 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 18:31 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 18:31 | |
| RP | JaMa: Its the LTS wiki page but it applies to all stable releases in reality | 18: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@192.55.55.43> has joined #yocto | 18:37 | |
| RP | JaMa: under the new policy, yes. I think we probably carry warrior until the next release to have the policy overlap resolved | 18:38 |
| RP | things are never simple :/ | 18:38 |
| JaMa | ok, and the old policy was 2 stable release + master or 3 released releases + master? | 18:42 |
| JaMa | 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 | 18:45 |
| khem | 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 | 18:54 |
| rburton | JaMa: finally had a play with a 2019 LG webOS TV last week. They're nice, good work :) | 18:55 |
| rburton | when our 10 year old sony dies i'll definitely get a LG | 18:56 |
| rburton | unfortunately it isn't showing any signs of dying | 18:56 |
| rburton | need to get the kids to play the wii again | 18:56 |
| * JaMa bought his first own personal TV for christmas and it was also a LG :) | 18:59 | |
| khem | quite expensive way to get hands on webos :) | 19:00 |
| JaMa | The Expanse from Amazon Video looks nice on it :) | 19:00 |
| khem | JaMa: is UI based on qt5 ? or is it fully chromium'ised | 19:01 |
| JaMa | both is available, most webapps are written in Enact and run on chromium based webruntime | 19:02 |
| khem | is enact some js art ? | 19:04 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 19:07 | |
| khem | ah react based and there is enyo which is js based directly | 19:08 |
| JaMa | enyojs apps are being migrated to enactjs (https://enactjs.com/docs/developer-guide/migration/migrating-enyo-apps/) | 19:14 |
| khem | I see, enyo is then being deprecated ? | 19:16 |
| *** rangergord <rangergord!~rangergor@modemcable186.198-70-69.static.videotron.ca> has quit IRC | 19:17 | |
| *** rangergord <rangergord!~rangergor@modemcable186.198-70-69.static.videotron.ca> has joined #yocto | 19:20 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 19:27 | |
| Saur | RP: There, two patches on the way to improve the performance during startup of bitbake. :) | 19:34 |
| Saur | 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). | 19:38 |
| RP | Saur: That sounds like a great improvement. I wonder why the difference with zeus too | 19:41 |
| Saur | RP: You mean Zeus -> master? Yeah, haven't looked into that yet... | 19:41 |
| khem | RP: are there some iterator function introduced in master in this area ? that could slow down sets | 19:43 |
| RP | Saur: it would probably be worth looking into | 19:43 |
| khem | iterating over contents of sets is usually slower than lists | 19:44 |
| RP | khem: we haven;t change much afaik | 19:44 |
| khem | master is 60s and zeus is 45 to 50s there is general slow down perhaps in different area | 19:47 |
| khem | which is added as it is | 19:47 |
| khem | then the numbers looks ok | 19:48 |
| khem | meaning this offset of 10-15 secs is there without the patches as well | 19:48 |
| RP | khem: right, there look to be multiple issues | 19:49 |
| JaMa | khem: yes I think so | 19:54 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:08 | |
| Saur | 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. :( | 20:12 |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 20:15 | |
| RP | Saur: can it be narrowed to some specific layer I wonder? | 20:26 |
| Saur | RP: I'm currently doing some tests with (some of) the OpenEmbedded layers added as well. | 20:27 |
| RP | Saur: cool, makes sense. These things can be "fun" to track down like this :/ | 20:28 |
| Saur | 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... | 20:30 |
| Saur | Ok, with the patches applied the times are down to ~5.5 s with both zeus-22.0.0 and master... | 20:34 |
| Saur | 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... | 20:41 |
| Saur | Hmm, scratch that. The result wasn't repeatable. :P | 20:45 |
| armpit | RP, my display name in groups.io is Armpit | 20:48 |
| armpit | that is why its being sent out that way | 20:48 |
| khem | JaMa: I opened another pull, for one more patch to qt5-creator fix on musl/x86 | 20:49 |
| RP | armpit: ok, fair enough. You just seemed surprised :) | 20:49 |
| RP | Saur: one downside to your second patch is encoding OE knowledge into bitbake :( | 20:53 |
| Saur | RP: Oh, sorry, didn't think of that. | 20:53 |
| RP | Saur: May be hard to generalise though :/ | 20:53 |
| *** camus <camus!~Instantbi@222.67.188.181> has joined #yocto | 20:55 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 20:56 | |
| *** camus is now known as kaspter | 20:56 | |
| Saur | 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. | 20:59 |
| *** d_thomas <d_thomas!d074ab12@208.116.171.18> has joined #yocto | 21:00 | |
| * armpit changed display name | 21:01 | |
| armpit | RP, 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 IRC | 21:03 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 21:03 | |
| RP | Saur: yes, moving it could be an option | 21:03 |
| RP | armpit: if we're not planning to take it, it should be dropped... | 21:04 |
| Saur | RP: 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 |
| RP | Saur: if you could take a look that would be good | 21:04 |
| RP | Saur: I like the idea in principle, hadn;t thought of that... | 21:04 |
| RP | Saur: moving is fine, just means some checks will rerun which is fine | 21:05 |
| *** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto | 21:07 | |
| d_thomas | 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 | 21:07 |
| d_thomas | 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! | 21:07 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 21:08 | |
| ecdhe | 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. | 21:09 |
| ecdhe | 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. | 21:10 |
| d_thomas | Unfortunately the error is "unable to handle kernel paging request at virtual address fffffffe" and the trace is just a hex dump. | 21:10 |
| ecdhe | Ahh, I've had a few of those. | 21:10 |
| Saur | 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. | 21:11 |
| d_thomas | 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 | 21:11 |
| d_thomas | So I should be more clear, if I could translate "function entered at [<c04b2c44>] from [<c04b5948>]", I might have something useful | 21:12 |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 21:15 | |
| RP | d_thomas: the kernel symbol table may help with that? | 21:16 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.250.39> has joined #yocto | 21:18 | |
| RP | d_thomas: (System.map file) | 21:18 |
| d_thomas | RP: Would that be hanging around in the build somewhere? | 21:18 |
| RP | d_thomas: yes, kernel build directory and its packaged somewhere too | 21:19 |
| * RP hasn't a build handy | 21:19 | |
| * RP is also going from rusty years old memories | 21:20 | |
| RP | d_thomas: ksymoops is a script which can do the translations of an oops for you based on the files like System.map iirc | 21:21 |
| d_thomas | 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 | 21:21 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 21:22 | |
| RP | d_thomas: with the offset you could get there with disassembly from objdump I guess | 21:23 |
| RP | function is a good start :) | 21:23 |
| *** berton_ <berton_!~berton@189.103.49.163> has quit IRC | 21:23 | |
| d_thomas | 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! | 21:24 |
| *** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has quit IRC | 21:37 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 21:40 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.250.39> has quit IRC | 21:42 | |
| *** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has quit IRC | 21:46 | |
| *** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has joined #yocto | 21:46 | |
| *** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC | 21:47 | |
| *** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto | 21:48 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:55 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 22:08 | |
| d_thomas | RP, I wasn't able to get ksymoops to build. Trying to figure out a plan B with objdump | 22:11 |
| Saur | 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. | 22:12 |
| RP | Saur: did you find a problem with other .lock or .log files? | 22:17 |
| Saur | RP: We have some .lock files in one of our layers that caused unnecessary notifications. | 22:18 |
| RP | Saur: I'm a little worried someone might put a .log or .lock file in SRC_URI :/ | 22:19 |
| RP | You really shouldn't be writing into layer directories... | 22:19 |
| Saur | 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... | 22:21 |
| Saur | ... that probably shouldn't be watched... | 22:21 |
| RP | Saur: right, it shouldn't be watching that | 22:22 |
| RP | Saur: I'd really like to understand why it is and fix that if we can | 22:23 |
| RP | Saur: I'm not trying to be awkward btw, I just want to ensure we fix the real problems | 22:23 |
| RP | Saur: Your looking into this is *much* appreciated | 22:23 |
| roussinm | Is it possible to use devtool with tarballs? Doesn't seems like it... | 22:26 |
| Saur | 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. | 22:27 |
| Saur | 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.) | 22:28 |
| *** d_thomas <d_thomas!d074ab12@208.116.171.18> has quit IRC | 22:31 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:34 | |
| Saur | 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. | 22:36 |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 22:38 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:46 | |
| Saur | 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. | 22:55 |
| *** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto | 22:56 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:05 | |
| RP | Saur: I think I would do that somewhere else more isolated as changes there will have other ways of catching you out | 23:06 |
| *** cpo <cpo!~cpo@helix.mybll.net> has quit IRC | 23:06 | |
| RP | Saur: ah, great, now I read the last line :) | 23:06 |
| Saur | :) | 23:06 |
| *** cpo <cpo!~cpo@helix.mybll.net> has joined #yocto | 23:06 | |
| Saur | cd - | 23:08 |
| *** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 23:41 | |
| *** kreyren[m] <kreyren[m]!~kreyrenm]@ip-86-49-115-152.net.upcbroadband.cz> has quit IRC | 23:42 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 23:44 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 23:46 | |
| *** kreyren[m] <kreyren[m]!~kreyrenm]@ip-86-49-115-152.net.upcbroadband.cz> has joined #yocto | 23:46 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-104-162-194-186.nyc.res.rr.com> has quit IRC | 23:53 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!