02:59 <opticron> Glanzmann, getting 110fps on supertuxkart with default settings on the underwater level, everything looks good. didn't try reboot

03:00 <opticron> the poweroff did work for me

03:03 <opticron> oooh, and you have the charge limit thresholds in there, too

03:03 <opticron> I'm excited

03:04 <opticron> I've been holding off on using this as a daily driver until I could make sure I wouldn't destroy the battery

03:04 <opticron> did that finally get merged or into asahi or are you pulling it from wip?

09:05 <Glanzmann> opticron: It got merged. This is the asahi tree that marcan yesterday released.

09:05 <marcan> I did not release anything

09:05 <marcan> you are still running pre-release software

09:06 <marcan> until it hits the `asahi` repo it is not releasexd

09:06 <marcan> I don't know how many times I have to say this...

09:06 <Glanzmann> marcan: Can you reproduce the 'reboot' hang?

09:06 <Glanzmann> marcan: Okay, let me rephrase, its the same version that you pushed to the pkgbuild yesterday.

09:07 <marcan> I did not push anything to the stable PKGBUILD branch

09:07 <marcan> which is the release branch

09:09 <marcan> at this rate I'm just going to switch to using private repos for everything because I do *not* need a bunch of altdistro guys pulling commits the minute I push them when things aren't even properly tested by the usual team and we're still fixing bugs

09:09 <marcan> y'all are worse than Manjaro

09:09 <Glanzmann> marcan: You asked us to test, we tested.

09:10 <Glanzmann> I did not push anything out to users, I just released the debs on the latest version in a tar ball in this channel.

09:10 <marcan> I asked #asahi-dev to test the `asahi-dev` packages.

09:13 <Glanzmann> I see, than let them test and we go back to sleep.

09:14 <Glanzmann> axboe had the wrong rust version btw and the gpu now also work him.

09:20 <mps> marcan: do you make tagged release and labeled as verified ok for distros?

09:21 <marcan> that's what the pkgbuilds in the `stable` branch are

09:21 <mps> aha, ok. I'm trying to stick with tagged kernels and verified

09:25 <mps> I noticed one crash of driver during boot but kernel works fine, at least for now. dmesg output is here https://tpaste.us/9MP0

09:41 <sven> and now you know why I rarely push wip branches anymore 🙃

09:42 <sven> for me it was random people asking me in /msg how to run a kernel with external display support

10:35 <chadmed> i swear we have this discussion at least once every couple of months

10:36 <ashi> So, who is the target audience for what PKGBUILDs main branch produces? Why is -alt not allowed to build that? And why is such an agressive atmosphere neccessary towards people who are just playing around, not demanding anything, not expecting anything. I am just happy to see software evolve. But you guys could be really nicer.

10:37 <ashi> There is no need to treat us like idiots, that kind of arrogance pisses me of.

10:38 <chadmed> this was all addressed last time you asked about the same thing but to reiterate the problem is absolutely not people wanting to test new and exciting stuff

10:39 <chadmed> its that time and time and time again someone distributes test builds or instructions on how to build test code to people who cannot support themselves

10:39 <chadmed> who then come here expecting to be supported, usually for some bug that is already known about and being worked on

10:40 <chadmed> s v e n getting private messages about external displays being a prime example here

10:41 <chadmed> to answer the question more directly, the target audience is people who can build, debug and support themselves through a release cycle

10:41 <chadmed> id est, developers

10:41 <ashi> I stopped doing that (sharing instructions, scripts, whatever) completely. But neither me not Glanzmann got the whole message! What we did last time was to build "random branches" without any tags, this time Glanzmann waited till there were PKGBUILDs who pointed to the exact commits or tags until he build that. I thought it was fine but again m a r c a n rant time.

10:44 <chadmed> playing both sides, sure it probably _could_ have been more explicitly stated where release/ready-to-package stuff lives but that said in what universe is the main branch of any remotely complex repo considered release-ready

10:45 <chadmed> further to that, this exact scenario happened months ago when people were trying to build linux-asahi/main, so the default asahi branch was spun out and made the default for release

10:45 <chadmed> like this exact scenario has literally happened before and it seems very little was learnt from it

10:47 <ashi> I *am* without any doubt the target audience. And I never intended to take someones time. I will try harder to understand the purpose of this channel then by reading passivly, maybe one day I get what it is for then.

10:47 <ashi> Thanks

11:21 <Retr0id> cy8aer, I guess you're talking about the glibc-widevine package? I don't maintain that, but if I had to guess it's the TLS alignment thing that's causing issues

11:22 <cy8aer> Retr0id: yep thought about this too. But thanks for your hack, I am nearby 😉

13:41 <leif> I'm just going to throw my 2 cents in here. Instead of of asking marcan whether he can reproduce an issue, why you don't you just install the arch asahi kernel on Debian? I can easily install the Arch kernel on Fedora via kernel-install (although this can be done manually as well). And also maybe think of setting up a github page (or something similar) and then moving some of the discussion over there? There's absolutely nothing wrong with

13:41 <leif> being on the bleeding edge. I personally love it. But I never ever pester the devs w/ support related questions for anything that hasn't been officially released.

13:46 <leif> FWIW, I just updated my project to the latest (ie bleeding edge) kernel, mesa, uboot...etc packages and am not not running into any reboot hang issues.

13:49 <as400> @leif I have a question. Asked this on your gh. But since you're here

13:49 <sven> yeah, usually the -dev releases are for developers who are comfortable debugging the kernel and figuring out *why* something broke. I don’t think anyone cares if you run them but if you package them for others users that becomes an issue

13:50 <as400> After installing your Fedora - can I switch to rawhide repos ? Or it's not recommended ?

13:50 <leif> as400 I'll answer your question on GH

13:53 <as400> Thanks ! Appreciate it.

14:17 <leif> hmmm...it can be issue, but it can also be extremely productive. I've sent a number of bugfixes and bugreports upstream for various issues that either myself or users of my project encountered.

14:32 <leif> Like everything in life, it's a balancing act. It is helpful to attract users -- as long as they're the right kind of users ;)

15:11 <marcan> right, the problem here is all the timewaster reports, not that people are running things at all

15:12 <marcan> "reboot doesn't work"... okay, debug it? give me repro instructions that don't involve "install my debian spin"?

15:12 <marcan> because that kind of stuff is 99% going to be some systemd nonsense or a missing kernel module, not something actually broken in the kernel

15:12 <marcan> (and Glanzmann has quite the history of forgetting to enable kernel modules)

15:14 <marcan> it's a dev release and I *already* have known real issues to figure out like kernel oopses, and known problems like stale DT patches, and a bunch of things we already found and fixed in like the first few hours after I started tagging 6.2 kernels

15:15 <marcan> when we are already halfway through chasing bugs between the folks who are knee deep in this stuff and know how to debug the kernel, random third party reports are most likely going to be 1) dupes, or 2) not actionable, or 3) lower priority

15:15 <marcan> and you can't know which and it's just much easier if you wait

15:16 <marcan> once *we* run out of kernel issues to fix *then* you can start reporting whatever ones you have left

15:20 <marcan> also PKGBUILDs repo now has stable as main and `dev` for dev, so there you go

15:22 <tpw_rules> marcan: not sure if this was deliberate to better reflect support level, but the new main branch is now several months before where the old stable branch was

15:22 <marcan> tpw_rules: I just fixed that

15:22 <tpw_rules> ninja'd? thanks

16:56 <marcan> like in particular these kinds of pings are just so *blatantly* a waste of my time I have no idea why Glanzmann insists on annoying me like this

16:56 <marcan> 02:33:59 < Glanzmann> marcan: Mesa does not build on Debian: https://pbot.rmdir.de/u/5w4beZcHH9vh7esDTfn3gw

16:56 <marcan> 03:04:50 < Glanzmann> Disabling freedreno let me compile mesa. Kernel boots, xorg starts.

16:57 <marcan> if you cannot look at a build failure and determine it has *nothing* to do with me before pinging me on IRC, you should not be running a distro remix period.

16:59 <marcan> I really, really shouldn't have to tell him that a lua parse error in a freedreno script (????) has nothing to do with us, and that he shouldn't be building freedreno at all if he's making asahi-specific packages (nor any other driver other than asahi and llvmpipe/swrast, like we do in our PKGBUILD)

16:59 <marcan> I'm not Glanzmann's nor any one else's personal "debug my packages" guy, sorry

17:00 <marcan> so yes, this kind of stuff is why I get annoyed

17:02 <marcan> not just people testing stuff and being quiet about it or reporting actual actionable stuff when the time comes, that's fine

17:13 <marcan> just to be clear, being a newbie and getting things wrong is also fine

17:14 <marcan> Glanzmann doesn't seem to have learned in a year+, unfortunately

17:17 <marcan> but on more general terms: our job is to get the hardware supported, and to help official distros figure out how to do things properly. alt distro remixes are fine *as long as* they are maintained by people who can actually do that without bugging us about things unrelated to hardware support.

17:18 <marcan> alt distro remixes have very little long-term value, just like the official ALARM remix does. our job is to make that remix stop existing, *and so should be yours* if you are doing the same for another distro

17:18 <marcan> if you are getting stuff upstreamed, that has real value

17:21 <marcan> but if you aren't, you should consider your altdistro a fun project you do for your own sake, not something we have to support in any way, and *definitely* not something we're going to help you with outside Mac-specific stuff, because just no. there are other avenues for learning how to do this stuff.

17:22 <marcan> and if you can't get stuff upstreamed, maybe pick a different distro (like we are, after ALARM has shown itself too unmaintained to work well nevermind upstream stuff to)

17:24 <marcan> we're the wrong people to ask for help about packaging stuff anyway, it's not what we do

17:25 <as400> Well, actually entire alarm thing is a really sad story.

17:25 <marcan> it is

17:25 <marcan> but what are we going to do?

17:25 <as400> I've been hit hard with numerous bugs.

17:26 <as400> It seems like very few distros have a strict QA procedures.

17:28 <marcan> I don't think ALARM has any QA, given what I've seen

17:29 <marcan> as far as I can tell it's mostly a pile of undocumented/nonpublic scripts running things mostly on their own, which work most of the time but sometimes fail horribly

17:30 <marcan> unfortunately the lack of documentation/public repos/infra means we can't even try to help

17:31 <as400> It's really extremely strange there is no public repos/docs. Like they don't want people to help ? Hard to understand for me.

17:32 <marcan> I think ALARM suffers from a particularly bad combination of historical laziness around having an open process (at best, or maybe they actively want to hold their cards close for some reason?) and recent serious decline in free time the maintainers have to maintain

17:32 <marcan> resulting in, well, an unmaintained bitrotting distro that nobody else can help with

17:33 <marcan> nor fork in any meaningful way

17:35 <marcan> I did have a promising conversation with the main developer when this whole thing all started, but I think since then he's stopped caring about us because he just doesn't have the time to maintain a distro for raspberry pis, nevermind a desktop distro people use on real desktop-class machines

17:35 <marcan> so there's nothing much for us to do other than move on at this point, unfortunately

17:36 <marcan> good news as I've said is we have a distro with proper upstream developer support coming up :)

17:37 <as400> Understandable. And sad. But you guys shouldn't be fighting all sorts of problems that distro is presenting. Yeah I know :) And it's number is 38, right ? :)

17:38 <marcan> well, we aren't for the most part

17:38 <marcan> I'm making no attempt to fix their broken packages etc

17:38 <marcan> going there would be a bad idea

17:38 <as400> It would just suck you in big time.

17:38 <marcan> yup

17:39 <marcan> like I really wish I had free time but I just *don't*

17:39 <handlerug> I'd really love its number to be 3.17 but glibc monopoly :(

17:40 <marcan> I'm at the point where I'm thinking of giving up on yet another personal hobby project I hold dear (that doesn't even take much of my time) because I just can't find the time for it

17:40 <marcan> I've already cut down on a lot of random personal stuff since Asahi started

17:40 <as400> I can imagine it's hell of a job.

17:40 <sven> just don’t burn out please!

17:41 <marcan> I *like* what I'm doing here and I really want the project to succeed and get us where I know we can get to

17:41 <sven> (easier said than done unfortunately)

17:41 <marcan> and yes, I take care not to outright burn myself out, I've done okay so far

17:41 <marcan> but I'm just saying, the answer to the question "do I have time for X" where X is not core to the project goals is just, no I don't, unfortunately

17:45 <marcan> today I was talking with a friend who is giving me a hand setting up a personal task board thing because I just have way too much stuff to keep in my head right now

17:45 <marcan> I might spend tomorrow setting all that up and writing a stupid python script to scrape asahi@ into a patches dashboard, so I can join the I-have-a-boutique-kernel-patch-tracker club too :p

17:49 <sven> lol, I just have a filter to put then in a separate mailbox :D

17:49 <sven> *them

17:49 <marcan> I have that but mail just doesn't cut it any more

17:50 <marcan> I just *cannot* keep track of patch emails any more, my inbox rarely goes under 500 and email is just horrible in every way for all the reasons we all know

17:51 <marcan> so the point of said script would be to scrape high-level attributes from those emails (like coalescing patch versions into one item, logging the last activity / last patch send timestamps, who sent them, automatically detect merges for those maintainers that bother replying with that, etc.)

17:51 <marcan> hopefully with that I can get the upstreaming train rolling smoother than it has so far

17:54 <steffen[m]> So something like patchwork?

17:54 <marcan> yes but less stupid and that actually does what I want

17:55 <handlerug> or patchew

17:56 <handlerug> side note: this would work well as a patch-oriented email client

17:56 <marcan> I don't care about having a frontend for things, I end up having to use email anyway. I just want an easy dashboard that tells me what I need to do next and what is getting stale and what needs a rev/resend/etc.

17:58 <marcan> most of these tools seem oriented towards maintainers, *receiving* patches

17:58 <marcan> there doesn't seem to be much oriented towards submitters *sending* patches

17:58 <marcan> or people overseeing a bunch of others sending patches on their own

17:59 <marcan> honestly I think what we're doing here is surprisingly unique as far as kernel dev goes

17:59 <marcan> (and my maintainer role is trivial enough - the soc stuff - that I don't need tooling)

18:01 <marcan> anyway, I need to wake up early tomorrow, good night :p

19:03 <opticron> glanzmann: fwiw, the charge limiter didn't seem to work properly. I set it to 85% just like my current daily driver and it charged up past 90%

20:18 <mps> nice, after upgrade u-boot asahi 2023.01-3 no more driver crash (I reported above) on kernel boot