IRC channel logs

<Arsen>ACTION hopes that HTL does not assume that pthread_t is an int, so that he may use a pointer to the TCB as pthread_t

<nexussfan>reading irc chat logs about xlibre in this channel, most of it is about either politics (unrelated to software) or about how the author added nothing new, which is untrue (Xnamespace)

<Arsen>it is delusional to claim that you can abstain from politics..

<Arsen>heh, seems that HTL must be used outside of libc, and NPTL inside libc

<nexussfan>Arsen: Explain to me how the ideology of a maintainer changes the quality of a project's code.

<Arsen>directly affects how they interact with contributors and vice-versa, ergo affecting the code

<nexussfan>Only if those other maintainers are politically polarized and care about something unrelated to softwaredev, which Xlibre maintainers don't because it's a bad thing to do that in SOFTWARE.

<Arsen>untrue

<Arsen>on both counts

<Arsen>"This fork was necessary since toxic elements within Xorg projects, moles from BigTech, are boycotting any substantial work on Xorg, in order to destroy the project, to eliminate competition of their own products. Classic "embrace, extend, extinguish" tactics." this is from xlibres website, it has clear political undertones

<Arsen>"This is an independent project, not at all affiliated with BigTech or any of their subsidiaries or tax evasion tools, nor any political activists groups, state actors, etc. It's explicitly free of any "DEI" or similar discriminatory policies. Anybody who's treating others nicely is welcomed." as does this

<Arsen>"Together we'll make X great again!" I don't even have to say

<nexussfan>they don't have a code of conduct for a reason :P

<Arsen>no, they do have a code of conducts

<nexussfan>And IBM/RedHat/fd.o is trying to kill xorg

<Arsen>they have a reactinary statement in its place

<Arsen>incorrect

<Arsen>nobody is "trying" to kill xorg, xorg is just not fit for modern hardware and ergo is bleeding devlopers

<nexussfan>No, they are stopping development from Xorg to Wayland.

<nexussfan>When Wayland still has lots of issues

<Arsen> 01:07:57 <Arsen> nobody is "trying" to kill xorg, xorg is just not fit for modern hardware and ergo is bleeding devlopers

<nexussfan>Arsen: I'm using XLibre on modern hardware.

<Arsen>anyway, the above was to disprove "which Xlibre maintainers don't because it's a bad thing to do that in SOFTWARE" - they're (singular) clearly very political

<nexussfan>"they're (singular)" Metux is not the only maintainer

<Arsen>they alone wrote those paragrafs

<Arsen>to disprove the former, politics directly affect the shape and norms of a community, which directly shapes interactions with contributors before politics are ever involved

<Arsen> 01:08:51 <nexussfan> Arsen: I'm using XLibre on modern hardware.

<Arsen>yes, and many people run windows 11 on netbooks

<Arsen>doesn't make it fit poorly

<nexussfan>I actually don't have any performance issues though, or any issues at all!

<Arsen>I'm glad to hear that

<Arsen>I have mixed-dpi and mixed-refresh-rate monitors, so I can't relate

<Arsen>I also resize windows frequently

<nexussfan>what is the problem with resizing windows in x11?

<Arsen>anyway.. I have an actual HTL-related question: in what scenario would the condition (__pthread_kill != NULL && GL (dl_pthread_threads) != NULL) be false? when libpthread isn't linked in?

<Arsen>(from raise.c)

<Arsen>I especially question the latter, because that isn't present if pthread is part of libc

<Arsen>nexussfan: X doesn't bother to wait for draw commands following a window resize, ergo it can flash/be filled with garbage

<Arsen>I don't blame it, with how the X protocol works that'd have been impractical

<Arsen>wrt the HTL question: I am also not sure why the latter check is useful? dl_pthread_threads isn't even used

<Arsen>aha, nevermind, I see it now, it's used indirectly by __pthread_kill in the hurd implementation

<Arsen>eh, whatever, I'll get pthread_in_libc=yes working later

<Arsen>heh, sysdeps/posix/sigwait.c seems to be dead code? I don't see any port using it

<youpi> Arsen: glibc is also used as base for some ports such as kfreebsd etc.

<Arsen>ah, kfreebsd is maintained out of tree?

<youpi>yes

<Arsen>ahh, I see, I thought it just got removed

<Arsen>would you happen to know where its upstream is?

<Arsen>NVM, found it on nongnu savannah

<Arsen>yeah, do_sigitid definitely appears to be a typo

<Arsen>ACTION rubs eyes..

<Arsen>copy-pasto perhaps.. that looks like it could've been do_sigwait at somepoint

<Arsen>(that = do_sigitid)

<Arsen> https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/mach/libc-lock.h hm, at a glance I don't see anything mach-specific here, why isn't this the generic implementation?

<youpi>because nobody yet took the time to clean it

<Arsen>fair enough

<Arsen>I can try consolidating it with the NPTL/Linux one at some point

<Arsen>... I'd do it tonight but it is getting quite late

<nexussfan>Is there CMake cross compile for hurd?

<nexussfan>Is there a way to fix the "X Error of failed request: GLXBadContext" error on Hurd with X

<damo22>VESA does not support opengl afaik

<damo22>but it should allow swrast

<damo22>maybe do a web search for "force swrast in X"

<jab>well my well I am continuing to try to get my T60 to work properly.

<jab>I've put a brand new SSD (samsung) in there.

<jab>And I keep getting their weird error messages that suggested that I was having some filesystem corruption. But I wasn't doing anything! It was a fresh install.

<jab>At present, my T60 is using "compatibility" in the BIOS. I'm going to try to see if I can switch the BIOS to "SATA" and see if rumpdisk will boot the ssd.

<jab>alright. fingers crossed. I set up the hurd to try to boot via SSD.

<jab>wish me luck!

<jab>it's booting now....

<jab>WARNING: 6 errors while detecting hardware: check system log.

<jab>ext2fs: part5:hd0: No such device or address.

<jab>that's weird...I know I ran:

<jab>and it seems that the boot is stopped.

<jab>I ran this command: sed -i 's/hd0/wd0/g' /etc/fstab

<jab>and I added "noide" to mach's command line.

<jab>but then why am I seeing hd0 ?

<jab>well let me boot via the installer cd and see if I actually changed /etc/fstab

<jab>oh, /etc/grub/grub.cfg had "hd0" duh. I missed that.

<jab>ok that wasn't it.

<jab>ex2fs: part:5:device:wd0: Nu such device or address

<jab>maybe rumpdisk is not detecting the SSD ?

<jab>I'm thinking that we should have by default multiple boot options in grub

<jab>"Debian GNU/Hurd w/ rumpdisk"

<jab>"Debian GNU/Hurd " etc.

<jab>I can't even seem to boot the installer cd image, with the BIOS is set to compatibility...

<jab>I see an error something like linux-glue/src/... I guess I need to tell it to boot via noide too.

<jab>I wonder if I need to change my last line of /etc/fstab

<jab>/dev/hd2 /media/cdrom0 -> /dev/wd2 /media/cdrom0

<jab>I feel like the answer is no.

<Arsen> https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/mach/htl/pt-block.c#L35 this seems wrong - that ought to be #define RETURN(val) return; no?

<Arsen>on that note, what does __pthread_block wait for? if anything

<youpi>It's not wrong, it's related to RETTYPE

<youpi>which is void if not specified otherwise

<youpi>as it names suggests, pthread_block blocks the thread

<youpi>and it's up to the caller to know when to unblock it

<jab>I'm trying to add "noide" to the grub prompt on the installer cd image. So that when I boot, linux hard drive device drivers will be disabled and rump should have an easier time of probing the SSD disk.

<jab>I guess I'll try pressing e on Pseudo-graphical install'

<jab>and changing the first line to

<jab>set options="GTK_NOVESA=1 VGA_OPTIONS=--font-width=9 noide"

<jab>and try booting that way

<jab>if that doesn't work, I'll ask damo22 for suggestions on which hard ware to buy and/or try crosshurd

<almuhs>jab: the T60 has a issue with rumpkernel, which doesn't detect the harddisk in AHCI mode. This is not a boot config issue, it's a rumpkernel bug

<almuhs>you only can boot with "compatibility" mode and the old harddisk driver integrated in gnumacj

<almuhs>*gnumach

<almuhs>compatibility mode emulates the IDE interface

<almuhs>so in this mode, the OS see the SATA interface as a IDE interface

<jab>ok, that's good to know. I'll try booting a hard drive on the T60 then. I didn't have much luck with "compatibility" and an SSD.

<almuhs>but the rumpdisk's IDE driver is broken too

<jab>though I did just buy this SSD. It is brand new. Maybe rumpkernel doesn't support it yet... *shrugs shoulders*

<almuhs>I got to boot a T410 with rumpdisk

<almuhs>but the T60, R60e, T61i... all have this bug

<almuhs>but we doesn't know the cause

<jab>410 with rumpdisk sounds like fun!

<almuhs>we only know that in these models rumpdisk doesn't detect the SATA interface, both in CD unit and HDD

<jab>I'm using a librebooted T400. I should install the Hurd on my spare SSD today. That would be an experiment.

<almuhs>in T410 I even got to boot a SSD in AHCI mode

<jab>I'll buy a T410 at some point then. I've got a T510 right now, but the keyboard won't let me press enter. *shrugs shoulders*

<almuhs>but only works without SMP... another bug with unknown cause

<almuhs>if you try the smp gnumach in T410, then rumpdisk doesn't works

<almuhs>with same error: doesn't detect the interface

<almuhs>the keyboard in these models is very fragile

<almuhs>but usually are cheap to buy

<jab>that's so weird!

<jab>we're lucky to have damo22 on the Hurd team. :)

<almuhs>you can buy a new keyboard in ebay or aliexpress

<almuhs>and it's very easy to replace

<jab>I'll probably buy another T510's keyboard and try that.

<jab>and now that I know the T410 works, I'll buy one of those too.

<almuhs>i have a bunch of Thinkpad to try Hurd ;)

<almuhs>in each driver update I try again

<almuhs>and in every new image

<almuhs>i have a x220 too, but the HDD doesn't fits: so much thick

<almuhs>the x220 slot is only for SSD

<jab>does the x220 work on the hurd?

<jab>I will create a table in the wiki about what the hard is, what works, date tested.

<jab>That would be a great idea!

<almuhs>i can't test it yet

<jab>I could also test Xen. That's what Samuel uses. I'm sure that works fine.

<Arsen>what are the semantics of __pthread_block ( https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/mach/htl/pt-block.c ) meant to be exactly? the users talk about messages, which makes me think it doesn't really have special semantics and should just behave like a mach port

<Arsen>interesting, the current hurd image locks up after a few seconds of use for me

<Arsen>the font changes in the QEMU display, and typing stops working

<Arsen>(namely, https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz )

<Arsen>my goal was to test https://dev.gentoo.org/~arsen/ct.c

<jab>well that was trippy!

<jab>I popped out the ssd from the T60 that had hurd installed on it, but with LOTS of filesystem corruption. I put that ssd in my T400. Surprizingly, the hurd booted on my T400 and rumpdisk worked! But the filesystem corruption was so bad, that upon "sudo shutdown now" -> I got a error message "Filesystem not correct. Press root password for maintence or press control D."

<jab>I then tried to use the installer cd on my librebooted T400. The installer cd didn't ultimately work. It got stuck at a usb port or something. I even tried "export install" and "text install", they both failed.

<jab>so now that I know that a 32 bit hurd & rumpdisk will run on my T400, maybe I'll try crosshurd. And maybe even the amd64 hurd!

<Arsen> https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/hurd/htl/pt-kill.c#L36 this seems wrong - that should be return -1 with a __set_errno before it I believe

<Arsen>(ditto for the _hurd_raise_signal call later)

<Arsen>I say this because this is directly aliased as pthread_kill and ergo should behave as specified for pthread_kill which is (as a general posix maldesign) to set the global variable and return -1

<youpi>Arsen: no, pthread functions always return the error value

<Arsen>ACTION facepalms

<Arsen>you're right, I misread the linux man-page for it

<Arsen>it is getting late here

<Arsen>{ return ENOSYS; } ah, the perfect implementation

<nikolar>it's perfectly predicatble

IRC channel logs

2025-10-24.log