| rgov[m] | Here are all the differences https://gist.github.com/rgov/08d5311d2ba1b6283aad8b5434b31e50 | 00:00 |
|---|---|---|
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 00:09 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection) | 00:17 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 00:18 | |
| *** Guest68 <Guest68!~Guest68@modemcable113.46-82-70.mc.videotron.ca> has quit IRC (Quit: Client closed) | 00:28 | |
| *** armpit <armpit!sid501830@id-501830.uxbridge.irccloud.com> has quit IRC (Ping timeout: 268 seconds) | 00:34 | |
| *** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (Ping timeout: 268 seconds) | 00:34 | |
| *** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has quit IRC (Ping timeout: 268 seconds) | 00:34 | |
| *** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has joined #yocto | 00:35 | |
| *** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto | 00:35 | |
| *** armpit <armpit!sid501830@id-501830.uxbridge.irccloud.com> has joined #yocto | 00:35 | |
| *** Guest68 <Guest68!~Guest68@modemcable113.46-82-70.mc.videotron.ca> has joined #yocto | 00:35 | |
| *** krowlan3[m] <krowlan3[m]!~krowlan3m@2001:470:69fc:105::1:6572> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** zagor <zagor!~zagor@user/zagor> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** Epictek[m] <Epictek[m]!~epictekma@2001:470:69fc:105::d7cd> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** famstutz[m] <famstutz[m]!~famstutzm@2001:470:69fc:105::1:5719> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (Ping timeout: 268 seconds) | 00:36 | |
| *** krowlan3[m] <krowlan3[m]!~krowlan3m@2001:470:69fc:105::1:6572> has joined #yocto | 00:38 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto | 00:38 | |
| *** famstutz[m] <famstutz[m]!~famstutzm@2001:470:69fc:105::1:5719> has joined #yocto | 00:41 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 00:44 | |
| *** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has joined #yocto | 00:45 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 00:52 | |
| *** Epictek[m] <Epictek[m]!~epictekma@2001:470:69fc:105::d7cd> has joined #yocto | 00:52 | |
| *** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 00:52 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 00:52 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Ping timeout: 256 seconds) | 00:53 | |
| *** zagor <zagor!~zagor@user/zagor> has joined #yocto | 00:53 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 00:53 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 00:54 | |
| *** Guest68 <Guest68!~Guest68@modemcable113.46-82-70.mc.videotron.ca> has quit IRC (Ping timeout: 256 seconds) | 01:15 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:18 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 01:20 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:21 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:22 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:23 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:25 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 01:33 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:43 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:45 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:45 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:46 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 256 seconds) | 01:52 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:52 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 02:40 | |
| bluelightning | RP: the fix was actually in https://git.yoctoproject.org/poky/commit/bitbake?id=f46f6af1f255544e4399e0ce4aee6ce9061a259d (although I am also taking the fixes you mentioned as well as the few related fixes) | 02:53 |
| bluelightning | thanks! | 02:53 |
| *** Konsgn <Konsgn!~Konsgn@user/Konsgn> has quit IRC (Quit: Leaving) | 03:13 | |
| *** amitk <amitk!~amit@103.208.71.109> has joined #yocto | 03:37 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 04:00 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 04:01 | |
| *** dushara <dushara!~IceChat95@119-18-18-27.771212.mel.static.aussiebb.net> has joined #yocto | 04:46 | |
| dushara | Hi noticed that svn fetcher in bitbake doesn't handle URLs with spaces properly. I started tweaking fetcher with shlex.quote() around URL, but seems to affect common unpack code as well. Any suggestion on best way to deal with this? | 04:49 |
| geoffhp | coldspark29[m]: no need to delete your layer to get it refreshed in kas. Use the --update flag in your as command . e.g. `kas build --update myconfig.yml` or `kas checkout --update myconfig.yml` | 05:43 |
| ad__ | hi, systemd 244 install (dunfell) is producing "chown: invalid group: ‘root:systemd-journal’" | 06:01 |
| ad__ | i have this group in host pc, sound strange | 06:01 |
| ad__ | oh, found, sry. i am in a container without that group | 06:05 |
| ad__ | mm stil lgetting that error even creating the group | 06:11 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:14 | |
| ad__ | ok looks something related to my systemd bbappend | 06:26 |
| *** dushara <dushara!~IceChat95@119-18-18-27.771212.mel.static.aussiebb.net> has quit IRC (Quit: Never put off till tomorrow, what you can do the day after tomorrow) | 06:30 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 06:36 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds) | 06:43 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:46 | |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.173> has joined #yocto | 06:54 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto | 07:05 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:21 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 07:28 | |
| *** frieder <frieder!~frieder@i59F72E74.versanet.de> has joined #yocto | 07:36 | |
| *** frieder <frieder!~frieder@i59F72E74.versanet.de> has quit IRC (Client Quit) | 07:37 | |
| *** frieder <frieder!~frieder@i59F72E74.versanet.de> has joined #yocto | 07:37 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:40 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 07:40 | |
| *** mckoan|away is now known as mckoan | 07:45 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 07:58 | |
| coldspark29[m] | <geoffhp> "coldspark29: no need to delete..." <- Great, thanks for the tip. I was skim-reading the docs, but couldn't find that, | 07:58 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 07:58 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 08:10 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:11 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 08:16 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:17 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Quit: Leaving) | 08:17 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 08:17 | |
| *** Guest21 <Guest21!~Guest21@2a01cb0404ad62001469766baefca449.ipv6.abo.wanadoo.fr> has joined #yocto | 08:19 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 08:20 | |
| Guest21 | Hi all, I would like to create a package (.zip) with a yocto image inside and severals binaries (in a github repo). As severals images need this feature I have planned to create a .bbclass, but the class have to fetch sources, only recipe can fetch from git isn't it ? feel free to ask | 08:25 |
| *** dev1990 <dev1990!~dev@81.168.185.188> has joined #yocto | 08:27 | |
| *** ederibaucourt <ederibaucourt!~ederibauc@85-170-128-172.rev.numericable.fr> has joined #yocto | 08:28 | |
| *** Guest2140 <Guest2140!~Guest21@2a04:cec0:11d7:f06c:cd4b:ed13:e480:c57b> has joined #yocto | 08:28 | |
| qschulz | Guest21: what I can say already is that there's a zip image type which makes a .zip of your image | 08:30 |
| qschulz | c.f. IMAGE_TYPES | 08:30 |
| *** ederibaucourt <ederibaucourt!~ederibauc@85-170-128-172.rev.numericable.fr> has quit IRC (Client Quit) | 08:31 | |
| qschulz | Guest21: those binaries, why are they not part of the "yocto imagE" ? | 08:31 |
| *** Guest21 <Guest21!~Guest21@2a01cb0404ad62001469766baefca449.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 256 seconds) | 08:32 | |
| *** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has joined #yocto | 08:33 | |
| Guest2140 | qschulz binaries are build outside from yocto. Our main board use this package to flash several devices (one of them use the yocto image) so binaries are not needed inside the "yocto image" | 08:35 |
| qschulz | why I am asking is that you could have a separate partition in a wic "image" for those binaries specifically and then have almost nothing to create n Yocto except a .wks file | 08:37 |
| Guest2140 | qschulz Thank you for sharing i will take a look to wic image | 08:38 |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has joined #yocto | 08:48 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 08:56 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:57 | |
| *** an_sensr[m] <an_sensr[m]!~ansensrma@2001:470:69fc:105::1:432c> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 09:02 | |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Ping timeout: 256 seconds) | 09:04 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:07 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:07 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 09:07 | |
| *** Guest2140 <Guest2140!~Guest21@2a04:cec0:11d7:f06c:cd4b:ed13:e480:c57b> has quit IRC (Quit: Client closed) | 09:11 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 09:17 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:17 | |
| *** Etheryon70 <Etheryon70!~Etheryon@79.114.104.56> has joined #yocto | 09:22 | |
| Etheryon70 | Hello | 09:23 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:26 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:26 | |
| coldspark29[m] | Morning, this imx kernel patching is really complicated. There is the linux-fslc-imx kernel that requires the linux-fslc.inc that requires the linux-imx.inc. | 09:28 |
| coldspark29[m] | What is the best way to apply our patches to this kernel? Should I just create a patch folder or fork the whole thing and apply our patches? I am looking to have as little work as possible for future releases. | 09:29 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:31 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:31 | |
| qschulz | coldspark29[m]: is this recipe inheriting kernel-yocto? | 09:33 |
| qschulz | (might be indirectly through other inherited classes or .inc files | 09:33 |
| coldspark29[m] | Yes, it is | 09:33 |
| qschulz | I think you're supposed to use scc/cfg "config" files in that case to patch things up | 09:34 |
| coldspark29[m] | All I need to do is add some drivers and device tree files | 09:34 |
| qschulz | but in short, have a bbappend for your recipe with FILESETRXAPATH:prepend := ... | 09:34 |
| coldspark29[m] | Yeah I thought so. Like this I will not have to fork and patch the kernel repository | 09:35 |
| qschulz | coldspark29[m]: usually you fork off and push to your own git repo and use that one instead, you'll quickly have too many patches for hosting stuff in Yocto | 09:35 |
| qschulz | also.. Yocto is a build system, not technically where source code resides | 09:35 |
| coldspark29[m] | Yeah, but I thought I could manage with some kconfig and .dts files. Yocto should be able to do that, shouldn't it? | 09:36 |
| qschulz | coldspark29[m]: https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/tree/recipes-kernel/linux this is what I did for our board which uses scc files | 09:36 |
| qschulz | "I could manage with some kconfig" sorry didn't understand | 09:37 |
| qschulz | the point is, your kernel sources shouldn't be associated with which build system you're using | 09:37 |
| qschulz | otherwise if you want to switch to Buildroot for example, you'll have to duplicate the patches | 09:38 |
| qschulz | also, makes it much harder to develop the kernel outside of Yocto | 09:38 |
| qschulz | just saying that forking off the kernel is what most people do. you use scc/cfg file to provide for customization options (e.g. does the user want Ethernet, hardened kernel, PCIe, etc...) | 09:39 |
| qschulz | so technically, what I did in our layer isn't (IMO) correct | 09:40 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 09:44 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:50 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 09:51 | |
| *** camus1 is now known as camus | 09:51 | |
| dacav | Hello. I would need some help for remote debugging. | 09:52 |
| dacav | I run `gdbserver 0.0.0.0:$port $command $args | 09:52 |
| dacav | Then on my host I run gdb, use `target remote $host:$port` | 09:53 |
| dacav | At this point I can effectively run the command by `continue`, but I don't see symbols | 09:53 |
| dacav | I've installed the debug symbols package | 09:54 |
| dacav | Am I missing some step maybe? | 09:54 |
| kroon | dacav, debug symbols need to be available on the host, not the target | 09:55 |
| dacav | I see. Calling `symbol-file` tells me they're in `target:/usr/bin/.debug/$command` | 09:56 |
| kroon | dacav, you can use "set sysroot" gdb command to point to where the target sysroot is on the host | 09:56 |
| dacav | Thanks kroon. I'm not sure of where that will be, but I guess I can find it below the yocto tmp/ | 09:56 |
| kroon | dacav, you can build the SDK, install it somewhere, it will contain the target sysroot with debug info | 09:57 |
| dacav | Too bad, my sdk is broken | 09:58 |
| dacav | (any advice is well accepted on that topic -- see yocto mailing list, and I mentioned on this channel too, it is somewhere in the backlog) | 09:58 |
| dacav | kroon: I'm only left with a docker image that was built before the SDK ended up in broken state | 09:59 |
| dacav | Question 1: pretending my SDK is not broken, how can it contain debug info that belongs to a binary I've built? | 10:00 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 10:01 | |
| kroon | dacav, oh, you built the binary outside yoto ? | 10:02 |
| dacav | kroon: I ended up to package my binary with a recipe, so I could leverage bitbake | 10:02 |
| dacav | (it kinda sucks to learn yocto from an established/ongoing/broken project) | 10:03 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:03 | |
| kroon | dacav, ah ok. i'm sure you can point gdb to the debug info on the host somehow. find the -dbg package and unpack it somewhere | 10:04 |
| kayterina[m] | Hello. I got a pseudo abort with inode mismatch in do_installwhile bitbaking a recipe, the link that says to start with a clean TMPDIR. Will a bitbake -c clean_all <recipe> suffice? | 10:04 |
| kayterina[m] | s/that// | 10:04 |
| dacav | kroon: So, something like unpacking the -dbg in a certain directory in the docker container that has the SDK, and then using `set sysroot` there? | 10:05 |
| kroon | 'sysroot', 'solib-search-path' | 10:05 |
| kroon | maybe there are other ways to instruct gdb where to look for debug info | 10:06 |
| dacav | Thanks | 10:06 |
| *** Etheryon70 <Etheryon70!~Etheryon@79.114.104.56> has quit IRC (Ping timeout: 256 seconds) | 10:10 | |
| kroon | dacav, can you post a link to the archived email detailing the sdk problem ? | 10:10 |
| *** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 10:12 | |
| qschulz | kayterina[m]: don't do that, just remove everything EXCEPT downloads and sstate-cache in your build directory | 10:13 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Ping timeout: 256 seconds) | 10:13 | |
| qschulz | cleanall removes the fetched sources and sstate-cache, almost making it a build from scratch | 10:14 |
| qschulz | kayterina[m]: if you're building within a container, I personally had to add --tmpfs /tmp to the podman/docker run command to make those pseudo abort go away | 10:14 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Ping timeout: 256 seconds) | 10:15 | |
| coldspark29[m] | <qschulz> ""I could manage with some..." <- I was just thinking that all I have to do is add the drivers source files, add our kconfig and device tree to the kernel | 10:15 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 10:15 | |
| qschulz | coldspark29[m]: and defconfig | 10:15 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:16 | |
| coldspark29[m] | So an .scc file seems like a patch list to me. Is that correct? My colleague just said the same thing as you, that is a patched repository makes you independent from build systems. | 10:17 |
| coldspark29[m] | qschulz: I probably meant that. Are they not the same? | 10:17 |
| qschulz | kconfig is the way of listing options, which is then parsed by tools such as menuconfig/xconfig/whatever to allow you to select options and create a defconfig | 10:18 |
| qschulz | ultimately, you need both. One (kconfig file/option) to declare a new option, and a defconfig (or modification of a defconfig) to select this option so it's built | 10:19 |
| coldspark29[m] | Ah so kconfig is the drivers sources available I guess | 10:19 |
| coldspark29[m] | I meant defconfig then | 10:19 |
| dacav | kroon: thanks! Sure! https://lists.yoctoproject.org/g/yocto/message/55836 | 10:20 |
| coldspark29[m] | Thanks | 10:20 |
| qschulz | no, kconfig is a config file listing options. kernel drivers are C source code files that gets compiled if the kconfig option is enabled in your defconfig (technically .config, since defconfig is just a stripped down version of defconfig) | 10:21 |
| dacav | kroon: I didn't discuss the broken sdk, actually | 10:21 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 10:21 | |
| kayterina[m] | with --tmpfs=/tmp in docker, what do you send to linux /tmp? Some temporary files of yocto? | 10:24 |
| kroon | dacav, ok. id suggest getting the sdk fixed. the devshell thing, you only get build dependencies in PATH, the output binaries for the actual recipe you're devshell:ing will not be in your PATH | 10:24 |
| qschulz | kayterina[m]: it makes /tmp inside the container a tmpfs, that's all I can say | 10:26 |
| kroon | dacav, so if you devshell a recipe the DEPENDS in your cross compiler, then you'd see it in PATH | 10:26 |
| RP | michaelo: are there other bitbake patches I'm missing? | 10:28 |
| kayterina[m] | and also I have to delete workspace directory? The error comes from building a recipe with changes to its code | 10:28 |
| dacav | kroon: I see. ...would it work to add the cross-compiler as DEPENDS of my tool? | 10:29 |
| kroon | dacav, i think so | 10:29 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 10:30 | |
| dacav | kroon: or I could spend time in fixing the SDK, but ...I'm really not sure which direction to take -- I'm a noob, and I find huge problems everywhere: I might spend months (one is gone) before I get to have some result :-/ | 10:30 |
| kroon | dacav, then devshell your tool, and you should have the cross compiler in PATH | 10:30 |
| dacav | kroon: thanks. That would be *MUCH* better than a docker container | 10:30 |
| dacav | docker is crap, I have to copy data or use volumes, then all permissions become root... pff... | 10:31 |
| kroon | dacav, its worth a shot decribing the problem with the SDK on the oe-core ml, people will help out if they can | 10:32 |
| dacav | kroon: I can put that on my todo list, sure. The problem comes from a patch that can't be applied, and the culprit recipe is in xilinx's layers | 10:34 |
| dacav | I know there's a xilinx mailing list. | 10:35 |
| dacav | should I use oe-core or xilinx ml? | 10:35 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:35 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 10:42 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit) | 10:42 | |
| dacav | - I'll be using oe-core as you say. It is now in my long pile of things to do later :( | 10:57 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 240 seconds) | 11:00 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 11:14 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has quit IRC (Quit: Client closed) | 11:18 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 11:40 | |
| dacav | kroon: thanks for the suggestions above. Adding DEPENDS on gdb-cross-aarch made it, and besides I correctly get the debug symbols too for free. | 11:53 |
| kroon | dacav, 👍 | 11:57 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 12:09 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 12:09 | |
| paulbarker | I'm trying to speed up yocto-check-layer runs in CI, is it safe to keep `${TMPDIR}/cache` and throw away the rest of `${TMPDIR}`? | 12:14 |
| paulbarker | Or does that cache depend on other info in `${TMPDIR}` | 12:14 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 12:25 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit) | 12:25 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 12:26 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 12:27 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 12:29 | |
| *** Konsgn <Konsgn!~Konsgnx3@user/Konsgn> has joined #yocto | 12:53 | |
| *** Konsgn <Konsgn!~Konsgnx3@user/Konsgn> has quit IRC (Client Quit) | 12:55 | |
| *** konsgn <konsgn!~konsgn@user/Konsgn> has joined #yocto | 12:55 | |
| *** radsquirrel <radsquirrel!~bradleyb@173.167.31.197> has quit IRC (Quit: WeeChat 3.4) | 12:58 | |
| dacav | Hi. I think I need to run ipkg-make-index if I want [ https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-ipk ] to be effective. | 12:59 |
| dacav | It looks like there's no recipe for it in yocto | 12:59 |
| dacav | (I was thinking that there should be probably a native one, but I could not find it) | 13:00 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 13:01 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 13:05 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 13:06 | |
| *** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto | 13:08 | |
| rburton | dacav: bitbake package-index | 13:09 |
| rburton | dacav: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management covers the build host side | 13:10 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 240 seconds) | 13:11 | |
| *** jmiehe1 is now known as jmiehe | 13:11 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 13:14 | |
| *** Guest96 <Guest96!~Guest96@2a02:3103:205c:200:bed3:df7f:f488:16a2> has joined #yocto | 13:20 | |
| Guest96 | FYI: https://www.yoctoproject.org/irc/ hasn't been updated for the whole year 2022 - could one please have a look | 13:21 |
| *** Guest96 <Guest96!~Guest96@2a02:3103:205c:200:bed3:df7f:f488:16a2> has quit IRC (Client Quit) | 13:21 | |
| qschulz | halstead: good morning :) can you have a look at what Guest96 just reported please? ^ | 13:24 |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Ping timeout: 256 seconds) | 13:27 | |
| *** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 13:31 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 13:31 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:43 | |
| *** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds) | 13:46 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 13:52 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 13:52 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:55 | |
| *** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 13:55 | |
| dacav | rburton: thanks, I'll check out :) | 13:58 |
| RP | michaelo: I tweaked some permissions to get the docs builds to stop failing | 14:00 |
| michaelo | RP: awesome, thanks a lot! | 14:06 |
| michaelo | RP: thanks for taking the BitBake patch. No other one was missing I believe. | 14:07 |
| RP | michaelo: thanks. I get a bit confused at times with patches that go to multiple lists so remind me if I miss anything | 14:08 |
| dacav | rburton: and the funny part is that I even read that already. Sorry for the dumb question. | 14:13 |
| *** marka is now known as Guest114 | 14:20 | |
| *** Guest114 <Guest114!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Killed (strontium.libera.chat (Nickname regained by services))) | 14:20 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 14:20 | |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto | 14:21 | |
| *** TundraMan is now known as marka | 14:21 | |
| Skinny79 | Hi All! Day 5 of my Yocto adventures:D Managed to create a custom layer with recipes for my board and software so that's looking promising | 14:22 |
| Skinny79 | Uploaded file: https://uploads.kiwiirc.com/files/83c55968f92f142caf60faa77dcfad0d/pasted.txt | 14:24 |
| Skinny79 | However when I add the 'podman' recipe (from meta-virtualization) to my image bitbake starts complaining about not being able to download ostree : | 14:24 |
| Skinny79 | ERROR: ostree-2021.3-r0 do_fetch: Fetcher failure for URL: 'gitsm://gitlab.gnome.org/GNOME/libglnx.git;protocol=https;name=libglnx;subpath=libglnx;bareclone=1;nobranch=1'. Unable to fetch URL from any source. | 14:24 |
| Skinny79 | ERROR: ostree-2021.3-r0 do_fetch: Fetcher failure for URL: 'gitsm://github.com/ostreedev/ostree;branch=main;protocol=https'. Unable to fetch URL from any source. | 14:24 |
| Skinny79 | When I go to the github page it all seems ok, and the revision id in the .bb file is actually a valid commit. Where do I start troubleshooting this ? I'm on the honister branch | 14:24 |
| rburton | the actual error is likely above what you pasted | 14:26 |
| rburton | can you pastebin the full log? | 14:26 |
| Skinny79 | you mean the console output or the complete task log ? | 14:27 |
| rburton | the console output will do | 14:29 |
| Skinny79 | console log : https://pastebin.com/JV79TVAh | 14:29 |
| Skinny79 | full task log file for the failing step (ostree) : https://pastebin.com/YtQJLYmc | 14:30 |
| Skinny79 | I can't find any obvious ERRORs on 'why' the download would fail | 14:30 |
| rburton | fatal: unable to access 'https://gitlab.gnome.org/GNOME/libglnx.git/': server certificate verification failed. CAfile: none CRLfile: none | 14:32 |
| Skinny79 | err | 14:32 |
| Skinny79 | how did I miss that ? lol | 14:32 |
| rburton | its not on the console, which is annoying | 14:32 |
| rburton | try a clone outside of yocto, you might have stale certificates | 14:33 |
| rburton | there was a major update a few months ago which you'll need | 14:33 |
| Skinny79 | git clone https://gitlab.gnome.org/GNOME/libglnx.git | 14:34 |
| Skinny79 | Cloning into 'libglnx'... | 14:34 |
| Skinny79 | fatal: unable to access 'https://gitlab.gnome.org/GNOME/libglnx.git/': server certificate verification failed. CAfile: none CRLfile: none | 14:34 |
| Skinny79 | indeed.. | 14:34 |
| Skinny79 | Freshly installed host machine (windows) with WSL2 ;-) | 14:34 |
| Skinny79 | Never thought the issue is in that area | 14:34 |
| paulbarker | Skinny79: What's the distro there? I had similar issues with an Ubuntu-based container which didn't have ca-certificates installed, you may want to try installing that if it's Ubuntu | 14:35 |
| Skinny79 | It has ca-certificates but now that I look at it its a version from 2019 :shrug: | 14:35 |
| Skinny79 | updating.. | 14:35 |
| paulbarker | That far out-of-date would definitely cause issues! | 14:36 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 14:37 | |
| Skinny79 | It's Ubuntu 20.04 LTS (but apparently not updated with recent updates) | 14:38 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:39 | |
| Skinny79 | Am I right when I say that "DISTRO_FEATURES" are built but not ending up on the rootfs until you actually "INSTALL_" them ? | 14:40 |
| rburton | DISTRO_FEATURES are not things that get built exactly | 14:42 |
| rburton | like there isn't a 'wifi' recipe | 14:42 |
| rburton | but yes, a thing being in distro features doesn't mean it is *definitely* in the image | 14:42 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!) | 14:42 | |
| rburton | concrete example would be useful | 14:42 |
| smurray | and what image you use as a base makes a difference, there's a bunch more of conditional inclusion based on DISTRO_FEATURES in some of the non-minimal ones | 14:44 |
| Skinny79 | Example would be that I need the 'salt' (stack) minion on my system. There is a recipe 'salt' in the meta-cloud-services/meta-openstack layer which actually builds all the packages for salt where I only need one specific binary in my final image. And also I have the feeling (based on the tasks performed) that a lot of stuff in the meta-openstack | 14:45 |
| Skinny79 | layer is also build but I don't need that at all. I'd really like to stick with the recipe already available instead of copy/pasting it into my own layer | 14:45 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has joined #yocto | 14:46 | |
| Skinny79 | BTW.. updating ca-certificates works, ends an afternoon looking for something in the wrong place, THANKS! | 14:46 |
| rburton | a root certificate expired, so everyone with stale certs suddenly got weird errors | 14:47 |
| Skinny79 | So it had nothing to do with ostree and googling for issues with that aren't very helpful in this case ;-) | 14:48 |
| rburton | the fetcher can be a pain as there's so many layers, best to look at the underlying log straight away | 14:48 |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 14:49 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 14:49 | |
| Skinny79 | Another lesson learned | 14:50 |
| *** amitk <amitk!~amit@103.208.71.109> has quit IRC (Ping timeout: 240 seconds) | 15:03 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 15:21 | |
| Skinny79 | Still trying to learn the concepts and best practices here : In my own layer I have a 'salt_3001.1.bbappend' file. What location is the "correct" one to include/require the base 'salt' recipe ? | 15:28 |
| qschulz | Skinny79: the bbappend (if found) will be applied to the original recipe matching the name and the version (if found) | 15:29 |
| qschulz | if that was your question | 15:29 |
| qschulz | there's no need to include/require the original recipe in a bbappend | 15:29 |
| rfs613 | Skinny79: a .bbappend file does not need to include/require the base recipe. It will instead be found by matching the filename (eg. salt_3001.1.bb) | 15:30 |
| qschulz | you just need to make sure your layer.conf has bbappends in the regexp in BBFILES | 15:30 |
| Skinny79 | ok, but I still need to add 'salt' to the IMAGE_INSTALL somewhere | 15:30 |
| qschulz | Skinny79: not necessarily | 15:31 |
| qschulz | if something RDEPENDS on salt and is part of IMAGE_INSTALL, then it's not needed | 15:31 |
| Skinny79 | okkkaay..... so.. | 15:31 |
| qschulz | if nothing pulls the dependency for you, then you need to add your package to the packages to be installed by the image recipe | 15:31 |
| Skinny79 | I have 'meta-custom' layer with recipes-core/mycore.bb which RDEPENDS 'salt' and has the .bbappend file | 15:32 |
| Skinny79 | then I only need 'mycore' in my local.conf to add everything | 15:32 |
| Skinny79 | correct ? | 15:32 |
| qschulz | Skinny79: sort of | 15:35 |
| Skinny79 | Uploaded file: https://uploads.kiwiirc.com/files/b8580559dda1037e37a4cb3f6374691b/image.png | 15:35 |
| qschulz | first usually you have an additional subdirectory, e.g. recipes-core/something/mycore.bb | 15:36 |
| Skinny79 | the .bb file has 'RDEPENDS:${PN} += " salt"' | 15:36 |
| qschulz | second, you are supposed to create/extend the image recipe you build to add mycore to IMAGE_INSTALL in there | 15:36 |
| qschulz | local.conf should not be versioned | 15:36 |
| Skinny79 | and in my local.conf I have IMAGE_INSTALL:append = " sentinel-core" | 15:36 |
| qschulz | Skinny79: yes, but again, create an image recipe to store IMAGE_INSTALL variable in it :) | 15:37 |
| *** amitk <amitk!~amit@103.208.71.109> has joined #yocto | 15:37 | |
| Skinny79 | Uploaded file: https://uploads.kiwiirc.com/files/41b8d6731e113ca9f7463bb913aabce1/image.png | 15:38 |
| Skinny79 | with IMAGE_INSTALL:append = " sentinel-core" | 15:38 |
| qschulz | Skinny79: yeah that's okay-ish for now, next step will be to create your own image recipe :) | 15:42 |
| Skinny79 | I think that's what so confusing me . Now I have a succesful build but the rootfs doesn't have either salt or my custom app (sentinel). | 15:42 |
| Skinny79 | Is that what's solved by the image recipe ? | 15:42 |
| qschulz | what's the value of BBFILES in your layer.conf file? | 15:43 |
| Skinny79 | just the default : https://pastebin.com/ThNM5ji1 | 15:43 |
| Skinny79 | What I am just not seeing is how just including my customer layer in 'bblayers.conf' will actually DO something ? I mean, otherwise just including a meta-xxx layer would just add all the software in there ? I figured that I need something in my local.conf but apparently I don't ? | 15:45 |
| qschulz | Skinny79: you need an additional parent directory | 15:45 |
| qschulz | otherwise it does not match the regexp in BBFILES and your bbappends aren't found | 15:45 |
| qschulz | you could see this by running btibake-layers show-append I think | 15:45 |
| Skinny79 | Uploaded file: https://uploads.kiwiirc.com/files/4dfc69acae262f8521803a393d90fef1/image.png | 15:45 |
| qschulz | Skinny79: you run bitbake core-image-minimal | 15:46 |
| Skinny79 | I think that's there : sentinel-core folder under recipes-core | 15:46 |
| Skinny79 | qschulz yes | 15:46 |
| Skinny79 | (for now) | 15:46 |
| qschulz | Skinny79: so that's what decides what gets build into your image | 15:46 |
| Skinny79 | One step at a time :) | 15:46 |
| qschulz | not all recipes | 15:46 |
| qschulz | just what's necessary to build your image recipe | 15:46 |
| qschulz | recipes-core/mycore.bb does NOT match BBFILES pattern | 15:47 |
| qschulz | recipes-core/core/mycore.bb does though | 15:47 |
| Skinny79 | no sorry, I mistyped that.. look at the screenshot for my actual folder structure | 15:47 |
| *** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has quit IRC (Remote host closed the connection) | 15:47 | |
| *** fleg <fleg!dfbb34cb39@user/fleg> has quit IRC (Remote host closed the connection) | 15:47 | |
| qschulz | Skinny79: recipes-images/core-image-minimal.bbappend does not match BBFILES either | 15:48 |
| Skinny79 | oh hold on | 15:48 |
| Skinny79 | that image recipe is not matching that structure | 15:48 |
| Skinny79 | that ^^ | 15:48 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 15:48 | |
| *** fleg <fleg!dfbb34cb39@user/fleg> has joined #yocto | 15:48 | |
| qschulz | also try to send text only and not images :) | 15:48 |
| *** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has joined #yocto | 15:48 | |
| Skinny79 | ok, np | 15:49 |
| qschulz | easier for us (don't need to pop-up some browser to watch it) and also makes it archive friendly for the IRC logs | 15:49 |
| qschulz | so people might be able to find the discussions with their favourite search engine | 15:49 |
| Skinny79 | true, I figured i t would be easier to read instead of ASCII folder structures ;-) | 15:49 |
| qschulz | Skinny79: find . -name "*.bb*" would probably have been enough :) | 15:50 |
| Skinny79 | ok one more as qemu doesn't allow text selection somehow | 15:50 |
| qschulz | or `tree` also helps :) | 15:50 |
| Skinny79 | Uploaded file: https://uploads.kiwiirc.com/files/dd1249ae1d299fc8f5680814fc01ce94/image.png | 15:50 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 15:50 | |
| qschulz | Skinny79: looks nice :) anything wrong? | 15:50 |
| Skinny79 | brilliant.. the beauty of sense is that when it makes sense to you it's beautiful | 15:50 |
| qschulz | Skinny79: if I may suggest the Youtube tutorial from LetoThe2nd.. will help you get started and build good foundations | 15:51 |
| Skinny79 | qschulz and the custom image recipe you were referring to is to replace my current core-image-minimal.bbappend with a core-sentinel-image.bb (or whatever) and use that as the argument for bitbake ? | 15:51 |
| qschulz | https://www.youtube.com/watch?v=ThTl4FItfMI&list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj | 15:52 |
| qschulz | Skinny79: absolutely | 15:52 |
| Skinny79 | Nice! Thanks.. Have watch a lot already but suggestions are very welcome | 15:52 |
| Skinny79 | -ed | 15:52 |
| Skinny79 | Thank you so much! | 15:53 |
| qschulz | enjoy :) | 15:53 |
| Skinny79 | Although my wife wouldn't agree because here's another night spend on hobbies ;-) | 15:53 |
| vd | hi there -- qschulz you were right. After a few tests I went back to a single distro with multiple images. It makes me write a lot of recipes, but it's way faster. Multiple distros (managed manually) or multiconfigs (from the same bitbake call) extend considerably the parsing and build time, kinda deal breaker. | 15:58 |
| kergoth | Ah, hadn't considered parse time! Makes sense | 16:00 |
| vd | kergoth: I just moved 3 customizations into 3 multiconfig, and it was literally 3 times longer and also a lot of messages about deferring tasks. | 16:03 |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 16:09 | |
| kergoth | I wish those messages were moved to only with verbose, they mean nothing to most users anyway | 16:10 |
| RP | kergoth: we possibly could do that now. The problem was where multiconfig builds went mental and we couldn't debug it, we're trying to avoid that and be able to debug failures | 16:15 |
| fray | I found in gatesgarth that merging multiconfigs was about the same amount of time as doing them manually -- for a large "fresh" build. But doing them for a small build often was longer due to parsing overhead.. (small build was one or two recipes). | 16:18 |
| fray | With Honister though, I'm finding that generally multiconfig builds are now _faster_ (which is what I would have expected with better re-use) for larger builds | 16:18 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 16:19 | |
| fray | I should add, one place we found a lot of slowdown though. When you get multiple copies of gcc (for different configs) building at the same time. It can overwealm the system. We ended up putting in some additional limits to try to avoid that and it gave us really good results. (Our builders run in some IT managed magic container system.. so I don't have a lot of details WHY it was failing, only that it | 16:21 |
| fray | was) | 16:21 |
| fray | Just looked we has to set: do_compile[number_threads] = "4" as well as PARALLEL_MAKE = '-j 4' (for gcc, binutils and gdb)... | 16:24 |
| *** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has quit IRC (Quit: Leaving) | 16:24 | |
| fray | the machine is a 48 thread machine, but 48/48 caused the system to kill threads | 16:24 |
| konsgn | just built a system, but now I get crashes when trying to power off, How would I debug that? stack traces on debug port show things like: WARNING: halt/1612 still has locks held! | 16:26 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:26 | |
| konsgn | earliest trace is : [<c01557d4>] (__do_sys_reboot) from [<c0100060>] (ret_fast_syscall+0x0/0x28) | 16:26 |
| halstead | qschulz: Guest96: I've updated the irc logging and 2022 logs are up now. | 16:36 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:41 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 16:43 | |
| qschulz | halstead: thanks :) | 16:44 |
| vd | given than the machine is parsed before the distro, is it OK to have FOO:append:mydistro = " bar" in a machine configuration? | 16:48 |
| rburton | yes, appends happen after parse | 16:49 |
| vd | rburton: but FOO:mydistro = "bar" would be a problem? | 16:49 |
| kergoth | It will *work*.. whether it's ideal is a different question. Ideally the boundaries should be kept between those axes of the build, but there are times when you need to configure for a particular distro/machine combination, or are dealing with external layers you don't want to fork | 16:49 |
| kergoth | I've seriously considered having my distro include conf/distro-machine/${DISTRO}-${MACHINE}.conf or something before, though never ended up doing int | 16:50 |
| kergoth | actually ended up using meta-mentor's custom setup scripts which append local.conf.append and local.conf.append.${MACHINE} fragments to local.conf as a way to modify machine behavior from the distro in a way that was user-visible instead.. | 16:50 |
| rburton | vd: more accurately, overrides happen after parse | 16:52 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 16:54 | |
| qschulz | vd: the second one (FOO:mydistro) will completely override FOO if mydristro is used | 16:55 |
| vd | qschulz: I know, my question was regarding the parsing order (since the distro is parsed after the machine config) | 16:55 |
| qschulz | vd: I don't think it matters unless you are requiring direct expansion (:= or d.getVar) | 16:59 |
| qschulz | I mean, if you use variables from other places that in the current file, for which the parsing order will matter | 17:00 |
| qschulz | otherwise, I'd say distro or machine first does not matter | 17:00 |
| qschulz | overrides are anyway all saved and at the end of parsing the one that applies is taken | 17:01 |
| vd | So the parsing is two passes? | 17:01 |
| qschulz | One pass and then everything is resolved? I don't know honestly about the internals | 17:02 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 17:03 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 17:03 | |
| vd | They are grey areas like this one: let's say your machine has a push button and you want the bootloader to behave differently for production and development when pressing that button. Is it a machine or a distro configuration? :-) | 17:03 |
| qschulz | if you;re going to have more changes, in the end, you'll most likely need a distro anyway | 17:05 |
| qschulz | but if that were to be the only change, I'd have two machines to maximise the sstate-cache reuse | 17:06 |
| qschulz | or even better, two bootloader recipes | 17:06 |
| vd | qschulz: so many machines requiring a base one isn't a problem? I was worried about duplicating kernel artifacts, and MACHINE_ARCH packages, etc. | 17:07 |
| vd | qschulz: and then you choose your preferred virtual/bootloader provider from the machine or distro conf ideally? | 17:08 |
| qschulz | in case of two bootloader recipes and only one machine conf, you just build both and have them deployed, create two wic files, one with production bootloader the other wiht debug bootloader? | 17:10 |
| qschulz | vd: you could even just make a U-Boot env recipe only and set environment variables based onproduction/debug and have the same uboot binary | 17:11 |
| qschulz | vd: the issue with distros is that nothing is re-used | 17:11 |
| qschulz | between distros ofc | 17:11 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Remote host closed the connection) | 17:14 | |
| vd | qschulz: that's a good insight thank you | 17:14 |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto | 17:15 | |
| vd | qschulz: having a single machine and a single distro is definitely faster... I forgot I could change the IMAGE_BOOT_FILES and WKS_FILE per image recipes. A dev image recipe could do the trick. | 17:19 |
| qschulz | vd: Ah I forgot we opnly support building one wks file at a time | 17:20 |
| qschulz | if we were to support multi wks file in one image recipe then both could be built at once | 17:20 |
| *** frieder <frieder!~frieder@i59F72E74.versanet.de> has quit IRC (Remote host closed the connection) | 17:21 | |
| kergoth | vd, qschulz: overrides used to be applied at a specific point in time at the end of parsing, but now they are applied when variable expansions are applied, which is done when the variable is *used* (i.e. when d.getVar() is run, either programmatically or when tasks are emitted to be run) | 17:21 |
| *** mckoan is now known as mckoan|away | 17:21 | |
| vd | it makes sense now that software like systemd split their config in a systemd-conf package. You can select different conf based on a the machine or distro. | 17:22 |
| vd | kergoth: that makes a lot of sense. | 17:22 |
| xperia64 | I'm having trouble with do_fetch[mcdepends]; when the dependency is rebuilt/dirty, the do_fetch[mcdepends] is still cached and marked as covered | 17:23 |
| vd | Wouldn't it be better to tweak the hostname file in an image class rather than tweaking hostname:pn-base-files globally? | 17:23 |
| rburton | vd: how would that work? :) | 17:25 |
| rburton | unless you mean write a rootfs postprocess thing | 17:25 |
| rburton | in which case sure, do that if you want | 17:25 |
| vd | rburton: yes a post process function overriding ${IMAGE_ROOTFS}/etc/hostname if ${HOSTNAME} is set. Wouldn't it be less intrusive? Similar to extrausers. | 17:26 |
| Skinny79 | Ok , one last for today:) | 17:29 |
| Skinny79 | NB_DIR = "/opt/newblack" | 17:29 |
| Skinny79 | do_install() { | 17:29 |
| Skinny79 | install ${WORKDIR}/sentinel-config ${D}${NB_DIR}/bin | 17:29 |
| Skinny79 | install -Dm644 ${WORKDIR}/sentinel-configuration.service "${D}${systemd_system_unitdir}/sentinel-configuration.service" | 17:29 |
| Skinny79 | } | 17:29 |
| Skinny79 | FILES:${PN} = "${systemd_system_unitdir} ${systemd_system_unitdir}/sentinel-configuration.service ${D}${NB_DIR}/bin/sentinel-config" | 17:29 |
| rburton | vd: depends on your usecase | 17:29 |
| rburton | vd: personally all my images are called bob, makes ssh easier :) | 17:29 |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has quit IRC (Quit: Connection closed) | 17:30 | |
| rburton | s/images/hostnames/ | 17:30 |
| *** Skinny7987 <Skinny7987!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto | 17:30 | |
| vd | rburton: is there a cost to tweak files from post process commands rather than relying on installed packages? | 17:30 |
| rburton | vd: package feeds break any changes | 17:31 |
| Skinny7987 | Two files, but the custom binary in /opt/newblack/bin/sentinel-config results in a ` [installed-vs-shipped]` error | 17:31 |
| Skinny7987 | the systemd unit works fine | 17:31 |
| Skinny7987 | What could be the reason ? | 17:31 |
| vd | rburton: what do you mean? | 17:31 |
| rburton | vd: if you fix the rootfs in a post-process and then use a pacakge feed, the feeds don't have the changes so an upgrade will revert to the non-tweaked file | 17:32 |
| rburton | Skinny7987: /opt isn't in FILES_${PN} by default, you'll need to add it yourself | 17:32 |
| vd | rburton: but you can't install an image from a package feed, can you? What's the point of it? | 17:33 |
| rburton | vd: if you're not using feeds, it's moot | 17:33 |
| rburton | if you're using feeds its a fundamental problem | 17:33 |
| Skinny7987 | ah.. adding only the file (within that path) isn't enough ? | 17:33 |
| Skinny7987 | FILES:${PN} = "${D}${NB_DIR}/bin ${D}${NB_DIR}/bin/sentinel-config ${systemd_system_unitdir} ${systemd_system_unitdir}/sentinel-configuration.service" | 17:33 |
| rburton | Skinny7987: don't use ${D} in FILES | 17:34 |
| vd | rburton: I'll be using opkg in a dev environment yes. I still don't see the impact on package feeds if the image is modified. You won't do 'opkg install core-image-minimal', so what is the problem exactly? | 17:35 |
| rburton | if you upgrade base-files then the hostname file changes | 17:36 |
| rburton | generically, any file you touch in a rootfs postprocess is not reflected in the feeds, so an upgrade will remove the rootfs postprocess changes | 17:36 |
| vd | rburton: hooo ok I see. That makes sense | 17:37 |
| vd | rburton: that must be a huge problem for users, passwords, or fstab created that way. How are people dealing with this when using feeds? | 17:38 |
| rburton | don't package those files in the first place | 17:39 |
| vd | true | 17:39 |
| rburton | stuff in /etc is typically marked as a conffile and packaging tools will offer to pick one | 17:39 |
| vd | hostname is a good candidate then | 17:40 |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Ping timeout: 256 seconds) | 17:42 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 17:42 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:42 | |
| vd | I wish I could select PREFERRED_PROVIDER in an image recipe | 17:43 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.173> has quit IRC (Quit: Konversation terminated!) | 17:51 | |
| RP | jonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/1940/steps/12/logs/warnings - that time of the cycle again | 18:01 |
| rburton | without looking, is it uboot | 18:02 |
| rburton | jon has a patch already | 18:02 |
| RP | rburton:bingo :) | 18:02 |
| rburton | our CI exploded a few hours ago :) | 18:02 |
| RP | cool | 18:02 |
| RP | that ordering doesn't look quite right :) | 18:02 |
| RP | (cool on the patch to be clear, not that CI exploded) | 18:03 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto | 18:07 | |
| paulg | RP, by any chance did you see anything about JIT and "accel=tcg" in the release notes or similar when you did the qemu upgrade in late Dec? | 18:17 |
| paulg | one of our internal sanity tests claims they now get "Error: JIT information is only available with accel=tcg" from qemu monitor and they think it happened coincident with the upgrade. | 18:18 |
| paulg | looks like they carved off some stuff into an optional module... https://www.mail-archive.com/qemu-devel@nongnu.org/msg818085.html | 18:21 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:28 | |
| *** Skinny7987 <Skinny7987!~Skinny79@88-159-172-31.fixed.kpn.net> has quit IRC (Quit: Connection closed) | 18:33 | |
| Saur | RP: I'm in the process of updating one of our builds from Honister 3.4 to 3.4.1, but it is failing in Jenkins left and right due to sstate_unpack_package() failing and causing setscene tasks to fail. Unfortunately there is no information in the log of why it fails. :( Looking at the function, after the changes that were introduced in 3.4.1, the only way for that function to fail should be if tar fails. The question now is what happens to | 18:34 |
| Saur | stderr from tar because I sure wish I could see it in the log... | 18:34 |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:fb9b:e9aa:f8f5:f294> has quit IRC (Remote host closed the connection) | 18:36 | |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:a02:4dcb:a9a:1e46> has joined #yocto | 18:37 | |
| Saur | Scratch that, I found the stderr from tar. Apparently there are empty tarballs in our global sstate cache. Argh. :P | 18:44 |
| jonmason | Is python3-cryptography_36.0.1.bb broken now? | 18:56 |
| jonmason | python3-cryptography_36.0.1.bb:21: Could not inherit file classes/setuptools3_rust.bbclass | 18:56 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 19:02 | |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto | 19:04 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-172-245.2.244.pool.telefonica.de> has joined #yocto | 19:33 | |
| rburton | moto-timo: ^^^ | 19:38 |
| moto-timo | did I miss a commit? | 19:38 |
| rburton | looks like it | 19:39 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 19:40 | |
| moto-timo | maybe tgamblin missed it in his PR | 19:41 |
| moto-timo | https://git.openembedded.org/meta-openembedded-contrib/commit/?h=timo/python3-cryptography_36.0.1&id=360dbafb5ca9b4cfd646a1ee1f63cb5d85b3a974 | 19:42 |
| moto-timo | https://git.openembedded.org/meta-openembedded-contrib/commit/?h=timo/python3-cryptography_36.0.1&id=2847980b4d497b069460a298853cb7f59fab662e | 19:42 |
| jonmason | https://gitlab.com/jonmason00/meta-arm/-/pipelines/450764044/failures | 19:45 |
| jonmason | that is all the ugly I'm seeing now | 19:45 |
| moto-timo | yeah, somehow the bbclass commits didn't get merged... I sent them and neither python3-cryptography nor python3-pyruvate would have built without them | 19:46 |
| *** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 19:49 | |
| *** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 19:49 | |
| *** chep` is now known as chep | 19:49 | |
| tgamblin | moto-timo: I must not be catching them all, let me send another | 19:50 |
| tgamblin | moto-timo: jonmason: rburton: khem: I did indeed miss two patches. PR: https://github.com/openembedded/meta-openembedded/pull/520 | 19:56 |
| tgamblin | sorry about that | 19:59 |
| moto-timo | tgamblin: weird corner case compared to the usual meta-python pipeline. always room for improvement! | 20:03 |
| moto-timo | let me know when you achieve perfection so I can learn how you did it | 20:03 |
| *** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 20:04 | |
| tgamblin | moto-timo: might be waiting a while :) | 20:04 |
| moto-timo | rburton: thank you for the quick heads up | 20:04 |
| moto-timo | tgamblin: an eternity perhaps | 20:04 |
| *** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 20:05 | |
| *** chep` is now known as chep | 20:05 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 20:07 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-172-245.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 20:24 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 20:28 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 20:30 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 256 seconds) | 20:41 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has joined #yocto | 20:43 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 20:49 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 20:56 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 21:04 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds) | 21:13 | |
| *** amitk <amitk!~amit@103.208.71.109> has quit IRC (Ping timeout: 240 seconds) | 21:25 | |
| *** olani <olani!~olani@134.238.48.37> has quit IRC (Ping timeout: 240 seconds) | 21:37 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has quit IRC (Quit: Client closed) | 21:37 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 21:40 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:42 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 21:47 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:53 | |
| *** konsgn <konsgn!~konsgn@user/Konsgn> has quit IRC (Quit: Leaving) | 22:01 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-172-245.2.244.pool.telefonica.de> has joined #yocto | 22:03 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:03 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 268 seconds) | 22:03 | |
| *** rr12zer <rr12zer!~rr12zer@62-183-153-56.bb.dnainternet.fi> has quit IRC (Ping timeout: 240 seconds) | 22:03 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 22:05 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 22:07 | |
| kanavin | RP: something seems off about debian9-ty-2 in general, it just looks very very sluggish https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/1178 | 22:12 |
| kanavin | halstead, ^^^ | 22:12 |
| halstead | kanavin: it might be failing. It's one of the oldest workers in the cluster if not the oldest. | 22:13 |
| halstead | I can check it out tomorrow | 22:13 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 22:14 | |
| *** bwoods <bwoods!~bwoods@149.199.62.130> has quit IRC (Quit: WeeChat 2.8) | 22:15 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Client Quit) | 22:16 | |
| *** dushara <dushara!~D@119-18-18-27.771212.mel.static.aussiebb.net> has joined #yocto | 22:40 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-172-245.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 22:40 | |
| dushara | Hi Is this the right channel to raise questions on bitbake? | 22:42 |
| dushara | Looks like there's a bug in the svn fetcher, wrt handling URLs with spaces | 22:48 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 268 seconds) | 23:12 | |
| moto-timo | jonmason: meta-openembedded has the classes now… | 23:14 |
| jonmason | moto-timo: thanks. it looks like almost everything is working for me now | 23:15 |
| jonmason | tf-m isn't happy, but haven't looked at why yet | 23:15 |
| jonmason | and xen is still broken for qemuarm64...zeddii | 23:15 |
| *** dev1990 <dev1990!~dev@81.168.185.188> has quit IRC (Quit: Konversation terminated!) | 23:22 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto | 23:30 | |
| *** olani <olani!~olani@h85-238-221-104.cust.a3fiber.se> has joined #yocto | 23:44 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
