| *** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 00:02 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Read error: Connection reset by peer) | 00:02 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 00:03 | |
| *** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 00:04 | |
| *** tantrum_ <tantrum_!~Srain@p549aa260.dip0.t-ipconnect.de> has joined #yocto | 00:33 | |
| *** tantrum <tantrum!~Srain@p549aaa2b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 260 seconds) | 00:36 | |
| *** tantrum_ is now known as tantrum | 00:36 | |
| *** florian__ <florian__!~florian@dynamic-002-244-130-092.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 264 seconds) | 00:58 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 01:10 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 01:48 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 01:51 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:24 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 02:26 | |
| *** camus1 is now known as camus | 02:26 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 05:02 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 264 seconds) | 05:03 | |
| *** camus1 is now known as camus | 05:03 | |
| *** yocti <yocti!~limnoria@mail.yoctoproject.org> has joined #yocto | 05:54 | |
| *** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has joined #yocto | 05:54 | |
| *** jonmason <jonmason!sid36602@id-36602.lymington.irccloud.com> has joined #yocto | 05:55 | |
| *** ndec <ndec!sid219321@id-219321.tinside.irccloud.com> has joined #yocto | 05:55 | |
| *** georgem <georgem!sid210681@id-210681.tinside.irccloud.com> has joined #yocto | 05:55 | |
| *** ChanServ sets mode: +v ndec | 05:55 | |
| *** wyre <wyre!~wyre@user/wyre> has joined #yocto | 05:55 | |
| *** tantrum <tantrum!~Srain@p549aa260.dip0.t-ipconnect.de> 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_!~patrick@nostromo.0x47.net> has quit IRC (*.net *.split) | 06:02 | |
| *** MWelchUK <MWelchUK!~MWelchUK@23.88.108.134> has quit IRC (*.net *.split) | 06:02 | |
| *** ak77 <ak77!~ak77@93-103-81-73.static.t-2.net> 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@107.170.225.75> has quit IRC (*.net *.split) | 06:02 | |
| *** perdmann <perdmann!~patrick@nostromo.0x47.net> has joined #yocto | 06:02 | |
| *** mrnuke <mrnuke!~mrnuke@c-98-195-139-126.hsd1.tx.comcast.net> has joined #yocto | 06:03 | |
| *** ak77 <ak77!~ak77@93-103-81-73.static.t-2.net> has joined #yocto | 06:03 | |
| *** MWelchUK <MWelchUK!~MWelchUK@gyros.collabora.co.uk> has joined #yocto | 06:03 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 06:11 | |
| *** glembo[m] <glembo[m]!~glembomat@2001:470:69fc:105::174> has joined #yocto | 06:11 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 06:15 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 06:15 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 245 seconds) | 06:30 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 06:53 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 06:54 | |
| *** camus1 is now known as camus | 06:54 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:01 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:06 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 07:07 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 07:30 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:31 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:49 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 07:51 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 07:51 | |
| *** vermaete <vermaete!~vermaete@ptr-figrjr1to9lheavmr3t.18120a2.ip6.access.telenet.be> has joined #yocto | 07:54 | |
| *** amitk <amitk!~amit@103.208.71.174> has joined #yocto | 08:04 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 08:10 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:13 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Ping timeout: 260 seconds) | 08:14 | |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving) | 08:37 | |
| dwagenk | Is 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 |
|---|---|---|
| dwagenk | Already tried both firefox and chromium. Both without changes in teh configuration compared to last time (~2 Weeks ago) | 08:48 |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 268 seconds) | 08:54 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 08:55 | |
| *** vermaete <vermaete!~vermaete@ptr-figrjr1to9lheavmr3t.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Client closed) | 08:55 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 08:59 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 08:59 | |
| dwagenk | searching 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@89.244.122.146> has quit IRC (Ping timeout: 246 seconds) | 09:24 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 09:24 | |
| *** bps2 <bps2!~bps@27-reverse.bang-olufsen.dk> has joined #yocto | 09:25 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 09:28 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 09:29 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 09:41 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 268 seconds) | 09:45 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 09:45 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 09:54 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 09:55 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 09:56 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 10:00 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 10:01 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 246 seconds) | 10:09 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 10:10 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:10 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 10:12 | |
| *** camus1 is now known as camus | 10:12 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 10:14 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 10:15 | |
| *** vicale <vicale!~vicale@dyn-13-cust157.netit.se> has quit IRC (Quit: Leaving) | 10:15 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 10:18 | |
| wCPO | I'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/desktop-shell.so: cannot open shared object file: No such file or directory | 10:23 |
| hmw[m] | btw im on dunfell | 10:23 |
| manuel1985 | hmw[m]: Do you have the package 'weston' installed? | 10:27 |
| hmw[m] | manuel1985: yes | 10:28 |
| hmw[m] | ( it is from /usr/bin/weston.log | 10:28 |
| hmw[m] | opkg list weston | 10:29 |
| hmw[m] | weston - 8.0.0-r0.arago3 | 10:29 |
| manuel1985 | hmw[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 |
| manuel1985 | I'm on Dunfell as well with weston 8.0.0-r0. | 10:31 |
| hmw[m] | rebuild it is then :( | 10:31 |
| hmw[m] | manuel1985: ty | 10:33 |
| manuel1985 | hmw[m]: Just checked the recipe, there seems to be a packageconfig option for shell-desktop | 10:33 |
| manuel1985 | Oh but if your weston log is throwing that error, that packageconfig option is probably already set to use shell-desktop | 10:34 |
| manuel1985 | Otherwise it wouldn't start looking for it | 10:34 |
| manuel1985 | Ok got no idea, sry. If you find out the reason, I'd be interested to learn. Best of luck. | 10:35 |
| marex | hmw[m]: well is the desktop-shell.so in tmp/work* ? | 10:42 |
| marex | hmw[m]: find tmp/work -name desktop-shell.so | 10:43 |
| marex | it should be somewhere in packages-split/ | 10:43 |
| marex | hmw[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 #yocto | 10: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 btw | 10:51 |
| *** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto | 10:52 | |
| marex | hmw[m]: there is some oddity in dunfell since a few days ago that the notifications from weston to systemd do not work | 10:53 |
| marex | so in case your weston instance magically gets killed after a few seconds, you might be hitting that | 10:53 |
| hmw[m] | the weston service is up for 22 min atm ( did not format the running system) | 10:54 |
| marex | revert 4efdcc10906945765aa28324ce1badc59cda2976 in oe-core if you run into this | 10:54 |
| marex | ok | 10:54 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 10:55 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 10:58 | |
| RP | kanavin_: please don't trigger anything as I need to restart the controller when the current build finishes | 11:06 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 11:17 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> 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 aborting | 11: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 does | 11:27 |
| kanavin_ | RP: I'll take it out, it fails this way on arm/mips but not x86 | 11:30 |
| kanavin_ | simply not well tested it seems | 11:30 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 11:30 | |
| agherzan | Hi. I'm a bit confused about how the psplash alternative symlink is supposed to work. We define the priority (not package override) as 100 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/psplash/psplash_git.bb#n73. 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 which | 11:32 |
| agherzan | comes 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 #yocto | 11:34 | |
| agherzan | My 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 |
| agherzan | I 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!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 11:35 | |
| agherzan | Now, 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 to | 11:36 |
| agherzan | SPLASH ?= "psplash-default" | 11:36 |
| agherzan | FEATURE_PACKAGES_splash = "${SPLASH}" | 11:36 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::e120> has joined #yocto | 11:39 | |
| RP | kanavin_: 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 Lithuania | 11:41 |
| kanavin_ | red hat has no interest anymore | 11:41 |
| RP | kanavin_: it is kind of sad | 11:43 |
| RP | kanavin_: 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, thanks | 11:44 |
| RP | kanavin_: NFS issues is the answer ;-) | 11:45 |
| rburton | couldnt believe rsync was that much slower than tar | 11: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 |
| RP | kanavin_: maybe use a-quick? :) | 11:47 |
| RP | rburton: its the number of files. File creation overhead on NFS is the bottlebeck | 11:48 |
| RP | I threw zstd in since it is there and helped | 11:48 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 11:52 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 11:52 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 12:02 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 12:06 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 12:08 | |
| rburton | RP: hm docs say that you cannot set SDKMACHINE in a distro configuration. I can't see why that would not work. | 12:16 |
| RP | rburton: include conf/machine-sdk/${SDKMACHINE}.conf | 12:17 |
| RP | include conf/distro/${DISTRO}.conf | 12:17 |
| rburton | oh right | 12:17 |
| rburton | why not swap that ;) | 12:17 |
| RP | rburton: distros are allowed to override machine config | 12:18 |
| RP | it is consistency | 12:18 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 268 seconds) | 12:18 | |
| *** chep <chep!~chep@88.168.197.200> has joined #yocto | 12:19 | |
| hmw[m] | <marex> "it should be somewhere in..." <- marex: the find on desktop-shell.so did not return ( on dunfell HEAD ) going to reverte to | 12:27 |
| hmw[m] | 4efdcc10906945765aa28324ce1badc59cda2976 | 12:27 |
| RP | kanavin_: ready for builds now | 12:28 |
| *** frosteyes <frosteyes!~frosteyes@185.53.130.211> has joined #yocto | 12:31 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 12:33 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Read error: Connection reset by peer) | 12:34 | |
| *** florian__ <florian__!~florian@78.48.24.219> has joined #yocto | 12:35 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 12:39 | |
| *** frosteyes <frosteyes!~frosteyes@185.53.130.211> has quit IRC (Quit: WeeChat 2.8) | 12:43 | |
| *** frosteyes <frosteyes!~frosteyes@185.53.130.211> has joined #yocto | 12:45 | |
| frosteyes | hi folks. A quick question. I have created a SDK, where I want to compile kernel modules out-of-tree. So have added kernel-devsrc | 12:47 |
| frosteyes | Next I am trying to run make -C /usr/local/oecore-x86_64/sysroots/corei7-64-poky-linux/usr/src/kernel prepare scripts | 12:47 |
| frosteyes | But the problem is that it fails the prepare with objtool. (no rule to make target .... objtool/fixdep.o) | 12:48 |
| frosteyes | Is using dunfell branch.. | 12:48 |
| frosteyes | I guess it might be an issue with how I use the kernel-devsrc part. | 12:48 |
| zeddii | frosteyes: What's your kernel version ? objtool is covered under devsrc, everything needed to rebuild it is packaged. | 12:51 |
| zeddii | but I can't say that I've tested with the SDK. | 12:52 |
| zeddii | if there are a set of configs and reproducing steps, I could always try it locally to see what's up. | 12:52 |
| frosteyes | Thanks zeddii - the kernel is a custom 4.19.130 | 12:54 |
| zeddii | aha. 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@71.220.185.242> has quit IRC (Ping timeout: 256 seconds) | 12:57 | |
| frosteyes | zeddii: to you know if 5.4 is working better? | 12:57 |
| zeddii | with 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 references | 12:58 |
| frosteyes | Okay.. | 12:59 |
| zeddii | it 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 |
| frosteyes | Will look into the eSDK, and also the other kernel.. | 12:59 |
| frosteyes | 5.4 seems to be the normal "dunfell" kernel.. | 13:00 |
| zeddii | dunfell was v5.2 and 5.4 at the time of release, so I know they were tested heavily | 13:00 |
| zeddii | right, and we deleted 5.2 after, so you'll only see 5.4 now in the dunfell branches | 13:00 |
| frosteyes | Yes | 13:00 |
| zeddii | I can try a dunfell SDK test, with all the stock bits. | 13:01 |
| zeddii | I just have to look up the incantation :D | 13:01 |
| frosteyes | That 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 https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2861 | 13:05 |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 13:13 | |
| marex | RP: 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 |
| marex | FOO:append:class-native:my-machine = " extraflag" seems to not work | 13:20 |
| marex | obviously, because MACHINE isnt set in class-native and neither is MACHINEOVERRIDES | 13:20 |
| *** GillesM <GillesM!~gilles@183.153.118.78.rev.sfr.net> has joined #yocto | 13:22 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 13:22 | |
| *** GillesM <GillesM!~gilles@183.153.118.78.rev.sfr.net> has quit IRC (Client Quit) | 13:22 | |
| smurray | marex: 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-weston | 13:26 |
| marex | smurray: on oe-core/dunfell too ? | 13:31 |
| marex | the dunfell part is important there | 13:31 |
| smurray | marex: I tested poky dunfell with qemux86-64 | 13:32 |
| marex | smurray: did you have the notification stuff above in weston systemd service file ? | 13:33 |
| smurray | marex: yes | 13:33 |
| marex | all right, in that case, I need to double-check why the notification isn't delivered here | 13:33 |
| *** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 13:36 | |
| smurray | marex: 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 modules=systemd-notify.so in our base weston.ini, so we're still okay (I think) | 13:44 |
| *** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 13:46 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:51 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 13:52 | |
| marex | smurray: that systemd-notify.so in modules should be unnecessary, see weston.log, it will complain it is loaded already | 13:52 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 13:52 | |
| smurray | marex: weston-start is adding it via the command-line, I figure that would be the cause of that? | 13:54 |
| marex | yep | 13:54 |
| *** scott_ <scott_!~scott@76-209-90-35.lightspeed.jcvlfl.sbcglobal.net> has joined #yocto | 13:54 | |
| *** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds) | 13:55 | |
| smurray | marex: 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.13 | 13:56 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:56 | |
| hmw[m] | marex: 4efdcc10906945765aa28324ce1badc59cda2976 also is not producing desktop-shell.so | 14:00 |
| hmw[m] | i also have added PACKAGECONFIG = "shell-desktop" to a new weston_%.bbappend | 14:00 |
| marex | hmw[m]: PACKAGECONFIG:append:yourmachine = " shell-desktop" | 14:01 |
| marex | hmw[m]: you can verify if it is picked up using bitbake -e weston | grep ^PACKAGECONFIG | 14:01 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 14:03 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 14:03 | |
| hmw[m] | it is was not in the package config. is the : new ? | 14:03 |
| marex | hmw[m]: it is new syntax which replaces the old _ one | 14:05 |
| marex | since honister | 14:05 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 14:12 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 14:14 | |
| sveinse | How 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 |
| RP | kanavin_: ah. My fault :( | 14:14 |
| sveinse | Is there a correspondance between the MACHINE running the bitbake-hashserv against the systems that is going to use the hash equivalence server? | 14:15 |
| sveinse | This is going to be used for ordinary image builds. I don't have any autobuilder setup | 14:16 |
| RP | kanavin_: workaround pushed until I can figure out something better | 14:16 |
| RP | marex: natives are only built once for all machines so what you're asking for isn't possible | 14:17 |
| RP | sveinse: you don't need metadata, just a copy of bitbake | 14:18 |
| RP | kanavin_: I restarted it for you | 14:21 |
| sakoman | \ | 14:22 |
| sveinse | Won't the bitbake-hashserve need access to the sstate cache? Or is that completely separate? E.g. handled by bitbake itself? | 14:23 |
| rburton | is anyone else looking at upgrading python3-cryptography? (cc moto_timo[m]) | 14:29 |
| moto-timo | rburton: pyo3 is not behaving well in cross-compile. Frustrating mess. | 14:31 |
| rburton | grr | 14:31 |
| rburton | we have a dependency on py-crypto for a firmware build, which breaks with openssl3 as py-cry doesn't support it | 14:32 |
| marex | RP: I guess I could use DISTROOVERRIDES for that ? | 14:32 |
| marex | RP: or is that awful ? | 14:32 |
| marex | RP: I am trying to avoid side-effects of the layer | 14:32 |
| kanavin_ | RP: thanks :) | 14:33 |
| hmw[m] | marex: tnx it it working now :D | 14:34 |
| marex | oh :) | 14:34 |
| marex | hmw[m]: so it was the missing append ? | 14:34 |
| smurray | marex: depending on what the -native bit is, don't you risk rebuilding piles of stuff? | 14:34 |
| hmw[m] | marex: yes | 14:34 |
| RP | marex: layers really shouldn't hack natives to be machine specific, ever | 14:35 |
| sveinse | I'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 all | 14:36 |
| rburton | patches welcome if you've tested the build | 14:36 |
| RP | sveinse: in most cases we've likely just never needed those variants and they do have a cost | 14:37 |
| sveinse | I see. I have a few python3-*.bbappends in my layers because of it | 14:39 |
| *** kiran <kiran!~kiran@2607:fea8:5a80:ea0:8a17:65be:d8b6:bd8c> has joined #yocto | 14:41 | |
| rburton | sveinse: just post the patches, they're trivial if you've tested them | 14:42 |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Remote host closed the connection) | 14:44 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 14:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 14:45 | |
| rburton | moto-timo: do you have any WIP? like a setuptools-rust recipe already? | 14:46 |
| moto-timo | rburton: https://git.openembedded.org/meta-openembedded-contrib/log/?h=timo/py-cryptography_35.0.0 | 14:47 |
| rburton | awesome | 14:47 |
| moto-timo | rburton: older version, simpler (no real rust) https://git.openembedded.org/meta-openembedded-contrib/log/?h=timo/rust_python3-cryptography | 14:48 |
| marex | smurray: luckily no, I am only doing this to fill PARALLEL_MAKE back into one crappy tool from crappy poorly maintained layer | 14:57 |
| marex | smurray: else it builds for effing ever | 14:58 |
| smurray | marex: maybe a bbappends that's dynamically applied would be enough? | 15:02 |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 246 seconds) | 15:04 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 15:05 | |
| marex | smurray: doesnt that blow up on yocto-check-layer or oelint-adv ? | 15:10 |
| smurray | marex: it likely would for y-c-l if you include the layer, yes | 15:11 |
| smurray | marex: but it's simpler than perhaps something with BBMASK set via anon python, which might be another route | 15:12 |
| smurray | marex: using BBFILES_DYNAMIC was what I was thinking of | 15:18 |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 15:19 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 15:19 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 260 seconds) | 15:24 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 15:25 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 15:31 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 15:32 | |
| marex | smurray: I am not entirely sure if that doesn;t trigger y-c-l either | 15:37 |
| marex | smurray: thanks anyway | 15:38 |
| smurray | marex: 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@172.58.191.91> has joined #yocto | 15:39 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.91> has quit IRC (Client Quit) | 15:40 | |
| smurray | marex: 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-l | 15:41 |
| smurray | marex: that's used in AGL in places to get y-c-l compliance | 15:42 |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 246 seconds) | 15:43 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 15:44 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Ping timeout: 246 seconds) | 15:48 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has joined #yocto | 15:48 | |
| *** bps2 <bps2!~bps@27-reverse.bang-olufsen.dk> has quit IRC (Ping timeout: 268 seconds) | 15:52 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 15:54 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 15:55 | |
| sveinse | rburton: yocto use mail patches? No scheme for PR? | 15:59 |
| rburton | correct | 15:59 |
| sveinse | How is copyright managed in yocto? Waived to commit? | 16:01 |
| rburton | https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines | 16:02 |
| rburton | basically, kernel-style DCO | 16:02 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 16:02 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 16:04 | |
| *** curious457 <curious457!~curious45@2607:fad8:4:6:d6dc:1ad2:ccfe:7af7> has quit IRC (Quit: Client closed) | 16:08 | |
| *** Guest81 <Guest81!~Guest81@84-216-190-107.customers.ownit.se> has joined #yocto | 16:09 | |
| Guest81 | Can I force a 32 bit user space by setting MLPREFIX="lib32-"? | 16:11 |
| sveinse | Can BB_HASHSERVE and BB_SIGNATURE_HANDLER be specified in site.conf ? | 16:11 |
| rburton | anything can be in site.conf | 16:11 |
| rburton | its parsed just before auto.conf, which is just before local.conf | 16:12 |
| tgamblin | khem: can you put "[oe] [PATCH][meta-python] python3-imgtool: add recipe" on master-next? | 16:25 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 16:25 | |
| sveinse | Will a hash equivalence server help on build times beyond what the sstate cache provides? | 16:28 |
| rburton | yes | 16:28 |
| rburton | if say libfoo rebuilds with different inputs, but the output is identical, the hashequi will say its the same result | 16:29 |
| rburton | so the output hash gets switched back, and other things might not rebuild | 16:29 |
| rburton | build 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 rebuilt | 16:29 |
| sveinse | Do you need to prime it with an existing sstate setup? I just fired it up, but I build the full honister two days ago | 16:30 |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 16:30 | |
| rburton | bitbake will look in the existing sstate too, but the hash equiv helps future builds | 16:31 |
| sveinse | I.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 #yocto | 16:33 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> 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@89.244.122.146> has joined #yocto | 16:53 | |
| *** zpfvo <zpfvo!~fvo@89.244.122.146> has quit IRC (Client Quit) | 16:57 | |
| halstead | dwagenk: I've resolved the issue with the layerindex dropdowns etc. Let me know if you still notice problems after a reload. | 16:57 |
| RP | sveinse: the rebuild that triggers will prime the hash equivalence server | 16:58 |
| *** Saur <Saur!~pkj@proxy01.se.axis.com> has joined #yocto | 17:10 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 17:10 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 17:12 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Ping timeout: 268 seconds) | 17:21 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 17:30 | |
| moto-timo | vmeson: any advice/examples for how to patch a crate without rust tooling? We need to patch pyo3 to search in ${STAGING_LIBDIR}/python-sysconfigdata https://github.com/PyO3/pyo3/blob/main/pyo3-build-config/src/impl_.rs#L836 | 17:31 |
| moto-timo | s/without/with our/ | 17:32 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 17:32 | |
| *** camus1 is now known as camus | 17:32 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has joined #yocto | 17:35 | |
| sveinse | RP: 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 this | 17:37 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 17:38 | |
| vd | Does 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 #yocto | 17:40 | |
| *** xantoz <xantoz!~tewi_inab@c-c0bae255.013-124-73746f25.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds) | 17:51 | |
| *** xantoz <xantoz!~tewi_inab@c-c0bae255.013-124-73746f25.bbcust.telenor.se> has joined #yocto | 17:52 | |
| rburton | no idea, but i doubt you'll be hitting the throughput limits | 17:52 |
| JaMa | vd: 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 visible | 17:53 |
| * JaMa has 6000s aorus gen4 2tb drive with 3970 and only 128g ram is bigger issue than io now | 17:56 | |
| vd | interesting! 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 assume | 17:59 |
| Saur | rburton: Did you see my question about the licenses for libx11-compose-data on the OE-Core list the other day? | 17:59 |
| JaMa | if you already have it running with PCIE 3 drive, then I would watch avq in atop during the build | 18:01 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 18:02 | |
| vd | JaMa don't have it yet, I'm about to order and NVMe PCI 3.0 vs 4.0 was my last step | 18:04 |
| JaMa | frosteyes submitted results with 5950x 128G ram and PCIE 4.0 Corsair SSD MP600 1TB, maybe he can share his experiences on his system | 18:05 |
| sveinse | One 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!~vermaete@ptr-figrjr1to9lheavmr3t.18120a2.ip6.access.telenet.be> has joined #yocto | 18:10 | |
| vd | JaMa: thoughts on QLC vs TLC nand for the NVMe? | 18:13 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 18:15 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 18:21 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 18:21 | |
| sveinse | How 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 |
| JPEW | sveinse: 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 #yocto | 18:58 | |
| *** florian__ <florian__!~florian@78.48.24.219> has quit IRC (Ping timeout: 268 seconds) | 19:00 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 19:12 | |
| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:d990:7e0d:b0a6:e609> has joined #yocto | 19:17 | |
| sveinse | Perhaps the Yocto community could start their own taskhash blockchain XD :P | 19:20 |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> 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─┬─as | 19:23 |
| sveinse | haha | 19:23 |
| sveinse | automake in each subdir I would guess | 19: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 |
| sveinse | yeah, I think bash doesn't pass on the vars for make to utilize the job-server of the top make | 19:32 |
| vd | JaMa: nevermind, I get it for TLC/QLC and NVMe/SSD. Endurance is the key for normal use :) | 19:34 |
| vmeson | moto-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@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 19:36 | |
| moto-timo | vmeson: https://git.openembedded.org/meta-openembedded-contrib/log/?h=timo/python3-cryptography_35.0.0 | 19:37 |
| moto-timo | vmeson: it fails in do_compile because of pyo3 | 19:38 |
| vmeson | moto-timo: thanks... time to reboot to pick up some updates, I'll take a look hopefully today. | 19:40 |
| JaMa | I remember oposite case in qt* long time ago when -j 64 from top level makefile was also used in 10+ make calls in subdirectories | 19:42 |
| moto-timo | vmeson: the error is from https://github.com/PyO3/pyo3/blob/main/pyo3-build-config/src/impl_.rs#L884 because it doesn’t know about ${STAGING_LIBDIR}/python-sysconfigdata | 19:45 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 19:58 | |
| *** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.) | 20:04 | |
| vd | what should you prioritize on an NVMe, SSTATE_DIR or TMPDIR? | 20:22 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 20:33 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 20:35 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 20:37 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 20:37 | |
| *** vermaete <vermaete!~vermaete@ptr-figrjr1to9lheavmr3t.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Client closed) | 20:42 | |
| *** mcfrisk_ is now known as mcfrisk | 20:44 | |
| JPEW | vd: TMPDIR | 20:46 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 20:48 | |
| JPEW | vd: 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 sstate | 20:48 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 20:49 | |
| vd | JPEW with the system on the NVMe as well or another disk? | 20:51 |
| JPEW | vd: OS is on the nvme, but I don't know how much that would matter | 20:53 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 20:54 | |
| JaMa | I 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 |
| JaMa | but 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 |
| JaMa | also depends on what are your typical images, building qtwebengine/chromium/nodejs easily takes 2GB per c++ process | 20:56 |
| vd | JaMa: building qtwebengine images on 16-core / 64Go ram, I was worried about the NVMe endurance even though it sounds nicer for TMPDIR | 20:57 |
| JaMa | also 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 build | 20:58 |
| JaMa | are you going to disable smp? | 20:59 |
| *** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has joined #yocto | 21:00 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 21:00 | |
| *** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto | 21:01 | |
| JaMa | doesn't 5950 have 16 cores, 32 threads? I was assuming you'll use -j 32 with it | 21:02 |
| JaMa | my gen4 nvme (used mostly for OE builds) is running for 11316 hours and still has 95% life left | 21:04 |
| JaMa | but it's true that last year I'm running significantly less builds here locally | 21:04 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:05 | |
| *** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has quit IRC (Quit: Client closed) | 21:05 | |
| *** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has joined #yocto | 21:06 | |
| JaMa | and I wrote around 240TB to it in 2 years, while rootfs disk shows only 13TB in 3-4 yers | 21:07 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 21:10 | |
| JaMa | I 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 partially | 21:11 |
| JaMa | written to disk) | 21:11 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:11 | |
| JaMa | that's why on servers with more ram than cores I prefer to use tmpfs to keep ssds healthy for longer | 21:12 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 21:16 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:18 | |
| *** florian_kc <florian_kc!~florian@78.48.24.219> has joined #yocto | 21:20 | |
| *** florian__ <florian__!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 21:24 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 21:26 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:28 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 21:33 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:34 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 21:40 | |
| *** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has quit IRC (Ping timeout: 256 seconds) | 21:41 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:41 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:44 | |
| *** yocton <yocton!~quassel@2001:bc8:3386::1> has joined #yocto | 21:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 21:45 | |
| *** camus1 is now known as camus | 21:45 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 21:46 | |
| *** GillesM <GillesM!~gilles@183.153.118.78.rev.sfr.net> has joined #yocto | 21:51 | |
| *** kiran <kiran!~kiran@2607:fea8:5a80:ea0:8a17:65be:d8b6:bd8c> has quit IRC (Ping timeout: 268 seconds) | 21:57 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:58 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 22:00 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 22:00 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 22:04 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:05 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> 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@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 22:09 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 22:11 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 22:12 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 22:12 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:13 | |
| moto-timo | vmeson: 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!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 22:17 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:19 | |
| *** florian_kc <florian_kc!~florian@78.48.24.219> has quit IRC (Ping timeout: 268 seconds) | 22:20 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Ping timeout: 260 seconds) | 22:20 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 22:25 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:27 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 22:30 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-024-219.78.48.pool.telefonica.de> has joined #yocto | 22:33 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 22:35 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:36 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 22:44 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:46 | |
| *** GillesM <GillesM!~gilles@183.153.118.78.rev.sfr.net> has quit IRC (Quit: Leaving) | 22:58 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 22:58 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 23:03 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:05 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 23:13 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:14 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 260 seconds) | 23:19 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:21 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 23:26 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:28 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 23:38 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 23:43 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:45 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 23:50 | |
| sveinse | What happes if the sstate cache is cleaned for e.g. old age and the hashserv? | 23:50 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:51 | |
| sveinse | What I mean is that the entry remains in the hashserv, but the sstate object goes away | 23:53 |
| sveinse | Will 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 irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!