<SiFuh>
zorz: When I had the new tyres installed on the truck I asked them did you take the truck to get the wheels aligned. They said yes. I brought it back and said that I don't think anything has been done. So they said they will take it back. Then when I picked up the truck I said it still doesn't feel like anything has been done. So I took the truck to my friends shop and today he and I did the alignment.
<SiFuh>
He looks at me and says "No one has ever done an alignment on this truck. I can tell because everything is seized. If they did the alignment recently, it wouldn't be like this" I said "I agree"
<zorz>
ooooo I hate when people dont do correct tyre algnment!
<zorz>
totally sucks
<zorz>
and women drivers that dont know, or gen z whatever..... they damage new tyres very fast.
<SiFuh>
I don't like when they say they did it but never did anything
<zorz>
SiFuh: you know i always prefer to check the production date
<zorz>
and how it is stored
<SiFuh>
Why would I know that?
farkuhar has joined #crux-social
<SiFuh>
farkuhar: My CRUX repo server is dead
<farkuhar>
Does that mean you won't be able to recover your patches to the rc scripts?
<SiFuh>
No that's probably on the laptop. I should really get around to taking that out of storage.
<farkuhar>
What kind of long-term storage precautions do you have to take with electronics in a tropical environment? Vials of hygroscopic material to prevent moisture from getting inside?
<SiFuh>
Plastic bag
<SiFuh>
I use Pelican cases.
<farkuhar>
So, how much inconvenience is caused by your CRUX repo server being down for a while?
<SiFuh>
None, because I can transfer the drivers hoepfully to another box. But at the moment I will not because I want to use that machine for CRUX MUSL ISO build.
<SiFuh>
drives*
<SiFuh>
That machine = another box
<farkuhar>
Speaking of CRUX MUSL ... With the recent release of SDL 3.2.0, it's no surprise that SDL 1.2 has fallen off the radar. I somehow have libsdl successfully built on one CRUX-MUSL machine, but on another machine just yesterday, errors involving iconv kept halting the libsdl build.
<SiFuh>
Uninstall iconv the build libsdl and the install iconv :-P
<farkuhar>
SiFuh: musl provides /usr/bin/iconv, so that's probably better left in place. My first thought is that the successful build of libsdl was on a machine without one of the optional dependencies, and problematic code in the libsdl source tree was omitted from that first build. After months of using CRUX-MUSL, one of the soft dependencies is now present, and libsdl attempts its build with that buggy
<farkuhar>
component enabled.
<SiFuh>
"Still, predictions say that solid-state batteries will be in tech we can buy by the end of the decade." Err many of my devices are already using solid state batteries.
<farkuhar>
According to engine analysis, White has a mating line if Black goes for anything other than stalemate (by sac'ing the queen with ..Qc1+) in this position: 7k/8/6QP/p3p3/Pp2Pq2/1P3P2/1KP5/8 b - -
<farkuhar>
It's kind of obvious if you consider White's pawn advantage. ..Qf8 only helps defend against mate for a move or two, giving White the chance to advance a battery of pawns to support the attack.
<farkuhar>
The battery doesn't have to be solid-state: someone adept at blindfold chess would advance a battery of pawns that has no existence outside the mind, while someone playing in a tropical climate with chocolate-covered pawns might find them melted to liquid state by the time mate is finally forced.
<SiFuh>
I dug out the laptop
<SiFuh>
Hydrolosis of the rubber
<SiFuh>
Fan is barely doing shit and it is constantly rebooting.
<SiFuh>
It did manage to get a screen but it was checker patterened
<SiFuh>
Waited 8 minutes for it to finally tell me the CMOS battery is bad and the screen went blank and nothing has happened
<SiFuh>
Oh my goodness, I see the kernel messages. It's booting. It's alive!
<SiFuh>
farkuhar: I cannot find the latest rc modification. But I found the modification before it
<SiFuh>
I remember doing this one. You'd boot to single and back to multi and it would mount /proc and /sys again even if it was already mounted.
<zorz>
SiFuh: ask beerman to help you with rc :P
<SiFuh>
Fuck no zorz
<SiFuh>
That's way out of his league. He is just a port puppy
<SiFuh>
port-a-potty
<SiFuh>
Hahaha
<zorz>
hahahahaha
<zorz>
rusty-porty bellman
<zorz>
hahaha
<zorz>
give him the valvolines..
<zorz>
nvidia was 5% down again today, deepseek and alibaba qwen bring memories of www buble
<SiFuh>
He's just a port maintainer on an ego trip. Thinks no one does anything but himself and that the only reason CRUX exists is because he single handedly keeps the operation running.
<zorz>
oooooooooooo this is so stupid
<SiFuh>
Must be a German thing. Thinks he is god's gift to CRUX
<zorz>
crux exists because of sysvinit, kernel, and package management aka pkgmk prt-get
<SiFuh>
CRUX exists because of Per
<zorz>
exactly
<zorz>
who ever put all this together.
<SiFuh>
And it existed before Beerman was a spermy in his daddy's ball sack.
<zorz>
ηαηαηαηαηαηα
<zorz>
hahahahahahaa
<zorz>
sorry for my greek
serpente has joined #crux-social
<zorz>
you know what beerman reminds me..... yesterday i ve seen a new terminal named ghostty checked is in binaries of void and i said lets give it a try, look dependancies https://0x0.st/8KMT.txthahah. ofcourse and i did not try it.
<SiFuh>
Yeah I made a mention of it in #crux as well when I was doing it
<SiFuh>
36920 00:21:24 [farkuhar> 2022-07-30 ivandi wrote: it would be nice to have this in /etc/rc: /bin/mountpoint -q /proc || /bin/mount -t proc none /proc, same goes for sys. w/o it there is an error message when using dracut
<SiFuh>
36923 00:23:13 [SiFuh> In fact I remember the fix had a '||' because
<farkuhar>
SiFuh: I invited zorz to join in my brainstorming session with darfo yesterday on the configuration files sourced by distro tooling, and zorz remarked upon seeing the IRC log of that discussion, "it's like reading an Agatha Kristie novel".
<farkuhar>
Anyway, was the /bin/mountpoint test the only thing you wanted to add to the rc scripts?
<SiFuh>
No
<SiFuh>
I said that is the one before i did full modification
<SiFuh>
I think from 3.5 that one was
<farkuhar>
Okay. And the laptop you just resurrected doesn't have a separate partition where 3.5 is installed?
<SiFuh>
No
<SiFuh>
It had the old rc from 3.5
<SiFuh>
Or maybe 3.6
<SiFuh>
farkuhar: I think I have modified the rc scripts 4 times and only 1 one implemented 18 years after I brought it to their attention.
<farkuhar>
Okay, here's the libsdl build log on the CRUX-MUSL machine where iconv.h is causing problems: https://0x0.st/8KMn.15.log
<SiFuh>
"GL_GLEXT_VERSION" redefined
<SiFuh>
I hate reading logs where more than one core is compiling.
<farkuhar>
It's definitely weird, because I have a successfully built package libsdl2#1.2.15 dated 2024-09-03, and the musl package that provides /usr/include/iconv.h hasn't been updated since then. You think the warnings about redefined GL_GLEXT_VERSION are hinting at an opengl update changing a function signature somewhere?
<farkuhar>
Timestamps are hard to reconcile this many months after the original builds, but here goes. /usr/include/GL/gl.h is dated 2023-09-12, presumably when it was last touched upstream before being bundled into the sources for libglvnd. My built package of libglvnd#1.7.0 is dated 2024-08-18, so it would have been in place at the time of the first (successful) libsdl build, as well as now. Now I wish I had
<farkuhar>
kept the build log from the package that succeeded on 2024-09-03.
<farkuhar>
Maybe the change in function signature can be blamed on the recent mesa update instead. I should try rebuilding glu to see if that fixes the problem.
<farkuhar>
No luck after rebuilding glu. Now I'm curious whether the iconv.h provided by glibc would also lead to the same "incompatible pointer type" error ('const char **' versus 'char ** restrict')
<farkuhar>
I admire the bluntness of the upstream site, https://www.libsdl.org/download-1.2.php "SDL 1.2 is no longer supported and no longer works on many modern systems, but the source code is available for historic purposes". Given this disavowal by its own creators, maybe CRUX should consider dropping the port (and its dependents) from the opt repo?
<farkuhar>
Hmm, I need to fix 'prt-get dependent --all --recursive' in my softdeps-aware fork. Inserting the safety check for dependency cycles (when optional dependencies are also considered) was harder to accomplish in jw's C++ code than in my Perl rewrite, so for some arguments the C++ version can go into an infinite loop, even though the Perl version will terminate.
<SiFuh>
farkuhar: 3 episodes back they put a memorial for Kenny Law who passed away in 2025. The last two episodes he is still in the series.
zorz has quit [Quit: leaving]
ppetrov^ has quit [Remote host closed the connection]
ppetrov^ has joined #crux-social
<farkuhar>
SiFuh: On CRUX-glibc the libsdl build still complains about redefining GL_GLEXT_VERSION, but eventually succeeds without triggering the "incompatible pointer type" error from iconv.
<farkuhar>
Both musl and glibc define in their header file an "extern size_t iconv" with the same types for all its arguments. Is it that musl interprets the SDL code to assign inbuf the type 'const char **', but with glibc that same variable gets assigned type 'char ** restrict'? In that case, maybe it's a different header that causes the discrepancy.
<farkuhar>
Not a different header, just a failure to satisfy an '#if defined(__GLIBC__)' macro. Interestingly, this macro appears in the libsdl 1.2.15 tarball, but on the upstream GitHub repo, they're doing it differently these days: https://github.com/libsdl-org/SDL-1.2/blob/main/src/stdlib/SDL_iconv.c#L37-L38
<farkuhar>
And here I thought all the work on SDL 3.2 was stealing developer time away from the legacy 1.2 branch. But as recently as 9 months ago, the SDL_iconv.c got an update that puts it ahead of the release tarball selected by beerman for our opt port.
<farkuhar>
The legacy 1.2 branch is still getting regular updates: https://github.com/libsdl-org/SDL-1.2/commits/main . It wouldn't be unprecedented to select a specific commit (even one without a tag or a release) and have our opt/libsdl port download the tarball at that commit.
<farkuhar>
The comment that introduces all those 'if defined(__GLIBC__)' tests promises more than it can deliver: "iconv() may or may not use const char ** for the inbuf param. If we get this wrong, it's just a warning, so no big deal."
<farkuhar>
"just a warning", heh. More like: "cause for an incompatible pointer type error, which breaks the build."