14:12fdobridge: <conan_kudo> I _want_ what you say to happen for 2, because that's the only way for rust to mature into "spec first" rather than "rustc first"
14:12fdobridge: <karolherbst🐧🦀> I don't
14:12fdobridge: <conan_kudo> the whole reason other rust compiler implementations have died off is because of this problem
14:13fdobridge: <karolherbst🐧🦀> I don't see how a spec could have helped
14:13fdobridge: <karolherbst🐧🦀> it's not a magical thing which makes other projects work
14:13fdobridge: <conan_kudo> no, it's the governance around the spec that matters
14:13fdobridge: <karolherbst🐧🦀> rust is at an impressive pace
14:13fdobridge: <karolherbst🐧🦀> others can't really keep up unless they get proper funding
14:13fdobridge: <karolherbst🐧🦀> and a spec won't really change that
14:14fdobridge: <karolherbst🐧🦀> I see the pain compilers do to C already, and it's a pain to support them all as they all do something different in annoying ways
14:15fdobridge: <karolherbst🐧🦀> I don't want to see projects with huge if else statements because 5 compilers do things in 5 different ways
14:15fdobridge: <karolherbst🐧🦀> and that exists even though C is speced
14:15fdobridge: <karolherbst🐧🦀> that a spec would help with alternative implementations is wishful thinking at best
14:16fdobridge: <karolherbst🐧🦀> as it doesn't solve any of the other problems around writing an alternative rust compiler
14:17fdobridge: <conan_kudo> man, all I _have_ for most things is wishful thinking
14:17fdobridge: <karolherbst🐧🦀> yeah.. fair enough 😄
14:17fdobridge: <karolherbst🐧🦀> I mean.. I totally get the idea and everything
14:17fdobridge: <karolherbst🐧🦀> I just don't think it actually gives us anything at this point in time
14:17fdobridge: <conan_kudo> hell, a good nouveau was wishful thinking for ten years
14:17fdobridge: <conan_kudo> and now here we are
14:17fdobridge: <conan_kudo> on the cusp of it
14:18fdobridge: <karolherbst🐧🦀> yeah... I don't say we won't have proper alternative rust compilers in 10 years
14:18fdobridge: <conan_kudo> we need the painful baby steps to get there
14:18fdobridge: <karolherbst🐧🦀> but I don't think a model like "do whatever rustc is doing" is wrong
14:18fdobridge: <conan_kudo> otherwise it never happens
14:18fdobridge: <karolherbst🐧🦀> heck.. OpenGL is "do whatever nvidia is doing" even though it does have a spec 😄
14:18fdobridge: <conan_kudo> it's not wrong now, but it's a problem when rust documentation tells you one thing and the compiler tells you another
14:19fdobridge: <conan_kudo> yeah, don't remind me
14:19fdobridge: <karolherbst🐧🦀> ahh yeah.. well.. that's bad, but same would happen with a rust spec
14:19fdobridge: <conan_kudo> sure, but the answer I get when that happens is "meh"
14:19fdobridge: <karolherbst🐧🦀> yeah..... that's not great
14:19fdobridge: <conan_kudo> I'd rather it be "oh crap, we should do something about it"
14:19fdobridge: <karolherbst🐧🦀> well.. you can also just fix the doc instead 🙃
14:19fdobridge: <karolherbst🐧🦀> but yeah...
14:20fdobridge: <conan_kudo> and hey rust 1.73 broke firefox 😄
14:20fdobridge: <karolherbst🐧🦀> the project is a bit too pragmatic at this point in time, but I also don't think it's necessarily a problem
14:20fdobridge: <karolherbst🐧🦀> 😄
14:20fdobridge: <conan_kudo> and hey rust 1.73 broke firefox 🙃 (edited)
14:20fdobridge: <karolherbst🐧🦀> funky
14:20fdobridge: <karolherbst🐧🦀> at runtime or compile time?
14:20fdobridge: <conan_kudo> yes
14:20fdobridge: <karolherbst🐧🦀> at least there are patch releases to fix those issues
14:20fdobridge: <conan_kudo> it also seems to have incomprehensibly broken kernel-asahi
14:21fdobridge: <karolherbst🐧🦀> mhhh
14:21fdobridge: <conan_kudo> so thumbed it down in bodhi
14:21fdobridge: <karolherbst🐧🦀> what broke btw?
14:21fdobridge: <conan_kudo> https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=34b8d13b298f3cf711e08433eb04d2e3
14:21fdobridge: <conan_kudo> and for firefox, simd crate is broken now
14:22fdobridge: <karolherbst🐧🦀> sounds like it's this? https://github.com/rust-lang/rust/pull/113199/
14:23fdobridge: <karolherbst🐧🦀> but yeah... those things shouldn't happen
14:23fdobridge: <karolherbst🐧🦀> but compilers bug do exist
14:23fdobridge: <conan_kudo> rust still doesn't make sense to me so it's goop to me
14:23fdobridge: <karolherbst🐧🦀> well.. it helps with programming non broken software, so there is that
14:23fdobridge: <conan_kudo> right, the problem is that the response to those kinda sucks right now because of how things are treated
14:24fdobridge: <karolherbst🐧🦀> yeah.. I won't deny that there are leadership problems...
14:25fdobridge: <conan_kudo> and no competition == no incentive to improve
14:25fdobridge: <karolherbst🐧🦀> ohh btw.. it's using an unstable feature
14:25fdobridge: <karolherbst🐧🦀> so you can expect things to break
14:26fdobridge: <karolherbst🐧🦀> did firefox use unstable features?
14:26fdobridge: <conan_kudo> nope
14:26fdobridge: <karolherbst🐧🦀> okay...
14:26fdobridge: <conan_kudo> that snippet is a repro from the asahi gpu code
14:27fdobridge: <karolherbst🐧🦀> yeah.. but that's unstable, so things can break at any updated
14:27fdobridge: <conan_kudo> sure, but @marcan couldn't figure out how to fix it
14:28fdobridge: <conan_kudo> so now I need to update kernel-rust accordingly
14:28fdobridge: <conan_kudo> so now I need to update rust-kernel accordingly and use it once 1.73 lands (edited)
14:28fdobridge: <karolherbst🐧🦀> yeah... I don't think that the kernel-rust experience will be great as long as unstable features are required
14:28fdobridge: <karolherbst🐧🦀> probably settle once all the things are in
14:29fdobridge: <conan_kudo> I don't like r4l very much right now because of how they're (not) stabilizing anything
14:29fdobridge: <conan_kudo> I don't like r4l very much right now because of how they're not stabilizing anything (edited)
14:30fdobridge: <karolherbst🐧🦀> yeah...
14:30fdobridge: <karolherbst🐧🦀> I don't suspect it's going to be way better until 2025
14:31fdobridge: <karolherbst🐧🦀> but anyway.. breaking users using only stable and not fixing it, is kinda bad...
14:31fdobridge: <karolherbst🐧🦀> does firefox work with .74 or .75?
14:31fdobridge: <karolherbst🐧🦀> ohh wait.. those aren't released yet
14:32fdobridge: <karolherbst🐧🦀> but anyway.. what broke there, because I can't really find anything, and other distributions seem to ship firefox + rust-1.73
14:46fdobridge: <conan_kudo> https://bodhi.fedoraproject.org/updates/FEDORA-2023-e29b93e24d
14:54fdobridge: <karolherbst🐧🦀> ahh okay.. so the firefox fail is also using unstable features
14:55fdobridge: <karolherbst🐧🦀> so yeah.... I mean... the path forward is then to stabilize those features, and I guess using features which are documented as unstable and expected to break is kinda what people signed into here
14:56fdobridge: <karolherbst🐧🦀> is there a firefox patch which can be backported already for this?
14:59linkmauve: conan_kudo, Linux is explicitly only supporting a single version of rustc, and will continue to do so until it doesn’t use any unstable feature.
14:59linkmauve: There is nothing to fix, just keep using the supported version of the toolchain instead of moving to newer ones expecting unstable features to stay frozen in time.
15:06fdobridge: <karolherbst🐧🦀> yeah.. this all sounds to me like "distributions are doing things they shouldn't"
15:06fdobridge: <karolherbst🐧🦀> or projects in case of the firefox issue
15:06linkmauve: Or users expecting to build with whichever toolchain their distribution provides, rather than the documented supported version by upstream.
15:07karolherbst: yeah.. I don't use fedoras rustc, I just use rustup, because that works and I won't have to deal with issues
15:07linkmauve: Distributions picking one version to ship isn’t much of an issue, since it’s trivial to install any other version with rustup.
15:07karolherbst: debian are shipping two rustcs anyway
15:08linkmauve: Super old one and normal old one? :D
15:08karolherbst: one whatever they stabilized on, and the other to build firefox ESR
15:08linkmauve: Ah yeah makes sense.
15:08karolherbst: I decided to not jump far ahead of what firefox ESR requires, so debian folks won't shout at me
15:10karolherbst: Fedora and others should do the same for the kernel.. probably
15:11karolherbst: the rust package kinda feels useless to ship anyway, as developers will most likely use rustup anyway
15:11karolherbst: and my suggestion is to never use distribution rustc anyway
15:12karolherbst: shipping firefox as distribution packages will be a thing of the past going forward anyway as I suspect it will be one of the things we only see as flatpacks/snaps anyway
15:41fdobridge: <marcan> they can't though? it's not like r4l can magically get Rust to stabilize features they need. it's up to Rust, not r4l.
15:41fdobridge: <marcan> saying that sounds like r4l is gratuitously using unstable features for no reason, but I'm pretty sure that's not it
15:42fdobridge: <marcan> the only way to get Rust to care about this stuff is to... use it
15:42fdobridge: <marcan> so it's either that or just... no r4l
15:43fdobridge:<conan_kudo> shrugs
15:44fdobridge: <conan_kudo> it's not entirely r4l's fault, sure
15:44fdobridge: <karolherbst🐧🦀> I think the point here is, that it's all fair game behavior on rusts side
15:44fdobridge: <karolherbst🐧🦀> they broke unstable features as it's their right to do
15:44fdobridge: <karolherbst🐧🦀> so I don't see how they could have reacted in any other way
15:44fdobridge: <karolherbst🐧🦀> or why they should have reacted differently
15:45fdobridge: <karolherbst🐧🦀> those things are unstable for a reason
15:45fdobridge: <marcan> usually unstable features break compatibility, or they get removed, they don't just stop working as intended
15:45fdobridge: <karolherbst🐧🦀> and unstable compiler/language features are a great way to get developers feedback
15:46fdobridge: <karolherbst🐧🦀> yeah... they should at least break at compile time if at all
15:46fdobridge: <karolherbst🐧🦀> not at runtime only
15:46fdobridge: <marcan> like if they intend to remove that const stuff (which it kind of sounds like they do) they should... remove it
15:46fdobridge: <marcan> not just break the compiler so it stops working
15:47fdobridge: <marcan> that would at least signal intent
15:47fdobridge: <karolherbst🐧🦀> yeah.. though that const trait stuff is kinda a painful thing
15:47fdobridge: <marcan> it does break the compile, just with an error which makes no sense because it contradicts the code
15:47fdobridge: <karolherbst🐧🦀> yeah...
15:48fdobridge: <karolherbst🐧🦀> could be they screwed up there, I didn't dig into it that deeply. Just that using unstable features also includes dealing with nonsense like this, sadly
15:54fdobridge: <karolherbst🐧🦀> maybe this fixes it? https://github.com/rust-lang/rust/pull/116058
15:55fdobridge: <karolherbst🐧🦀> ehh that's something else
15:55fdobridge: <karolherbst🐧🦀> but anyway...
18:53gfxstrand: dakr: Are you aware of any fence use-after-free errors in nouveau that you may have fixed in the last month or two?
18:54gfxstrand: I'm getting a refcount underflow in nouveau_fence_unref() coming from nouveau_exec_job_free()
18:54dakr: gfxstrand: Yes, there was a fix for this, let me quickly find a link.
18:55dakr: https://lore.kernel.org/lkml/20230829223847.4406-1-dakr@redhat.com/
19:10gfxstrand: Okay, I think I'm going to just run drm-misc-fixes and see if it works
19:21gfxstrand: drm-misc-next-fixes, actually
19:28fdobridge: <airlied> Run drm misc fixes
19:29fdobridge: <airlied> Misc next fixes isn't an active tree right now
19:29gfxstrand: ah
20:29fdobridge: <gfxstrand> I should probably figure out GSP
20:29fdobridge: <gfxstrand> That would make these dumb sync tests run faster
20:31fdobridge: <airlied> the oom still isn't sorted, need to get back to it
20:36fdobridge: <airlied> for doing anything that isn't running CTS GSP is probably fine, but CTS runs will die
20:42fdobridge: <gfxstrand> Well, survived a `dEQP-VK.synchronization.*` run. Time to try mustpass again.
20:44fdobridge: <airlied> yeah it'll go for ages and then gsp will randomly run out of RAM
20:47fdobridge: <gfxstrand> 😭