Tuesday, 2022-01-18

rgov[m]Here are all the differences https://gist.github.com/rgov/08d5311d2ba1b6283aad8b5434b31e5000: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 #yocto00: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 #yocto00:35
*** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto00:35
*** armpit <armpit!sid501830@id-501830.uxbridge.irccloud.com> has joined #yocto00:35
*** Guest68 <Guest68!~Guest68@modemcable113.46-82-70.mc.videotron.ca> has joined #yocto00: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 #yocto00:38
*** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto00:38
*** famstutz[m] <famstutz[m]!~famstutzm@2001:470:69fc:105::1:5719> has joined #yocto00:41
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto00:44
*** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has joined #yocto00:45
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto00:52
*** Epictek[m] <Epictek[m]!~epictekma@2001:470:69fc:105::d7cd> has joined #yocto00:52
*** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto00:52
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto00:52
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Ping timeout: 256 seconds)00:53
*** zagor <zagor!~zagor@user/zagor> has joined #yocto00:53
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto00:53
*** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto00: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 #yocto01: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 #yocto01: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 #yocto01:25
*** Tokamak <Tokamak!~Tokamak@> 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 #yocto01: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 #yocto01: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 #yocto02:40
bluelightningRP: 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
*** Konsgn <Konsgn!~Konsgn@user/Konsgn> has quit IRC (Quit: Leaving)03:13
*** amitk <amitk!~amit@> has joined #yocto03: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 #yocto04:01
*** dushara <dushara!~IceChat95@119-18-18-27.771212.mel.static.aussiebb.net> has joined #yocto04:46
dusharaHi 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
geoffhpcoldspark29[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 strange06:01
ad__oh, found, sry. i am in a container without that group06:05
ad__mm stil lgetting that error even creating the group06:11
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:14
ad__ok looks something related to my systemd bbappend06: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 #yocto06: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 #yocto06:46
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto06:54
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto07:05
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:21
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:28
*** frieder <frieder!~frieder@i59F72E74.versanet.de> has joined #yocto07:36
*** frieder <frieder!~frieder@i59F72E74.versanet.de> has quit IRC (Client Quit)07:37
*** frieder <frieder!~frieder@i59F72E74.versanet.de> has joined #yocto07:37
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:40
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:40
*** mckoan|away is now known as mckoan07:45
*** zpfvo <zpfvo!~fvo@> has joined #yocto07: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@> has quit IRC (Ping timeout: 256 seconds)08:10
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:11
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)08:16
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:17
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Quit: Leaving)08:17
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto08:17
*** Guest21 <Guest21!~Guest21@2a01cb0404ad62001469766baefca449.ipv6.abo.wanadoo.fr> has joined #yocto08:19
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:20
Guest21Hi 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 ask08:25
*** dev1990 <dev1990!~dev@> has joined #yocto08:27
*** ederibaucourt <ederibaucourt!~ederibauc@85-170-128-172.rev.numericable.fr> has joined #yocto08:28
*** Guest2140 <Guest2140!~Guest21@2a04:cec0:11d7:f06c:cd4b:ed13:e480:c57b> has joined #yocto08:28
qschulzGuest21: what I can say already is that there's a zip image type which makes a .zip of your image08:30
qschulzc.f. IMAGE_TYPES08:30
*** ederibaucourt <ederibaucourt!~ederibauc@85-170-128-172.rev.numericable.fr> has quit IRC (Client Quit)08:31
qschulzGuest21: 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 #yocto08:33
Guest2140qschulz 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
qschulzwhy 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 file08:37
Guest2140qschulz Thank you for sharing i will take a look to wic image08:38
*** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has joined #yocto08:48
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)08:56
*** zpfvo <zpfvo!~fvo@> has joined #yocto08: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 #yocto09:02
*** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Ping timeout: 256 seconds)09:04
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)09:07
*** zpfvo <zpfvo!~fvo@> has joined #yocto09: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@> has quit IRC (Ping timeout: 268 seconds)09:17
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:17
*** Etheryon70 <Etheryon70!~Etheryon@> has joined #yocto09:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)09:26
*** zpfvo <zpfvo!~fvo@> has joined #yocto09: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@> has quit IRC (Ping timeout: 240 seconds)09:31
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:31
qschulzcoldspark29[m]: is this recipe inheriting kernel-yocto?09:33
qschulz(might be indirectly through other inherited classes or .inc files09:33
coldspark29[m]Yes, it is09:33
qschulzI think you're supposed to use scc/cfg "config" files in that case to patch things up09:34
coldspark29[m]All I need to do is add some drivers and device tree files09:34
qschulzbut 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 repository09:35
qschulzcoldspark29[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 Yocto09:35
qschulzalso.. Yocto is a build system, not technically where source code resides09: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
qschulzcoldspark29[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 files09:36
qschulz"I could manage with some kconfig" sorry didn't understand09:37
qschulzthe point is, your kernel sources shouldn't be associated with which build system you're using09:37
qschulzotherwise if you want to switch to Buildroot for example, you'll have to duplicate the patches09:38
qschulzalso, makes it much harder to develop the kernel outside of Yocto09:38
qschulzjust 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
qschulzso technically, what I did in our layer isn't (IMO) correct09:40
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto09:44
*** camus1 <camus1!~Instantbi@> has joined #yocto09:50
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)09:51
*** camus1 is now known as camus09:51
dacavHello.  I would need some help for remote debugging.09:52
dacavI run `gdbserver$port $command $args09:52
dacavThen on my host I run gdb, use `target remote $host:$port`09:53
dacavAt this point I can effectively run the command by `continue`, but I don't see symbols09:53
dacavI've installed the debug symbols package09:54
dacavAm I missing some step maybe?09:54
kroondacav, debug symbols need to be available on the host, not the target09:55
dacavI see.  Calling `symbol-file` tells me they're in `target:/usr/bin/.debug/$command`09:56
kroondacav, you can use "set sysroot" gdb command to point to where the target sysroot is on the host09:56
dacavThanks kroon.  I'm not sure of where that will be, but I guess I can find it below the yocto tmp/09:56
kroondacav, you can build the SDK, install it somewhere, it will contain the target sysroot with debug info09:57
dacavToo bad, my sdk is broken09: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
dacavkroon: I'm only left with a docker image that was built before the SDK ended up in broken state09:59
dacavQuestion 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 #yocto10:01
kroondacav, oh, you built the binary outside yoto ?10:02
dacavkroon: I ended up to package my binary with a recipe, so I could leverage bitbake10: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 #yocto10:03
kroondacav, ah ok. i'm sure you can point gdb to the debug info on the host somehow. find the -dbg package and unpack it somewhere10: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
dacavkroon: 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
kroonmaybe there are other ways to instruct gdb where to look for debug info10:06
*** Etheryon70 <Etheryon70!~Etheryon@> has quit IRC (Ping timeout: 256 seconds)10:10
kroondacav, 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 #yocto10:12
qschulzkayterina[m]: don't do that, just remove everything EXCEPT downloads and sstate-cache in your build directory10:13
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Ping timeout: 256 seconds)10:13
qschulzcleanall removes the fetched sources and sstate-cache, almost making it a build from scratch10:14
qschulzkayterina[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 away10: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 kernel10:15
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)10:15
qschulzcoldspark29[m]: and defconfig10:15
*** zpfvo <zpfvo!~fvo@> has joined #yocto10: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
qschulzkconfig 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 defconfig10:18
qschulzultimately, 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 built10:19
coldspark29[m]Ah so kconfig is the drivers sources available I guess10:19
coldspark29[m]I meant defconfig then10:19
dacavkroon: thanks! Sure! https://lists.yoctoproject.org/g/yocto/message/5583610:20
qschulzno, 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
dacavkroon: I didn't discuss the broken sdk, actually10:21
*** zpfvo <zpfvo!~fvo@> 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
kroondacav, 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 PATH10:24
qschulzkayterina[m]: it makes /tmp inside the container a tmpfs, that's all I can say10:26
kroondacav, so if you devshell a recipe the DEPENDS in your cross compiler, then you'd see it in PATH10:26
RPmichaelo: 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 code10:28
dacavkroon: I see.  ...would it work to add the cross-compiler as DEPENDS of my tool?10:29
kroondacav, i think so10:29
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)10:30
dacavkroon: 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
kroondacav, then devshell your tool, and you should have the cross compiler in PATH10:30
dacavkroon: thanks.  That would be *MUCH* better than a docker container10:30
dacavdocker is crap, I have to copy data or use volumes, then all permissions become root... pff...10:31
kroondacav, its worth a shot decribing the problem with the SDK on the oe-core ml, people will help out if they can10:32
dacavkroon: 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 layers10:34
dacavI know there's a xilinx mailing list.10:35
dacavshould I use oe-core or xilinx ml?10:35
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:35
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10: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 #yocto11:14
*** jatedev <jatedev!~jatedev@> has quit IRC (Quit: Client closed)11:18
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto11:40
dacavkroon: 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
kroondacav, 👍11:57
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:09
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto12:09
paulbarkerI'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
paulbarkerOr does that cache depend on other info in `${TMPDIR}`12:14
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto12:25
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit)12:25
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:26
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto12:27
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto12:29
*** Konsgn <Konsgn!~Konsgnx3@user/Konsgn> has joined #yocto12:53
*** Konsgn <Konsgn!~Konsgnx3@user/Konsgn> has quit IRC (Client Quit)12:55
*** konsgn <konsgn!~konsgn@user/Konsgn> has joined #yocto12:55
*** radsquirrel <radsquirrel!~bradleyb@> has quit IRC (Quit: WeeChat 3.4)12:58
dacavHi.  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
dacavIt looks like there's no recipe for it in yocto12: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 #yocto13:01
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)13:05
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto13:06
*** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto13:08
rburtondacav: bitbake package-index13:09
rburtondacav: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management covers the build host side13:10
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 240 seconds)13:11
*** jmiehe1 is now known as jmiehe13: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 #yocto13:20
Guest96FYI: https://www.yoctoproject.org/irc/ hasn't been updated for the whole year 2022 - could one please have a look13:21
*** Guest96 <Guest96!~Guest96@2a02:3103:205c:200:bed3:df7f:f488:16a2> has quit IRC (Client Quit)13:21
qschulzhalstead: good morning :) can you have a look at what Guest96 just reported please? ^13:24
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 256 seconds)13:27
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto13:31
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto13:31
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13: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 #yocto13:52
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto13:55
*** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)13:55
dacavrburton: thanks, I'll check out :)13:58
RPmichaelo: I tweaked some permissions to get the docs builds to stop failing14:00
michaeloRP: awesome, thanks a lot!14:06
michaeloRP: thanks for taking the BitBake patch. No other one was missing I believe.14:07
RPmichaelo: thanks. I get a bit confused at times with patches that go to multiple lists so remind me if I miss anything14:08
dacavrburton: and the funny part is that I even read that already.  Sorry for the dumb question.14:13
*** marka is now known as Guest11414: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 #yocto14:20
*** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto14:21
*** TundraMan is now known as marka14:21
Skinny79Hi 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 promising14:22
Skinny79Uploaded file: https://uploads.kiwiirc.com/files/83c55968f92f142caf60faa77dcfad0d/pasted.txt14:24
Skinny79However when I add the 'podman' recipe (from meta-virtualization) to my image bitbake starts complaining about not being able to download ostree :14:24
Skinny79ERROR: 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
Skinny79ERROR: 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
Skinny79When 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 branch14:24
rburtonthe actual error is likely above what you pasted14:26
rburtoncan you pastebin the full log?14:26
Skinny79you mean the console output or the complete task log ?14:27
rburtonthe console output will do14:29
Skinny79console log : https://pastebin.com/JV79TVAh14:29
Skinny79full task log file for the failing step (ostree) : https://pastebin.com/YtQJLYmc14:30
Skinny79I can't find any obvious ERRORs on 'why' the download would fail14:30
rburtonfatal: unable to access 'https://gitlab.gnome.org/GNOME/libglnx.git/': server certificate verification failed. CAfile: none CRLfile: none14:32
Skinny79how did I miss that ? lol14:32
rburtonits not on the console, which is annoying14:32
rburtontry a clone outside of yocto, you might have stale certificates14:33
rburtonthere was a major update a few months ago which you'll need14:33
Skinny79git clone https://gitlab.gnome.org/GNOME/libglnx.git14:34
Skinny79Cloning into 'libglnx'...14:34
Skinny79fatal: unable to access 'https://gitlab.gnome.org/GNOME/libglnx.git/': server certificate verification failed. CAfile: none CRLfile: none14:34
Skinny79Freshly installed host machine (windows) with WSL2 ;-)14:34
Skinny79Never thought the issue is in that area14:34
paulbarkerSkinny79: 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 Ubuntu14:35
Skinny79It has ca-certificates but now that I look at it its a version from 2019 :shrug:14:35
paulbarkerThat far out-of-date would definitely cause issues!14:36
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)14:37
Skinny79It'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 #yocto14:39
Skinny79Am I right when I say that "DISTRO_FEATURES" are built but not ending up on the rootfs until you actually "INSTALL_" them ?14:40
rburtonDISTRO_FEATURES are not things that get built exactly14:42
rburtonlike there isn't a 'wifi' recipe14:42
rburtonbut yes, a thing being in distro features doesn't mean it is *definitely* in the image14:42
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!)14:42
rburtonconcrete example would be useful14:42
smurrayand 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 ones14:44
Skinny79Example 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-openstack14:45
Skinny79layer 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 layer14:45
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto14:46
Skinny79BTW.. updating ca-certificates works, ends an afternoon looking for something in the wrong place, THANKS!14:46
rburtona root certificate expired, so everyone with stale certs suddenly got weird errors14:47
Skinny79So it had nothing to do with ostree and googling for issues with that aren't very helpful in this case ;-)14:48
rburtonthe fetcher can be a pain as there's so many layers, best to look at the underlying log straight away14: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 #yocto14:49
Skinny79Another lesson learned14:50
*** amitk <amitk!~amit@> 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
Skinny79Still 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
qschulzSkinny79: the bbappend (if found) will be applied to the original recipe matching the name and the version (if found)15:29
qschulzif that was your question15:29
qschulzthere's no need to include/require the original recipe in a bbappend15:29
rfs613Skinny79: 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
qschulzyou just need to make sure your layer.conf has bbappends in the regexp in BBFILES15:30
Skinny79ok, but I still need to add 'salt' to the IMAGE_INSTALL somewhere15:30
qschulzSkinny79: not necessarily15:31
qschulzif something RDEPENDS on salt and is part of IMAGE_INSTALL, then it's not needed15:31
Skinny79okkkaay..... so..15:31
qschulzif nothing pulls the dependency for you, then you need to add your package to the packages to be installed by the image recipe15:31
Skinny79I have 'meta-custom' layer with recipes-core/mycore.bb which RDEPENDS 'salt' and has the .bbappend file15:32
Skinny79then I only need 'mycore' in my local.conf to add everything15:32
Skinny79correct ?15:32
qschulzSkinny79: sort of15:35
Skinny79Uploaded file: https://uploads.kiwiirc.com/files/b8580559dda1037e37a4cb3f6374691b/image.png15:35
qschulzfirst usually you have an additional subdirectory, e.g. recipes-core/something/mycore.bb15:36
Skinny79the .bb file has 'RDEPENDS:${PN} += " salt"'15:36
qschulzsecond, you are supposed to create/extend the image recipe you build to add mycore to IMAGE_INSTALL in there15:36
qschulzlocal.conf should not be versioned15:36
Skinny79and in my  local.conf I have IMAGE_INSTALL:append = " sentinel-core"15:36
qschulzSkinny79: yes, but again, create an image recipe to store IMAGE_INSTALL variable in it :)15:37
*** amitk <amitk!~amit@> has joined #yocto15:37
Skinny79Uploaded file: https://uploads.kiwiirc.com/files/41b8d6731e113ca9f7463bb913aabce1/image.png15:38
Skinny79with IMAGE_INSTALL:append = " sentinel-core"15:38
qschulzSkinny79: yeah that's okay-ish for now, next step will be to create your own image recipe :)15:42
Skinny79I 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
Skinny79Is that what's solved by the image recipe ?15:42
qschulzwhat's the value of BBFILES in your layer.conf file?15:43
Skinny79just the default : https://pastebin.com/ThNM5ji115:43
Skinny79What 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
qschulzSkinny79: you need an additional parent directory15:45
qschulzotherwise it does not match the regexp in BBFILES and your bbappends aren't found15:45
qschulzyou could see this by running btibake-layers show-append I think15:45
Skinny79Uploaded file: https://uploads.kiwiirc.com/files/4dfc69acae262f8521803a393d90fef1/image.png15:45
qschulzSkinny79: you run bitbake core-image-minimal15:46
Skinny79I think that's there : sentinel-core folder under recipes-core15:46
Skinny79qschulz yes15:46
Skinny79(for now)15:46
qschulzSkinny79: so that's what decides what gets build into your image15:46
Skinny79One step at a time :)15:46
qschulznot all recipes15:46
qschulzjust what's necessary to build your image recipe15:46
qschulzrecipes-core/mycore.bb does NOT match BBFILES pattern15:47
qschulzrecipes-core/core/mycore.bb does though15:47
Skinny79no sorry, I mistyped that.. look at the screenshot for my actual folder structure15: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
qschulzSkinny79: recipes-images/core-image-minimal.bbappend does not match BBFILES either15:48
Skinny79oh hold on15:48
Skinny79that image recipe is not matching that structure15:48
Skinny79that ^^15:48
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto15:48
*** fleg <fleg!dfbb34cb39@user/fleg> has joined #yocto15:48
qschulzalso try to send text only and not images :)15:48
*** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has joined #yocto15:48
Skinny79ok, np15:49
qschulzeasier for us (don't need to pop-up some browser to watch it) and also makes it archive friendly for the IRC logs15:49
qschulzso people might be able to find the discussions with their favourite search engine15:49
Skinny79true, I figured i t would be easier to read instead of ASCII folder structures ;-)15:49
qschulzSkinny79: find . -name "*.bb*" would probably have been enough :)15:50
Skinny79ok one more as qemu doesn't allow text selection somehow15:50
qschulzor `tree` also helps :)15:50
Skinny79Uploaded file: https://uploads.kiwiirc.com/files/dd1249ae1d299fc8f5680814fc01ce94/image.png15:50
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving)15:50
qschulzSkinny79: looks nice :) anything wrong?15:50
Skinny79brilliant.. the beauty of sense is that when it makes sense to you it's beautiful15:50
qschulzSkinny79: if I may suggest the Youtube tutorial from LetoThe2nd.. will help you get started and build good foundations15:51
Skinny79qschulz 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
qschulzSkinny79: absolutely15:52
Skinny79Nice! Thanks.. Have watch a lot already but suggestions are very welcome15:52
Skinny79Thank you so much!15:53
qschulzenjoy :)15:53
Skinny79Although  my wife wouldn't agree because here's another night spend on hobbies ;-)15:53
vdhi 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
kergothAh, hadn't considered parse time! Makes sense16:00
vdkergoth: 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@> has joined #yocto16:09
kergothI wish those messages were moved to only with verbose, they mean nothing to most users anyway16:10
RPkergoth: 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 failures16:15
frayI 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
frayWith 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 builds16:18
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)16:19
frayI 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 it16:21
frayJust 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
fraythe machine is a 48 thread machine, but 48/48 caused the system to kill threads16:24
konsgnjust 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 #yocto16:26
konsgnearliest trace is : [<c01557d4>] (__do_sys_reboot) from [<c0100060>] (ret_fast_syscall+0x0/0x28)16:26
halsteadqschulz: Guest96: I've updated the irc logging and 2022 logs are up now.16:36
*** alessioigor <alessioigor!~alessioig@> has joined #yocto16:41
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)16:43
qschulzhalstead: thanks :)16:44
vdgiven than the machine is parsed before the distro, is it OK to have FOO:append:mydistro = " bar" in a machine configuration?16:48
rburtonyes, appends happen after parse16:49
vdrburton: but FOO:mydistro = "bar" would be a problem?16:49
kergothIt 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 fork16:49
kergothI've seriously considered having my distro include conf/distro-machine/${DISTRO}-${MACHINE}.conf or something before, though never ended up doing int16:50
kergothactually 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
rburtonvd: more accurately, overrides happen after parse16:52
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:54
qschulzvd: the second one (FOO:mydistro) will completely override FOO if mydristro is used16:55
vdqschulz: I know, my question was regarding the parsing order (since the distro is parsed after the machine config)16:55
qschulzvd: I don't think it matters unless you are requiring direct expansion (:= or d.getVar)16:59
qschulzI mean, if you use variables from other places that in the current file, for which the parsing order will matter17:00
qschulzotherwise, I'd say distro or machine first does not matter17:00
qschulzoverrides are anyway all saved and at the end of parsing the one that applies is taken17:01
vdSo the parsing is two passes?17:01
qschulzOne pass and then everything is resolved? I don't know honestly about the internals17: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 #yocto17:03
vdThey 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
qschulzif you;re going to have more changes, in the end, you'll most likely need a distro anyway17:05
qschulzbut if that were to be the only change, I'd have two machines to maximise the sstate-cache reuse17:06
qschulzor even better, two bootloader recipes17:06
vdqschulz: 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
vdqschulz: and then you choose your preferred virtual/bootloader provider from the machine or distro conf ideally?17:08
qschulzin 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
qschulzvd: you could even just make a U-Boot env recipe only and set environment variables based onproduction/debug and have the same uboot binary17:11
qschulzvd: the issue with distros is that nothing is re-used17:11
qschulzbetween distros ofc17:11
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)17:14
vdqschulz: that's a good insight thank you17:14
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto17:15
vdqschulz: 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
qschulzvd: Ah I forgot we opnly support building one wks file at a time17:20
qschulzif we were to support multi wks file in one image recipe then both could be built at once17:20
*** frieder <frieder!~frieder@i59F72E74.versanet.de> has quit IRC (Remote host closed the connection)17:21
kergothvd, 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|away17:21
vdit 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
vdkergoth: that makes a lot of sense.17:22
xperia64I'm having trouble with do_fetch[mcdepends]; when the dependency is rebuilt/dirty, the do_fetch[mcdepends] is still cached and marked as covered17:23
vdWouldn't it be better to tweak the hostname file in an image class rather than tweaking hostname:pn-base-files globally?17:23
rburtonvd: how would that work? :)17:25
rburtonunless you mean write a rootfs postprocess thing17:25
rburtonin which case sure, do that if you want17:25
vdrburton: 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
Skinny79Ok , one last for today:)17:29
Skinny79NB_DIR = "/opt/newblack"17:29
Skinny79do_install() {17:29
Skinny79    install ${WORKDIR}/sentinel-config ${D}${NB_DIR}/bin17:29
Skinny79    install -Dm644 ${WORKDIR}/sentinel-configuration.service "${D}${systemd_system_unitdir}/sentinel-configuration.service"17:29
Skinny79FILES:${PN} = "${systemd_system_unitdir} ${systemd_system_unitdir}/sentinel-configuration.service ${D}${NB_DIR}/bin/sentinel-config"17:29
rburtonvd: depends on your usecase17:29
rburtonvd: 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
*** Skinny7987 <Skinny7987!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto17:30
vdrburton: is there a cost to tweak files from post process commands rather than relying on installed packages?17:30
rburtonvd: package feeds break any changes17:31
Skinny7987Two files, but the custom binary in /opt/newblack/bin/sentinel-config results in a ` [installed-vs-shipped]` error17:31
Skinny7987the systemd unit works fine17:31
Skinny7987What could be the reason ?17:31
vdrburton: what do you mean?17:31
rburtonvd: 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 file17:32
rburtonSkinny7987: /opt isn't in FILES_${PN} by default, you'll need to add it yourself17:32
vdrburton: but you can't install an image from a package feed, can you? What's the point of it?17:33
rburtonvd: if you're not using feeds, it's moot17:33
rburtonif you're using feeds its a fundamental problem17:33
Skinny7987ah.. adding only the file (within that path) isn't enough ?17:33
Skinny7987FILES:${PN} = "${D}${NB_DIR}/bin ${D}${NB_DIR}/bin/sentinel-config ${systemd_system_unitdir} ${systemd_system_unitdir}/sentinel-configuration.service"17:33
rburtonSkinny7987: don't use ${D} in FILES17:34
vdrburton: 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
rburtonif you upgrade base-files then the hostname file changes17:36
rburtongenerically, any file you touch in a rootfs postprocess is not reflected in the feeds, so an upgrade will remove the rootfs postprocess changes17:36
vdrburton: hooo ok I see. That makes sense17:37
vdrburton: 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
rburtondon't package those files in the first place17:39
rburtonstuff in /etc is typically marked as a conffile and packaging tools will offer to pick one17:39
vdhostname is a good candidate then17:40
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 256 seconds)17:42
*** Tokamak <Tokamak!~Tokamak@> 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
vdI wish I could select PREFERRED_PROVIDER in an image recipe17:43
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC (Quit: Konversation terminated!)17:51
RPjonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/1940/steps/12/logs/warnings - that time of the cycle again18:01
rburtonwithout looking, is it uboot18:02
rburtonjon has a patch already18:02
RPrburton:bingo :)18:02
rburtonour CI exploded a few hours ago :)18:02
RPthat 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 #yocto18:07
paulgRP, 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
paulgone 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
paulglooks like they carved off some stuff into an optional module...   https://www.mail-archive.com/qemu-devel@nongnu.org/msg818085.html18:21
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:28
*** Skinny7987 <Skinny7987!~Skinny79@88-159-172-31.fixed.kpn.net> has quit IRC (Quit: Connection closed)18:33
SaurRP: 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 to18:34
Saurstderr 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 #yocto18:37
SaurScratch that, I found the stderr from tar. Apparently there are empty tarballs in our global sstate cache. Argh. :P18:44
jonmasonIs python3-cryptography_36.0.1.bb broken now?18:56
jonmasonpython3-cryptography_36.0.1.bb:21: Could not inherit file classes/setuptools3_rust.bbclass18: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 #yocto19:04
*** florian_kc <florian_kc!~florian@dynamic-002-244-172-245.2.244.pool.telefonica.de> has joined #yocto19:33
rburtonmoto-timo: ^^^19:38
moto-timodid I miss a commit?19:38
rburtonlooks like it19:39
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)19:40
moto-timomaybe tgamblin missed it in his PR19:41
jonmasonthat is all the ugly I'm seeing now19:45
moto-timoyeah, somehow the bbclass commits didn't get merged... I sent them and neither python3-cryptography nor python3-pyruvate would have built without them19:46
*** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto19: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 chep19:49
tgamblinmoto-timo: I must not be catching them all, let me send another19:50
tgamblinmoto-timo: jonmason: rburton: khem: I did indeed miss two patches. PR: https://github.com/openembedded/meta-openembedded/pull/52019:56
tgamblinsorry about that19:59
moto-timotgamblin: weird corner case compared to the usual meta-python pipeline. always room for improvement!20:03
moto-timolet me know when you achieve perfection so I can learn how you did it20:03
*** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto20:04
tgamblinmoto-timo: might be waiting a while :)20:04
moto-timorburton: thank you for the quick heads up20:04
moto-timotgamblin: an eternity perhaps20: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 chep20: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 #yocto20:30
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 256 seconds)20:41
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto20:43
*** goliath <goliath!~goliath@user/goliath> has joined #yocto20:49
*** alessioigor <alessioigor!~alessioig@> has joined #yocto20:56
*** alessioigor <alessioigor!~alessioig@> 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@> has quit IRC (Ping timeout: 240 seconds)21:25
*** olani <olani!~olani@> has quit IRC (Ping timeout: 240 seconds)21:37
*** jatedev <jatedev!~jatedev@> has quit IRC (Quit: Client closed)21:37
*** leon-anavi <leon-anavi!~Leon@> 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@> has joined #yocto21:47
*** Tokamak <Tokamak!~Tokamak@> 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 #yocto22:03
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22: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 #yocto22:05
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto22:07
kanavinRP: something seems off about debian9-ty-2 in general, it just looks very very sluggish https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/117822:12
kanavinhalstead, ^^^22:12
halsteadkanavin: it might be failing. It's one of the oldest workers in the cluster if not the oldest.22:13
halsteadI can check it out tomorrow22:13
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto22:14
*** bwoods <bwoods!~bwoods@> has quit IRC (Quit: WeeChat 2.8)22:15
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Client Quit)22:16
*** dushara <dushara!~D@119-18-18-27.771212.mel.static.aussiebb.net> has joined #yocto22: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
dusharaHi Is this the right channel to raise questions on bitbake?22:42
dusharaLooks like there's a bug in the svn fetcher, wrt handling URLs with spaces22:48
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 268 seconds)23:12
moto-timojonmason: meta-openembedded has the classes now…23:14
jonmasonmoto-timo: thanks.  it looks like almost everything is working for me now23:15
jonmasontf-m isn't happy, but haven't looked at why yet23:15
jonmasonand xen is still broken for qemuarm64...zeddii23:15
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)23:22
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto23:30
*** olani <olani!~olani@h85-238-221-104.cust.a3fiber.se> has joined #yocto23:44

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!