09:03 <linusw__> arnd: I think that was a side effect of using b4 which uses get_maintainers and then post to that MAINTAINERS entry as krzk points out.

09:05 <arnd> ah, for drivers/pinctrl/spear/

09:08 <jn> avoiding addresses that get_maintainers prints out is a hassle, and should (IMHO) never be necessary. the automation should be kept in a good enough shape to use as is

09:33 <ukleinek> arnd: do you have a patch handy to compile busybox (or the whole BSP) with yocto with 64bit time support?

09:34 <arnd> ukleinek: I've given up trying to do this with glibc, but any musl -1.2.x based build gets time64 automatically

09:35 <ukleinek> arnd: can you explain in one sentence why you gave up von glibc?

09:38 <arnd> my impression was that a lot of libc developers (not all) just want to kill off 32-bit support entirely rather than make it work, and each debate about time64 just turns into making it harder to use.

09:38 <arnd> it's possible that someone has managed to do this by now, but I'm no longer following the mailing list

09:50 <ukleinek> arnd: ok, thanks

10:34 <marex> is AMS gko down again ?

10:34 <marex> seems like SIN is up, AMS not

10:59 <arnd> ukleinek: I think the difference is that for LFS there is some sense in letting an application decide to use it, but for time64, you really can't. The only sensible way to use time64 is to hardcode CFLAGS=-D_TIME_BITS=64 somewhere, either in the toolchain or distro-wide config

11:46 <broonie> marex: Yeah, ams is *super* unhappy which is really messing with -next today.

11:53 <arnd> I had problems yesterday afternoon for about an hour, but then it started working as normal again, and I assumed that someone actively fixed it

11:57 <broonie> I suspect we may have a timezone issue with getting help.

12:46 <broonie> marex: Sorted now.

13:10 <ukleinek> arnd: I don't understand, what the the upside of not using LFS?

13:11 <arnd> ukleinek: there are occasionally problems with backward compatibility

13:12 <ukleinek> arnd: as with time64?

13:13 <arnd> Debian still has a handful of packages that expose off_t in their abi, and no need to make those 64 bit because they are known to never need large files

13:13 <broonie> The increase of file sizes is less inevitable than the forward match of time.

13:14 <arnd> For time_t there is no value in changing some packages as long as you don't do all of them

13:18 <arnd> It's really about the amount of work needed to transition the abi of a library and all its users. If Debian were to go through a scheduled full rebuild like Fedora, they probably would have changed it long ago

13:20 <arnd> But as long as you maintain compatibility across releases, you need to have someone who is sufficiently motivated to do the work

13:42 <marex> broonie: nice, thank you

14:19 <broonie> marex: Thank mricon and/or his team, I suspect they'll have seen monitoring at least as soon as my message.

18:09 <ardb> broonie: will you be at connect?

18:11 <broonie> ardb: No plan for that.

18:11 <ardb> ah ok

18:11 <ardb> i'm looking for someone who might be able to help me reprogram a SOIC SPI flash chip

18:11 <ardb> i bricked my loongarch box by changing a BIOS menu option

18:12 <broonie> Ah, oh dear :(

18:12 <ardb> yeah typical :-))

18:12 <broonie> That sounds like hardware which physically exists which is kind of out of my wheelhouse these days :P

18:12 <ardb> right

18:13 <ardb> it said 'SPI' so i thought i'd check with you

18:13 <ardb> i'll check with daniel thompson as well

18:14 <broonie> Perhaps the Linaro lab people might be able to help, though I don't actually know who's still there now (Luca perhaps?)

18:14 <ardb> no idea

18:14 <ardb> i'll go and poke some people

19:15 <linusw__> ardb: I won't be there either, but SPI flash is still a flash memory, and by infering the set of MTD maintainers with the set of Linaro employees I have concluded that you want to talk to Tudor Ambarus.

21:09 <ardb> linusw__: thanks!