07:10 <sven> 😔

11:41 <Foxboron> marcan: fwiw, manjaro is a shitshow. They just take other peoples work, remove contribution attributes and then release

11:41 <Foxboron> Their ARM ports are just stolen pkgbuilds from ALARM

11:46 <ar> and then there's the whole pine vs manjaro vs other distros thing…

11:48 <jannau> what are stolen PKGBUILDs? copied but removed attibution?

11:49 <chadmed[m]> fwiw they did credit you as the contributor for linux-asahi (or apple-silicon or whatever they call it) so thats nice of them :P

11:55 <Foxboron> jannau: yes

11:56 <Foxboron> They might have gotten better.. but previously they just took stuff from other distros and said "we made this"

12:04 <jannau> chadmed[m]: lol

12:08 <jannau> but this seems now already deleted. their testing on the m1 macbook air couldn't have that extensive given that they didn't notice that the headphone jack wasn't working

12:08 <jannau> their (v6.0-rcX) kernel config misses cs42l83

12:11 <nicolas17> is that supposed to be a commit hash?

12:11 <j`ey> no

12:11 <j`ey> its the audio codec

12:11 <j`ey> sound/soc/codecs/cs42l83-i2c.c

12:11 <nicolas17> damn obscure chip names :D

13:59 <jannau> marcan: the admac dt-bindings iommus/power-domain patch is in dmaengine next: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next

14:01 <jannau> not sure how to proceed but I git merge should be able to handle commits with the same content gracefully

14:07 <amarioguy> sven: sorry for duplicate emails, i forgot to add the first one to the mailing list :/

14:35 <sven> no worries

18:58 <JanKral[m]> Hello, I have found an issue in the asahi-installer script main.py: my free_part.size is 29999759360, self.get_size() method (main.py: L272) for default "max" option returns 29999759360 and the installer prints "Size is too large, please enter a value ...". I think this is a bug and the condition "if os_size >= free_part.size" (main.py: L281 ) should include only >.

19:01 <JanKral[m]> Should I open issue in github?

19:44 <amarioguy> btw quick question on stuff in AICv2, when it says "max irq" is that "max IRQs any variant of AICv2 will ever support" or "max number of IRQs this particular SoC can theoretically service"?

19:47 <amarioguy> (i know NR_IRQ means "number of IRQs actually used by the platform" but i'm not sure if MAX_IRQ has been static for all versions of AICv2 on all SoCs to this point (given you have to do a bitwise AND with 0xFFFF on the max_irq register i doubt it but couldn't hurt to clarify)

20:32 <jannau> JanKral[m]: please do