Monday, 2021-11-01

*** dvorkindmitry <dvorkindmitry!~dv@> has quit IRC (Quit: KVIrc 5.0.0 Aria
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)00:02
*** otavio <otavio!> has joined #yocto00:03
*** rsalveti <rsalveti!> has joined #yocto00:04
*** tantrum_ <tantrum_!> has joined #yocto00:33
*** tantrum <tantrum!> has quit IRC (Ping timeout: 260 seconds)00:36
*** tantrum_ is now known as tantrum00:36
*** florian__ <florian__!> has quit IRC (Ping timeout: 264 seconds)00:58
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)01:10
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:48
*** camus <camus!~Instantbi@> has joined #yocto01:51
*** camus1 <camus1!~Instantbi@> has joined #yocto02:24
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)02:26
*** camus1 is now known as camus02:26
*** camus1 <camus1!~Instantbi@> has joined #yocto05:02
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 264 seconds)05:03
*** camus1 is now known as camus05:03
*** yocti <yocti!> has joined #yocto05:54
*** Fanfwe <Fanfwe!> has joined #yocto05:54
*** jonmason <jonmason!> has joined #yocto05:55
*** ndec <ndec!> has joined #yocto05:55
*** georgem <georgem!> has joined #yocto05:55
*** ChanServ sets mode: +v ndec05:55
*** wyre <wyre!~wyre@user/wyre> has joined #yocto05:55
*** tantrum <tantrum!> has quit IRC (Ping timeout: 264 seconds)06:02
*** glembo[m] <glembo[m]!~glembomat@2001:470:69fc:105::174> has quit IRC (*.net *.split)06:02
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (*.net *.split)06:02
*** perdmann_ <perdmann_!> has quit IRC (*.net *.split)06:02
*** MWelchUK <MWelchUK!~MWelchUK@> has quit IRC (*.net *.split)06:02
*** ak77 <ak77!> has quit IRC (*.net *.split)06:02
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has quit IRC (*.net *.split)06:02
*** kergoth <kergoth!~kergoth@> has quit IRC (*.net *.split)06:02
*** perdmann <perdmann!> has joined #yocto06:02
*** mrnuke <mrnuke!> has joined #yocto06:03
*** ak77 <ak77!> has joined #yocto06:03
*** MWelchUK <MWelchUK!> has joined #yocto06:03
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto06:11
*** glembo[m] <glembo[m]!~glembomat@2001:470:69fc:105::174> has joined #yocto06:11
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)06:15
*** camus <camus!~Instantbi@> has joined #yocto06:15
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 245 seconds)06:30
*** camus1 <camus1!~Instantbi@> has joined #yocto06:53
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)06:54
*** camus1 is now known as camus06:54
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)07:01
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:06
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:07
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)07:30
*** camus <camus!~Instantbi@> has joined #yocto07:31
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:49
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto07:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:51
*** vermaete <vermaete!> has joined #yocto07:54
*** amitk <amitk!~amit@> has joined #yocto08:04
*** bps2 <bps2!> has joined #yocto08:10
*** tnovotny <tnovotny!> has joined #yocto08:13
*** bps2 <bps2!> has quit IRC (Ping timeout: 260 seconds)08:14
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving)08:37
dwagenkIs the layerindex webUI broken right now? The dropdown menu for branch selection doesn't work, it doesn't search for anything when typing... Only thing that works as normal: pressing <Enter> clears the search box.08:48
dwagenkAlready tried both firefox and chromium. Both without changes in teh configuration compared to last time (~2 Weeks ago)08:48
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)08:54
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:55
*** vermaete <vermaete!> has quit IRC (Quit: Client closed)08:55
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)08:59
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:59
dwagenksearching on othe tabs (recipes, machines, ..) works OK. it is just the layer search and the dropdown menus that are not working.09:00
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)09:24
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:24
*** bps2 <bps2!> has joined #yocto09:25
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)09:28
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:29
*** xmn <xmn!> has joined #yocto09:41
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)09:45
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:45
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)09:54
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:55
*** mihai <mihai!~mihai@user/mihai> has joined #yocto09:56
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)10:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:01
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)10:09
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:10
*** camus1 <camus1!~Instantbi@> has joined #yocto10:10
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)10:12
*** camus1 is now known as camus10:12
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)10:14
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:15
*** vicale <vicale!> has quit IRC (Quit: Leaving)10:15
*** florian__ <florian__!> has joined #yocto10:18
wCPOI'm having trouble building groff-native (hardknott) as it can't find automake-1.16: "groff-native/1.22.4-r1/groff-1.22.4/build-aux/missing: line 81: automake-1.16: command not found", has anyone experienced this before?10:19
hmw[m]hi im getting: Failed to load module: /usr/lib/weston/ cannot open shared object file: No such file or directory10:23
hmw[m]btw im on dunfell10:23
manuel1985hmw[m]: Do you have the package 'weston' installed?10:27
hmw[m]manuel1985: yes10:28
hmw[m]( it is from /usr/bin/weston.log10:28
hmw[m]opkg list weston10:29
hmw[m]weston - 8.0.0-r0.arago310:29
manuel1985hmw[m]: No idea. oe-pkgdata-util tells me this file is part of package 'weston', and it indeed is installed on my machine.10:30
manuel1985I'm on Dunfell as well with weston 8.0.0-r0.10:31
hmw[m]rebuild it is then :(10:31
hmw[m]manuel1985: ty10:33
manuel1985hmw[m]: Just checked the recipe, there seems to be a packageconfig option for shell-desktop10:33
manuel1985Oh but if your weston log is throwing that error, that packageconfig option is probably already set to use shell-desktop10:34
manuel1985Otherwise it wouldn't start looking for it10:34
manuel1985Ok got no idea, sry. If you find out the reason, I'd be interested to learn. Best of luck.10:35
marexhmw[m]: well is the in tmp/work* ?10:42
marexhmw[m]: find tmp/work -name desktop-shell.so10:43
marexit should be somewhere in packages-split/10:43
marexhmw[m]: if it is, then make sure that package is installed in your image , is it ?10:43
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:49
hmw[m]marex:  shall check in a bit ( did a reset of my build system ) will take until ~13:00 the rebuild. thanks for info btw10:51
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto10:52
marexhmw[m]: there is some oddity in dunfell since a few days ago that the notifications from weston to systemd do not work10:53
marexso in case your weston instance magically gets killed after a few seconds, you might be hitting that10:53
hmw[m]the weston service is up for 22 min atm ( did not format the running system)10:54
marexrevert 4efdcc10906945765aa28324ce1badc59cda2976 in oe-core if you run into this10:54
*** florian_kc <florian_kc!> has joined #yocto10:55
*** florian__ <florian__!> has quit IRC (Ping timeout: 268 seconds)10:58
RPkanavin_: please don't trigger anything as I need to restart the controller when the current build finishes11:06
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)11:17
*** otavio <otavio!> has quit IRC (Remote host closed the connection)11:19
kanavin_RP: sure, I was just about to :)11:24
kanavin_RP: why am I not surprised, newly released xserver-xorg in qemu: [    29.108] (EE) Caught signal 11 (Segmentation fault). Server aborting11:27
kanavin_they also forgot to put important files into the tarball, the 'obsolete' autotools build doesn't mind, but the shiny new meson build does11:27
kanavin_RP: I'll take it out, it fails this way on arm/mips but not x8611:30
kanavin_simply not well tested it seems11:30
*** florian_kc <florian_kc!> has joined #yocto11:30
agherzanHi. I'm a bit confused about how the psplash alternative symlink is supposed to work. We define the priority (not package override) as 100 So a new psplash package (set with FEATURE_PACKAGES) to psplash-foo will end up having the alternative configuration for priority 100. Now, the main package, also pulls in as a RECOMMENDS psplash-default which11:32
agherzancomes with the same 100 priority for the symlink. All this means that the build will always warn about a `Warn: update-alternatives: psplash has multiple providers with the same priority` because both psplash-foo and psplash-default come with alternative configuration for the psplash symlink set with priority 100. For me, the `RRECOMMENDS_psplash=" psplash-default"` sounds fishy.11:32
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto11:34
agherzanMy usecase is simple: I want to provide a new psplash package without messing with any of the defaults (so people can easily switch based on SPLASH/FEATURE_PACKAGES).11:34
agherzanI know this was the entire idea of the way we set this initially but it sounds like that RRECOMMENDS just forces a default that doesn't sound right.11:35
*** otavio <otavio!> has joined #yocto11:35
agherzanNow, in image.bbclass we define the default to `splash`. And I think this is the actual root of the issue. Because by doing so, RRECOMMENDS is used to pull in the actual binary. Shouldn't it be the other way around? Remove the RRECOMMENDS and set the image.bbaclass default to11:36
agherzanSPLASH ?= "psplash-default"11:36
agherzanFEATURE_PACKAGES_splash = "${SPLASH}"11:36
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::e120> has joined #yocto11:39
RPkanavin_: I suspect it is new people doing the release and they just don't have the experience :/11:40
kanavin_RP: basically one hobbyist-looking guy from Lithuania11:41
kanavin_red hat has no interest anymore11:41
RPkanavin_: it is kind of sad11:43
RPkanavin_: FWIW the autobuilder should have faster build "startup" time now. I just want to get to the bottom of some scheduler bugs in buildbot (upstream are asking me to test a fix)11:43
kanavin_RP: I was wondering what goes on in that 15 minute startups, thanks11:44
RPkanavin_: NFS issues is the answer ;-)11:45
rburtoncouldnt believe rsync was that much slower than tar11:46
kanavin_RP: I also wanted to ask this: do we really need to run those heavy toolchain tests in every a-full? If people look at them separately, maybe they should be moved to nightlies?11:46
RPkanavin_: maybe use a-quick? :)11:47
RPrburton: its the number of files. File creation overhead on NFS is the bottlebeck11:48
RPI threw zstd in since it is there and helped11:48
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)11:52
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:52
*** florian__ <florian__!> has joined #yocto12:02
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)12:06
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)12:08
rburtonRP: hm docs say that you cannot set SDKMACHINE in a distro configuration. I can't see why that would not work.12:16
RPrburton: include conf/machine-sdk/${SDKMACHINE}.conf12:17
RPinclude conf/distro/${DISTRO}.conf12:17
rburtonoh right12:17
rburtonwhy not swap that ;)12:17
RPrburton: distros are allowed to override machine config12:18
RPit is consistency12:18
*** xmn <xmn!> has quit IRC (Ping timeout: 268 seconds)12:18
*** chep <chep!~chep@> has joined #yocto12:19
hmw[m]<marex> "it should be somewhere in..." <- marex:  the find on did not return ( on dunfell HEAD ) going to reverte to12:27
RPkanavin_: ready for builds now12:28
*** frosteyes <frosteyes!~frosteyes@> has joined #yocto12:31
*** florian_kc <florian_kc!> has joined #yocto12:33
*** florian__ <florian__!> has quit IRC (Read error: Connection reset by peer)12:34
*** florian__ <florian__!~florian@> has joined #yocto12:35
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)12:39
*** frosteyes <frosteyes!~frosteyes@> has quit IRC (Quit: WeeChat 2.8)12:43
*** frosteyes <frosteyes!~frosteyes@> has joined #yocto12:45
frosteyeshi folks. A quick question. I have created a SDK, where I want to compile kernel modules out-of-tree. So have added kernel-devsrc12:47
frosteyesNext I am trying to run make -C /usr/local/oecore-x86_64/sysroots/corei7-64-poky-linux/usr/src/kernel prepare scripts12:47
frosteyesBut the problem is that it fails the prepare with objtool. (no rule to make target .... objtool/fixdep.o)12:48
frosteyesIs using dunfell branch..12:48
frosteyesI guess it might be an issue with how I use the kernel-devsrc part.12:48
zeddiifrosteyes: What's your kernel version ? objtool is covered under devsrc, everything needed to rebuild it is packaged.12:51
zeddiibut I can't say that I've tested with the SDK.12:52
zeddiiif there are a set of configs and reproducing steps, I could always try it locally to see what's up.12:52
frosteyesThanks zeddii - the kernel is a custom 4.19.13012:54
zeddiiaha. yes, there could be parts missing for that kernel version. kernel-devsrc is curated to pick up just what we need, so I end up tweaking it through the versions.12:55
*** jatedev <jatedev!~jatedev@> has quit IRC (Ping timeout: 256 seconds)12:57
frosteyeszeddii: to you know if 5.4 is working better?12:57
zeddiiwith the SDK  .. I can't say for sure. But any of those versions, we have a nightly test that builds out of tree modules, so we know that it works for any given release, with the kernel versions we've tested as the references12:58
zeddiiit is tested on target for those out of tree tests, but I do know it works in the eSDK. I just don't use the SDK.12:59
frosteyesWill look into the eSDK, and also the other kernel..12:59
frosteyes5.4 seems to be the normal "dunfell" kernel..13:00
zeddiidunfell was v5.2 and 5.4 at the time of release, so I know they were tested heavily13:00
zeddiiright, and we deleted 5.2 after, so you'll only see 5.4 now in the dunfell branches13:00
zeddiiI can try a dunfell SDK test, with all the stock bits.13:01
zeddiiI just have to look up the incantation :D13:01
frosteyesThat would be great :) I have a task for upgrading kernel also. So will properly look into it - before my "getting SDK to work with out-of-tree modules"13:02
kanavin_RP: something broke
*** troth <troth!> has joined #yocto13:13
marexRP: I have this question ... say I have a BSP layer for a board and I want to bbappend a recipe which is built for class-native, but only for specific machine so that the BSP layer won't have side effects on other layers, is that possible ?13:19
marexFOO:append:class-native:my-machine = " extraflag" seems to not work13:20
marexobviously, because MACHINE isnt set in class-native and neither is MACHINEOVERRIDES13:20
*** GillesM <GillesM!> has joined #yocto13:22
*** kayterina <kayterina!> has joined #yocto13:22
*** GillesM <GillesM!> has quit IRC (Client Quit)13:22
smurraymarex: re weston startup, I did a test build of latest dunfell with INIT_MANAGER="systemd" last night, and weston seems to start and stay running in core-image-weston13:26
marexsmurray: on oe-core/dunfell too ?13:31
marexthe dunfell part is important there13:31
smurraymarex: I tested poky dunfell with qemux86-6413:32
marexsmurray: did you have the notification stuff above in weston systemd service file ?13:33
smurraymarex: yes13:33
marexall right, in that case, I need to double-check why the notification isn't delivered here13:33
*** paulg <paulg!> has joined #yocto13:36
smurraymarex: are you using a BSP layer as well?  Some dork with weston startup, could see it breaking.  We don't use weston-start in AGL, but do have in our base weston.ini, so we're still okay (I think)13:44
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto13:46
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13:51
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)13:52
marexsmurray: that in modules should be unnecessary, see weston.log, it will complain it is loaded already13:52
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:52
smurraymarex: weston-start is adding it via the command-line, I figure that would be the cause of that?13:54
*** scott_ <scott_!> has joined #yocto13:54
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)13:55
smurraymarex: not a problem in our AGL images, I think, but I'll keep an eye out for the message when we upgrade to 3.1.1313:56
*** sakoman <sakoman!> has joined #yocto13:56
hmw[m]marex: 4efdcc10906945765aa28324ce1badc59cda2976 also is not producing desktop-shell.so14:00
hmw[m]i also have added PACKAGECONFIG = "shell-desktop" to a new weston_%.bbappend14:00
marexhmw[m]: PACKAGECONFIG:append:yourmachine = " shell-desktop"14:01
marexhmw[m]: you can verify if it is picked up using bitbake -e weston | grep ^PACKAGECONFIG14:01
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)14:03
*** camus <camus!~Instantbi@> has joined #yocto14:03
hmw[m]it is was not in the package config. is the : new ?14:03
marexhmw[m]: it is new syntax which replaces the old _ one14:05
marexsince honister14:05
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)14:12
*** otavio <otavio!> has joined #yocto14:14
sveinseHow can I setup a build server site wide hash equivalent server? Download any fairly new poky, setup an arbitrary local.conf pointing to the site-wide sstate and run bitbake-hashserv with a global port?14:14
RPkanavin_: ah. My fault :(14:14
sveinseIs there a correspondance between the MACHINE running the bitbake-hashserv against the systems that is going to use the hash equivalence server?14:15
sveinseThis is going to be used for ordinary image builds. I don't have any autobuilder setup14:16
RPkanavin_: workaround pushed until I can figure out something better14:16
RPmarex: natives are only built once for all machines so what you're asking for isn't possible14:17
RPsveinse: you don't need metadata, just a copy of bitbake14:18
RPkanavin_: I restarted it for you14:21
sveinseWon't the bitbake-hashserve need access to the sstate cache? Or is that completely separate? E.g. handled by bitbake itself?14:23
rburtonis anyone else looking at upgrading python3-cryptography? (cc moto_timo[m])14:29
moto-timorburton: pyo3 is not behaving well in cross-compile. Frustrating mess.14:31
rburtonwe have a dependency on py-crypto for a firmware build, which breaks with openssl3 as py-cry doesn't support it14:32
marexRP: I guess I could use DISTROOVERRIDES for that ?14:32
marexRP: or is that awful ?14:32
marexRP: I am trying to avoid side-effects of the layer14:32
kanavin_RP: thanks :)14:33
hmw[m]marex:  tnx  it it working now :D14:34
marexoh :)14:34
marexhmw[m]: so it was the missing append ?14:34
smurraymarex: depending on what the -native bit is, don't you risk rebuilding piles of stuff?14:34
hmw[m]marex: yes14:34
RPmarex: layers really shouldn't hack natives to be machine specific, ever14:35
sveinseI've noticed that it's a bit variable if python3-* recipes have BBCLASSEXTEND = "native nativesdk" or not. Some doesn't have any, some only native, a few have all14:36
rburtonpatches welcome if you've tested the build14:36
RPsveinse: in most cases we've likely just never needed those variants and they do have a cost14:37
sveinseI see. I have a few python3-*.bbappends in my layers because of it14:39
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:8a17:65be:d8b6:bd8c> has joined #yocto14:41
rburtonsveinse: just post the patches, they're trivial if you've tested them14:42
*** kayterina <kayterina!> has quit IRC (Remote host closed the connection)14:44
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)14:45
*** camus <camus!~Instantbi@> has joined #yocto14:45
rburtonmoto-timo: do you have any WIP? like a setuptools-rust recipe already?14:46
moto-timorburton: older version, simpler (no real rust)
marexsmurray: luckily no, I am only doing this to fill PARALLEL_MAKE back into one crappy tool from crappy poorly maintained layer14:57
marexsmurray: else it builds for effing ever14:58
smurraymarex: maybe a bbappends that's dynamically applied would be enough?15:02
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)15:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:05
marexsmurray: doesnt that blow up on yocto-check-layer or oelint-adv ?15:10
smurraymarex: it likely would for y-c-l if you include the layer, yes15:11
smurraymarex: but it's simpler than perhaps something with BBMASK set via anon python, which might be another route15:12
smurraymarex: using BBFILES_DYNAMIC was what I was thinking of15:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)15:19
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:19
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)15:24
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:25
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)15:31
*** otavio <otavio!> has joined #yocto15:32
marexsmurray: I am not entirely sure if that doesn;t trigger y-c-l either15:37
marexsmurray: thanks anyway15:38
smurraymarex: the BBFILES_DYNAMIC?  I believe it won't until you include the layer that triggers it (unless you put some other mechanism on top)15:38
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:39
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Client Quit)15:40
smurraymarex: the only other option that comes to mind is tying to a distro feature or other variable like meta-virt does to gate it's modifications and pass y-c-l15:41
smurraymarex: that's used in AGL in places to get y-c-l compliance15:42
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)15:43
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:44
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)15:48
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:48
*** bps2 <bps2!> has quit IRC (Ping timeout: 268 seconds)15:52
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)15:54
*** otavio <otavio!> has joined #yocto15:55
sveinserburton: yocto use mail patches? No scheme for PR?15:59
sveinseHow is copyright managed in yocto? Waived to commit?16:01
rburtonbasically, kernel-style DCO16:02
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)16:02
*** otavio <otavio!> has joined #yocto16:04
*** curious457 <curious457!~curious45@2607:fad8:4:6:d6dc:1ad2:ccfe:7af7> has quit IRC (Quit: Client closed)16:08
*** Guest81 <Guest81!> has joined #yocto16:09
Guest81Can I force a 32 bit user space by setting MLPREFIX="lib32-"?16:11
sveinseCan BB_HASHSERVE and BB_SIGNATURE_HANDLER be specified in site.conf ?16:11
rburtonanything can be in site.conf16:11
rburtonits parsed just before auto.conf, which is just before local.conf16:12
tgamblinkhem: can you put "[oe] [PATCH][meta-python] python3-imgtool: add recipe" on master-next?16:25
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:25
sveinseWill a hash equivalence server help on build times beyond what the sstate cache provides?16:28
rburtonif say libfoo rebuilds with different inputs, but the output is identical, the hashequi will say its the same result16:29
rburtonso the output hash gets switched back, and other things might not rebuild16:29
rburtonbuild an image, make a trivial change to a core library which has no impact (like add a comment), and watch it decide that large chunks don't need to be rebuilt16:29
sveinseDo you need to prime it with an existing sstate setup? I just fired it up, but I build the full honister two days ago16:30
*** bps2 <bps2!> has joined #yocto16:30
rburtonbitbake will look in the existing sstate too, but the hash equiv helps future builds16:31
sveinseI.e. does it add anything wiping the sstate cache before using the hashserv?16:31
*** curious457 <curious457!~curious45@2607:fad8:4:6:9e37:92c4:687d:a8c7> has joined #yocto16:33
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)16:50
*** curious457 <curious457!~curious45@2607:fad8:4:6:9e37:92c4:687d:a8c7> has quit IRC (Quit: Client closed)16:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:53
*** zpfvo <zpfvo!~fvo@> has quit IRC (Client Quit)16:57
halsteaddwagenk: I've resolved the issue with the layerindex dropdowns etc. Let me know if you still notice problems after a reload.16:57
RPsveinse: the rebuild that triggers will prime the hash equivalence server16:58
*** Saur <Saur!> has joined #yocto17:10
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)17:10
*** otavio <otavio!> has joined #yocto17:12
*** bps2 <bps2!> has quit IRC (Ping timeout: 268 seconds)17:21
*** camus1 <camus1!~Instantbi@> has joined #yocto17:30
moto-timovmeson: any advice/examples for how to patch a crate without rust tooling? We need to patch pyo3 to search in ${STAGING_LIBDIR}/python-sysconfigdata
moto-timos/without/with our/17:32
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)17:32
*** camus1 is now known as camus17:32
*** dev1990 <dev1990!> has joined #yocto17:35
sveinseRP: yeah, thanks. Just wiped the sstate cache and started a complete rebuild of all build lanes. Will take 12 hours to complete :D Hopefully we get a good hashserv out of this17:37
*** vd <vd!> has joined #yocto17:38
vdDoes PCI 4.0 on a NVMe makes a difference compared to PCI 3.0 when compiling?17:39
*** Artzaik[m] <Artzaik[m]!~artzaikma@2001:470:69fc:105::1:2941> has joined #yocto17:40
*** xantoz <xantoz!> has quit IRC (Ping timeout: 260 seconds)17:51
*** xantoz <xantoz!> has joined #yocto17:52
rburtonno idea, but i doubt you'll be hitting the throughput limits17:52
JaMavd: depends on where you bottleneck is, using it on quad core laptop probably won't make much difference, on 128 core 3995wx the effect would be much more visible17:53
* JaMa has 6000s aorus gen4 2tb drive with 3970 and only 128g ram is bigger issue than io now17:56
vdinteresting! So with a modest 5950X CPU / 64Go RAM, PCI 3.0 or 4.0 for NVMe won't make any significant difference so better go with the PCI 3.0 I assume17:59
Saurrburton: Did you see my question about the licenses for libx11-compose-data on the OE-Core list the other day?17:59
JaMaif you already have it running with PCIE 3 drive, then I would watch avq in atop during the build18:01
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto18:02
vdJaMa don't have it yet, I'm about to order and NVMe PCI 3.0 vs 4.0 was my last step18:04
JaMafrosteyes submitted results with 5950x 128G ram and PCIE 4.0 Corsair SSD MP600 1TB, maybe he can share his experiences on his system18:05
sveinseOne of the few things not affected by this crazy electronics crisis?18:05
* JaMa bought his before crisis started and before Chia was announced :)18:06
*** vermaete <vermaete!> has joined #yocto18:10
vdJaMa: thoughts on QLC vs TLC nand for the NVMe?18:13
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto18:15
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)18:21
*** camus <camus!~Instantbi@> has joined #yocto18:21
sveinseHow well does hashserv enabled build interact with older non-hashserve builds? Both will fill the sstate cache, but only the enable builds will fill the hashserve db. Could that affect build performance? Or are older systems pre-hashserve so different from newer that they don't really share anything in sstate cache anyways?18:24
JPEWsveinse: There is probably not a lot that pre-hashserve builds would share anyway, so your assessment sounds correct (to me anyway)18:51
*** cryptollision[m] <cryptollision[m]!~cryptolli@2001:470:69fc:105::f778> has left #yocto18:58
*** florian__ <florian__!~florian@> has quit IRC (Ping timeout: 268 seconds)19:00
*** florian__ <florian__!> has joined #yocto19:12
*** Xagen <Xagen!~Xagen@2600:1700:211:7e60:d990:7e0d:b0a6:e609> has joined #yocto19:17
sveinsePerhaps the Yocto community could start their own taskhash blockchain XD :P19:20
*** florian__ <florian__!> has quit IRC (Ping timeout: 268 seconds)19:21
kanavin_autotools gone mad: kea:compile───run.do_compile.───make───make───bash───bash───make───bash───bash───make───bash───bash───make───bash───bash───make───x86_64-poky-lin───x86_64-poky-lin─┬─as19:23
sveinseautomake in each subdir I would guess19:24
kanavin_I don't mind what crazy shit they pull in there, but running just one compiler at a time, even though top level make runs with -j 16 is not ok.19:28
sveinseyeah, I think bash doesn't pass on the vars for make to utilize the job-server of the top make19:32
vdJaMa: nevermind, I get it for TLC/QLC and NVMe/SSD. Endurance is the key for normal use :)19:34
vmesonmoto-timo: do you have a branch of the meta-python repo that I could take a look at?19:36
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)19:36
moto-timovmeson: it fails in do_compile because of pyo319:38
vmesonmoto-timo: thanks...  time to reboot to pick up some updates, I'll take a look hopefully today.19:40
JaMaI remember oposite case in qt* long time ago when -j 64 from top level makefile was also used in 10+ make calls in subdirectories19:42
moto-timovmeson: the error is from because it doesn’t know about ${STAGING_LIBDIR}/python-sysconfigdata19:45
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto19:58
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)20:04
vdwhat should you prioritize on an NVMe, SSTATE_DIR or TMPDIR?20:22
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)20:33
*** otavio <otavio!> has joined #yocto20:35
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)20:37
*** camus <camus!~Instantbi@> has joined #yocto20:37
*** vermaete <vermaete!> has quit IRC (Quit: Client closed)20:42
*** mcfrisk_ is now known as mcfrisk20:44
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)20:48
JPEWvd: SSTATE_DIR is (mostly) pretty linear (write an archive, read an archive). TMPDIR actually does builds so I would imagine seeking is a lot more important.... at least that's my hunch. I run NVMe TMPDIR and a 1TB spinning disk sstate20:48
*** otavio <otavio!> has joined #yocto20:49
vdJPEW with the system on the NVMe as well or another disk?20:51
JPEWvd: OS is on the nvme, but I don't know how much that would matter20:53
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)20:54
JaMaI have OS on another nvme, because I expect the OE one to die much sooner and at least use separate partition where you're more comfortable with long sync interval (and nobarrier)20:54
JaMabut with 64G ram on 32 cores I don't expect that there will be a lot of memory left for disk cache (like on my 64cores with 128G)20:55
JaMaalso depends on what are your typical images, building qtwebengine/chromium/nodejs easily takes 2GB per c++ process20:56
vdJaMa: building qtwebengine images on 16-core / 64Go ram, I was worried about the NVMe endurance even though it sounds nicer for TMPDIR20:57
JaMaalso I use it as regular desktop during the builds, so chrome tabs get killed by OOMK first (and don't help much) then c++ gets killed and I need to restart the build20:58
JaMaare you going to disable smp?20:59
*** nad <nad!> has joined #yocto21:00
*** florian__ <florian__!> has joined #yocto21:00
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto21:01
JaMadoesn't 5950 have 16 cores, 32 threads? I was assuming you'll use -j 32 with it21:02
JaMamy gen4 nvme (used mostly for OE builds) is running for 11316 hours and still has 95% life left21:04
JaMabut it's true that last year I'm running significantly less builds here locally21:04
*** otavio <otavio!> has joined #yocto21:05
*** nad <nad!> has quit IRC (Quit: Client closed)21:05
*** nad <nad!> has joined #yocto21:06
JaMaand I wrote around 240TB to it in 2 years, while rootfs disk shows only 13TB in 3-4 yers21:07
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)21:10
JaMaI should check what smart says about server ssds, because here I don't usually use rm_work, so the builds stay valid relatively long, while on jenkins build server I'm using rm_work + delete TMDIR after jenkins job is finished, so with every job it needs to unpack a lot of sstate and a lot of writes to TMPDIR even when it gets removed shortly after (but maybe not quickly enough before it gets partially21:11
JaMawritten to disk)21:11
*** otavio <otavio!> has joined #yocto21:11
JaMathat's why on servers with more ram than cores I prefer to use tmpfs to keep ssds healthy for longer21:12
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)21:16
*** otavio <otavio!> has joined #yocto21:18
*** florian_kc <florian_kc!~florian@> has joined #yocto21:20
*** florian__ <florian__!> has quit IRC (Ping timeout: 268 seconds)21:24
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)21:26
*** otavio <otavio!> has joined #yocto21:28
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)21:33
*** otavio <otavio!> has joined #yocto21:34
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)21:40
*** nad <nad!> has quit IRC (Ping timeout: 256 seconds)21:41
*** otavio <otavio!> has joined #yocto21:41
*** camus1 <camus1!~Instantbi@> has joined #yocto21:44
*** yocton <yocton!~quassel@2001:bc8:3386::1> has joined #yocto21:45
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)21:45
*** camus1 is now known as camus21:45
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)21:46
*** GillesM <GillesM!> has joined #yocto21:51
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:8a17:65be:d8b6:bd8c> has quit IRC (Ping timeout: 268 seconds)21:57
*** otavio <otavio!> has joined #yocto21:58
*** bps2 <bps2!> has joined #yocto22:00
*** xmn <xmn!> has joined #yocto22:00
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)22:04
*** otavio <otavio!> has joined #yocto22:05
*** bps2 <bps2!> has quit IRC (Ping timeout: 260 seconds)22:05
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Ping timeout: 268 seconds)22:06
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)22:09
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)22:11
*** bps2 <bps2!> has joined #yocto22:12
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)22:12
*** otavio <otavio!> has joined #yocto22:13
moto-timovmeson: rburton: pushed a pyo3 recipe created with cargo-bitbake (plus an attempt at a patch, but it doesn't work yet)22:13
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)22:17
*** otavio <otavio!> has joined #yocto22:19
*** florian_kc <florian_kc!~florian@> has quit IRC (Ping timeout: 268 seconds)22:20
*** bps2 <bps2!> has quit IRC (Ping timeout: 260 seconds)22:20
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)22:25
*** otavio <otavio!> has joined #yocto22:27
*** bps2 <bps2!> has joined #yocto22:30
*** florian_kc <florian_kc!> has joined #yocto22:33
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)22:35
*** otavio <otavio!> has joined #yocto22:36
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)22:44
*** otavio <otavio!> has joined #yocto22:46
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)22:58
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)22:58
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)23:03
*** otavio <otavio!> has joined #yocto23:05
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)23:13
*** otavio <otavio!> has joined #yocto23:14
*** otavio <otavio!> has quit IRC (Ping timeout: 260 seconds)23:19
*** otavio <otavio!> has joined #yocto23:21
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)23:26
*** otavio <otavio!> has joined #yocto23:28
*** jatedev <jatedev!~jatedev@> has joined #yocto23:38
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)23:43
*** otavio <otavio!> has joined #yocto23:45
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)23:50
sveinseWhat happes if the sstate cache is cleaned for e.g. old age and the hashserv?23:50
*** otavio <otavio!> has joined #yocto23:51
sveinseWhat I mean is that the entry remains in the hashserv, but the sstate object goes away23:53
sveinseWill it simply regenerates the artifacts, uploads them to the sstate cache and updates the hashserv, overwriting the old entry?23:53
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:54

Generated by 2.17.2 by Marius Gedminas - find it at!