**** BEGIN LOGGING AT Wed Jan 19 02:59:57 2022 Jan 19 10:49:10 Saur[m]: if your sstate cache isn't really fast, throw a http server on it and use that: bitbake will download once then Jan 19 12:36:23 rburton: Yeah, we have considered it. However, then it comes down to authentication. Not everyone at the company has access to the code. Jan 19 12:45:17 Saur: http auth might work in the url? Jan 19 16:12:53 Hey all! I need latest Rust in Yocto dunfell, and I found it in openembedded-core. However, openembedded-core only has it in the "master" branch, not in "dunfell" (and not in newer Yocto releases either as far as I can see). Jan 19 16:13:00 Can it be backported to dunfell? Jan 19 16:16:19 to oe-core, no Jan 19 16:16:38 ask the meta-rust maintainers if you want that to have a backport of new rust Jan 19 16:17:07 part of the expectation of the LTS releases is that people with eg an interest in latest rust for dunfell will maintain a layer which simply contains latest rust for dunfell Jan 19 16:24:02 ok Jan 19 17:11:38 Is there a way to have 'resolve' added to '/etc/nsswitch' when the 'libnss-resolve2' package is included in an image? I've tried adding a 'pkg_postinst:libnss-resolve2:libc-glibc () {...}' function in a 'systemd_%.bbappend' file, but that doesn't seem to work. Jan 19 17:11:43 This seems to me that it would be something that should be added to the 'systemd' recipe since installing the 'libnss-resolve2' package in an image doesn't do much until you add 'resolve' to '/etc/nsswitch'. Jan 19 17:12:22 The only thing I got to work is to replace the 'pkg_postinst:${PN}:libc-glibc () {...}' function in my bbappend to add 'resolve' and override the function defined in the main systemd recipe. Jan 19 19:48:33 Huh, did they add an OSS/ELC in Japan this year? Jan 19 19:48:50 I think they normally do one Jan 19 19:49:35 Crofton[m]: Huh. Maybe I just missed it before Jan 19 19:50:03 smurray: might have more info Jan 19 19:56:35 JPEW: there has been a OSSJ with colocated Automotive Linux Summit for several years, at least. It's usually in the summer, but the pandemic has messed witht hat Jan 19 19:57:02 ah, cool Jan 19 19:57:21 ... well not the pandemic part Jan 19 19:58:59 JPEW: there does tend to be a bit more embedded stuff from ALS being part of it, but it's not under ELC. There's a separate quarterly (I think) 1-day embedded jamboree thing that goes on that I think Tim had/has some hand in Jan 19 21:23:36 khem: hey, I recall you did a bit with weston in oe-core some time ago, since this https://git.openembedded.org/openembedded-core/commit/?id=4efdcc1090 landed in dunfell, I cannot get weston to start Jan 19 21:23:53 if I switch the service back to "Type=Simple" "NotifyAccess=none", it works again Jan 19 21:24:02 am I missing something obvious ? Jan 19 21:50:20 uh ... could it be weston-launch and systemd-notify do not work well together ? if I enforce launcher to weston only, the notification is delivered, so lets see Jan 19 22:40:19 marex: Check out weston in post-dunfell (not sure exactly when) Jan 19 22:43:29 JPEW: I have a feeling I know what is going on here ... Jan 19 22:48:04 so yeah ... Jan 19 22:48:09 https://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/wayland?id=aa3bced2e1de2f4ba507aa014835b06edccc138a this got in first ... Jan 19 22:48:15 +ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log $OPTARGS Jan 19 22:48:25 https://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/wayland?id=c8aa0222ce2be647911114aaebcbb0d55d7caf87 this got in much later ... Jan 19 22:48:35 only the second patch was backported to dunfell ... Jan 19 22:51:00 marex: To add more complication: https://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/wayland?id=dd83fb40f76749c6689807afabc63b9d5c2a4065 :) Jan 19 22:52:22 JPEW: do you think we can convince RP to backport all that to dunfell LTS ? :-) Jan 19 22:52:28 I think I can answer that myself ... Jan 19 22:54:15 JPEW: I can think of two options -- one liner workaround (check if env contains $NOTIFY_SOCKET , if so, avoid weston-launch and use plain weston) -- or just revert the backport outright Jan 19 22:54:38 marex: We actually carry a local version of the current weston-init Jan 19 22:55:04 my-special-weston-init.bb :) Jan 19 22:55:08 JPEW: I do in some layers too all right ... that "run weston as user" is nice Jan 19 22:55:21 Ya, it's super simple too Jan 19 22:55:29 but I doubt this huge change can be backported into LTS, no way Jan 19 22:55:52 add WAYLAND_DISPLAY=/run/wayland-0 and weston automatically starts when needed. We put it to great effect with the fullscreen shell Jan 19 22:56:27 marex: There more of an argument if something is broken Jan 19 22:57:50 hmmmmmm, it feels too disruptive, the users would eat us alive for backporting change of that magnitude I think Jan 19 23:20:35 JPEW: I documented it and sent out a revert ... it seems to be the most sane approach Jan 19 23:33:58 Sounds good **** ENDING LOGGING AT Thu Jan 20 02:59:56 2022