| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 00:01 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 00:02 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:09 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:20 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:31 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:41 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:57 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:58 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 01:03 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 01:05 | |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has joined #yocto | 01:07 | |
| *** CTer_ <CTer_!~clemens.t@176.95.71.124> has joined #yocto | 01:07 | |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has quit IRC | 01:10 | |
| *** CTer <CTer!~clemens.t@176.95.71.124> has quit IRC | 01:10 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:11 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 01:22 | |
| *** jimr <jimr!~jimr@pool-173-66-141-210.washdc.fios.verizon.net> has quit IRC | 01:25 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 01:40 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 01:40 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 01:56 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 01:57 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has quit IRC | 02:04 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has joined #yocto | 02:05 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:46 | |
| kergoth | RP: https://blog.ram.rachum.com/post/621791438475296768/improving-python-exception-chaining-with | 02:46 |
|---|---|---|
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 02:46 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 02:50 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 02:55 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 03:02 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 03:04 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 03:15 | |
| *** King_In3 <King_In3!~King_InuY@47.19.105.250> has joined #yocto | 03:25 | |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 03:27 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 03:28 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 03:29 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 03:57 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 03:57 | |
| *** jobroe <jobroe!~manjaro-u@p579eb731.dip0.t-ipconnect.de> has joined #yocto | 04:21 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-krbxwvwafkvhnztd> has quit IRC | 04:29 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 04:54 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 04:54 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has joined #yocto | 04:57 | |
| *** ctlnwr_ <ctlnwr_!~catalin@46.97.150.20> has joined #yocto | 04:57 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 05:05 | |
| *** stew-dw <stew-dw!~stew-dw@172.58.87.99> has quit IRC | 05:06 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:08 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:9820:87ad:875d:cc7e:3120:8572> has joined #yocto | 05:08 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has quit IRC | 05:13 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has joined #yocto | 05:16 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 05:19 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 05:20 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has quit IRC | 05:26 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has joined #yocto | 05:27 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-204.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 05:30 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 05:33 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 05:35 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has quit IRC | 05:40 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:47 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 05:48 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 05:49 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 05:55 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:06 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 06:06 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 06:14 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 06:14 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 06:17 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:19 | |
| yann | what's the status for 3.1.3 ? on track for release today ? | 06:22 |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 06:33 | |
| * mcfrisk wonders if finding and fixing bitbake and build script race conditions will be my job until retirement in 25 years? It's been the last 20 or so already. Even bazel had race conditions in bazel installation itself which had decided to download java code into $HOME and failed to auto-update them on build servers. all hope lost? | 06:44 | |
| *** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.181.14> has joined #yocto | 06:45 | |
| *** mckoan|away is now known as mckoan | 06:45 | |
| * mcfrisk also wonders when SW crash root causes will finally be detected before seeing them in real product testing. static analyzers and compilers are able to find roughly 95% of them at compile time but developers seem to be really ignorant at those tools. Things like checking return values or pointers in C/C++ are really simple things which everyone seems to get wrong. Not much has improved in last 20 | 07:00 | |
| * mcfrisk years, which means next 25 years until my retirement will bethe same story. Or can go and rust really break through and get rid of these? java didn't seem to help much, seen so many null pointer crashes there... I think I need a beer already | 07:00 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 07:03 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:9820:87ad:875d:cc7e:3120:8572> has quit IRC | 07:10 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 07:10 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:17c9:5517:98b9:fd98:9ae9:5600> has joined #yocto | 07:14 | |
| RP | kergoth: we should definitely start using that for BBHandledException | 07:17 |
| RP | mcfrisk: The time I've been spending with intermittent failures does start to get to you after a while! | 07:18 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 07:21 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 07:22 | |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 07:22 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:17c9:5517:98b9:fd98:9ae9:5600> has quit IRC | 07:23 | |
| *** stew-dw <stew-dw!~stew-dw@172.58.140.212> has joined #yocto | 07:28 | |
| mcfrisk | RP: ignorance is bliss. if one stops ignoring issues and treats all of them as bugs to fix, it easily becomes a full time job and a career. with the broad deployment of continuous integration and test setups, jeez, so many problems become very visible in projects and organizations. Trick is to get order of magnitude improvements and fix the root causes before they cause issues. static analysis for C and | 07:31 |
| mcfrisk | C++, validation for build scripts? | 07:31 |
| RP | mcfrisk: how many issues do you see from bitbake itself? Just wondering how we're doing... | 07:32 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 07:33 | |
| mcfrisk | RP: a bit too many, actually. doing zeus to dunfell updates, it's too easy to get bitbake to 'crash' or hang when meta layers are all messed/mixed up. Once those are sorted, things on yocto and open source side are better. It's usually the company specific SW and build scripts which have races and issues. Though lately also meta-java... | 07:36 |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has quit IRC | 07:37 | |
| mcfrisk | oh and the BSP layers.. they can screw everything up. I think some of mine are even corrupting sstate cache somehow. have to wipe tmp for all builds just be sure.. | 07:38 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 07:39 | |
| *** ptsneves <ptsneves!b0dd7824@176.221.120.36> has joined #yocto | 07:54 | |
| RP | mcfrisk: bad metadata messing up sstate is a tough one. Do you have examples of crashing or hanging bitbake? That sounds like something we should try and avoid | 07:56 |
| *** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.181.14> has quit IRC | 07:58 | |
| mcfrisk | RP: bitbake crashes only when meta layers have odd things, wrong branch or some parsing errors. I'm often able to find out manually what the problems are. examples are lost already. Hangs, well also happen for same reasons sometimes. And then there is the 'bitbake -c devshell foo' open for more than 24 hours and exiting console just hangs bitbake. Have to kill processes or build container to recover. | 07:59 |
| *** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.181.14> has joined #yocto | 08:01 | |
| RP | mcfrisk: well, this is open source and we are happy to try and improve things if we can | 08:01 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:08 | |
| manuel1985 | Any ideas on how to use that `aws` tool to download stuff from an s3 bucket from a yocto recipe? | 08:10 |
| ptsneves | manuel1985 it a jva tool right | 08:10 |
| ptsneves | java | 08:10 |
| manuel1985 | I think it's python but let me look it up | 08:11 |
| ptsneves | regadless the way to go is a native recipe | 08:11 |
| manuel1985 | ptsneves: | 08:12 |
| manuel1985 | manuel@debian:~$ head -1 /usr/local/bin/aws | 08:12 |
| manuel1985 | #!/usr/bin/python3 | 08:12 |
| manuel1985 | What do you mean with `native recipe`? | 08:13 |
| *** xtron <xtron!~xtron@103.113.103.14> has joined #yocto | 08:13 | |
| ptsneves | a recipe for the build system to use. | 08:13 |
| ptsneves | so to run on the host | 08:13 |
| manuel1985 | Yeah that's what I'm intending to do. The question is: Do I have `aws` available from a docker recipe? I would like to run `aws s3 cp s3://myfile ${WORKDIR}`. Didn't try yet, but I guess I don't have `aws` available in a recipe. | 08:14 |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 08:16 | |
| ptsneves | manuel1985 can you clarify what you mean by running from a docker recipe? | 08:17 |
| *** florian_kc is now known as florian | 08:19 | |
| manuel1985 | I would like to put a `do_fetch()` function in my recipe which downloads this file from the s3 bucket. And in this function I'd call `aws` | 08:19 |
| *** xtron <xtron!~xtron@103.113.103.14> has quit IRC | 08:19 | |
| manuel1985 | I can't try it out right now, but I assume it won't work, because in an issue unrelated to this I once tried to run `docker pull` in the same way in a recipe, and I think it told me it can't find `docker` altough it's installed on the machine the build was running on | 08:20 |
| rburton | right, inside builds you have minimal commands from the host | 08:20 |
| rburton | so that you don't end up relying on stuff on the host which isn't tracked by dependencies | 08:21 |
| rburton | the hack is to add aws to HOSTTOOLS, but then you need to document that everyone using the recipe needs to install those things | 08:21 |
| rburton | the proper fix is a recipe that installs aws, and DEPEND on that | 08:21 |
| rburton | fwiw, there is already a s3 fetcher | 08:22 |
| rburton | i suspect it has aged badly as it assumes aws is present on $PATH so will hit the same issue, but that's easily fixed | 08:23 |
| manuel1985 | Alright, gonna look for it :) That was valuable information, thanks for the insight on the inner workings of yocto! aws is available in my $PATH so hopefully I won't run into problems :) | 08:28 |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 08:31 | |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has joined #yocto | 08:32 | |
| rburton | "inside builds you have minimal commands from the host" is saying that aws *won't* be on $PATH | 08:41 |
| rburton | thus the hosttools hack | 08:41 |
| rburton | there should be an aws-native recipe that can get magically depended on | 08:42 |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 08:49 | |
| fbre | Hi! I use dunfell. How do I add the kernel .bin file to the boot partition of my SD card? I added INITRAMFS_IMAGE = "core-image-tiny-initramfs" and INITRAMFS_IMAGE_BUNDLE = "1" which bitbakes a file Image-initramfs-imx8mmevk.bin | 08:52 |
| fbre | But the core-image-minimal-imx8mmevk.wic.gz doesn't seem to contain that Image-initramfs-imx8mmevk.bin | 08:53 |
| fbre | With yocto "sumo" I found out I have to add this line to my conf file: IMAGE_BOOTFILES += "${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin" | 08:54 |
| fbre | But it doesn't have an effect with dunfell | 08:54 |
| fbre | Anyway, when I'm in u-boot and do "fatls mmc 1:1" I just see 2 files: Image and my device tree .dtb file | 08:59 |
| *** Jackiehjm <Jackiehjm!~quassel@60.247.85.82> has quit IRC | 09:01 | |
| qschulz | Image is the kernel image? | 09:03 |
| fbre | yes | 09:04 |
| ernstp | RP: I'm going to ping this again :-) https://www.openembedded.org/pipermail/bitbake-devel/2019-May/019998.html | 09:04 |
| RP | ernstp: didn't we try testing that and it caused problems? :/ | 09:05 |
| ernstp | RP: I'm not aware of that. I can search the ML | 09:06 |
| RP | ernstp: I think my other concern would be special casing specific fetchers in the core code. That is usually a bad sign and we've usually been able to avoid doing it | 09:07 |
| RP | I wish I had the time to sit down and properly look at these things :( | 09:07 |
| ernstp | RP: 1) git protocol is blocked. 2) we download an git archive tar from a PREMIRROR, everyone is happy. 3) a recipe is updated with a new sha1 4) yocto tries to do "git fetch" in the archive, but it's configured for the git protocol and that's still blocked | 09:09 |
| ernstp | RP: so this is very much related to the PREMIRROR system, which is a bit more "core" than just the git fetcher itself | 09:10 |
| RP | ernstp: are you doing 2) manually? | 09:11 |
| ernstp | RP: no that works out of the box | 09:11 |
| ernstp | RP: there are only a couple of recipes with git protocol gits | 09:12 |
| ptsneves | @ern | 09:12 |
| ptsneves | ernstp what are you trying to solve? | 09:12 |
| *** hpsy <hpsy!~hpsy@92.118.12.31> has quit IRC | 09:12 | |
| *** hpsy <hpsy!~hpsy@92.118.12.31> has joined #yocto | 09:12 | |
| ernstp | ptsneves: I submitted a patch some time ago, pinged it again: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13278 | 09:12 |
| ptsneves | ernstp from your description and commit message it sounds the behavior is already taken care by a fresh clone | 09:13 |
| ptsneves | which would be triggered if the hash was not found in the local downloads | 09:13 |
| RP | ernstp: Can you at least resend the patch with more of the info above. That does make the situation clearer and helps. I'm not promising to merge it but it would help | 09:13 |
| ernstp | ptsneves: you get ERROR: prelink-native-1.0+gitAUTOINC+05aeafd053-r0 do_unpack: Fetcher failure: | 09:13 |
| ernstp | fatal: reference is not a tree: 05aeafd053e56356ec8c62f4bb8f7b95bae192f3 | 09:13 |
| RP | ernstp: I note I'm the owner of that bug :( | 09:14 |
| RP | sorry | 09:14 |
| ernstp | RP: i get an email every time you push it to the next milestone :-) | 09:14 |
| ptsneves | ernstp it is interesting, because we were victims of a similar issue but found that the behavior in yocto was correct. | 09:14 |
| RP | ernstp: I have way more bugs than its feasible for me to handle :( | 09:15 |
| ernstp | ptsneves: it's annoying to have to go into Jenkins servers and clear their download cache etc... | 09:15 |
| ernstp | RP: yeah, I'll just ping you once every year :-) | 09:16 |
| ernstp | but yeah I can resend it to the list, with a longer message | 09:16 |
| qschulz | fbre: then what's the issue? | 09:17 |
| RP | ernstp: please do that rather than just ping :) | 09:17 |
| ernstp | there was no testing I think: https://lists.openembedded.org/g/bitbake-devel/search?ev=0&q=%22Replace+old+git+with+mirror%22 | 09:17 |
| RP | ernstp: or I forgot to report back :( | 09:19 |
| ernstp | RP: might need to rebase it also, master has of course moved... | 09:20 |
| ptsneves | the issue i have with that patch is that it couples the __init__ with git fetcher | 09:23 |
| ptsneves | trying to see an alternative | 09:25 |
| fbre | aaaarghhh (facepalm) - the viariable is not IMAGE_BOOTFILES but IMAGE_BOOT_FILES X) :') | 09:26 |
| fbre | That has changed from sumo to dunfell | 09:27 |
| fbre | now it works | 09:27 |
| ernstp | ptsneves: i wondered if it could be made more generic, but I wanted to be conservative and limit it as much as possible to reduce risk | 09:27 |
| ptsneves | > 1) git protocol is blocked. 2) we download an git archive tar from a PREMIRROR, everyone is happy. 3) a recipe is updated with a new sha1 4) yocto tries to do "git fetch" in the archive, but it's configured for the git protocol and that's still blocked | 09:29 |
| ptsneves | from this description i do not understand why the git fetch does not try to fetch from the upstream mirror as in the first time | 09:30 |
| ptsneves | it is the issue right? | 09:31 |
| ernstp | ptsneves: yeah you run into a "Fetcher failure". The exception says "General fetcher exception when something happens incorrectly" | 09:44 |
| ernstp | ptsneves: yeah ok there should be an additional item in the list | 09:45 |
| ernstp | it does fetch it from the upstream mirror but it does that to a different path, git.yoctoproject.org.git.prelink-cross.git vs git.yoctoproject.org.prelink-cross.git | 09:49 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 09:49 | |
| ernstp | so that's what my patch does, it fixes that link | 09:49 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:54 | |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has quit IRC | 10:03 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has quit IRC | 10:07 | |
| *** ctlnwr_ <ctlnwr_!~catalin@46.97.150.20> has quit IRC | 10:07 | |
| *** Klanticus <Klanticus!~quassel@189.76.143.176> has joined #yocto | 10:12 | |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has joined #yocto | 10:17 | |
| *** CTer_ <CTer_!~clemens.t@176.95.71.124> has quit IRC | 10:18 | |
| yann | anyone konws the status for 3.1.3 ? on track for release today ? | 10:18 |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has quit IRC | 10:19 | |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has joined #yocto | 10:20 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 10:21 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 10:21 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 10:28 | |
| *** sev_ <sev_!~sev@2003:a:12a:1300:8e16:45ff:fe1e:3785> has joined #yocto | 10:33 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 10:38 | |
| *** guerra <guerra!52386921@host-82-56-105-33.retail.telecomitalia.it> has joined #yocto | 10:39 | |
| *** ptsneves <ptsneves!b0dd7824@176.221.120.36> has quit IRC | 10:42 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zntnsscmupttpzkl> has joined #yocto | 10:48 | |
| RP | yann: QA report due next week. Its a little behind | 10:50 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 10:50 | |
| RP | yann: it is built and in QA | 10:50 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 10:51 | |
| *** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto | 10:52 | |
| yann | is the tag available somewhere already ? I'm preparing our first dunfell-based release and i'd prefer to use that one from the start | 10:54 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 10:54 | |
| yann | for now I've taken 44ab5a84770bf as closest guess I could make :) | 10:55 |
| pev | So I built a generic core-image-minimal qemuarmv5 build in dunfell but I don't get a virtual console working although doing "runqemu ... nographic" is fine. Is that something that should be expected to work as per qemuarm core-image-minimal? | 11:08 |
| rburton | if you pass nographic then you should get a login prompt, yes | 11:11 |
| *** stew-dw <stew-dw!~stew-dw@172.58.140.212> has quit IRC | 11:26 | |
| *** stew-dw_ <stew-dw_!~stew-dw@172.58.140.75> has joined #yocto | 11:27 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 11:36 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 11:37 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:40 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 11:41 | |
| RP | yann: the QA email has the revisions in (sent to the yocto list) | 11:45 |
| RP | yann: basically current tip of dunfell | 11:46 |
| *** ak77 <ak77!c12e4b03@193.46.75.3> has joined #yocto | 11:47 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 12:06 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has joined #yocto | 12:24 | |
| *** ctlnwr_ <ctlnwr_!~catalin@46.97.150.20> has joined #yocto | 12:24 | |
| yann | RP: I recieved the 3.2M3 notifications but not the 3.1.3 one | 12:44 |
| *** carlsb3rg <carlsb3rg!c147afcf@193.71.175.207> has joined #yocto | 12:44 | |
| carlsb3rg | in my <machine>.conf, I specify a WKS_FILE. Where do I actually put the file? | 12:45 |
| carlsb3rg | I've copied the directdisk-bootloader-config.wks, common.wks.inc and directdisk-bootloader-config.cfg from ~/poky/scripts/lib, but have no clue where to put them or whether this is the right way of doing things | 12:47 |
| carlsb3rg | my main objective is to have a custom directdisk-bootloader-config.cfg without changing the one in the poky repo (since touching the poky repo is considered bad practice) | 12:49 |
| yann | RP: in the yocto-3.2_M3.rc2 thread you wrote "The 3.1.3 build should also be arriving shortly" but https://lists.yoctoproject.org/g/yocto/search?q=3.1.3 does not show anything more precise than "3.1.3 will be built soon" afterwards - and I still can't wrap my mind around the ML archive UI to be able to see the latest mails in the list | 12:50 |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 13:00 | |
| *** stew-dw_ <stew-dw_!~stew-dw@172.58.140.75> has quit IRC | 13:00 | |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 13:00 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has joined #yocto | 13:00 | |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 13:01 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 13:04 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:05 | |
| *** camus1 is now known as kaspter | 13:05 | |
| *** xtron1 is now known as xtron | 13:10 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 13:12 | |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 13:18 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:19 | |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 13:30 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 13:30 | |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 13:31 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 13:47 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto | 13:53 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 14:00 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:00 | |
| *** camus1 is now known as kaspter | 14:00 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has quit IRC | 14:06 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has joined #yocto | 14:09 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 14:18 | |
| *** jobroe <jobroe!~manjaro-u@p579eb731.dip0.t-ipconnect.de> has quit IRC | 14:23 | |
| *** King_In3 <King_In3!~King_InuY@47.19.105.250> has quit IRC | 14:23 | |
| *** WillMiles <WillMiles!~Will@209.87.231.80> has joined #yocto | 14:25 | |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 14:27 | |
| *** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has quit IRC | 14:29 | |
| RP | yann: the email didn't make it to the list :( | 14:34 |
| RP | yann: I've resent | 14:36 |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has quit IRC | 14:36 | |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has joined #yocto | 14:37 | |
| yann | RP: got it, thx! | 14:38 |
| yann | I was wondering, I remember sometimes seeing a meta-oe sha1 in such reports - what's the rule here ? | 14:39 |
| RP | yann: not sure meta-oe has ever been listed there | 14:40 |
| RP | yann: meta-oe isn't used in the autobuilders release build target | 14:40 |
| yann | ok, I'm probably confusing with a different report | 14:42 |
| RP | we probably should test more but it is what it is | 14:42 |
| armpit | meta-oe should not have been in yocto list | 14:42 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 14:43 | |
| armpit | yann Khen sends out world build status from time to time | 14:43 |
| armpit | for meta-oe | 14:43 |
| RP | armpit: Yann Khen? I've not heard of them before :) | 14:44 |
| *** exoyds <exoyds!1fcdc9f8@31.205.201.248> has joined #yocto | 14:44 | |
| armpit | hehe, forgot the comma | 14:44 |
| yann | :) | 14:44 |
| armpit | and misspelled | 14:44 |
| armpit | yann, oecore is in the QA listing | 14:50 |
| *** exoyds <exoyds!1fcdc9f8@31.205.201.248> has quit IRC | 14:53 | |
| ad__ | hi, building dunfell from poky/crops, at the end, bitbake stays a lot of time (>30min) stop on "Summary: There were 39 WARNING messages shown." without completing. Is this normal ? | 14:53 |
| RP | ad__: is it doing something with buildhistory? Its probably doing something but 30mins is a long time | 14:54 |
| RP | ad__: its also possible there are processes which aren't exiting. What does ps ax show as running? | 14:54 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 14:55 | |
| sgw | Morning folks | 14:55 |
| RP | morning sgw | 14:55 |
| sgw | RP: I just send a couple of RFC patches for the target dumping | 14:55 |
| ad__ | RP, it's stop in this way https://pasteboard.co/JsJje2c.png | 14:56 |
| yann | ad__: doesn't crops need to publish/copy-out sstate and such ? | 14:56 |
| RP | ad__: hmm, so probably not buildhistory | 14:56 |
| yann | (for persistence between builds) | 14:56 |
| *** pabigot <pabigot!~pab@c-73-65-46-39.hsd1.mn.comcast.net> has joined #yocto | 14:56 | |
| sgw | biab | 14:57 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:57 | |
| ad__ | RP, ps aux | grep python does not show any process | 14:58 |
| ad__ | i only see containerd-shim and docker run | 14:58 |
| RP | sgw: you're implying we already have a set of commands and they're just not running? | 14:58 |
| RP | ad__: I'm no crops expert but that sounds it should have exited then :/ | 14:59 |
| ad__ | i tried CTRL+C nothing happen, so, closed the terminal | 14:59 |
| ad__ | let's see | 14:59 |
| ad__ | now re-running | 14:59 |
| *** Zajc <Zajc!~Zajc@193.9.55.10> has joined #yocto | 15:00 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 15:02 | |
| ad__ | now on rebuild it completed fine | 15:02 |
| ad__ | well, thanks anyway for the support | 15:02 |
| ecdhe | zeddii: I found it, my defconfig file was not found because I had accidentally copy pasted a similar but not identical filename | 15:03 |
| ecdhe | zeddii: it was obvious once I found the actuall directory that bitbake was looking in, but I still wish it had told me | 15:04 |
| yann | ad__: that's really what a sstate rsync would look like :) | 15:04 |
| ad__ | yann, ah ok, thanks. Will study on it. | 15:05 |
| yann | 30min looks like a lot, but I've see some docker instances (gitlab.com's) being really slow when it comes to copying data, even inside a single docker container | 15:05 |
| *** agodard <agodard!51b9acdd@221.172.185.81.rev.sfr.net> has joined #yocto | 15:06 | |
| yann | copying an unpacked yocto SDK (not even an extended one) does takes more than that time | 15:06 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 15:14 | |
| *** agodard <agodard!51b9acdd@221.172.185.81.rev.sfr.net> has quit IRC | 15:15 | |
| RP | ecdhe: there is a patch for that in master now | 15:15 |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has quit IRC | 15:29 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 15:31 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 15:32 | |
| RP | JPEW, fray: core-image-sato builds and passes testimage with path filtering :) | 15:34 |
| JPEW | RP: Cool | 15:34 |
| * RP should probably do a binary image compare next, see if anything weird happened. | 15:35 | |
| RP | the more I look at the pseudo logs in WORKDIR, the more I think there are things which are very very wrong today when reusing builddirs | 15:35 |
| *** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-lztkmsucflxwamqu> has quit IRC | 15:38 | |
| kergoth | Hmm, I bet the values returned by the config in python-native probably don't apply to a mingw prebuilt binary windows python installation. Guess I should test it, though | 15:39 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has quit IRC | 15:41 | |
| RP | jonmason: do you have thoughts on the cortex-m0 patch in master-next? | 15:44 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:46 | |
| sgw | RP: there seems to be two paths, one for testimage class that uses OEQemuTarget and the other for HW , which seems to have a QemuTarget class also | 15:53 |
| sgw | The HW/QemuTarget path had a cmd dumper, but the OEQemuTarget did not. | 15:53 |
| RP | sgw: and that works over serial? | 15:55 |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has joined #yocto | 15:55 | |
| RP | (the dump commands are run over the serial interface) | 15:57 |
| sgw | RP: yes the code I provided runs over the qemu serial, since I still had your Took x seconds to login code, I saw that multiple times. | 15:58 |
| RP | sgw: ok, cool. I'm just surprised its this simple! | 15:58 |
| RP | as ever its all about knowing which small number of magic lines to put where :) | 15:59 |
| sgw | Took me a while to figure out is was not going to be complex as I had to backtrace where things where coming from. | 15:59 |
| RP | sgw: we really need to simplify some of it | 16:00 |
| sgw | And then figuring out I did not have 'd' available to get the args and ... | 16:00 |
| RP | sgw: indeed, the lack of d can be a shock :) | 16:00 |
| sgw | Yesh I thought having two qemu targets was wrong, they seem to serve very different purposes. That's a longer term clean-up I think | 16:01 |
| jonmason | RP: rburton mentioned that to me. I was going to take a look after lunch. | 16:01 |
| sgw | It initially confused me because the QemuTarget did have access to the Dumpers, but I figured out the OEQemuTarget is not of the same class, OEQemuTarget is of the OESSHTarget Class | 16:01 |
| RP | jonmason: ok, np. I just need a hint on whether it is right or not :) | 16:02 |
| RP | sgw: those names look quite poor :/ | 16:02 |
| sgw | I will wait until next week and then and if anyone has comments then move it out of RFC, unless your comfortable with it now. | 16:03 |
| RP | sgw: I'll probably put it in testing for builds over the weekend | 16:03 |
| sgw | Sounds fair, how often has the network failure been happening? | 16:03 |
| RP | sgw: it sounds good at least :) | 16:03 |
| RP | sgw: not very often, just often enough to be annoying | 16:03 |
| RP | once every week or two | 16:03 |
| jonmason | RP: the previous m0plus looked okay. So I'm going to assume without looking that it should be fine. But I'll have an answer in an hour or so | 16:04 |
| RP | jonmason: np, I just didn't know it ross had talked to you | 16:04 |
| *** carlsb3rg <carlsb3rg!c147afcf@193.71.175.207> has quit IRC | 16:05 | |
| jonmason | Similarly, I have cortex m series queued but was waiting on the cortex a stuff to get sorted first | 16:05 |
| jonmason | That's also why I was messing with zephyr, as it's a good test bed | 16:05 |
| RP | jonmason: I've left that series as I don't think its right unfortunately :( | 16:05 |
| RP | if we make changes like that this late in the release I need to be convinced they're right and I'm not (I think I said as much) :/ | 16:06 |
| jonmason | I'm doing v3 now, I just keep getting pulled into other stuff. It should be out today | 16:06 |
| RP | jonmason: ok | 16:07 |
| jonmason | And if this needs to wait until after gatesgarth is released, that seems reasonable | 16:08 |
| RP | jonmason: If its just adding files we have a bit more flexibility, will depend on the changes | 16:09 |
| jonmason | Then I'll take that into account and maybe do some of the organization in a follow-up series | 16:15 |
| kergoth | Hmm, I wonder if it'd be useful to create a recipetool or devtool command to take a specified .bb file and shove it into a temporary layer and build it there after adjusting priorities and verifying it'll be the selected provider, as an alternative to bitbake -b | 16:17 |
| kergoth | course that assumes it's not in one already, so perhaps not | 16:18 |
| ecdhe | is yocto sumo so old that I should be using something else? | 16:18 |
| kergoth | just thinking about quick and dirty work on a new recipetool-create'd recipe | 16:18 |
| kergoth | https://wiki.yoctoproject.org/wiki/Releases shows it was released on april 2018 | 16:18 |
| kergoth | and has a current upstream support level of EOL | 16:18 |
| ecdhe | A vendor shipped a bsp based on sumo in mid 2019 | 16:19 |
| kergoth | but it depends on your perspective, of course | 16:19 |
| sgw | RP: I am looking at something else regarding package.manifest creation, ideally a way to create a custom manifest. I am thinking of 2 possibly ways, I am sure there are more. 1) bbclass that gets inherited or 2) extend the format_pkg_list() in lib/oe/utils.py to take a custom ret_format and handle in there with getVar("TBD_CUSTOM_MANIFEST"). Thoughts? | 16:19 |
| ecdhe | How hard is it to upgrade? I've never done it, but it looks like I might need to based on the fact that it can no longer pull source for stuff like htop and sudo | 16:19 |
| RP | sgw: I remember nothing about package manifests :/ | 16:20 |
| RP | ecdhe: have a read of the migration guides in the manual for thud and later ? | 16:20 |
| RP | If you're just using standard yocto project its easier than a ton of BSPs and custom recipes | 16:21 |
| ecdhe | RP, a board vendor shipped us a bsp based on sumo. But I've got another board for which the vendor shipped buildroot. | 16:23 |
| sgw | RP: fair enough, I will dig around some and come up with a proposal, more about checking on creating interface that a bbclass could use vs have kind of script called from a variable to create the manifest | 16:23 |
| RP | ecdhe: we can't know how hard that BSP will be to work with something more recent | 16:24 |
| ecdhe | I wanted the new board to use yocto instead. Since the new board's buildroot just downloads a U-Boot and kernel source tree and builds them, I cloned the first vendor's Sumo project and changed the git repos, defconfigs, device tree references etc, and have, for the most part, gotten yocto to execute the same basic build steps that buildroot was taking. | 16:25 |
| ecdhe | RP: My build is failing at the moment because I can't acquire all the package source. | 16:25 |
| RP | ecdhe: I'd probably have done something similar to that FWIW | 16:26 |
| ecdhe | But I'd really prefer to get my ported BSP fulling building on sumo before I migrate to a newer version | 16:26 |
| RP | ecdhe: that would seem sensible | 16:26 |
| ecdhe | Since I have the original sumo build environment (all 60 gigs) I might be interested in transplanting cached copies of the no-longer attainable source | 16:27 |
| ecdhe | Then once I get a build I can migrate to Dunfell or so | 16:27 |
| ecdhe | or even the pending October release | 16:28 |
| RP | ecdhe: seems reasonable to me. dunfell is our LTS so I'd try and get to that at least | 16:29 |
| *** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC | 16:31 | |
| ecdhe | RP, my sumo build is failing saying it can't download http://ftp.sudo.ws/sudo/dist/sudo-1.8.22.tar.gz | 16:33 |
| ecdhe | If I find sudo-1.8.22.tar.gz in my old yocto workspace, do I just copy it to the same relative path in the new workspace? | 16:34 |
| ecdhe | It's in ./build/downloads/sudo-1.8.22.tar.gz | 16:35 |
| ecdhe | or is there some other step that I'll need to take | 16:36 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-204.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 16:36 | |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has quit IRC | 16:36 | |
| RP | ecdhe: that will work. I'm surprised it doesn't find it from the yocto project mirrors | 16:37 |
| qschulz | RP: don't underestimate the power of badly written BSP layers and wrappers :) | 16:37 |
| qschulz | RP: I wouldn't be surprised if they replaced the mirrors with theirs or entirely removed them :) | 16:37 |
| RP | qschulz: I'm doing my best not to think too hard about it | 16:38 |
| qschulz | RP: hehehe, if that makes you sleep better :D | 16:38 |
| qschulz | ecdhe: are you building on the same machine different Yocto projects? In that case, you can share the DL_DIR and SSTATE_DIR, it should be just fine (and if it isn't, scream at vendor) | 16:39 |
| qschulz | and not have to duplicate your download directory (and benefit from shared sstate cache dir :) ) | 16:39 |
| RP | rburton: good news is that buildhistory on an image without my pseudo changes built in one builddir and one with the changes don't show any permissions issues. They do show pam differences :/ | 16:40 |
| *** mckoan is now known as mckoan|away | 16:42 | |
| RP | JPEW: nice build corruption issue. PACKAGECONFIG_append_pn-shadow = " pam", bitbake shadow, remove that line, bitbake shadow, /etc/pam.d/* still present | 16:50 |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 16:52 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:52 | |
| JPEW | Hmm, because ${D} isn't cleared out? | 16:56 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 16:57 | |
| rburton | nice | 16:59 |
| qschulz | jonmason: Reviewed-off-by? nice typo :D | 17:01 |
| jonmason | crap | 17:01 |
| RP | JPEW: WORKDIR | 17:01 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 17:02 | |
| rburton | RP: it does globbing in WORKDIR? | 17:02 |
| RP | rburton: yes, its clear when you read the recipe why it breaks | 17:02 |
| RP | its the second time recently I've seen this :( | 17:03 |
| rburton | that's a horrible thing to do | 17:03 |
| RP | I'm starting to think the fetcher shouldn't just dump files in WORKDIR | 17:03 |
| JPEW | RP: Oh, ya. That's a really gross way to do the recipe | 17:04 |
| JPEW | Using PACKAGECONFIG in SRC_URI seems like a bit of a red flag | 17:05 |
| RP | I noticed a problem with the ssh pregen keys recipe where if you remove a file from the ssh sources directory, the file still ends up in the image :( | 17:05 |
| RP | its because the fetcher evidently doesn't/can't clean up WORKDIR | 17:06 |
| RP | there SRC_URI = "file://sshdir/" so its a directory of files | 17:07 |
| rburton | hm fun | 17:08 |
| RP | two issues are different but related :( | 17:09 |
| rburton | i wonder how much will break if WORKDIR isn't actually the parent of S and friends | 17:11 |
| rburton | ie WORKDIR was /work/ alongside /temp/ and so on | 17:11 |
| rburton | then you could blast it away on re-fetch | 17:11 |
| RP | rburton: I think fetch just had to stop poking into WORKDIR. Maybe we mark recipes as "transitioned" with a flag that changes the fetcher behaviour? | 17:12 |
| RP | and then warn on the recipes which don't set it? | 17:12 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:12 | |
| rburton | where would the fetcher put files otherwise? | 17:12 |
| RP | rburton: named directory configured by a variable? or just a common name? | 17:13 |
| rburton | call it WORKDIR and put it in /work/ ;) | 17:13 |
| RP | ${WORKDIR}/fetched-files/ ? | 17:13 |
| moto-timo | for bug 13803, I noticed: | 17:14 |
| moto-timo | ERROR: setUpModule (devtool) [ (subunit.RemotedTestCase) | 17:14 |
| moto-timo | What does the RemotedTestCase mean? | 17:14 |
| RP | moto-timo: oe-selftest -j for parallelism | 17:14 |
| RP | moto-timo: means subunit and testtools are proxing the test results over a pipe from multiple processes | 17:15 |
| moto-timo | RP: thanks. That might explain why I can't get the copytree (directory) target to work | 17:15 |
| qschulz | RP: ${WORKDIR}/oe-local-files ? that'd match what devtool is using :) | 17:15 |
| RP | qschulz: match an existing standard?! ;-) | 17:16 |
| RP | qschulz: seriously, thanks, I hadn't remembered it was doing that | 17:16 |
| moto-timo | I instrumented the heck out of the code, but it's only been passing in files shutil.copy2 mode and so even when I force copytree it's invalid | 17:16 |
| moto-timo | lol | 17:16 |
| moto-timo | ok, I'll run with -j | 17:17 |
| moto-timo | or just send the patch | 17:17 |
| qschulz | RP: been bitten by it :D though... I hate how. We use SRC_URI = "file://oe-local-files.patch;patchdir=.." for patching files coming from upstream recipes.... | 17:17 |
| moto-timo | but I'd rather see it working | 17:17 |
| qschulz | obviously this does not work with devtool putting the local files in a different "directory layout" | 17:18 |
| qschulz | RP: but honestly, +1 for putting files in a different dir than WORKDIR, it's super confusing | 17:19 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 17:20 | |
| qschulz | RP: the issue is with recipes only having "file://"s where you'd actually have S = ${WORKDIR} and that wouldn't work. But that's pretty easy to error on since that wouldn't make any sense anymore | 17:21 |
| qschulz | (thinking out loud :) ) | 17:21 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 17:34 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 17:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:43 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 17:52 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 17:53 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 17:58 | |
| moto-timo | at least the shutils.copytree is being called now, but it hasn't gotten to a test where __pycache__ would be copied yet. Getting close! | 18:05 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 18:08 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 18:10 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 18:14 | |
| *** WillMiles <WillMiles!~Will@209.87.231.80> has quit IRC | 18:14 | |
| *** JonathanCrockett <JonathanCrockett!~textual@c-67-180-231-187.hsd1.ca.comcast.net> has joined #yocto | 18:31 | |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has joined #yocto | 18:33 | |
| jrdn | if devtool reset times out while trying to clean the sysroot how can I manually reset it? I removed the workspace folder but devtool status still lists it as present | 18:34 |
| ecdhe | RP: it built! It built! | 18:48 |
| ecdhe | now, will it run? | 18:48 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 18:49 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 18:49 | |
| *** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 18:55 | |
| ecdhe | RP: eeeetts aliiiieeeeeve!!!! | 19:05 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 19:28 | |
| jonmason | RP: just sent v2 out. Hopefully it is more towards your liking :) | 19:30 |
| RP | ecdhe: great! | 19:30 |
| RP | jonmason: thanks, will take a look | 19:30 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:34 | |
| *** sev_ <sev_!~sev@2003:a:12a:1300:8e16:45ff:fe1e:3785> has left #yocto | 19:34 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:49 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 19:56 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:57 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 20:00 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 20:17 | |
| ecdhe | Within a recipe that builds some C code, you might have serveral tasks, like do_fetch, do_configure, do_build, do_install, do_deploy. Steps like fetch, build, install, deploy cause data to be copied/transformed from one domain/directory to another. | 20:28 |
| *** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto | 20:29 | |
| ecdhe | in this situation, do_build ${S} => ${B}, do_install ${B} => ${D}, do_deploy ${B} => ${DEPLOY_DIR} | 20:29 |
| ecdhe | What about when you're not building C code? What if you're downloading a static file from a http server and putting it right into the deploy directory | 20:30 |
| *** zkrx <zkrx!~quassel@adsl-89-217-234-211.adslplus.ch> has quit IRC | 20:31 | |
| ecdhe | The do_fetch task would still bring the file from the remote webserver to ${S} | 20:31 |
| ecdhe | But in what task would you perform the ${S} => ${DEPLOY_DIR} copy? | 20:31 |
| ecdhe | Does it break convention too badly to have do_deploy() copy from ${S} instead of ${B}? | 20:32 |
| *** zkrx <zkrx!~quassel@adsl-89-217-234-211.adslplus.ch> has joined #yocto | 20:35 | |
| *** zkrx <zkrx!~quassel@adsl-89-217-234-211.adslplus.ch> has quit IRC | 20:38 | |
| *** zkrx <zkrx!~quassel@adsl-89-217-234-211.adslplus.ch> has joined #yocto | 20:43 | |
| kergoth | ecdhe: nothing wrong with that, plenty of recipes do it. a lot of upstream project buildsystems don't support a source vs build/object separation. | 20:43 |
| *** manuel1985 <manuel1985!~manuel@089144219251.atnat0028.highway.a1.net> has joined #yocto | 20:46 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:01 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 21:14 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 21:16 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:19 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:21 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:26 | |
| ecdhe | Thanks kergoth. I just want to avoid making unmaintainable messes, and I haven't worked with yocto long enough to have an intuitive sense of smell for worst practices | 21:31 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 21:37 | |
| RP | The fun thing about testing do_unpack rm improvements is you break build directories quickly :( | 21:59 |
| RP | kergoth: think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=7adaca6ff63e0d3495a1cd0cc5e5221b8c82a4a6 will work to fix do_unpack? | 22:10 |
| *** ak77 <ak77!c12e4b03@193.46.75.3> has quit IRC | 22:12 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:15 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:40 | |
| pev | dumb question : im trying to modify QB_OPT_APPEND in local.conf but can't see any changes taking effect when using "runqemu". Am I missing something obvious? | 22:45 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:46 | |
| pev | bitbake -e can determine its an extra operation when added but no change in value so I guess someone overwrites the value after local.conf is parsed. If so is there a "right" way to do this? | 22:46 |
| kergoth | RP: seems reasonable. i'm assuming utils.remove() uses rm, not python? i'd have used pathlib personally, but that's personal preference, the concept is sound. the other thing i'd wonder is whether anyone is using prefuncs on do_unpack, as the order would change if that's the case. i doubt anyone is, though :) | 22:47 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 22:48 | |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 22:58 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:10 | |
| *** nrossi1 <nrossi1!nrossimatr@gateway/shell/matrix.org/x-uhtnmbpdsanbfpsx> has joined #yocto | 23:10 | |
| *** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 23:11 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-lnlgwqxekmiktzlx> has quit IRC | 23:13 | |
| *** zbooth- <zbooth-!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC | 23:13 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 23:13 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 23:14 | |
| *** JonathanCrockett <JonathanCrockett!~textual@c-67-180-231-187.hsd1.ca.comcast.net> has quit IRC | 23:15 | |
| RP | kergoth: I have found meson.bbclass is making some assumptions but that is easily fixed | 23:17 |
| RP | kergoth: utils.remove uses a mixture of things depending on what we've found is fastest | 23:17 |
| RP | kergoth: we have a different fun class of bug. Modify do_unpack and it will rerun but prepare_recipe_sysroot does not. It will however uninstall "bad" dependencies from the sysroot | 23:29 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
