IRC channel logs

<azeem>youpi: I'm wondering whether the recent libc fix for makeauth / setreuid might fix the "perl programs fail to send SIGHUP to processes of the same user but which were started by a different user" I reported in february

<azeem>11:17 < azeem> right, the perl code runs setregid(105, -1); setreuid(101, -1); setresuid(-1, 101, -1) on Linux

<youpi>is that perl issue not due to https://www.gnu.org/software//hurd/open_issues/kill_setuid.html ?

<azeem>hrm yeah, probably. It was a pretty weird corner-case in the way the Debian perl Postgres wrapper was switching uids, but I guess it boils down to that, yeah

<azeem>youpi: but no, isn't the case of the above the X runs effectively as root, and the original user cannot send the signal?

<youpi>yes, it is

<azeem>my case is postgres being started as root but then set to user postgres, and then postgres cannot send the signal

<youpi>but it's essentially the question of "non-user"

<youpi>non-same-user"

<azeem>the user currently reported by ps is not able to send a signal ehre

<azeem>here*

<youpi>ah, I misread

<youpi>then maybe, yes

<azeem> https://paste.debian.net/hidden/278f8cbb was the test program

<azeem>if run that as sudo, then switch to user postgres (or uid 101 in this case) I cannot send HUP

<youpi>$ sudo /tmp/test.pl

<youpi>switching to uid 101 and gid 105

<youpi>euid: 101, uid: 101, gid: 105 0

<youpi>$ ./testrun.sh /usr/bin/perl /tmp/test.pl

<youpi>switching to uid 101 and gid 105

<youpi>Could not change user id at /tmp/test.pl line 14.

<youpi>ah, no, I don't have the patch installed in that glibc build tree

<youpi>and I forgot to sudo :)

<youpi>-bash: kill: (22371) - Opération non permise

<youpi>still couldn't

<youpi>euid: 101, uid: 101, gid: 105 0

<youpi>I'm getting that in both cases

<azeem>too bad, thanks for checking

<azeem>saves me building libc

<etno>> I remember that at some point there's been an effort to update mesa and fix the GLX invalid context issue. There was a MR opened in the mesa repo (https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/443), but the drm.h change was redirected to the linux kernel maintainers.

<etno>gnu_srs1: hi ! Any info to share about the above query ? ^^

<gnu_srs1>youpi: Maybe you should give back the build of python3.15. How to do that? BTW: We had a large power loss, but everything is OK by now.

<youpi>gnu_srs1: yes, that's part of my buidld restart process :)

IRC channel logs

2026-09-03.log