Thursday, 2024-03-07

*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.8)00:00
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)00:11
*** Saur75 <Saur75!~Saur75@> has joined #yocto00:12
*** tlwoerner <tlwoerner!> has quit IRC (Ping timeout: 260 seconds)00:18
*** tlwoerner <tlwoerner!> has joined #yocto00:21
*** Perflosopher <Perflosopher!~perflosop@> has joined #yocto00:24
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 252 seconds)00:28
*** tlwoerner <tlwoerner!> has quit IRC (Ping timeout: 264 seconds)00:32
*** tlwoerner <tlwoerner!> has joined #yocto00:33
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 264 seconds)00:37
*** chep <chep!chep@gateway/vpn/airvpn/chep> has quit IRC (Quit: ZNC 1.8.2 -
*** chep <chep!chep@gateway/vpn/airvpn/chep> has joined #yocto00:39
*** tlwoerner <tlwoerner!> has quit IRC (Ping timeout: 264 seconds)00:39
*** vlrk <vlrk!~vlrk@> has joined #yocto00:41
*** tlwoerner <tlwoerner!> has joined #yocto00:42
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto00:43
*** tlwoerner <tlwoerner!> has quit IRC (Read error: Connection reset by peer)00:45
*** tlwoerner <tlwoerner!> has joined #yocto00:45
moto-timoI'll note that anyone can submit a layer. You do not have to be a layer maintainer.00:55
moto-timoYou might unearth problems with a given layer and perhaps that will lead the the layerindex maintainers (me) sending the layer maintainers helpful emails.00:55
*** Smokey <Smokey!~Smokey@> has quit IRC (Quit: Ping timeout (120 seconds))00:55
*** chep <chep!chep@gateway/vpn/airvpn/chep> has quit IRC (Quit: ZNC 1.8.2 -
*** chep <chep!chep@gateway/vpn/airvpn/chep> has joined #yocto01:00
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)01:12
*** vlrk <vlrk!~vlrk@> has quit IRC (Quit: Client closed)01:24
*** Daanct12 <Daanct12!~danct12@user/danct12> has joined #yocto01:24
*** vlrk <vlrk!~vlrk@> has joined #yocto01:26
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection)01:27
*** vlrk <vlrk!~vlrk@> has quit IRC (Client Quit)01:27
*** vlrk <vlrk!~vlrk@> has joined #yocto01:28
*** nerdboy <nerdboy!~nerdboy@> has joined #yocto01:30
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)02:03
*** davidinux <davidinux!~davidinux@> has joined #yocto02:05
*** vlrk <vlrk!~vlrk@> has quit IRC (Quit: Client closed)02:06
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)02:15
*** Saur75 <Saur75!~Saur75@> has joined #yocto02:15
*** joekale <joekale!~quassel@> has joined #yocto02:25
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:26
*** starblue <starblue!> has joined #yocto02:28
*** jclsn <jclsn!~jclsn@2a04:4540:6537:3400:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 272 seconds)02:32
*** jclsn <jclsn!~jclsn@2a04:4540:651f:4600:2ce:39ff:fecf:efcd> has joined #yocto02:34
*** mulk <mulk!> has quit IRC (Ping timeout: 256 seconds)02:42
*** mulk <mulk!> has joined #yocto02:43
*** jmd <jmd!~user@2001:a61:2aa0:ea01:fcec:2373:8649:cf16> has joined #yocto03:17
*** pedrowiski <pedrowiski!~pedrowisk@user/pedrowiski> has quit IRC (Read error: Connection reset by peer)03:22
*** sakoman <sakoman!> has joined #yocto03:24
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)03:29
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 260 seconds)03:37
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto03:39
mischiefis it possible to generate the '-native' sstate artifacts that a different host arch would need somehow? say, if we only push to our sstate mirror from x86_64 hosts, but we would want to provide sstate for people aarch64 laptops.03:47
*** joekale <joekale!~quassel@> has quit IRC (Ping timeout: 264 seconds)03:55
*** kpo <kpo!> has joined #yocto04:10
*** kpo <kpo!> has quit IRC (Ping timeout: 272 seconds)04:21
*** xmn <xmn!> has quit IRC (Ping timeout: 255 seconds)04:39
*** alperak <alperak!~alperak@> has joined #yocto04:50
*** alimon <alimon!~alimon@> has quit IRC (Ping timeout: 260 seconds)04:53
*** vlrk <vlrk!~vlrk@> has joined #yocto04:54
*** vlrk <vlrk!~vlrk@> has quit IRC (Quit: Client closed)05:07
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)05:25
*** Saur75 <Saur75!~Saur75@> has joined #yocto05:26
*** paulg <paulg!> has quit IRC (Ping timeout: 246 seconds)05:26
*** paulg <paulg!> has joined #yocto05:27
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto05:55
*** jmd <jmd!~user@2001:a61:2aa0:ea01:fcec:2373:8649:cf16> has quit IRC (Remote host closed the connection)05:57
*** jmd <jmd!~user@2001:a61:2aa0:ea01:fcec:2373:8649:cf16> has joined #yocto06:00
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)06:01
*** Saur75 <Saur75!~Saur75@> has joined #yocto06:02
*** jmd <jmd!~user@2001:a61:2aa0:ea01:fcec:2373:8649:cf16> has quit IRC (Remote host closed the connection)06:13
*** gvmeson <gvmeson!> has joined #yocto06:14
*** vmeson <vmeson!> has quit IRC (Ping timeout: 260 seconds)06:14
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)06:36
*** shivamurthy <shivamurthy!> has quit IRC (Ping timeout: 256 seconds)06:56
*** shivamurthy <shivamurthy!> has joined #yocto06:59
*** Daanct12 <Daanct12!~danct12@user/danct12> has quit IRC (Ping timeout: 252 seconds)07:09
*** amitk_ <amitk_!~amit@> has joined #yocto07:21
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 268 seconds)07:24
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:27
*** mckoan|away is now known as mckoan07:31
*** vladest <vladest!> has quit IRC (Ping timeout: 264 seconds)07:35
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)07:37
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:38
*** Daanct12 <Daanct12!~danct12@user/danct12> has joined #yocto07:42
*** rob_w <rob_w!> has joined #yocto07:44
*** alperak <alperak!> has joined #yocto07:48
*** Guest94 <Guest94!~Guest94@> has joined #yocto07:48
*** pretec <pretec!~pretec@> has joined #yocto07:49
*** Guest94 <Guest94!~Guest94@> has quit IRC (Client Quit)07:50
*** luc4 <luc4!~luca@2a00:6d43:501:1201:9997:c7c8:aabe:c87a> has joined #yocto07:54
*** frieder <frieder!> has joined #yocto07:57
*** vladest <vladest!~Thunderbi@> has joined #yocto08:08
*** zpfvo <zpfvo!> has joined #yocto08:13
*** ptsneves <ptsneves!> has joined #yocto08:27
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 255 seconds)08:32
*** mbulut <mbulut!> has joined #yocto08:38
*** mbulut <mbulut!> has quit IRC (Client Quit)08:38
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto08:43
*** prabhakalad <prabhakalad!~prabhakar@> has quit IRC (Quit: Konversation terminated!)08:46
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto08:46
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:01
*** creich <creich!> has joined #yocto09:05
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)09:05
*** Saur75 <Saur75!~Saur75@> has joined #yocto09:06
creichhey guys, we've encountered very low download speeds (~40KiB/s) when cloning the linux-yocto repo from we've watched this a few weeks now, and it allways is only that one repository. is this a known issue? or is there any specific reason for this?09:11
RPcreich: no specific reason. Could you drop a note mentioning the issue along with which IP address is resolving to and a traceroute please?09:13
RPcreich: we think there is a problematic network route but we're struggling to resolve it since we don't own the network involved09:13
creichRP: thanks for the hint. i'll write a mail09:14
RPrburton: how does the screensaver work on our qemu images?09:16
RPrburton: you might wonder why I ask that...09:17
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)09:18
*** Saur75 <Saur75!~Saur75@> has joined #yocto09:19
*** pretec_ <pretec_!~pretec@> has joined #yocto09:20
mckoanclever: same here, and it results in a do_fetch failure09:22
*** pretec <pretec!~pretec@> has quit IRC (Ping timeout: 256 seconds)09:23
mckoanclever: consider that in EU we have problems due to undersea cables broken in red sea09:23
RPrburton: xorg.conf manuals say 10 mins then 20-40 mins for DPMS09:24
*** pretec_ is now known as pretec09:29
*** Vonter_ <Vonter_!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds)09:35
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto09:35
*** pretec_ <pretec_!~pretec@> has joined #yocto09:38
*** pretec <pretec!~pretec@> has quit IRC (Ping timeout: 256 seconds)09:41
*** ptsneves <ptsneves!> has joined #yocto10:33
*** Guest9743 <Guest9743!~Guest9743@> has joined #yocto10:42
*** starblue <starblue!> has quit IRC (Ping timeout: 264 seconds)10:43
*** starblue <starblue!> has joined #yocto10:44
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)10:54
*** Saur75 <Saur75!~Saur75@> has joined #yocto10:55
*** Noor <Noor!~Noor@> has joined #yocto11:11
NoorHello Guys, I have a question. is there a way to say the recipe that it should not generate the sstate and everytime it should build from scratch11:12
creichNoor: SSTATE_SKIP_CREATION = "1"11:20
creichNoor: you can put this into your recipe, this way it shuold avoid using sstate11:21
mckoanNoor: or do_compile[nostamp] = "1"11:21
Nooraahhh thanks. so nice if you guys11:22
creichmckoan: wouldn't that force a rebuild like everytime?11:22
creichjust asking out of couriosity, since i also was just thought about it11:23
NoorI think so. I think image recipes has this11:23
creichNoor: so actually it depends on what you need explicitly11:23
creichthe second option would rebuild that recipe every time you run bitbake11:23
creichthe other option should only avoid using a sstate cache but i think it'll still use stamps and try to avoid a rebuild when there is no obvious change11:24
rburtonthe question is do you actually want it to run every time (in which case use nostamp) or do you just want to force it in testing (in which case use bitbake -C)11:24
rburtonor is the problem "my recipe makes so much sstate its actually faster to rebuild than pull from sstate"11:25
*** pretec__ <pretec__!~pretec@> has joined #yocto11:37
NoorI am moving towards SSTATE_SKIP_CREATION  as I don't want it rebuilding every time. I just want not use sstate. I remember nostamp is used in images which get rebuilt every time11:39
*** pretec_ <pretec_!~pretec@> has quit IRC (Ping timeout: 264 seconds)11:40
NoorActually I want gdb to be used outside from build folder. Currently using it from its image folder. so when it is built from cached image folder is not there so we can't find working binary11:41
wmills_I use screen /dev/ttyUSBX for a serial terminal.  With recent builds from master my text cursor disappears.  This has not happended to me before.  Does anyone know why?11:42
rburtonNoor: so you're battling sstate because of something to do with gdb?11:43
rburtonif you want to run gdb-native then running it from inside the build tree is just the wrong thing to do11:43
rburtonbecause, yeah, if it came from sstate then the build tree does not exist11:44
rburtonNoor: oe-run-native is the tool you want to run an arbitrary binary from an arbitrary native recipe.  that will handle setting paths and dependencies so linkage actually works.11:45
rburtonclassic example of 'explain your problem not what you think the solution is' to be honest :)11:46
*** Saur75 <Saur75!~Saur75@> has quit IRC (Ping timeout: 250 seconds)11:47
*** pretec_ <pretec_!~pretec@> has joined #yocto11:55
*** pretec__ <pretec__!~pretec@> has quit IRC (Ping timeout: 255 seconds)11:57
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)12:12
*** pretec_ <pretec_!~pretec@> has quit IRC (Quit: Leaving)12:17
*** lexano <lexano!~lexano@> has joined #yocto12:35
*** Daanct12 <Daanct12!~danct12@user/danct12> has quit IRC (Quit: WeeChat 4.2.1)12:40
*** Saur75 <Saur75!~Saur75@> has joined #yocto12:43
Noorwe need gdb binary to debugging purpose. yocto docs recommended to build gdb-cross-<architecture>. We found that "tmp/work/x86_64-linux/gdb-cross-aarch64/11.2-r0/image/home/ahsann/mel/releases/builds/ginkgo/hycon/build_hycon/tmp/work/x86_64-linux/gdb-cross-aarch64/11.2-r0/recipe-sysroot-native/usr/bin/aarch64-oe-linux/aarch64-oe-linux-gdb" can be12:50
Noorused. But when gdb-cross-<architecure> is built from sstate image folder is not created as install tasks is not executed. So I want to build gdb-cross-<architecture> from scratch (don't use sstate) so that we can get a working binary in image folder.12:50
NoorI hope explained the problem and my solution both above12:51
rburton_never_ run stuff from the build tree directly13:04
rburtonoe-run-native will tell you to run bitbake gdb-cross-aarch64 -caddto_recipe_sysroot, which will populate the sysroot for you13:05
rburtonyou don't want to build it from scratch, you want a sysroot13:05
rburtonas i said: explain the problem not what you think the solution is13:05
landgrafrburton: "_never_ run stuff from the build tree directly" - unless you want to debug some weird issue with built binaries  :)13:06
rburtonNoor: problem: i need to run a binary from a native recipe.  your solution: i want to turn off sstate so when. i build gdb it always rebuilds. actual solution: populate the sysroot for the native recipe.13:06
* landgraf ran opkg from build tree few times13:06
rburtonlandgraf: shush :)13:08
*** xmn <xmn!> has joined #yocto13:10
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Ping timeout: 252 seconds)13:18
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto13:19
*** ctraven_ <ctraven_!~ctraven@> has quit IRC (Ping timeout: 255 seconds)13:26
*** ctraven <ctraven!~ctraven@> has quit IRC (Ping timeout: 256 seconds)13:27
*** rsalveti <rsalveti!> has quit IRC (Quit: Connection closed for inactivity)13:39
Noorrburton: (y)13:39
Noornow next step. I have my solution I will not share it :). I want to have this gdb binary available when we build the virtual kernel so that our customer don't have to build gdb-cross-aarch64 by themselves. They just be able to find the binary and mentioned place when kernel is built13:42
Noornow how to add gdb-cross-aarch64 -> addto_recipe_sysroot dependency with virtual kernel so that when kernel is built binary is available for the customer13:46
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)13:49
*** Guest2 <Guest2!~Guest18@> has joined #yocto13:53
*** Xagen <Xagen!> has joined #yocto13:53
*** mvlad <mvlad!~mvlad@2a02:2f05:850d:7800:29e:fcb2:97cb:4cd> has joined #yocto13:54
*** gvmeson is now known as vmeson13:57
*** joekale <joekale!~quassel@2620:a2:6000:13:1e0c:bf92:4ed7:9223> has joined #yocto13:58
*** Guest2 <Guest2!~Guest18@> has quit IRC (Quit: Client closed)13:58
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)13:59
rburtonthat's just a [depends]14:04
*** rsalveti <rsalveti!> has joined #yocto14:10
*** Chach_Deenu <Chach_Deenu!~Noor@> has joined #yocto14:18
*** rfuentess <rfuentess!> has joined #yocto14:19
*** Noor <Noor!~Noor@> has quit IRC (Quit: Client closed)14:19
*** Noor <Noor!~Noor@> has joined #yocto14:23
Noorrburton: but in that case we will not have gdb binary available to the customer or I am  missing something14:25
rburtonNoor: you're not explaining what the customer builds or is given14:27
rburtonNoor: if the customer builds the kernel and you have a dependency on gdb-cross in the kernel then they'll also build gdb-cross14:27
*** Michael_Guest <Michael_Guest!> has joined #yocto14:28
*** Michael_Guest <Michael_Guest!> has quit IRC (Client Quit)14:28
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)14:30
Noorrburton: We our customer has our BSP. So we want to provide them a faciltiy to debug the kernel. We don't want him to do it via SDK. So when he build a BSP we want to provide a working binary of gdb-cross so that he can debug kernel. we also want if customer remove the tmp folder and build is executed from sstate use still be able to get the14:32
Noorgdb-cross bianry.14:32
rburtonNoor: as i said, use addto_recipe_sysroot and it doesn't matter if sstate is used or not.14:33
rburtonif you want to provide tools that work without a tmpdir then that's called a SDK14:33
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto14:36
Noorah now I get it. You mean something like do_compile[depends] += "gdb-cross-aarch64:do_addto_recipe_sysroot" in kernel recipe14:45
rburtondo_build[depends] but yeah14:48
Noorone last questions :). is there a way to use override in do_build[depends] syntax. So that this is only effective when this override is there14:56
*** belsirk <belsirk!> has joined #yocto14:56
*** rfuentess <rfuentess!> has quit IRC (Ping timeout: 240 seconds)14:59
*** Xagen <Xagen!> has joined #yocto15:04
*** roussinm <roussinm!~mroussin@> has joined #yocto15:07
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)15:12
alperaklets say, need to add a recipe( to meta-oe but there is a meta-foo only for this recipe( and this layer is depends on meta-oe. what should i do in this case? should i use RCONFLICTS or PROVIDES?15:13
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)15:13
*** Saur75 <Saur75!~Saur75@> has joined #yocto15:14
*** vladest <vladest!~Thunderbi@> has quit IRC (Quit: vladest)15:21
roussinmMy recipe depends on `tbb`, but `tbb` isn't installed in my image. From my current knowledge of yocto, if my recipe DEPENDS on a recipe, most of the time, it should be found in the resulting image. Anyone depending on `tbb` having to do something special?15:22
rburtonroussinm: that's not true though15:24
rburtonDEPENDS is *only* about what is in the sysroot at build time15:24
roussinmI think the current version that my recipe doesn't link on tbb yet, but futur version will, but the TBB dependency is already present. It is because my current recipe doesn't link on it bitbake doesn't bother adding the RDEPEND on it?15:26
rburtonwhat does happen is that recipe foo will DEPEND on libbar, and then produce a binary foo that links to Bitbake knows that is provided by libbar and add RDEPENDS for you.  This is why you don't need to specify RDEPENDS=libc for every recipe, but also why no recipes pull in gcc into the target (which would be the case is DEPENDS=RDEPENDS)15:26
roussinmIf that binary doesn't link on it, bitbake will omit that RDEPENDS, correct?15:27
rburtonif there's no linkage theres nothing to add, right15:28
rburtonit literally finds binaries in the packages, identifies what they link to, and adds RDEPENDS as needed15:28
rburtonso your C helloworld will automatically depend on libc15:28
roussinmOk, ya it all make sense now. thanks!15:29
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)15:30
*** sakoman <sakoman!> has joined #yocto15:32
*** sev99 <sev99!> has joined #yocto15:36
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds)15:52
*** vladest <vladest!> has joined #yocto15:53
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto15:53
*** belsirk <belsirk!> has quit IRC (Remote host closed the connection)16:11
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)16:12
*** Saur75 <Saur75!~Saur75@> has joined #yocto16:13
*** luc4 <luc4!~luca@2a00:6d43:501:1201:9997:c7c8:aabe:c87a> has quit IRC (Ping timeout: 260 seconds)16:13
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto16:16
qschulzcan someone tell me the purpose of the stable/<release>-nut branches for meta-openembedded ?16:21
qschulzit's way behind <release> and <release>-next branches, so wondering what they are for16:21
rburton-nut is next-under-test, so they're just staging branches that the maintainer was using16:22
rburtonignore them :)16:22
qschulzthanks :) (the stable prefix is very misleading though ;) )16:23
*** Noor <Noor!~Noor@> has quit IRC (Ping timeout: 250 seconds)16:28
*** jmd <jmd!~user@2001:a61:2aa0:ea01:fcec:2373:8649:cf16> has joined #yocto16:29
*** Chach_Deenu <Chach_Deenu!~Noor@> has quit IRC (Quit: Leaving)16:32
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)16:37
*** Saur75 <Saur75!~Saur75@> has joined #yocto16:38
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:41
moto-timoqschulz: would stable-next make more sense somehow?16:43
moto-timonaming is hard16:44
rburtonblame sgw16:44
rburtonhe called his staging branches mut from master-under-test16:44
rburtonthat turned into next-under-test for some for the branches that are not even next16:45
khemRP: seeing `| chown: cannot access '/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/systemd/255.4/image/var/log/journal': No such file or directory`16:54
khemI wonder if its related to version bump staged in master-next16:55
*** mckoan is now known as mckoan|away17:00
qschulzmoto-timo: what's wrong with <release>-next?17:00
moto-timoqschulz: well, -nut implies more (it is now a release candidate)17:01
moto-timo<release>-next just means it is a candidate to getting merged into the branch, but not a TAG17:01
qschulzmoto-timo: not getting it sorry, can you try rephrasing?17:04
moto-timoqschulz: I was trying to figure out if a different naming of the branch would have not confused you.17:07
moto-timoqschulz: we're now beating a dead horse I think ;)17:07
qschulzdidn't get the "-nut implies more (it is now a release candidate)" part :)17:08
qschulzmoto-timo: i know which branch i should be using now, but i don't know why :)17:08
moto-timoqschulz: -nut is only used when that build is being targeted as a release candidate. One that will be released and tagged as a release.17:09
RPkhem: I haven't seen that issue :/17:09
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)17:11
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)17:17
vvnoe-init-build-env is meant to be idempotent, correct?17:18
rburtoni think there was a bug in older releases where it wasn't quite17:18
qschulzmoto-timo: why is stable/kirkstone-nut last commit 4 months ago then?17:24
rburtonqschulz: point at the policy that says that branch will 1) exist 2) be continually updated17:26
rburtonpersonally i'd always push next and testing branches to the contrib repo, but i'm not a meta-oe maintainer so that's moot17:26
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto17:29
qschulzmoto-timo: a mistkae it is then, fine with this explanation :) thx17:34
*** zpfvo <zpfvo!> has quit IRC (Read error: Connection reset by peer)17:34
qschulzmoto-timo: jus tto be sure: stable/<release>-nut (-rc0, -rc1, etc... basically) until <release> is released, then commits to <release>-next first and merged into <release> every now and then17:35
moto-timoqschulz: probably better answered by sakoman, armpit or khem17:36
moto-timoI am also not a stable release maintainer17:36
moto-timoand for layers like meta-java, I do not personally use -nut nor do I tag releases.17:37
moto-timothat would imply things in that layer work17:37
moto-timo"patches welcome"17:37
rburtonqschulz: i'd ignore those branches, they're just staging branches used by the maintainer.  the contents might be stale, or broken, or anything else.17:37
rburtonif you actually watch oe-core master-next you'll see all sort of things pop in and out17:38
sakomanqschulz: more like 3 hours ago :-)
sakomanI use stable/xxx-nut for initial patch testing, patches will come and go in this branch, so you shouldn't use it for anything other than to check whether a new patch on the list has entered testing17:40
sakomanafter I have a patch set that passes testing, I will send a review request to the mailing list, and move the patchset to stable/xxx-next17:41
sakomanIf there are no comments I will pull the patches from stable/xxx-next into xxx17:42
*** DvorkinDmitry <DvorkinDmitry!> has joined #yocto17:46
DvorkinDmitryryzen 7700 vs 7900 - how big difference will I have with the same SSD/mem at OE/Yocto build speed?17:47
rburtonif you have the clout, ask your hardware provider for test machines17:52
rburtonbest way to answer that question17:53
qschulzsakoman: so -nut branches are personal playground, got it. -next may be rebased, <release> is the real deal17:54
*** florian <florian!> has quit IRC (Quit: Ex-Chat)18:13
khemRP: and the patch it in now sadly, I would suggest to revert it18:26
khemda9db878a15 systemd: fix dead link /var/log/README18:26
khemRP: this happens when VOLATILE_LOG_DIR = "no" is set18:32
khemI think poky defaults are different perhaps ?18:32
*** sev99 <sev99!> has quit IRC (Quit: Client closed)18:33
DvorkinDmitryrburton, I haven't ofcause. the question is how big improvement will be if I'll have 16 cores on 7700 or 24 cores on 7900 ?18:36
DvorkinDmitryis the RAM speed/size and SSD speed mre significant? Now I'm running my builds on 24GB RAM, 12 cores and RAID of two old hdds... And I feel it is very slow. The complete build takes about 12 hours.18:38
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)18:39
DvorkinDmitryI'm buying the new machine for my builds, SSD instead of HDD, RAM 64GB ddr5 instead of 24GB DDR3, ryzen 7700 (or 7900) instead of core i7 (12 threads)18:40
*** Saur75 <Saur75!~Saur75@> has joined #yocto18:40
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)18:42
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto18:44
DvorkinDmitryso I'm thinking if the CPU will be the bottleneck in my config? Do I have to buy 7900?18:58
gmorellDvorkinDmitry: the 7900 won't hurt, but I think the ssd/ram will definitely be far more significant for builds19:00
DvorkinDmitrygmorell, ok! If i'm building my current image in 12 hours, how fast do you think I'll build it with new config on 7700 or in 7900 ?19:03
DvorkinDmitryThe price for 7900 is 1.5 bigger then 7700 for me.19:04
*** florian_kc <florian_kc!> has joined #yocto19:04
gmorellI can't tell you about time, too many variables19:05
gmorellmy personal philosophy is to max these out because you'll likely be running these for years on end19:05
DvorkinDmitrygmorell, hdd will be 10 times faster. RAM * 2.5 and 2 times faster. bogomis for 7700 is *3, for 7900 is *4.19:06
DvorkinDmitryso I'm thinking is cpu *3 or *4 will give the same performance improvement, or it will be less significant ?19:07
gmorellthey're within spitting distance19:10
gmorellyou have 50% more cores, but at a lower clock because of cooling factors19:10
khemRP: sent a patch to fix systemd fallout19:10
XogiumDvorkinDmitry: by the way, bogomips are worthless and don't reflect the actual performance of a machine19:12
Xogiumjust saying19:12
gmorellthis too19:12
gmorelli wonder if anyone has benched yocto with x3d units vs non x3d units19:14
gmorellif the extra pile of L3 actaully helps at all19:14
Xogiumtbh I personally stick to amd these days, because it feels like intel sucks more and more19:14
Xogiumand not just in terms ot tdp ;)19:15
Xogium*of tdp, rather19:15
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 264 seconds)19:23
*** frieder <frieder!> has quit IRC (Remote host closed the connection)19:34
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)19:39
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 255 seconds)19:42
*** ptsneves <ptsneves!> has joined #yocto19:46
*** Saur75 <Saur75!~Saur75@> has quit IRC (Quit: Client closed)20:13
*** Saur75 <Saur75!~Saur75@> has joined #yocto20:14
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 255 seconds)20:17
khemso latest patch bomb has broken recipes builds in meta-openembedded -
khemand thats just one arch.20:20
*** sakoman <sakoman!> has quit IRC (Ping timeout: 268 seconds)20:21
khemI wish there were people fixing things beyond core and yocto AB20:22
khemhere is error -
*** paulg <paulg!> has quit IRC (Read error: Connection reset by peer)20:35
*** sakoman <sakoman!> has joined #yocto20:36
khemlibxml2 has an incompatible API change between 2.11 and 2.12 someone should notice such things this late in release20:38
*** kpo <kpo!> has joined #yocto20:46
*** ptsneves <ptsneves!> has joined #yocto20:50
LetoThe2ndzeddii: yo - in terms of trying the simplest k3s-on-yocto build, should core-image-minimal+packagegroup-k3s-host+packagegroup-k3s-node do the trick? then running som magic from
*** prabhakalad <prabhakalad!~prabhakar@> has quit IRC (Ping timeout: 264 seconds)20:56
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto20:57
*** paulg <paulg!> has joined #yocto20:57
*** vladest <vladest!> has quit IRC (Remote host closed the connection)21:01
*** prabhakalad <prabhakalad!~prabhakar@> has quit IRC (Ping timeout: 246 seconds)21:01
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto21:02
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 255 seconds)21:05
LetoThe2ndzeddii: the suggested incantation "k3s agent -t /var/lib/rancher/k3s/server/token --server http://localhost:6443/" errs out because of not https, and changing to "k3s agent -t /var/lib/rancher/k3s/server/token --server https://localhost:6443/" complains "failed to get CA certs: Get "": read tcp> read: connection reset by peer"21:05
*** joekale_ <joekale_!~quassel@> has joined #yocto21:06
*** joekale <joekale!~quassel@2620:a2:6000:13:1e0c:bf92:4ed7:9223> has quit IRC (Ping timeout: 268 seconds)21:06
*** joekale <joekale!~quassel@2620:a2:6000:13:f517:32f3:2b68:ad91> has joined #yocto21:32
*** joekale_ <joekale_!~quassel@> has quit IRC (Ping timeout: 260 seconds)21:32
*** florian <florian!> has joined #yocto21:48
*** alessioigor_ <alessioigor_!> has joined #yocto21:49
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Ping timeout: 268 seconds)21:49
*** alessioigor_ is now known as alessioigor21:49
*** mvlad <mvlad!~mvlad@2a02:2f05:850d:7800:29e:fcb2:97cb:4cd> has quit IRC (Remote host closed the connection)21:54
DvorkinDmitrygmorell, Xogium, thank you!21:59
*** DvorkinDmitry <DvorkinDmitry!> has quit IRC (Quit: KVIrc 5.0.0 Aria
*** prabhakalad <prabhakalad!~prabhakar@> has quit IRC (Ping timeout: 255 seconds)22:05
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto22:06
*** alessioigor <alessioigor!> has quit IRC (Quit: alessioigor)22:08
zeddiiLetoThe2nd: are you on master-next of meta-virt ? I'm still working through testing of the recent changes.22:10
*** prabhakalad <prabhakalad!~prabhakar@> has quit IRC (Ping timeout: 255 seconds)22:12
*** prabhakalad <prabhakalad!~prabhakar@> has joined #yocto22:12
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)22:22
*** joekale <joekale!~quassel@2620:a2:6000:13:f517:32f3:2b68:ad91> has quit IRC (Ping timeout: 268 seconds)22:34
RPStill a few too many issues with master for M3 build, trying again22:34
RPkhem: thanks, I'll try and get that in22:44
RPzeddii: - meta-virt needs to update LAYERSERIES_COMPAT_virtualization-layer = "nanbield"22:45
RPmeta-intel and meta-aws too22:45
* RP notes that swat isn't doing the work so does it himself to send the reminders22:51
*** Xagen <Xagen!> has joined #yocto23:03
*** Xagen <Xagen!> has quit IRC (Client Quit)23:06
sakomanzeddii: your patch seems to have fixed the parted ptest issues, but now {'util-linux': ['fdisk:_gpt-resize']} ptest is failing :-(23:07
zeddiiI'm out of time trying to update the old kernel. I'll pick it up in a few weeks again.23:07
sakomanzeddi: should I revert that linux-yocto 5.15 version bump series then?23:08
sakomanI really screwed up in merging them :-(23:08
zeddiitrying the ubuntu patch might be another option, but it needs to have it's context fixed for our tree versus theirs.23:09
*** Xagen <Xagen!> has joined #yocto23:09
zeddiisakoman: that's probably your only option (revert), I have to turn my attention back to meta-virt and some internal things that are due very shortly.23:09
sakomanzeddi: OK, will do23:10
*** |Xagen <|Xagen!> has joined #yocto23:10
zeddiithe wind river guys are still using 5.15, so asking them what they are doing for this might also be useful.23:10
zeddiiKexin is sanity testing the -stable updates for their SDK based BSPs, so presumably they are keeping up to date with the tip of my tree and might not even know they have this problem.23:11
*** Xagen <Xagen!> has quit IRC (Ping timeout: 272 seconds)23:14
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Quit: Bye)23:14
*** kpo <kpo!> has quit IRC (Ping timeout: 255 seconds)23:32
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto23:42
RPhmm, another weird failure:
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!