| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 00:02 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:49 | |
| *** nerdboy <nerdboy!~sarnold@47.143.129.109> has joined #yocto | 00:50 | |
| *** nerdboy <nerdboy!~sarnold@47.143.129.109> has quit IRC | 00:58 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 00:58 | |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 01:01 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 01:54 | |
| *** radsquirrel <radsquirrel!~radsquirr@173-167-31-198-michigan.hfc.comcastbusiness.net> has joined #yocto | 02:11 | |
| *** radsquirrel <radsquirrel!~radsquirr@173-167-31-198-michigan.hfc.comcastbusiness.net> has quit IRC | 02:47 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 02:50 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:00 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 03:27 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 03:29 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-064.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 04:34 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC | 05:32 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 05:33 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 05:39 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:44 | |
| *** zangman <zangman!7458c728@116.88.199.40> has joined #yocto | 05:45 | |
| zangman | I am really confused about how package management works with Yocto. If I set PACKAGE_CLASSES = "package_deb" and then do a 'bitbake core-image-full-cmdline', it doesn't auto populate the repository sources | 05:47 |
|---|---|---|
| zangman | It's the same problem with package_ipkg | 05:47 |
| zangman | I don't want to set up a package repo myself, can I not have this set to whatever repository is used at the time of build? | 05:48 |
| zangman | Also to clarify, I'm building this for the de10-nano-soc, and using the meta-altera layer - https://github.com/kraj/meta-altera | 05:49 |
| kergoth | there's a package-index recipe you can build if you want a feed. the feed used to build images isn't meant for external consumption. | 05:50 |
| erbo | zangman: I guess that's "by design", it's not supposed to set up a package feed unless you explicitly tell it to since you need to be careful when using feeds to not mess up. | 05:50 |
| kergoth | indeed :) | 05:50 |
| zangman | Ah I see - are there publicly available feeds I can set up for such purposes? Does the package-index recipe include these? | 05:51 |
| erbo | zangman: You can find some details here if you just want something quick for development: https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed | 05:51 |
| zangman | @erbo: Thank you, I've gone through the page, I tried copying the same thing for deb and used the official debian repository, but it doesn't populate it correctly in sources.list: http://deb.debian.org/debian/ | 05:53 |
| zangman | Even after I correct it after booting the device, it still doesn't work saying error with the signature yada yada | 05:54 |
| zangman | fix the signature issue, then it dies with a cryptic error | 05:54 |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 05:54 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 06:03 | |
| erbo | zangman: just so I understand correctly, did you try to use the original debian repo? Or did you use it as a template to create a source pointing to your own repo? | 06:04 |
| zangman | erbo: I tried to use the original debian repo. Basically booted up Yocto on my SoC device, copied debian repo URLs from my desktop debian and pasted them in the Yocto build | 06:06 |
| erbo | zangman: you can't use debian repos, that will never work. Those packages are built for debian systems | 06:07 |
| zangman | erbo: But I checked the debian repo, they do have an armhf repository. My device uses an armv7hf | 06:08 |
| zangman | erbo: I assumed it would sort of work :| | 06:08 |
| erbo | zangman: yes, but it's different distributions. Like you don't use rpms from Fedora in other rpm based distros. | 06:08 |
| zangman | erbo: Ah - so package_deb is not sufficient to make it a debian based distro | 06:09 |
| zangman | so the approach listed on the tips and tricks page is a way for me to fetch all the packages that I want to make available to my device and upload them to my own server? | 06:10 |
| zangman | i.e. bitbake package-index | 06:10 |
| *** zangman <zangman!7458c728@116.88.199.40> has quit IRC | 06:11 | |
| *** zangman <zangman!7458c728@116.88.199.40> has joined #yocto | 06:11 | |
| erbo | zangman: yes. that approach creates a repo containing all the .deb created in your yocto build | 06:12 |
| zangman | erbo: How does it handle package updates? For example, if there's a new version of vim, I would have to ... | 06:14 |
| zangman | erbo: run `bitbake package-index`, upload the package to my server, and then run apt-get update on my device? | 06:15 |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 06:16 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:18 | |
| erbo | zangman: I haven't used package feeds for anything other than quick n dirty dev work. But you'll need to use a PR-server to ensure that package versions keep increasing etc in order to get updates to work | 06:28 |
| erbo | zangman: https://wiki.yoctoproject.org/wiki/PR_Service | 06:28 |
| *** simonpe^1 <simonpe^1!~starlord@c80-217-45-68.bredband.comhem.se> has joined #yocto | 06:28 | |
| simonpe^1 | Hey! It's me again, the dude with the config fragments. I've switched from the meta-imx stuff to meta-freescale @ dunfell and the linux-fslc-imx kernel, I managed to get m | 06:29 |
| simonpe^1 | the meta-virtualization layer working by adding some weird kernel meta yocto-kernel-cache stuff to my kernel bbappend | 06:29 |
| simonpe^1 | but my custom fragments are still not applied | 06:30 |
| zangman | erbo: Talk about rabbit holes! But this is great, thank you - First, I will try and spin up my own package server at home to at least get that going and second, I will go through the PR_Service link and see if I need to set that up | 06:30 |
| zangman | erbo: Thank you so much, appreciate it! :) | 06:30 |
| *** mckoan|away is now known as mckoan | 06:32 | |
| simonpe^1 | I realize I have two irssi opened so I'm closing this one :S | 06:32 |
| *** simonpe^1 <simonpe^1!~starlord@c80-217-45-68.bredband.comhem.se> has quit IRC | 06:32 | |
| simonpe^^ | ^^ | 06:32 |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 06:33 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 06:47 | |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto | 06:50 | |
| *** fl0v0 <fl0v0!~fvo@i5E86934E.versanet.de> has joined #yocto | 06:55 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:02 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 07:09 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 07:13 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 07:28 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 07:31 | |
| *** zangman <zangman!7458c728@116.88.199.40> has quit IRC | 07:31 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 07:34 | |
| *** jkimblad <jkimblad!~jacob@h-161-8.A137.corp.bahnhof.se> has joined #yocto | 07:54 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.110> has joined #yocto | 08:02 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 08:06 | |
| *** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto | 08:08 | |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.184.176.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 08:11 | |
| simonpe^^ | what happened to u-boot-fw-utils? It seems to not exist anymore to me | 08:14 |
| qschulz | simonpe^^: libubootenv now :) | 08:16 |
| simonpe^^ | oh | 08:16 |
| simonpe^^ | also, what's the difference between the u-boot-fslc/u-boot-imx/u-boot variations of u-boot? | 08:18 |
| simonpe^^ | and which one is preferred | 08:18 |
| qschulz | simonpe^^: u-boot is the upstream one with potential patches for making it build for all archs with Yocto. u-boot-imx is probably the official NXP version, and u-boot-fslc a community based one? | 08:20 |
| simonpe^^ | so why would one pick the fslc over the upstream one? | 08:22 |
| qschulz | simonpe^^: not full support in upstream. Usually what happens for vendors is that they add support to a fixed version of u-boot as quickly as possible so they can start selling their HW | 08:23 |
| qschulz | **some** vendors then start upstreaming a few patches to upstream projects (it takes time) | 08:24 |
| qschulz | so, upstream might not work fully or have support for everything you need | 08:24 |
| qschulz | until it's taken from the vendor versions and put into upstream (vendor or community effort) | 08:24 |
| simonpe^^ | oh I see, so its vendor -> community -> upstream | 08:26 |
| simonpe^^ | so the best solution for me would be to try out the upstream one, if that doesn't work the community one, and if all else fails the vendor one? | 08:27 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 08:27 | |
| qschulz | simonpe^^: most of the time yes (while community can be clients of said vendor), very few vendors (NXP does it) upstream stuff directly and do not rely 100% on the community to do it | 08:27 |
| simonpe^^ | ok cool, thanks | 08:28 |
| qschulz | simonpe^^: yeah, especially for u-boot, if you don't need fancy stuff, go for upstream | 08:28 |
| qschulz | see if it works good enough for you | 08:28 |
| simonpe^^ | Imma need HAB eventually | 08:28 |
| qschulz | if not, it might just be a few patches you need from vendor | 08:28 |
| simonpe^^ | not sure if that's a factor | 08:28 |
| qschulz | simonpe^^: HAB is supported on imx6 for sure upstream | 08:28 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:28 | |
| qschulz | don't know for the other stuff | 08:28 |
| simonpe^^ | I'm on imx8 | 08:28 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 08:28 | |
| qschulz | simonpe^^: https://elixir.bootlin.com/u-boot/latest/source/doc/imx/habv4/introduction_habv4.txt | 08:30 |
| simonpe^^ | thanks, thats super helpful | 08:31 |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 08:34 | |
| *** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC | 08:37 | |
| *** awe003 <awe003!~awe00@unaffiliated/awe00> has joined #yocto | 09:00 | |
| *** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/matrix.org/x-lzboudtkbcgcoory> has quit IRC | 09:02 | |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 09:02 | |
| *** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-kgvtgkepcejrppsq> has quit IRC | 09:03 | |
| *** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-rnfvkeoknuxkrdar> has joined #yocto | 09:04 | |
| *** iamarobott <iamarobott!4d6ff777@77.111.247.119> has joined #yocto | 09:09 | |
| iamarobott | hello lovely people | 09:10 |
| iamarobott | how do I add a waveshare display or any other display to my build configuration? | 09:10 |
| iamarobott | i mean the drivers because I don't have lets say gcc on my target device and I don't want to build that | 09:11 |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.184.176.nat.umts.dynamic.t-mobile.pl> has quit IRC | 09:12 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 09:12 | |
| *** zand__ <zand__!~zandrey@193.8.40.126> has joined #yocto | 09:16 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:17 | |
| iamarobott | i know its monday but come on guys, tell me what I want to know and I'll get you the stuff xD | 09:20 |
| rburton | JaMa: re harfbuzz the easy fix is to just explictly build that target first in a do_compile_prepend, but i was trying to fix the meson build properly. of course the meson files are designed to be a clone of the autotools, instead of doing it properly for meson... | 09:20 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.110> has quit IRC | 09:20 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has joined #yocto | 09:25 | |
| *** iamarobott <iamarobott!4d6ff777@77.111.247.119> has quit IRC | 09:45 | |
| *** submux <submux!~submux@2a01:79c:cebd:fee8:8822:9716:c5bd:c1dd> has joined #yocto | 09:48 | |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-xhxgfqhhtbdbstpu> has joined #yocto | 10:01 | |
| *** marble_visions_ <marble_visions_!~user@68.183.79.8> has quit IRC | 10:21 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 10:23 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 10:24 | |
| *** micka_ <micka_!~micka@reverse-75.fdn.fr> has joined #yocto | 10:31 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 10:33 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 10:44 | |
| *** mbulut_ <mbulut_!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 10:57 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 10:58 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:58 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 11:06 | |
| fbre | Hi! A .bbappend file here has a line "include foo.inc". In foo.inc is a function do_configure_prepend() { echo "huhu" } but this is never called. Do you have an idea why? | 11:12 |
| fbre | Anyway I can't find such echo entry in the log files | 11:13 |
| RobertBerger | @fbre don't use echo, but bbwarn "--> huhu <--" | 11:18 |
| fbre | RobertBerger: Do I have to cleansstate after changing from echo to bbwarn? | 11:21 |
| RobertBerger | @fbre cleansstate is always a good idea ;) | 11:22 |
| RobertBerger | @iamarobott: What stuff and how much of it if I tell you what to read ;) | 11:22 |
| qschulz | fbre: no need for cleansstate as Yocto will know that your do_configure changed and need to be re-run | 11:24 |
| qschulz | fbre: if you need to use cleansstate => badly written recipe and fixes are needed | 11:24 |
| simonpe^^ | there should be a shellcheck for bitbake files | 11:25 |
| qschulz | fbre: though, cleaning sstate-cache is heavily recommended before releasing software to make sure you're not based on some broken behavior/sstate-cache | 11:25 |
| fbre | I wonder where I should actually see that bbwarn output, I mean, In which logfile should I see it? | 11:25 |
| qschulz | fbre: shake with bitbake-layers show-appends that your bbappends is found | 11:25 |
| qschulz | fbre: s/shake/check /me facepalms | 11:25 |
| RobertBerger | @fbre you should see it on the terminal as well | 11:26 |
| RP | RobertBerger: cleansstate is not a good idea and I wish people would stop saying it was | 11:27 |
| qschulz | I'm back with some devshell question again :) is there any difference between executing run.do_task scripts with and without devshell? | 11:29 |
| RP | qschulz: pseudo? | 11:31 |
| RobertBerger | @RP: Then you have to make sure all recipes in all layers are written in way that it's not needed anymore ;) - Which is certainly not the case at the moment. | 11:32 |
| *** luneff <luneff!~yury@80.72.17.178> has joined #yocto | 11:33 | |
| luneff | when I do "devtool modify linux-raspberrypi" the resulting source tree does not contain patches applied from my .bbappend. Is that ok? | 11:34 |
| RP | RobertBerger: people should be highlighting those broken layers then | 11:35 |
| RobertBerger | @RP - poky ;) | 11:36 |
| RP | RobertBerger: what exactly breaks in poky? | 11:36 |
| qschulz | luneff: no. Have you checked with bitbake-layers show-appends that Yocto can find your bbappend? | 11:36 |
| luneff | haven't looked before. yes, it includes my bbappend. And when I do full image build, it's ok | 11:37 |
| fbre | hmm... there is not output of bbwarn for do_configure_prepend. Which logfile should contain that? | 11:38 |
| RP | fbre: the do_configure task log | 11:38 |
| qschulz | fbre: even your console should have it. check with bitbake-layers show-appends that your bbappend is found by Yocto | 11:38 |
| *** micka_ <micka_!~micka@reverse-75.fdn.fr> has quit IRC | 11:39 | |
| RobertBerger | @RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11403 - In this specific one it's an SSTATE server, but if you don't cleansstate you will not have kernel sources and it's not going to build | 11:39 |
| fbre | no such logging there | 11:40 |
| RobertBerger | @RP and it's from 2017! - Not a bug! | 11:41 |
| fbre | though do_configure_append() does log | 11:41 |
| luneff | "INFO: SRC_URI contains some conditional appends/prepends - will create branches to represent these" | 11:41 |
| qschulz | fbre: one more time... check with bitbake-layers show-appends that your bbappend is found by Yocto | 11:41 |
| *** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 11:42 | |
| RP | RobertBerger: that is really a workflow problem, the tools are using files which need to be built and aren't tracked by sstate | 11:42 |
| RP | RobertBerger: telling everyone sstate is broken because of that usecase is insane :( | 11:42 |
| RobertBerger | @RP I'm not saying SSTATE is broken. | 11:43 |
| RP | RobertBerger: by telling everyone to always run cleansstate, you are | 11:44 |
| RobertBerger | I am also not saying to always run cleansstate. | 11:44 |
| qschulz | luneff: :/ I had weird things with SRC_URI_append_<machine> as well with devtool. Probably worth sharing something with bluelightning when he's here (or by mail), I should probably do the same | 11:45 |
| RobertBerger | I am saying that if things are not working as expected it might be a good idea to run it - at least for me it helps sometimes. | 11:45 |
| RP | RobertBerger: "(12:22:11) RobertBerger: @fbre cleansstate is always a good idea ;)" | 11:45 |
| fbre | linux-fslc_5.4.bb (skipped): | 11:45 |
| fbre | ........../recipes-kernel/linux/linux-fslc_5.4.bbappend | 11:45 |
| qschulz | fbre: linux-fslc_5.4.bb (skipped): ***skipped*** <= !!!!! | 11:45 |
| RobertBerger | Let me rephrase that: "If you don't see the output of a bbwarn, you might try to run cleansstate" | 11:46 |
| qschulz | fbre: are you building the correct machine? are you building the correct distro? are you building the correct kernel? | 11:46 |
| RP | RobertBerger: I'd much rather people used the --no-setscene type options for example to avoid the corner case you linked to | 11:46 |
| RobertBerger | Well then this should be also documented as such somewhere plus where it should be used. | 11:49 |
| RobertBerger | BTW currently I have another interesting issue with DEPENDS vs. [depends] which went magically away ;) | 11:50 |
| RobertBerger | Just as I came up with an explanation why DEPENDS does not work for what I want it, I can't reproduce the problem. | 11:50 |
| fbre | RobertBerger: I did cleansstate | 11:51 |
| qschulz | fbre: you're not building the kernel you think you are | 11:52 |
| RobertBerger | @fbre you will burn in BitBake hell ;) | 11:53 |
| RobertBerger | @fbre is this about a raspberry-pi kernel ? | 11:53 |
| fbre | no, imx8 | 11:54 |
| RobertBerger | @fbre and which kernel recipe? | 11:55 |
| fbre | bitbake --read=../mystuff.conf core-image-minimal calls linux-fslc_5.4.bbappend. This is for sure because I see how it comes to an echo output there. This linux-fslc_5.4.bbappend calls include linux-imx/mystuff/mystuff.inc and also shows that testwise added echo call there. | 11:58 |
| fbre | But do_configure_prepend() {.....} is not called although it is also in mystuff.inc | 11:59 |
| RobertBerger | @fbre maybe someone else does a do_configure_prepend? | 12:01 |
| RP | RobertBerger: please help us document the crosstap case, its very rare you'd need to do anything like that | 12:02 |
| RobertBerger | @RP - once I understand how to get it fixed with --no-setscene I can do so. At the moment I am just hacking around and sometimes it even works ;) | 12:04 |
| RP | RobertBerger: "bitbake virtual/kernel -c clean; bitbake virtual/kernel --nosetscene" will force the kernel to have a full build present | 12:06 |
| RP | and is much much less evil that removing things from sstate which is slow and high impact | 12:06 |
| RobertBerger | @RP: Now you got me interested ;) | 12:06 |
| fbre | RobertBerger: I thought my layer overwrites the other ones. So my do_configure_prepend() should be the one which is called | 12:08 |
| RobertBerger | @RP: and how about SSTATE mirrors? Will it not fetch it from mirrors? | 12:08 |
| *** submux <submux!~submux@2a01:79c:cebd:fee8:8822:9716:c5bd:c1dd> has left #yocto | 12:08 | |
| RP | RobertBerger: not with --no-setscene it won't | 12:08 |
| RobertBerger | @RP - That's the thing I was searching for then ;) | 12:09 |
| RobertBerger | @fbre: If your layer has a high prio then I would say you bbappend is applied at the end after all potential other bbappends. | 12:12 |
| qschulz | fbre: the only "overwrites" that happens are for classes or recipes, not bbappends. Your linux-fslc is skipped so please find out why before trying to understand why your bbappend is not being applied (because well... you're building a completely different recipe so it's to be expected your bbappend does not "work") | 12:17 |
| RobertBerger | @RP: So to elaborate a bit more on the --no-setscene vs. cleansstate | 12:20 |
| simonpe^^ | Does anyone have a good suggestion for a nice chroot script that does all the mounting unmounting of /proc /sys etc automagically? | 12:20 |
| RobertBerger | @If I would want to be sure that do_configure is executre, I would do a cleansstate followed by a do_configure (before knowing the new trick) | 12:22 |
| RobertBerger | @RP But now I would do that: bitbake linux-yocto-custom-up -c clean && bitbake linux-yocto-custom-up -c do_configure --no-setscene | 12:25 |
| *** zand__ <zand__!~zandrey@193.8.40.126> has quit IRC | 12:25 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 12:26 | |
| fbre | (facepalm) I think it uses meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb but I have a file my-layer/recipes-kernel/linux/linux-fslc_5.4.bbappend | 12:27 |
| zandrey | fbre: "linux-fslc_5.4.bb (skipped):" <- this means your PREFERRED_PROVIDER_virtual/kernel is not set to point to that kernel | 12:27 |
| RobertBerger | use 5.4.%.bbappend | 12:27 |
| zandrey | fbre: correct! :D you just found the answer while i was typing it | 12:27 |
| fbre | I thought bitbake uses meta-freescale/recipes-kernel/linux/linux-fslc_5.4.bb | 12:28 |
| fbre | I wasn't aware there are multiple kernel .bb files, and linux-imx_5.4.3.bb is default | 12:29 |
| RP | RobertBerger: configure isn't a setscene task so " bitbake linux-yocto-custom-up -c clean && bitbake linux-yocto-custom-up -c do_configure" is enough | 12:29 |
| zandrey | fbre: please inspect https://github.com/Freescale/meta-freescale/blob/c4ac2aee0eeca51a8983e92635766eff43fd88d1/conf/machine/include/imx-base.inc#L312 | 12:29 |
| RP | RobertBerger: I'd just do bitbake linux-yocto-custom-up -c do_configure -f personally | 12:29 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 12:30 | |
| zandrey | linux-fslc in a more-or-less "vanilla" kernel, while linux-fslc-imx is an NXP+latest stable patchlevel | 12:30 |
| RobertBerger | @RP OK, but the other one would work as well and not kill my sstate - just for my understanding | 12:31 |
| zandrey | RP: would bitbake linux-yocto-custom-up -C configure work in this case as well? Capital C should invalidate the configure sstate in this case | 12:31 |
| fbre | But somehow it uses linux-imx_5.4.3.bb here, not linux-fslc_5.4.bb but I don't know why | 12:31 |
| fbre | and linux-fslc-imx_5.4.bb either (don't know why) | 12:32 |
| RobertBerger | @zandrey: I guess as well, but not sure if the same tasks will be executed. It invalidates the SSTATE | 12:32 |
| RP | RobertBerger: yes, just trying to be really clear :) | 12:32 |
| RP | zandrey: yes, -C is basically adding a -f | 12:33 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 12:33 | |
| zandrey | fbre: as you can see here [https://github.com/Freescale/meta-freescale/blob/c4ac2aee0eeca51a8983e92635766eff43fd88d1/conf/machine/include/imx-base.inc#L318] mx8 machines uses linux-fslc-imx by default | 12:33 |
| RP | -f will cause sstate to be skipped as the hash is now invalid | 12:33 |
| fbre | zandrey: But it don't use the one with -fscl- | 12:35 |
| fbre | zandrey: linux-imx instead | 12:35 |
| zandrey | fbre: just again for clarity. "linux-fslc" is a vanilla stable kernel from kernel.org with few cherry-picks from upstream. "linux-imx" is a *default* kernel from NXP, which is also found in their BSP release. "linux-fslc-imx" is a merge of *default* NXP kernel with latest 5.4.y patchlevel from stable branch of kernel.org | 12:36 |
| qschulz | fbre: PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-imx" in your machine conf if it's the one you really want | 12:37 |
| zandrey | qschulz: my point exactly! ;) | 12:37 |
| qschulz | zandrey: didn't say otherwise :) | 12:39 |
| zandrey | fbre: basically, linux-fslc-imx has all features that NXP provided at the time or release + latest stable versions (current in kernel.org: 5.4.63, current in recipe: 5.4.62) so you get all critical fixes. | 12:40 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 12:41 | |
| zandrey | 5.4.63 is now under PR in https://github.com/Freescale/linux-fslc and once merged - would be updated in recipe | 12:41 |
| fbre | Ah, I think I found the reason because I copied a few .conf and .inc files from the old NXP-sumo stuff to our own meta layer. And there is a file with PREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx" | 12:44 |
| fbre | This is the reason why my bitbake uses meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb in the end | 12:45 |
| fbre | Today I've learned there are many kernels and PREFERRED_PROVIDER sets the kernel to use :-) | 12:47 |
| fbre | I mean PREFERRED_PROVIDER_virtual/kernel | 12:48 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 12:48 | |
| qschulz | fbre: indeed :) | 12:50 |
| fbre | I can't remember why I downloaded the RT patch for 5.4.61, but anyway now that my .bbappend file is really called, I get the error it cannot apply patch-5.4.61-rt37.patch to my kernel. | 12:57 |
| fbre | I suppose linux-fslc_5.4.bb uses 5.4.61 but linux-imx_5.4.3.bb uses 5.4.3, right? | 12:58 |
| fbre | I reckon I have to set my PREFERRED_PROVIDER_virtual/kernel to linux-fslc-imx to use 5.4.61 | 12:59 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 13:03 | |
| zandrey | fbre: if you remove all the NXP files from you layer, then the only thing that would be left for you to do is to switch the kernel version and SRCREV in your append to point to 5.4.61 version. you have to do this since the latest RT patch available for 5.4y kernel is indeed 5.4.61 | 13:09 |
| zandrey | set SRCREV="8afe26f2c98897b494e641cfc9b20e84389c92b4" and LINUX_VERSION="5.4.61", then go ahead with RT patch - it applies clean | 13:10 |
| fbre | zandrey: thanx! I'll try that | 13:11 |
| zandrey | fbre: bare in mind - this combination is *not* tested, neither by me nor by RT-team. if there is a problem with any of NXP drivers - then you would have to deal with it. :) | 13:12 |
| fbre | Which combination is tested? | 13:13 |
| zandrey | may i ask you what is the reason to apply RT-patch? do you require determinism? | 13:13 |
| *** rcoote <rcoote!~rcoote@x52716343.dyn.telefonica.de> has joined #yocto | 13:13 | |
| fbre | zandrey: yes, determinism | 13:14 |
| zandrey | RT is not validated at all, i don't think that NXP ever performed any validation here. | 13:14 |
| fbre | we need very small latency with gpio stuff. The RT patch should help a bit to improve that | 13:15 |
| *** bzb <bzb!~bzb@214.ip-51-79-55.net> has joined #yocto | 13:16 | |
| qschulz | fbre: you | 13:17 |
| fbre | it's just an example of small latency. Actually we don't need big latency at all (between kernel and user space) | 13:17 |
| qschulz | 're probably not using gpio interfaces correctly? | 13:17 |
| qschulz | fbre: there's been a lot of testing done with gpios, try to look up a bit out to read/write to gpios, it's a common topic | 13:17 |
| zandrey | fbre: why not use M-cluster for this? or you really need this in Linux? just a suggestion from my side. see - the RT requires a very precise implementation not only in kernel, but in driver's code. if this is not properly done in those parts that NXP implemented - you might end up with the latencies much higher that those you have wiith normal preemption. | 13:17 |
| zandrey | but you would eventually see it, and probably would tell us here ;) | 13:18 |
| zandrey | i dealt with RT kernels before, but used it only in a very special case where a latency jitter was in microsec range | 13:20 |
| fbre | linux-fslc-qoriq PROVIDES virtual/kernel but was skipped: incompatible with machine imx8mmevk (not in COMPATIBLE_MACHINE) | 13:21 |
| zandrey | fbre: correct. that one is for Layerscape family | 13:21 |
| fbre | all such errors and in the end: ERROR: Required build target 'core-image-minimal' has no buildable providers. | 13:22 |
| fbre | The assignment is this: PREFERRED_PROVIDER_virtual/kernel_imx = "linux-fscl-imx" | 13:23 |
| fbre | PREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx" does not lead to an error but don't use 5.4.61 | 13:25 |
| fbre | s/don't/doesn't | 13:26 |
| fbre | not that easy to switch to linux-fscl-imx :-) | 13:26 |
| *** hch <hch!~hch@unaffiliated/hch> has joined #yocto | 13:26 | |
| fbre | Hmmmm.... I see there is an RT patch also for 5.4.3. So I could stick to "linux-imx" (instead of "linux-fscl-imx") and use that RT patch | 13:28 |
| *** crazyfermions <crazyfermions!50ff069b@80.255.6.155> has joined #yocto | 13:29 | |
| zandrey | fbre: mind the typo -> "linux-fscl-imx" should be "linux-fslc-imx". fslc stands for "FreeScaLe Community" :) | 13:37 |
| fbre | hehehe thought fscl is FreeSCaLe :-) | 13:38 |
| fbre | ok | 13:38 |
| zandrey | fbre: nope. ;) | 13:38 |
| crazyfermions | Hi! I am trying to compile linux-yocto-rt (4.14) from yocto on yocto-2.6.4 (migrated from a working 2.6.3) and I am unable to compile the kernel because of an issue, "'struct irq_affinity_notify' has no member named 'work'; did you mean 'swork'?" with this particular code: | 13:38 |
| crazyfermions | https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/tree/kernel/irq/manage.c?h=v4.14/standard/preempt-rt/base&id=72075349c6af55a7a6d024f0aa241711653fcb97#n366 -- in preempt-rt context, the field oldnotify->work is not defined, instead there is a new field named swork. That is why there are #ifdefs all over the place to cope with that (for | 13:38 |
| crazyfermions | example in line 352). Does someone have experience with that? It feels kind of unrealistic that this is a bug in upstream because it simply fails to compile and it should have been noticed. | 13:38 |
| zandrey | let me guess - no kernel provider found? | 13:38 |
| zandrey | fbre: if you do not modify PREFERRED_PROVIDER_virtual/kernel then you should pick up the correct kernel recipe name -> linux-fslc-imx | 13:41 |
| fbre | *sigh* now I'm trying what bitbake brings with MACHINE='imx8mmevk' and DISTRO ?= "poky" In other words I don't use the NXP-sumo stuff I once copied to my meta layer. | 13:49 |
| fbre | I hope it's 5.4.61 with that linux-fslc-imx | 13:50 |
| RobertBerger | @fbre this should work, I did this in my writeup | 13:52 |
| fbre | I have an unsecure feeling about that because that copied NXP stuff contains a lot of things I'm not sure if I need it somehow | 13:53 |
| fbre | ... all those wayland distro stuff | 13:54 |
| *** rcoote <rcoote!~rcoote@x52716343.dyn.telefonica.de> has quit IRC | 13:54 | |
| fbre | timeout for today. See you guys and thank you for your patience ;-) | 13:56 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 13:57 | |
| *** rcoote <rcoote!~rcoote@x52716343.dyn.telefonica.de> has joined #yocto | 13:59 | |
| *** rcoote <rcoote!~rcoote@x52716343.dyn.telefonica.de> has quit IRC | 14:10 | |
| zandrey | guys, what is the nick of Armin here? i've sent an email regarding last 'bind' upgrade, just wanted to check the status back with him. | 14:13 |
| *** bzb <bzb!~bzb@214.ip-51-79-55.net> has quit IRC | 14:14 | |
| qschulz | zandrey: give him some time, according to the mail's metadata he's in the US, they'll soon start their day and you wrote on Friday late :) | 14:18 |
| qschulz | -late | 14:19 |
| zandrey | qschulz: oh sorry... :) didn't mind the time span... :D | 14:19 |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 14:25 | |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto | 14:25 | |
| *** awe003 <awe003!~awe00@unaffiliated/awe00> has quit IRC | 14:27 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 14:30 | |
| *** crazyfermions <crazyfermions!50ff069b@80.255.6.155> has quit IRC | 14:31 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 14:32 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 14:32 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:36 | |
| *** mbulut_ <mbulut_!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 14:50 | |
| RP | zandrey: he's armpit here | 14:56 |
| RobertBerger | @RP Should DEPENDS do all that https://pastebin.com/tHMPQ422 or should it have stopped at do_populate_sysroot? | 14:57 |
| zandrey | RP: thanks! i'd go as qschulz suggested and wait a bit, as i realized that there is a span between EU and US and i've sent the report on US late Friday eve. | 14:58 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 14:58 | |
| RP | RobertBerger: that would depend on the wider context of what you're doing | 14:59 |
| RobertBerger | @RP The doc says: Here, the dependency is such that the do_configure task for recipe "a" depends on the do_populate_sysroot task of recipe "b". | 14:59 |
| RP | RobertBerger: when recrdeps gets involved it gets more complex | 14:59 |
| RobertBerger | Let me give you the exact context | 14:59 |
| RP | RobertBerger: is recrdeps involved? It so, read the docs for that as it can also process DEPENDS | 15:00 |
| RobertBerger | Not that I am aware of: https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/master/recipes-bsp/u-boot/u-boot-phytec-imx_2019.04.bb#L17 | 15:00 |
| RP | RobertBerger: what is the command you're running to evaluate this? | 15:00 |
| RobertBerger | You mean how I get my list of tasks? | 15:01 |
| RobertBerger | I just bitbake and that's from the log dir log.task_order | 15:01 |
| * armpit and today is a US holiday | 15:01 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:01 | |
| RP | RobertBerger: do_compile[depends] = "firmware-imx-8m:do_deploy" is quite different from DEPENDS += "firmware-imx-8m" | 15:02 |
| RobertBerger | My problem is, that DEPENDS until recently behaved as expected - stopping at do_populate_sysroot, so I used [depends] instead | 15:02 |
| RobertBerger | Yes - this was my fix ;) | 15:02 |
| RP | RobertBerger: which task of u-boot-phytec-imx are you running? | 15:02 |
| RobertBerger | I tried to reproduce my inital problem | 15:03 |
| RobertBerger | Juts bitbake u-boot-phytec-imx | 15:03 |
| RP | RobertBerger: simplify your probably to "bitbake u-boot-phytec-imx -c clean; bitbake u-boot-phytec-imx -c compile" | 15:03 |
| RobertBerger | And it used to break, as expected - hence I replaced DEPENDS with do_compile[depends] | 15:03 |
| RP | simplify your problem to | 15:03 |
| RP | well, clean firmware-imx-8m too | 15:04 |
| RP | DEPENDS += "firmware-imx-8m" may or may not trigger a do_deploy by the time do_compile of uboot runs | 15:04 |
| zandrey | armpit: "Labor Day" :) as the name suggests - it should actually be a working day! :D | 15:04 |
| RP | in fact the DEPENDS may not run do_deploy at all | 15:05 |
| RobertBerger | Yes this is what I am trying to reproduce | 15:05 |
| RobertBerger | but it can't ;) | 15:05 |
| RP | RobertBerger: the best way to reproduce is as I mention, be explicit about the tasks you're running | 15:06 |
| RobertBerger | It works | 15:06 |
| RobertBerger | Also like this: https://pastebin.com/k8YEgJKS | 15:06 |
| RobertBerger | And I even understand why, since I would need to clean up the the other recipes output. | 15:07 |
| RP | RobertBerger: right, clean the other recipe too, first | 15:07 |
| RobertBerger | OK | 15:07 |
| RobertBerger | "bitbake firmware-imx-8m -c clean; bitbake u-boot-phytec-imx -c clean; bitbake u-boot-phytec-imx -c compile" | 15:09 |
| RP | right | 15:09 |
| RobertBerger | Now it breaks - Halleluja ! | 15:09 |
| * RP likes the irony of helping people break their builds | 15:10 | |
| armpit | zandrey, its a holiday from the work that pays | 15:10 |
| armpit | RP, yes it is | 15:10 |
| RobertBerger | I was really frustrated that I made a fix for something I could not break anymore ;) | 15:11 |
| RobertBerger | Thanks - that helps! | 15:11 |
| RobertBerger | Let's see if this proves that my fix is actually needed, but I think it does | 15:11 |
| * armpit time to play in opensource | 15:12 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 15:13 | |
| zandrey | armpit: we have similar thing here across the Pond, just a bit earlier. :) | 15:14 |
| RobertBerger | @RP: ".. but RP helped me to successfully break it" will be soon on a new blog post ;) | 15:14 |
| RP | Can anyone remember why we get tracebacks on some distros (e.g. ubuntu1804) with zeus in oe-selftest but not in others (e.g. centos8) | 15:22 |
| *** luneff <luneff!~yury@80.72.17.178> has quit IRC | 15:24 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 15:24 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 15:26 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 15:30 | |
| armpit | RP, the system I used to do zeus work was ubuntu1804 and dont recall such an issue. do you what test? | 15:31 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-064.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 15:31 | |
| RP | armpit: its https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1344 that worries me | 15:37 |
| RP | armpit: found a few zeus bugs I'm sorting a series for (in an effort to get the stable builds working with the new toolchains) | 15:37 |
| RP | JPEW: I'm wondering if the signing patch I just sent out could explain the gpg issue we saw? | 15:39 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 15:41 | |
| armpit | RP, there are a few additional patches for zeus. I can quere those up and look @ the build issues at the same time if that helps | 15:45 |
| RP | armpit: the one which puzzles me/worries me is why centos8 isn't showing oe-selftest errors | 15:46 |
| RP | armpit: see zeus-next for the things I'm wondering about (to be build with contrib/rpurdie/zeus for autobuilder-helper) | 15:46 |
| armpit | the error log says the system is CentOS8 | 15:49 |
| RP | armpit: right, maybe the buildtools tarball being used there is problematic? | 15:50 |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC | 15:51 | |
| armpit | IIRC that series gave me issues but since the branch built w/o without them, i put it on the back burner | 15:56 |
| armpit | maybe the new uniative 2.9 | 15:57 |
| armpit | dunfell does not have the 2.9 | 15:58 |
| RP | armpit: series is massively revised now | 15:59 |
| RP | armpit: made a note to tell sakoman about 2.9 | 16:00 |
| armpit | I can send a patch for dunfell | 16:01 |
| armpit | that should do the trick | 16:02 |
| RP | armpit: I put something in dunfell-next to remind me | 16:02 |
| RP | armpit: I doubt 2.9 is affecting the autobuilder yet though | 16:02 |
| *** fl0v0 <fl0v0!~fvo@i5E86934E.versanet.de> has quit IRC | 16:08 | |
| armpit | patch send as a reminder | 16:12 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 16:12 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 16:14 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 16:14 | |
| RP | armpit: thanks. I've sent email out on what I think we need to do with stable series builds/patches | 16:14 |
| zandrey | armpit: saw the reply, thanks a lot! i'd strip the current setup i have to get something really simple and would report back. | 16:14 |
| armpit | RP, do you mean the perf build failures too on zeus? | 16:14 |
| armpit | zandrey, ok. thanks | 16:15 |
| RP | armpit: didn't even see that :( | 16:16 |
| RP | armpit: that doesn't look good :( | 16:16 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:17 | |
| armpit | I see autobuild-helper is missing using the new buildtools | 16:19 |
| RP | armpit: in which branch? | 16:20 |
| armpit | zues | 16:20 |
| armpit | missing from zeus | 16:20 |
| armpit | master has this | 16:20 |
| RP | armpit: its in contrib/rpurdie/zeus though | 16:20 |
| armpit | http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/commit/?id=2e6c7ee4081b7aa97d4cb5d04d4dd2145e97de97 | 16:20 |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 16:20 | |
| armpit | autobuilder | 16:20 |
| RP | armpit: to be clear, there are fixes for the gpg and reproducibility failures in zeus-next. What isn't there is why there isn't a proper error on centos8 and that perf build issue is also a worry | 16:21 |
| RP | armpit: I'm testing with contrib/rpurdie/zeus as per the email I've sent | 16:21 |
| armpit | RP, i just found your email | 16:24 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:25 | |
| JaMa | RP: the last 6 e-mails in openembedded-commits aren't really from you, right? :) https://lists.openembedded.org/g/openembedded-commits/topics | 16:26 |
| RP | JaMa: no | 16:26 |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC | 16:29 | |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto | 16:31 | |
| armpit | RP, is there anything at this point I can help with since you have the train on its way? | 16:32 |
| sakoman | I'm attempting to send out a patch series for reviewa nd one of khem's patches (https://git.openembedded.org/openembedded-core-contrib/commit/?h=stable/dunfell-nut&id=d26c5882ee5dbdb41d5c8903b0e470f2291512a5) is causing a problem with send-pull-request: | 16:34 |
| sakoman | fatal: pull-28962/0004-json-c-Fix-CVE-2020-12762.patch: 253: patch contains a line longer than 998 characters | 16:34 |
| sakoman | Has anyone encountered this issue before and if so how did you handle it? | 16:35 |
| armpit | JaMa, except for the ones saying he is " Prince needing some money" ; ) | 16:35 |
| armpit | sakoman, the fix in master is missing the "test" changes which I suspect are the issue. | 16:41 |
| armpit | if Khem is the author of the Dunfell patch, maybe he worked around it some how | 16:42 |
| JaMa | I have seen this few times, but usually it was in commit message (like build command being too long) so it was easy to wrap on more reasonable line lenght | 16:45 |
| sakoman | armpit: the way he worked around it was to bypass email when sending me the patch :-) | 16:46 |
| sakoman | JaMa: in this case it is one of the lines in a patch that originates from upstream json-c | 16:47 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 16:47 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16:48 | |
| sakoman | The patch is already in git and tested, so the issue is just sending out for review via email. I supposed I could truncate that line and insert a <snip> since I suspect no one will actually review that long line of data! | 16:49 |
| sakoman | Any other ideas? | 16:49 |
| RP | sakoman: I'd probably just truncate as described and mention in the series log | 16:50 |
| armpit | yep.. that is the reasonable way to go | 16:52 |
| *** mckoan is now known as mckoan|away | 16:58 | |
| RP | armpit: if it helps I was able to get a backtrace out the centos8 case where the connection dies | 17:04 |
| armpit | k, want me to poke at it? | 17:11 |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 17:13 | |
| RP | armpit: I'd love someone else to fix it, just not sure its fair to hand it off half way through debugging | 17:19 |
| armpit | I believe the "test_testimage_virgl_gtk" is a known issue we intend on not fixing. we should disable that | 17:31 |
| RP | armpit: yes | 17:45 |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:dda9:6d30:abe4:4c17> has joined #yocto | 17:47 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 17:56 | |
| RP | armpit: its easy to reproduce. Just add self.assertTrue(False) into a test and then do oe-selftest -r <testname> -j 1 | 17:57 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 17:59 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 17:59 | |
| *** ruru4143 <ruru4143!~ruru4143@vmi243882.contaboserver.net> has quit IRC | 18:06 | |
| RP | armpit: I'm going to guess http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=19e3031e3a1e600e417625997fad11f708a1b3b5 | 18:08 |
| RP | armpit: confirmed that fixes it | 18:10 |
| * RP is happier now | 18:11 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:27 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 20:03 | |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC | 20:07 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 20:07 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 20:09 | |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-68.bredband.comhem.se> has quit IRC | 20:11 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 20:28 | |
| *** elGamal <elGamal!~elg@37.120.221.4> has quit IRC | 20:30 | |
| *** elGamal <elGamal!~elg@37.120.221.4> has joined #yocto | 20:31 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 20:40 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 20:41 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has quit IRC | 20:59 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has joined #yocto | 20:59 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has quit IRC | 21:03 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has joined #yocto | 21:03 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:07 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 21:34 | |
| RP | armpit: I reran zeus-next and it shows two signing failures in selftest. Help appreciated with those. Not sure if I screwed up the builddir patch or what has happened there :( | 21:49 |
| RP | armpit: looks like it breaks on master too. Maybe I get to keep the pieces | 22:05 |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 22:06 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 22:07 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:17 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:42 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 22:44 | |
| *** elGamal <elGamal!~elg@37.120.221.4> has quit IRC | 23:16 | |
| *** elGamal <elGamal!~elg@217.138.222.44> has joined #yocto | 23:18 | |
| *** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC | 23:36 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 23:36 | |
| *** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto | 23:46 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 23:47 | |
| *** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC | 23:52 | |
| *** j2411 <j2411!~Adium@20.ip-51-79-160.net> has joined #yocto | 23:53 | |
| *** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto | 23:53 | |
| *** D`K_C <D`K_C!~dkc@55.ip-158-69-215.net> has joined #yocto | 23:53 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 23:54 | |
| *** dkc <dkc!~dkc@55.ip-158-69-215.net> has quit IRC | 23:54 | |
| *** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has quit IRC | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!