| *** Habbie <Habbie!peter@lorentz.7bits.nl> has quit IRC (Ping timeout: 244 seconds) | 00:19 | |
| *** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #oe | 00:27 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #oe | 00:44 | |
| *** sanbeam <sanbeam!~Sanjeev@204.83.75.119> has joined #oe | 00:53 | |
| *** tgamblin_ <tgamblin_!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #oe | 00:54 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 244 seconds) | 00:57 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 00:59 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has joined #oe | 01:03 | |
| *** sanbeam <sanbeam!~Sanjeev@user/sanbeam> has quit IRC (Ping timeout: 260 seconds) | 01:05 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #oe | 01:05 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has joined #oe | 01:06 | |
| *** tgamblin_ is now known as tgamblin | 01:06 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 260 seconds) | 01:09 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has joined #oe | 01:13 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 260 seconds) | 01:16 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has joined #oe | 01:17 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 01:19 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 248 seconds) | 01:19 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has joined #oe | 01:22 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 260 seconds) | 01:25 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has joined #oe | 01:27 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 260 seconds) | 01:30 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.204> has joined #oe | 01:35 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 276 seconds) | 01:44 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has joined #oe | 04:10 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has joined #oe | 04:15 | |
| *** sanbeam18 <sanbeam18!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 260 seconds) | 04:18 | |
| *** sanbeam9 <sanbeam9!~Sanjeev@204.83.75.119> has quit IRC (Ping timeout: 276 seconds) | 04:22 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 06:24 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has joined #oe | 07:14 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 07:21 | |
| mort | I wonder if I should just make my own recipes for rust and go, which pretty much just grabs the source code from those projects and compiles the compilers | 07:52 |
|---|---|---|
| mort | that way we can pick the latest versions of these languages and upgrade when we want instead of waiting for other people | 07:54 |
| kanavin_ | mort, you don't need to wait. Update the recipes in core, and send patches. We'd really appreciate. | 08:42 |
| mort | do you even accept patches for kirkstone anymore | 08:43 |
| mort | anyway I don't want to have to patch LLVM and what not just to upgrade the rust version, it would be great to be able to just change a version number and get a new rust version | 08:44 |
| mort | I wanna try to just download pre-built rustc+cargo binaries from rust's servers and let that be it | 08:44 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe | 08:46 | |
| mort | I don't know if that's a reasonable approach at all but I would really *really* like rust and go language version upgrades to be easy, so that we can actually stay up to date, they're both languages where staying on a year old toolchain version is pain | 08:47 |
| *** mvlad <mvlad!~mvlad@2a02:2f05:810e:b200:e88e:21ff:fe65:be18> has joined #oe | 08:55 | |
| kanavin_ | mort, we have https://git.yoctoproject.org/meta-lts-mixins for that | 09:32 |
| kanavin_ | but generally if you want newer rust, update your yocto to scarthgap or even master | 09:33 |
| kanavin_ | you can't have it both ways: stay on old LTS and expect new software | 09:34 |
| kanavin_ | if you figure out how to make toolchain updates easy, we're all ears. It's one of the hardest things to do actually. | 09:34 |
| kanavin_ | maybe you have better experience with prebuilt binaries, but they won't be accepted in mainline as default choice. as an option, maybe | 09:35 |
| kanavin_ | I just checked debian, they're doing even worse. 1.63 in debian 12 | 09:38 |
| mort | it's not like I wouldn't love to always stay on the latest yocto, but there's an ecosystem | 09:51 |
| mort | meta-variscite-bsp for example isn't on scarthgap yet | 09:52 |
| kanavin_ | ask them to follow master, and not hold you hostage to old yocto | 09:53 |
| kanavin_ | if you're in a vendor-supplier relationship, this should be in the contract | 09:53 |
| kanavin_ | anyway, that lts mixin layer does have rust 1.75 | 09:54 |
| kanavin_ | and go 1.22 too | 09:56 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 10:17 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 10:25 | |
| mort | Rust 1.75 is almost a year old T_T | 10:42 |
| mort | but okay meta-rust for rust 1.78 + meta-lts-mixins for Go 1.22 isn't terrible, I still would've liked to be able to just update the toolchain when necessary but ... it's not Go 1.17 and Rust 1.59 | 10:44 |
| kanavin_ | mort, then you should help us getting it up to date in master. It doesn't magically update itself, someone needs to sit down and do it, and we don't have enough people. | 10:44 |
| mort | some things actually do magically update themselves | 10:44 |
| kanavin_ | like what? | 10:44 |
| mort | like rust and go on my laptop | 10:44 |
| kanavin_ | how? | 10:45 |
| mort | I mean I have to do 'rustup update' for rust and use the installer for go but that's as close to 0 effort as you're realistically gonna get | 10:45 |
| kanavin_ | yeah, but that's just for local development, and won't be suitable for any production work | 10:45 |
| mort | there's little reason why it shouldn't be | 10:45 |
| kanavin_ | then you're welcome to implement that in yocto | 10:46 |
| mort | I gave it a shot with rust but I realized I don't know how to marry bitbake's assumption about recipes with rust's assumptions about its environment | 10:46 |
| kanavin_ | which are? | 10:47 |
| mort | and I don't know if that's due to my lack of knowledge about the two, or if they're incompatible | 10:47 |
| mort | well, rust wants to have a ~/.cargo folder which stays in one place for one, and then it controls everything in that folder; doesn't bitbake create hard links so that every recipe gets its own sysroot? | 10:48 |
| kanavin_ | I don't think they are. all this self-updating stuff is really meant strictly for local development, and not for packaging or deployment. | 10:48 |
| mort | I wouldn't want it to self-update, I would want to pin the version | 10:49 |
| mort | (which rustup lets you do, 'rustup default 1.80.1' or whatever sets the default toolchain to 1.80.1) | 10:49 |
| kanavin_ | yeah, but you'd need to use standard bitbake fetchers. Anything that gets random unverified stuff from the network is a non-starter. | 10:50 |
| mort | it's not a non-starter *for me* | 10:50 |
| mort | but yes it's a non-starter for upstream | 10:51 |
| mort | though when I was looking into making a recipe which uses the pre-built binaries, I actually didn't use rustup, I downloaded the pre-built tarball they distribute, using a normal fetcher | 10:51 |
| mort | but I gave up when I realized that the way you're expected to add new targets is with rustup, so it wouldn't work as a cross compiler without rustup and I didn't think I'd be able to get rustup to work | 10:52 |
| kanavin_ | I mean, such experiments are entirely welcome. We do want to offer a 'prebuilt rust' option, for example, at least for rust-native, to cut build times. | 10:53 |
| *** sakoman <sakoman!~sakoman@98.142.47.158> has quit IRC (Ping timeout: 246 seconds) | 10:54 | |
| kanavin_ | but we also do need to keep rust updated in core, and I'd rather see you help there. | 10:54 |
| kanavin_ | we just about managed to get 1.78 there, but it's at 1.80 now | 10:54 |
| mort | the only thing I understand about the recipes related to rust is that I don't understand them and that they keep changing in ways I also don't understand | 10:54 |
| kanavin_ | I get that. They're very complex things. | 10:58 |
| mort | if I could update scarthgap's recipe to 1.80 and then use that updated recipe I would be interested in trying to figure this stuff out | 10:58 |
| kanavin_ | mort, the path to that is update master to 1.80 and then backport to scarthgap/rust in meta-lts-mixins (not in oe-core proper) | 10:59 |
| mort | I would be very scared by the fact that you guys need to patch LLVM but I mean I could probably figure out how to forward-port those patches when needed, or identify when they patch problems which have since been fixed (or the patch has been submitted and merged) | 10:59 |
| mort | but the problem is, I couldn't use the 1.80 scarthgap recipe in kirkstone | 10:59 |
| mort | I didn't look at it a ton but things like which bbclasses even exist has changed | 10:59 |
| mort | also, we're not just talking about "is this something I want to do", but rather "is this something my employer would appreciate me spending a week on" | 11:03 |
| kanavin_ | mort, this is what every other employer would say too. So how is yocto supposed to be developed and maintained? Someone else's problem? | 11:07 |
| kanavin_ | You need to educated your employer: part of your time has to go towards upstream work. | 11:07 |
| mort | Upstream work which we can't even use for a year is a tough sell <_< | 11:08 |
| kanavin_ | yeah. So the first step should indeed be moving closer to upstream, so that gap isn't so huge, and the sell becomes easier. | 11:09 |
| mort | correct | 11:09 |
| kanavin_ | I've been advocating staying on top of master (periodic rebase onto milestones) for years. Then when an LTS happens, you get a fresh new LTS stack 'for free'. | 11:09 |
| kanavin_ | just by branching off master at the release point. | 11:10 |
| kanavin_ | then you can put that new LTS into old products, or maybe make new products with it. | 11:11 |
| mort | now how do you move closer to upstream when external people are doing the whole "building a yocto system for the hardware" thing and their clear suggestion has been to use kirkstone until bsp meta layers are ready for scarthgap | 11:11 |
| *** sakoman <sakoman!~sakoman@98.142.47.158> has joined #oe | 11:11 | |
| kanavin_ | obviously I strongly object to the notion of 'bsp meta layers' getting ready for latest LTS with a massive delay :) they should follow master too. | 11:12 |
| mort | yeah but I can't fix the world | 11:12 |
| kanavin_ | well, if they're your supplier, you can fix the contract | 11:13 |
| mort | we buy some hardware from them sometimes, it's not exactly a relationship where we have a lot of power | 11:13 |
| mort | maybe I should have insisted that we use upstream for everything, that we don't use SoM vendor BSP layers but instead do the devicetree and whatever kernel/bootloader work is needed ourselves | 11:15 |
| kanavin_ | mort, that's an option too. Figure out what bits from the BSP layer you actually need, take those out into your private BSP layer, and throw away everything else. | 11:15 |
| kanavin_ | and then you have freedom from vendor deliveries. | 11:15 |
| kanavin_ | at least for the layer, you'd probably still have some old awful vendor kernel, but that's easier to make work with latest yocto | 11:16 |
| JaMa | "I couldn't use the 1.80 scarthgap recipe in kirkstone" why not? just add another mixing branch with necessary changes to make it compatible with kirkstone | 11:18 |
| mort | JaMa: right that's not using the scarthgap recipe in kirkstone, that's making a new rust 1.80 kirkstone recipe | 11:18 |
| mort | and then I might as well not have made the scarthgap one | 11:19 |
| JaMa | not new, just adjusted | 11:19 |
| JaMa | if someone already did the heavy lifting of upgrading the recipe in master, backporting to older release is much simpler task | 11:19 |
| mort | the changes from kirkstone to scarthgap seem pretty large | 11:19 |
| JaMa | then complain to your employer that your job is too hard for you, other people already backported rust from scarthgap to kirkstone and it wasn't difficult | 11:21 |
| mort | man I'm primarily a software developer, I like to write application software in Rust and C++ and Go, that's what I'm good at | 11:22 |
| mort | I do Yocto stuff because it's necessary, when it's necessary | 11:22 |
| JaMa | maybe your employer need to hire some additional person for OE work if that's not something you're interested in, but complaining that the recipe from scarthgap doesn't magically work in kirkstone doesn't help anyone | 11:23 |
| kanavin_ | mort, yes, system integration is a specialty in itself, and your company should have people dedicated to that. It's okay if you don't want to go that way, but you do need someone for that task. | 11:23 |
| JaMa | "you're not interested in" | 11:23 |
| JaMa | https://github.com/webosose/meta-webosose/commit/30ed2fbfb9836ff0536d4ccb475b088b52f65c72 really isn't that hard (and now we did the same with 1.75 recently) | 11:25 |
| mort | JaMa: we're 3 developers | 11:25 |
| mort | this isn't some huge operation with a yocto team | 11:25 |
| *** florian <florian!~florian@dynamic-093-131-063-206.93.131.pool.telefonica.de> has joined #oe | 11:25 | |
| mort | I would love to get a Yocto / embedded Linux expert who can spend all their time making everything Linux and Yocto perfect and work closely with upstream and all that | 11:25 |
| JaMa | you can pay someone familiar with OE to create the mixin layer with the versions you want (if you're not happy with existing options) | 11:28 |
| mort | or we could use rust 1.78 and upgrade when the mixin layer upgrades | 11:29 |
| mort | but neither of these options helps upstream much, upstream wants 1.80 or whatever for scarthgap | 11:29 |
| mort | (upstream meaning you guys) | 11:29 |
| mort | also, paying someone to make a mixin recipe for 1.80 wouldn't really help *us* much, my goal here isn't really to get 1.80 to work but rather to have a sustainable way to stay as up to date as possible | 11:31 |
| mort | that's why I was looking at options for using binaries distributed by the rust and go projects | 11:32 |
| *** Xagen_ <Xagen_!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 12:52 | |
| *** tgamblin_ <tgamblin_!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #oe | 12:53 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 272 seconds) | 12:56 | |
| *** dv_ <dv_!~dv@80.123.121.62> has joined #oe | 13:24 | |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has joined #oe | 13:40 | |
| smurray | mort: I’m working on updating the kirkstone/rust mixin layer to match or-core master Rust (should land next week) and plan on creating a scarthgap/rust mixin soon. That probably does not help you today, though. | 13:56 |
| mort | smurray: not today, but it's good to know. Thank you | 14:03 |
| mort | one question, to what degree is the kirkstone/rust recipes "backport scarthgap to kirkstone", and to what degree is it "port the kirkstone recipe to new rust"? | 14:04 |
| smurray | mort: it is the former, though it’s going past scarthgap on the the next update since the layer tries to track the Rust version in oe-core master. I’ve just been a bit slow on updating it now that the logjam has been unblocked in oe-core wrt Rust reproducility | 14:19 |
| smurray | mort: when I started doing the Rust mixin layers, I looked at both approaches, and backporting updates as they go into master seemed a lot less effort than banging on the old recipes | 14:23 |
| mort | I see | 14:27 |
| mort | I could see myself getting involved in backporting from oe-core in the future maybe | 14:28 |
| *** alimon <alimon!~alimon@189.172.34.118> has joined #oe | 14:45 | |
| *** tgamblin_ is now known as tgamblin | 16:17 | |
| *** florian <florian!~florian@dynamic-093-131-063-206.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 16:25 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 18:52 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:810e:b200:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection) | 20:32 | |
| *** olani- <olani-!~olani@78-66-73-195-no2814.tbcn.telia.com> has joined #oe | 21:02 | |
| *** reavertm <reavertm!~reavertm@gentoo/developer/reavertm> has joined #oe | 21:09 | |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:29 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 252 seconds) | 22:21 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 22:30 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.205> has joined #oe | 22:34 | |
| *** florian <florian!~florian@dynamic-093-131-063-206.93.131.pool.telefonica.de> has joined #oe | 23:03 | |
| *** mort2 <mort2!~mort@188.166.114.29> has joined #oe | 23:03 | |
| *** jpuhlman- <jpuhlman-!~jpuhlman@50.240.203.141> has joined #oe | 23:03 | |
| *** reichi_ <reichi_!~reichi@2a03:4000:4f:f89:dead:beef:1337:4> has joined #oe | 23:03 | |
| *** mort <mort!~mort@188.166.114.29> has quit IRC (Quit: Ping timeout (120 seconds)) | 23:04 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50.240.203.141> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 23:04 | |
| *** reichi <reichi!~reichi@user/reichi> has quit IRC (Quit: connection reset by beer) | 23:04 | |
| *** mort2 is now known as mort | 23:04 | |
| *** olani- <olani-!~olani@78-66-73-195-no2814.tbcn.telia.com> has quit IRC (Ping timeout: 248 seconds) | 23:34 | |
| *** florian <florian!~florian@dynamic-093-131-063-206.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 246 seconds) | 23:39 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!