| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:08 | |
| *** BobPungartnik <BobPungartnik!~Pung@187.113.146.96> has joined #yocto | 00:17 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 246 seconds) | 01:03 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.193> has joined #yocto | 01:08 | |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC (Ping timeout: 265 seconds) | 01:08 | |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto | 01:11 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 258 seconds) | 01:12 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 01:16 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 01:36 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:26 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 02:27 | |
| *** camus1 is now known as camus | 02:27 | |
| *** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto | 03:01 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.193> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 03:29 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.193> has joined #yocto | 03:29 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 03:33 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 03:33 | |
| *** amitk <amitk!~amit@103.208.69.73> has joined #yocto | 03:48 | |
| *** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has quit IRC (Quit: ZNC - http://znc.in) | 04:03 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 268 seconds) | 04:05 | |
| *** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has joined #yocto | 04:05 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 04:41 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 04:46 | |
| *** roussinm <roussinm!~mroussin@184.145.222.193> has quit IRC (Quit: WeeChat 3.3-dev) | 05:24 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:54 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:06 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:07 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 245 seconds) | 06:15 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.193> has quit IRC (Ping timeout: 258 seconds) | 06:16 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has joined #yocto | 06:24 | |
| *** frieder <frieder!~frieder@i59F727AA.versanet.de> has joined #yocto | 06:30 | |
| *** mckoan|away is now known as mckoan | 06:37 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Remote host closed the connection) | 06:48 | |
| *** alimon <alimon!~alimon@ec2-54-225-101-41.compute-1.amazonaws.com> has quit IRC (Read error: Connection reset by peer) | 06:50 | |
| *** alimon <alimon!~alimon@ec2-54-225-101-41.compute-1.amazonaws.com> has joined #yocto | 06:52 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 06:53 | |
| *** hpsy <hpsy!~hpsy@85.203.15.12> has joined #yocto | 06:56 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 06:56 | |
| *** zpfvo <zpfvo!~fvo@88.130.220.89> has joined #yocto | 06:57 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Remote host closed the connection) | 07:00 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 255 seconds) | 07:03 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 07:06 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 07:06 | |
| *** camus1 is now known as camus | 07:06 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 07:10 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:11 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.129> has joined #yocto | 07:16 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:21 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 252 seconds) | 07:25 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 07:28 | |
| *** _franck_ <_franck_!~fjullien@70.5.9.93.rev.sfr.net> has left #yocto (The Lounge - https://thelounge.chat) | 07:29 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 07:31 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 256 seconds) | 07:34 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:39 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 07:39 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 07:40 | |
| *** camus1 is now known as camus | 07:40 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 07:41 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 07:42 | |
| ykrons | Hello all | 08:04 |
|---|---|---|
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 268 seconds) | 08:07 | |
| ykrons | I was often using devshell to rework some patches and use quilt to update them. Today I would like to do the same with devtool but it seems patches are applied in the source tree and there is no way to use quilt. | 08:07 |
| ykrons | So what is the proper way to applied remove patches during development using devtool? | 08:07 |
| qschulz | JPEW: re: pyrex. I removed the container image locally, re-sourced pyrex-init-buildenv, it fetched from docker.io correctly. Then I re-sourced it once again to make sure it'd take the "local copy". It seems to work as good as before. | 08:08 |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 08:08 | |
| qschulz | ykrons: devtool is using git and you have a commit for each patch applied, so you can edit them manually | 08:09 |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Read error: Connection reset by peer) | 08:15 | |
| ykrons | qschulz: thanks. and reworking a commit will update accordingly the corresponding patch? | 08:16 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 08:16 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 08:18 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 08:18 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:19 | |
| qschulz | ykrons: I think there's a devtool command for that (a subcommand of devtool finish?) | 08:24 |
| qschulz | I replace the patches manually by running git format-patch and overwrite the original patch (or add it in a bbappend) | 08:24 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 08:28 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 08:28 | |
| ykrons | qschulz: ok thanks | 08:28 |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 258 seconds) | 08:31 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 08:33 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 08:38 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:38 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 08:48 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:55 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 252 seconds) | 08:58 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 09:06 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:07 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:07 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 09:09 | |
| *** camus1 is now known as camus | 09:09 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 255 seconds) | 09:21 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 09:25 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 240 seconds) | 09:27 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 250 seconds) | 09:36 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 09:39 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.129> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 09:40 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 09:49 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 09:53 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Quit: WeeChat 3.1) | 09:54 | |
| OutBackDingo | ok, ive got a thought, all the newest "broken" link fetches, mostly due to github changes from master to main branches. Is there possibly a way to test like bitbake fetch world, find everything broken and fix it :) | 09:56 |
| RP | OutBackDingo: like "bitbake universe -c fetch"? :) | 09:57 |
| OutBackDingo | sure, then i can fixup all the brokenness and supply a single patch :) | 09:58 |
| *** mattsm is now known as Guest9382 | 09:58 | |
| *** Guest9382 <Guest9382!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Killed (osmium.libera.chat (Nickname regained by services))) | 09:58 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 09:58 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Read error: Connection reset by peer) | 09:59 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 09:59 | |
| wyre | why do you think I'm having this problem when shutting down the SoM https://bpa.st/ZMJQ from the bash cli? | 10:22 |
| *** BobPungartnik <BobPungartnik!~Pung@187.113.146.96> has quit IRC (Quit: Leaving) | 10:33 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 10:34 | |
| LetoThe2nd | yo dudx | 10:35 |
| Ad0 | upgrading from warrior to dunfell wasn't that bad | 10:36 |
| Ad0 | what do you do though when an out of tree kernel calls functions in a newer kernel coming with the newer yocto that isn't there anymore :P I patched the kernel by reintroducing the function but that can't go on forever | 10:43 |
| qschulz | Ad0: you port the out of tree driver to the newer kernel | 10:45 |
| Ad0 | yeah like know that haha | 10:45 |
| qschulz | check what the function was replaced with (if it was) in git log of the kernel and do the same for your out-of-tree driver | 10:45 |
| Ad0 | yeah | 10:45 |
| qschulz | surround all of those changes with a nice #ifdef with the version of the kernel and you're good to go | 10:46 |
| Ad0 | https://github.com/torvalds/linux/commit/cc16567e5a8a7bb9439ef61ab80069acdd33f76f#diff-4c37105797392cd2ca5f5d9af97e03e71ddafdd74cafa81b7e6ac1d20bcad37e | 10:49 |
| Ad0 | no idea what the replacement for that would be | 10:51 |
| Ad0 | I thought the mantra was "never break anything" but they did there | 10:52 |
| Ad0 | if the driver was in-kernel it would have stayed | 10:53 |
| qschulz | Ad0: the mantra is: out-of-tree driver, your shit to fix :) | 10:58 |
| Ad0 | haha | 10:59 |
| Ad0 | I guess | 10:59 |
| qschulz | the only thing that is guaranteed to stay consistent across releases is the sysfs ABI | 10:59 |
| Ad0 | the chip supplier has to fix it but for now I patched the kernel by reintroducing the function | 10:59 |
| qschulz | and it's a PITA | 10:59 |
| qschulz | (from kernel dev pov, but very good for userspace) | 10:59 |
| Ad0 | and that's what they do too. they have the same patch | 10:59 |
| Ad0 | but one day that function will break | 11:00 |
| qschulz | Ad0: yes, and you'll need to fix it. If you want the kernel to not break your out-of-tree custom driver, upstream it | 11:00 |
| Ad0 | hehe | 11:03 |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Quit: %quit%) | 11:08 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto | 11:09 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:31 | |
| *** Guest26 <Guest26!~Guest26@64.222.164.134> has quit IRC (Quit: Client closed) | 11:58 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:58 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 11:59 | |
| *** camus1 is now known as camus | 11:59 | |
| JPEW | qschulz: thanks | 12:03 |
| wyre | what poky version do you recommend me to work with? | 12:10 |
| rburton | latest release | 12:10 |
| wyre | Hardknott? | 12:10 |
| wyre | the LTS is Dunfell | 12:11 |
| rburton | yeah either | 12:11 |
| rburton | LTS will still EOL at some point, but there'll be a new LTS to replace it | 12:11 |
| rburton | depends on what sort of cadence you want to follow | 12:11 |
| rburton | LTS releases are every two years. other releases are every six months, but are EOL when the next one is released. | 12:12 |
| rburton | So if you use a non-LTS release you need to keep up | 12:12 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 12:27 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 12:30 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 12:46 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 258 seconds) | 12:50 | |
| *** jsandman <jsandman!~jsandman@95.179.203.88> has quit IRC (Quit: Ping timeout (120 seconds)) | 12:55 | |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Read error: Connection reset by peer) | 12:55 | |
| *** jsandman <jsandman!~jsandman@95.179.203.88> has joined #yocto | 12:55 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 12:56 | |
| *** alejandrohs <alejandrohs!~alejandro@cpe-70-112-59-126.austin.res.rr.com> has quit IRC (Ping timeout: 265 seconds) | 12:57 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 12:58 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 12:58 | |
| *** alejandrohs <alejandrohs!~alejandro@cpe-70-112-59-126.austin.res.rr.com> has joined #yocto | 12:58 | |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto | 13:00 | |
| *** yates_home <yates_home!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has joined #yocto | 13:02 | |
| yates_home | in my build folder there is an elf application that is used in run.do_uboot_mkimage: <build>/tmp/work/qemucsky-poky-linux/linux-csky/5.12-r0/recipe-sysroot-native/usr/bin/uboot-mkimage | 13:04 |
| yates_home | where is the source for this application? | 13:04 |
| rburton | $ git grep uboot-mkimage | 13:09 |
| rburton | recipes-bsp/u-boot/u-boot-tools.inc: install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage | 13:10 |
| *** mcc_ <mcc_!~mccc@c-73-239-24-228.hsd1.wa.comcast.net> has joined #yocto | 13:14 | |
| Ad0 | I did devtool workspace finish , but yocto insists to keep building the workspace kernel sources | 13:15 |
| Ad0 | is there some documentation to properly finish and exit the workspace so it goes back to normal yocto sources w/patch? | 13:15 |
| *** creich_ <creich_!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 13:15 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@37.163.172.33> has joined #yocto | 13:15 | |
| yates_home | rburton: thanks. good tip. | 13:15 |
| *** zyga__ <zyga__!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 13:16 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Killed (sodium.libera.chat (Nickname regained by services))) | 13:17 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 13:17 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@37.163.172.33> has quit IRC (Client Quit) | 13:17 | |
| *** splatch_ <splatch_!~lukasz@18.ip-217-182-76.eu> has joined #yocto | 13:18 | |
| *** chrysh_ <chrysh_!~chrysh@someserver.de> has joined #yocto | 13:18 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** tkoskine <tkoskine!tkoskine@kapsi.fi> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.137.82> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** splatch <splatch!~lukasz@18.ip-217-182-76.eu> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** creich <creich!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** mccc <mccc!~mccc@c-73-239-24-228.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** chrysh <chrysh!~chrysh@someserver.de> has quit IRC (Ping timeout: 255 seconds) | 13:18 | |
| *** tkoskine <tkoskine!tkoskine@kapsi.fi> has joined #yocto | 13:18 | |
| *** Vonter <Vonter!~Vonter@2406:7400:73:8f06:ba27:ebff:fe40:73d2> has joined #yocto | 13:18 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 13:19 | |
| yates_home | Ad0: it's been a long time since i used devtool, but a) properly finishing it should work and b) there is a good bit of documentation on the tool. | 13:19 |
| Ad0 | ok | 13:19 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 13:20 | |
| Ad0 | I need to patch a kernel driver | 13:20 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 13:20 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.137.82> has joined #yocto | 13:20 | |
| yates_home | yeah, thats a perfect use-case, i think | 13:20 |
| Ad0 | https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#using-devtool-to-patch-the-kernel | 13:20 |
| Ad0 | I followed this one | 13:20 |
| Ad0 | first off "devtool modify linux-yocto" doesn't work. I have to do virtual/kernel | 13:21 |
| Ad0 | I have some confusion between virtual/kernel and linux-raspberrypi, etc | 13:21 |
| Ad0 | is virtual/kernel some magic alias? | 13:23 |
| yates_home | Ad0: virtual/kernel is defined somewhere to be a default kernel. | 13:23 |
| Ad0 | my kernel is called linux-raspberrypi | 13:23 |
| Ad0 | but starting devtool with that gives error | 13:23 |
| Ad0 | virtual/kernel works. why? :) | 13:23 |
| Ad0 | somehow devtool finish does not give error on linux-raspberrypi | 13:24 |
| * Ad0 is very confused | 13:24 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 13:24 | |
| Ad0 | also, in warrior it started an interactive shell with screen, I can't seem to see this now | 13:25 |
| rburton | sounds like you're not really using linux-rpi | 13:25 |
| Ad0 | it does run the recipes and overrides with that name | 13:26 |
| yates_home | Ad0: search for "PREFERRED PROVIDER" in your custom layer or your build conf's | 13:26 |
| Ad0 | recipes-kernel/linux/linux-raspberrypi | 13:26 |
| rburton | oh right, you said 'first off "devtool modify linux-yocto" doesn't work.' | 13:26 |
| rburton | yes: you are using linux-raspberrypi | 13:26 |
| Ad0 | no matches | 13:27 |
| Ad0 | sorry I meant "devtool modify linux-raspberrypi" | 13:27 |
| rburton | to bitbake your kernel, what do you type? | 13:27 |
| Ad0 | I don't explicitly do that I built my image | 13:27 |
| Ad0 | I will try it again | 13:27 |
| Ad0 | it worked now with "devtool modify linux-raspberrypi" . | 13:28 |
| Ad0 | must have been some strange things going on in the upgrade :) | 13:28 |
| rburton | youd only modify linux-yocto if that was the kernel you had selected | 13:28 |
| Ad0 | yeah | 13:29 |
| rburton | ideally, just use virtual/kernel everywhere | 13:29 |
| Ad0 | so that's the alias for the current kernel | 13:29 |
| Ad0 | yeah I should really use the virtual/kernel | 13:29 |
| Ad0 | is it dangerous to do "devtool modify linux-raspberrypi" and then use virtual/kernel for finish , for example? | 13:30 |
| Ad0 | also, I have a full kernel config (defconfig) I want to overwrite, what is the most appropiate way to do that in my layer? I have seen misc posts with different approaches. | 13:33 |
| rburton | misc posts are often wrong | 13:34 |
| rburton | the documentation tends to be right: https://docs.yoctoproject.org/kernel-dev/common.html#creating-a-defconfig-file | 13:34 |
| rburton | one would hope that devtool doesn't get confused if you use different aliases for the same recipe, so it *shouldn't* break | 13:35 |
| rburton | https://docs.yoctoproject.org/kernel-dev/common.html#changing-the-configuration has more details re defconfig | 13:35 |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:40 | |
| smurray | RP JPEW: if I have a stuck bitbake-server process, any pointers on digging out why? | 13:40 |
| JPEW | Is it possible to attach PDB to a stuck process? | 13:41 |
| Ad0 | thanks rburton :) | 13:42 |
| smurray | JPEW: I'm able to attach with gdb and poke with the python extensions, e.g. py-bt | 13:42 |
| Ad0 | I recall that doing that gave me "defconfig was supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping SRC_URI defconfig" | 13:43 |
| Ad0 | didn't happen in warrior, happens in dunfell | 13:43 |
| rburton | most likely meta-rpi using KBUILD_DEFCONFIG | 13:43 |
| smurray | JPEW: I was doing a run with plain master poky on a loaner machine, so I have a suspicion it might be hash equiv not shutting down, but there's like > 100 threads ;) | 13:44 |
| Ad0 | does this mean it ditches my defconfig, or should I just ignore it | 13:44 |
| smurray | JPEW: err, nm, > 100 stack frames, -ENOCOFFEE | 13:44 |
| rburton | Ad0: "dropping SRC_URI defconfig" sounds pretty clear. unset KBUILD_DEFCONFIG too | 13:45 |
| rburton | ? | 13:45 |
| smurray | JPEW: it's sitting in hash equiv's run_loop_forever, hence my thinking it's stuck | 13:46 |
| Ad0 | yeah just wondered if it dropped the variable or the file itself :) was a bit unclear to me hehe | 13:46 |
| JPEW | smurray: On the client side? | 13:46 |
| smurray | JPEW: looks like server based on this: https://paste.debian.net/1205243 | 13:48 |
| JPEW | smurray: Ah you are using `BB_HASHSERVE = "auto"` ? | 13:49 |
| smurray | indeed | 13:49 |
| smurray | there was a reason I asked for that run on the autobuilder | 13:49 |
| JPEW | Right | 13:49 |
| smurray | this is stock poky defaults | 13:49 |
| JPEW | So bitbake server itself is waiting for the hash server to exit? | 13:49 |
| smurray | I think that's what it means | 13:50 |
| override | running in to weird errors after setting up a distro. any debugging ideas would be highly appreciated. ERROR: opentrons-ot3-image-1.0-r0 do_image_complete: The recipe opentrons-ot3-image is trying to install files into a shared area when those files already exist. Those files and their manifest location are: | 13:51 |
| override | /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.manifest | 13:51 |
| override | (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete) | 13:51 |
| override | /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.wic.bmap | 13:51 |
| override | (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete) | 13:51 |
| smurray | JPEW: it's the same failure mode as was being seen with the reworked pr serv AIUI | 13:51 |
| override | /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/image-Reference-Minimal-Image.json | 13:51 |
| override | (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete) | 13:51 |
| override | /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.tar.xz | 13:51 |
| override | (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete) | 13:51 |
| override | sorry about the spam.. | 13:51 |
| override | was trying to paste a pastebin link sorry so sorry | 13:51 |
| override | just ignore that for now actually | 13:51 |
| JPEW | smurray: Hmm, I wonder if the server even got the singal | 13:59 |
| JPEW | the SIGTERM signal that is | 14:00 |
| override | ok so I keep getting the "trying to install files into a shared are where the files already exisit". for wiping out tmp do we just rm -rf it or is there some better way of going about it? | 14:00 |
| smurray | JPEW: yeah, that's occurred to me just now as well from looking at the code | 14:00 |
| JPEW | smurray: Can you put a break point in the signal handler in asyncrpc/serv.py and manually send the process a SIGTERM? | 14:01 |
| smurray | JPEW: I'll try, not used the gdb python extensions very much before | 14:02 |
| JPEW | smurray: Me either | 14:03 |
| qschulz | override: rm -rf it, or I think just removing the inode of the directory is enough? don't remember, but I always rm -rf :) | 14:05 |
| qschulz | make sure you don't have your sstate-cache and downloads dir in your tmp | 14:06 |
| override | qschulz: not sure why but i did an rm -rf on my deploy folder too | 14:07 |
| qschulz | override: shouldnt deploy be in your tmp dir by default? | 14:07 |
| override | ohhh, maybe its not.. remeber rburton pointed that out once. my bso is putting it elsewhere | 14:08 |
| override | bsp* | 14:08 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:10 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving) | 14:11 | |
| JPEW | smurray: I wonder if there is still a connected client that is preventing the loop from exiting | 14:12 |
| *** rcw <rcw!~rcwoolley@45.72.203.103> has quit IRC (Quit: Leaving) | 14:14 | |
| smurray | JPEW: there are no other processes at this point that I see, just this one cooker + hash equiv server set after a oe-selftest run with a bunch more errors than expected | 14:18 |
| smurray | JPEW: looking in cooker, it's where you'd expect, it's waiting on the join after the process.terminate | 14:19 |
| JPEW | Yep | 14:19 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 14:20 | |
| JPEW | Too bad the async server doesn't log when it gets a new client connection | 14:21 |
| smurray | yeah, I suspect it might take a bit of instrumentation to work through this | 14:29 |
| JPEW | smurray: How easily can you reproduce? | 14:30 |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 14:30 | |
| smurray | JPEW: somewhat reliably, I suspect, but it takes hours since it's running oe-selftest | 14:30 |
| smurray | JPEW: heh, I've found examples of setting breakpoints on python function name, but they're all for py2, and of course the unicode stuff in py3 makes them obsolete | 14:32 |
| JPEW | Ok. I'll give you a new patch with some logging | 14:32 |
| JPEW | I *think* I might know what the problem is | 14:32 |
| JPEW | Or at least I think I can fix it if the theory is that there is a dangling client preventing the loop from exiting | 14:33 |
| *** Guest26 <Guest26!~Guest26@64.222.164.134> has joined #yocto | 14:33 | |
| Ad0 | rburton, "ERROR: No recipe named 'virtual/kernel' in your workspace | 14:33 |
| Ad0 | " even if I did "devtool modify virtual/kernel" | 14:33 |
| Ad0 | first I did "devtool modify virtual/kernel" - that worked, then "devtool build virtual/kernel". | 14:34 |
| smurray | JPEW: would there be an open socket around from that that I could poke around for? or I can maybe dig down to look at the asyncio loop object contents in gdb... | 14:36 |
| JPEW | smurray: Good call! there should be a unix domain socket in /proc/PID/fds | 14:36 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 14:40 | |
| smurray | JPEW: there are a few: https://paste.debian.net/1205248/ | 14:40 |
| JPEW | K | 14:41 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 14:45 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 14:57 | |
| JPEW | smurray: are you sure it's stuck in loop.run_forever()? | 14:59 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 15:00 | |
| smurray | JPEW: every time I attach to the process it's in there, so I'd say yes? | 15:01 |
| JPEW | smurray: Ok, can you post the callstack? | 15:01 |
| smurray | JPEW: this, you mean?: https://paste.debian.net/1205243 | 15:02 |
| JPEW | smurray: Ya thanks | 15:02 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer) | 15:04 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 15:04 | |
| smurray | JPEW: this gets truncated, but might be helpful: https://paste.debian.net/1205251/ | 15:05 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer) | 15:05 | |
| smurray | JPEW: I notice the loop has a _stopping=False internal value | 15:05 |
| JPEW | Also _closed=False | 15:05 |
| JPEW | So I think it's not getting the signal for some reason | 15:06 |
| smurray | JPEW: yeah, but it's unclear to me how that SIGTERM would get dropped | 15:06 |
| JPEW | Either it's blocked, or the signal arrived before the server installed the handler.... | 15:07 |
| JPEW | Hmm, I but I can test that :) | 15:08 |
| JPEW | smurray: What test is it failing on? | 15:09 |
| smurray | JPEW: I don't believe it's any specific test, that's been the problem, random failures under heavy load | 15:09 |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 15:14 | |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer) | 15:15 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 15:19 | |
| JPEW | smurray: Ok, I think maybe I can reproduce it in a simple test case, I'll push it up and see what you think | 15:19 |
| smurray | JPEW: if you have logging or a potential fix, I can kick off a run, would hopefully see results later this aft or in the evening | 15:20 |
| JPEW | K. The fix is a little more involved... but I'll work on one | 15:20 |
| smurray | heh, even logging to confirm the problem would be good ;) | 15:21 |
| JPEW | I *think* that the loop not being in the _closed state is sufficient, but yes, I'll add some logging for the signal handler | 15:22 |
| RP | smurray, JPEW: if/as/when there are patches you think I should merge, can you point me at them. I don't know what to with the ones in -next really now :/ | 15:25 |
| JPEW | OK | 15:26 |
| JPEW | I'll take a look at the patches in -next and see what needs done after I write up the proposed fix | 15:26 |
| smurray | RP: I think you just have a couple of minor bits, not the whole pr server rework to use asyncrpc? | 15:28 |
| RP | smurray: correct, just not sure if those should be going in or not | 15:29 |
| smurray | RP: the bad message error message change seems innocuous enough, the 30s timeout for the client is maybe more debatable | 15:32 |
| smurray | RP: but if that's working on the autobuilder, then it seems unlikely to be a problem in general perhaps | 15:34 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 15:34 | |
| JPEW | If the theory is correct, it's only a problem under high load when bitbake-server attempts to exit before the hashserver/prserver have installed their signal handler (so unlikely in cases other than the AB) | 15:35 |
| JPEW | It's a race basically | 15:36 |
| smurray | ah, interesting | 15:44 |
| smurray | I have a change in my local work to shift where the loop gets created that I could maybe repurpose to block for that | 15:44 |
| JPEW | The fix is to mask of the SIGTERM signal before we start the server so that inherits that mask, then unblock the signal in the hashserve process after it's install the handler (which will immediately deliver any pending signals) | 15:45 |
| smurray | ah, much better than my thought ;) | 15:45 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.51> has joined #yocto | 15:45 | |
| JPEW | I'm putting a wrapper in AsyncServer to do this so it's easier | 15:46 |
| smurray | JPEW: do you think there's still benefit to shifting the asyncio loop creation into the child process? | 15:46 |
| JPEW | smurray: I'm not sure | 15:46 |
| JPEW | Lets see if this fixes it first | 15:46 |
| smurray | okay | 15:47 |
| rfs613 | what could be causing the "do_build" step of every recipe to have a dependency on "db.do_package_write_deb" ? | 16:09 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 16:09 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 16:11 | |
| smurray | rfs613: deb packaging is turned on, i.e. package_deb is in PACKAGE_CLASSES | 16:13 |
| rfs613 | smurray: and this needs berkley DB? | 16:14 |
| smurray | rfs613: I'm not sure about dpkg, but I think dnf may, and I believe it's used even with deb | 16:16 |
| rfs613 | smurray: hmm, okay, i'll go digging there... thanks ;-) | 16:16 |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has joined #yocto | 16:17 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 16:17 | |
| smurray | rfs613: no worries, good luck | 16:17 |
| *** zpfvo <zpfvo!~fvo@88.130.220.89> has quit IRC (Remote host closed the connection) | 16:19 | |
| JPEW | RP, smurray : Patch send to bitbake ML | 16:19 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:21 | |
| JPEW | If you comment out the signal.pthread_sigmask() in AsyncServer.serve_as_process(), you should be able to reliably reproduce the bug (the test_slow_server_start) will fail after 300 seconds) | 16:25 |
| smurray | JPEW: okay | 16:33 |
| *** zyga__ <zyga__!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 265 seconds) | 16:36 | |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Read error: Connection reset by peer) | 16:42 | |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto | 16:42 | |
| *** mckoan is now known as mckoan|away | 16:44 | |
| smurray | JPEW: I've put that on top on my plain poky setup and started a run to compare against last night's | 16:51 |
| *** dev1990 <dev1990!~dev@dynamic-62-87-242-228.ssp.dialog.net.pl> has joined #yocto | 16:54 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 16:55 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 16:56 | |
| *** camus1 is now known as camus | 16:56 | |
| rfs613 | noticed small typo in poky/meta/lib/oeqa/manual/toaster-managed-mode.json ... it needs s/PACKAGE_CLASES/PACKAGE_CLASSES/ ... should I report this somewhere? | 17:05 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 17:05 | |
| rburton | rfs613: you can send a patch to openembedded-core@lists.openembedded.org | 17:07 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 17:07 | |
| rburton | or file a bug in bugzilla.yoctoproject.org. the patch would be best :) | 17:07 |
| rfs613 | rburton: patch sent... it's pretty trivial ;-) | 17:11 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 17:13 | |
| rfs613 | I left off the 2nd hunk which added newline at end of file | 17:14 |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 17:16 | |
| override | When we define a custom IMAGE_FSTYPE class as a bbclass, so we need to add that class to some other variable too, or is jsut having that bblass enough? | 17:30 |
| smurray | override: IMGCLASSES would be my guess, see meta/classes/image.bbclass | 17:35 |
| smurray | override: though I'm willing to believe I'm wrong, there's also IMAGE_TYPES in image_types.bbclass, which might be more relevant if it's a new fstype | 17:36 |
| override | ill set IMAGE_FSTYPE to thene class i just eclared and see what breaks | 17:38 |
| smurray | override: I think you add your class's name to IMAGE_CLASSES so it gets pulled in, and your class adds its new type to IMAGE_TYPES | 17:39 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 17:43 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 17:44 | |
| override | smurray: where do i even name the custom image class? the image bbclass which came with my bsp, i dont see the type getting named anywhere | 17:46 |
| smurray | override: I'd need some more context, I think. Is the class adding a new output type like ext4 or the like? | 17:48 |
| override | yeah | 17:48 |
| override | lets say you make a custon image class.. | 17:49 |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:44f2:149e:9572:50da> has joined #yocto | 17:49 | |
| smurray | override: they might just be inheriting in a recipe before setting IMAGE_FSTYPES, I'd probably grep through the BSP layer to see where it's being references | 17:50 |
| smurray | *referenced | 17:50 |
| override | been grepping, ill double check | 17:51 |
| *** kanavin <kanavin!~Alexander@2a02:2454:2a0:cb00:eb83:2e01:3dda:5d46> has joined #yocto | 17:54 | |
| override | maybe all bbclasses with a image_type_ prefixed to their name start getting picked up as possible IMAGE_FSTYPE ? | 17:54 |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Remote host closed the connection) | 17:54 | |
| override | maybe im just being horribly ineloquent as I try to explain this | 17:55 |
| override | lets say I declare some image_type_smurray.bblcass, can I just go ahead and do something like IMAGE_FSTYPE = smurrayimg now? | 17:56 |
| override | thats what my bsp is leading me to belive right now | 17:56 |
| override | or wait, maybe I do need a IMAGE_CLASSES_append before I can start using that image type | 17:58 |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has joined #yocto | 17:58 | |
| override | ok, think I got now, didnt see this when I first grepped t | 17:58 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 255 seconds) | 18:02 | |
| smurray | override: cool | 18:06 |
| *** florian <florian!~florian@dynamic-093-131-018-086.93.131.pool.telefonica.de> has joined #yocto | 18:06 | |
| override | smurray: so the IMAGE_CLASSES_append bit makes sense | 18:07 |
| override | im just appening the new image class to it | 18:07 |
| smurray | yes, that makes sense | 18:07 |
| override | but even now the name being given in IMAGE_FSTYPE has an img at its end.. i dint get where we are defining this name.. | 18:08 |
| override | the image class is called img_type_tezi, i append img_type_tezi to IMAGE_CLASSES_append, but then in IMAGE_FSTYPE i see teziimg getting added | 18:09 |
| override | is that just like some yocto magic or what? | 18:09 |
| override | smurray: see what im trying to get at? ^ | 18:12 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 18:12 | |
| smurray | override: I'd need to see the class, my guess is they're adding teziimg to IMAGE_TYPES in it | 18:12 |
| smurray | override: that's what registers the type for use in IMAGE_FSTYPES, it's not based on the bbclass name | 18:14 |
| override | oh, let me double check.. maybe I wasnt differentiating between my IMAGE_FSTYPES and IMAGE_TYPE as i grepped for teziimg or something | 18:17 |
| *** frieder <frieder!~frieder@i59F727AA.versanet.de> has quit IRC (Remote host closed the connection) | 18:36 | |
| override | smurray: I still dont get the teziimg bit.. https://github.com/sotaoverride/test-oe-core/blob/main/layers/meta-opentrons/classes/image_type_tezi_ot3.bbclass | 18:44 |
| override | not seeing the IMAGE_TYPES or nothing | 18:45 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.51> has quit IRC (Ping timeout: 255 seconds) | 18:51 | |
| smurray | override: there might be some magic somewhere, the definition of IMAGE_CMD_teziimg and the other stuff there is about what I'd expect, but as you say there's no adding of teziimg to IMAGE_TYPES or CONVERSIONTYPES | 18:52 |
| override | hmmm | 18:56 |
| override | interesting | 18:56 |
| smurray | I'd also be willing to believe I'm missing something about image.bbclass ;) | 18:56 |
| *** yates_home <yates_home!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has quit IRC (Remote host closed the connection) | 18:57 | |
| *** yates <yates!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has quit IRC (Remote host closed the connection) | 18:58 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has joined #yocto | 19:00 | |
| override | smurray: do u know why this class insny including the base image class or something? | 19:00 |
| smurray | override: if it's providing a new type it wouldn't have to, just get added to IMAGE_CLASSES somewhere | 19:02 |
| smurray | override: or in their image recipe, they inherit it manually | 19:02 |
| override | smurray: inheriting core-image would take care of it? | 19:15 |
| override | and how does it work again - in recipes you inherit and in classes you require? | 19:15 |
| smurray | override: AIUI inheriting core-image (and this image) wouldn't drive pulling this image type class in unless it's in IMAGE_CLASSES | 19:16 |
| *** dev1990 <dev1990!~dev@dynamic-62-87-242-228.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 19:17 | |
| smurray | override: inherit is specifically for classes, include/require are for pulling in another file | 19:17 |
| whuang0389 | does anyone have experience configuring LLVM build for an aarch64? | 19:18 |
| whuang0389 | i think im doing something wrong.. host-target triple comes up as x86_64-unknown-linux-gnu lol | 19:18 |
| override | smurray: whats AIUI again? | 19:19 |
| whuang0389 | as i understand it | 19:19 |
| smurray | override: as I understand it | 19:19 |
| whuang0389 | only thing i know in my life right now is AIUI | 19:19 |
| override | very nice | 19:19 |
| override | Im also trying to work with on a hdmi dongle side project, something kinda like amaxzon firestick or something. Would anyone have any reccomendations at all for prototype boards? | 19:21 |
| override | the toradex im working with right now might be an overkill i feel | 19:21 |
| override | want some dev board with everything video over hdmi, 4k and all | 19:22 |
| whuang0389 | pi4? | 19:25 |
| smurray | if it's for a product that you'd sell, SoC availability and cost would likely be the drivers. A lot of such things use Allwinner and Amlogic SoCs, I think, but whether you can source them is a good question | 19:25 |
| smurray | rockchip is the other vendor that comes to mind in that cheap set top box/stick space | 19:26 |
| override | nice.. ill start looking into those | 19:27 |
| smurray | if it's for a hobby project and form factor isn't an issue, then rpi4. For an actual HDMI dongle product it'd likely be a non-starter since getting those chips is likely impossible for small players | 19:27 |
| override | the usecase would be for tvs in hotels rooms , so guest servies and all can use it. you can setup like a wakeup call or whatever off of it , switch to normal tv programming. | 19:29 |
| smurray | note that your mileage may vary for the vendors I've mentioned, some of them don't have great upstream support for various things | 19:29 |
| override | I can prototype with rpi4, if i can switch to something else later which can fit in a hdmi dongle form factor only by writing a new machine config filr or soemthing | 19:30 |
| smurray | the other possibility would be one of the i.MX8 variants, though I suspect they'd be pricier than the set top box oriented SoCs from the Chinese mfgers | 19:30 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 19:30 | |
| override | smurray: if i were to start out with an rpi4 would yocto make the swithc over to imx etc super swift? | 19:33 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 19:34 | |
| smurray | override: in theory, though there's usually at least some h/w specific tweaking required around things like packages for graphics, video decode, etc. that aren't necessarily all handled in BSP layers in a consistent way | 19:37 |
| override | I bet, just bringing over this toradex filesystem image class to my meta-layer is proving to be no walk in the park... | 19:38 |
| smurray | for the Automotive Grade Linux demo images we build for a bunch of platforms, the BSP specific tweaks tend to be around stuff like that | 19:38 |
| smurray | the other area you'd maybe see differences would be h/w specific security features like secure boot, there's still a variety of different vendor things there you might need to account for | 19:40 |
| override | will start looking up all the vendors u mentioned | 19:42 |
| override | learning some solidworks too, so the form factor and all would be pretty involved | 19:43 |
| override | need some vendor doing timy soms for hdmi dongles | 19:44 |
| *** florian <florian!~florian@dynamic-093-131-018-086.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 265 seconds) | 19:44 | |
| override | smurray: on replacing that teziimg class with my own, im running into some virtual/dtb errors. whats a virtual/dtb to begin with? | 19:46 |
| smurray | override: I've no idea, sorry | 19:47 |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 252 seconds) | 19:48 | |
| override | no worries, looking into it | 19:48 |
| smurray | I know what the virtual/ mechanism is for, I didn't think upstream oe-core / poky used it for devicetrees | 19:50 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 19:53 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer) | 19:56 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 19:56 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 252 seconds) | 20:06 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 20:12 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 20:35 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 20:40 | |
| *** florian <florian!~florian@dynamic-093-131-018-086.93.131.pool.telefonica.de> has joined #yocto | 21:08 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 21:25 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Remote host closed the connection) | 21:29 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:50 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 250 seconds) | 21:51 | |
| *** camus1 is now known as camus | 21:51 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:44f2:149e:9572:50da> has quit IRC (Quit: Client closed) | 21:54 | |
| JaMa | zeddii: around? | 22:11 |
| *** hpsy <hpsy!~hpsy@85.203.15.12> has quit IRC (Quit: Leaving.) | 22:15 | |
| *** florian <florian!~florian@dynamic-093-131-018-086.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 22:42 | |
| JaMa | zeddii: meta-virtualization/recipes-extended/uxen/uxen-guest-tools_4.1.7.bb:do_patch is now failing in dunfell, gatesgarth, hardknott, honister "bitbake world" builds and I'm pretty sure that it wasn't failing before (as I would notice in jenkins jobs), but the strange part is that it wasn't changed for long time (not uxen-guest-tools, quilt, module.bbclass) and definitely not in all 4 releases at the same | 22:46 |
| JaMa | time, any idea what might cause this sudden change? | 22:46 |
| JaMa | stdout: Applying patch fix-Makefile-for-OE-kernel-build.patch | 22:46 |
| JaMa | patching file Makefile | 22:46 |
| JaMa | Hunk #1 FAILED at 1 (different line endings). | 22:46 |
| JaMa | Hunk #2 FAILED at 19 (different line endings). | 22:46 |
| JaMa | 2 out of 2 hunks FAILED -- rejects in file Makefile | 22:46 |
| JaMa | uxen-guest-tools/4.1.7-r0/uxen-vmsupport-linux-4.1.7/Makefile: makefile script, ASCII text, with CRLF line terminators | 22:46 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 250 seconds) | 22:47 | |
| JaMa | it also doesn't use AUTOREV or something to silently start using different source now | 22:48 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 22:50 | |
| smurray | JaMa: maybe something's gone off with sha384sum? It's not tested in oe-core AFAICT, and I must admit I didn't think it was supported | 22:57 |
| smurray | JaMa: that plus upstream changing the zip file in place might explain a failure? I'm just spitballing, though | 22:58 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 22:58 | |
| smurray | JPEW: the oe-selftest run I started earlier with your change isn't done yet, but it's looking promising, none of those failures so far | 23:04 |
| JPEW | smurray: excellent! Thanks! | 23:06 |
| smurray | JPEW: I'll do another run overnight, perhaps racheting the -j option up a bit further, then tomorrow I can apply the PR server patches and try with those | 23:07 |
| JPEW | smurray: I forgot to check the patches in master-next, but the fix should be pretty easy. You'll need to change how the server is started to use the new API like hashserver | 23:10 |
| smurray | JPEW: yeah, I noticed that, should be straightforward enough | 23:10 |
| *** amitk <amitk!~amit@103.208.69.73> has quit IRC (Ping timeout: 258 seconds) | 23:18 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 23:19 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 23:20 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 23:21 | |
| *** camus1 is now known as camus | 23:21 | |
| JaMa | smurray: thanks, I didn't notice that this recipe is using sum384sum, but that would mean that sum384sum checking is completely broken (I don't expect anyone able to figure out sha384 collision to overlook accidentally changing line endings in files) :) | 23:22 |
| smurray | JaMa: heh, yes, it'd indeed take more than one thing being broken | 23:26 |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds) | 23:30 | |
| JaMa | and sha384sum isn't completely broken as well: | 23:34 |
| JaMa | echo foo > downloads/uxen-vmsupport-linux-4.1.7.zip | 23:34 |
| JaMa | WARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Checksum mismatch for local file /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip | 23:35 |
| JaMa | Cleaning and trying again. | 23:35 |
| JaMa | WARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Renaming /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip to /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip_bad-checksum_8effdabfe14416214a250f935505250bd991f106065d899db6e19bdc8bf648f3ac0f19 | 23:35 |
| JaMa | 35c4f65fe8f798289b1a0d1e06 | 23:35 |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 23:37 | |
| smurray | JaMa: hrm, if it's working then the patch not applying is indeed quite strange | 23:37 |
| JaMa | my current theory is that it wasn't included in "bitbake world" for some strange reason, because now I'm looking at 2 days old "bitbake world" build for qemux86-64 and it's not shown there | 23:40 |
| *** sbach <sbach!~sbach@user/sbach> has quit IRC (Remote host closed the connection) | 23:43 | |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 23:43 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:58 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!