IRC channel logs

<damo22>i686-linux-gnu-gcc: error: unrecognized command-line option ‘ -ftrivial-auto-var-init=pattern

<damo22>im using gcc-10

<Gooberpatrol66>sneek: later tell almuhs did you record the hurd new years party

<damo22>youpi: it took 4min 16 seconds to cross compile 32 and 64 mig and gnumach with one specific configuration on my build server using 1 core

<damo22>i can parallelise the server to 2 cores

<damo22>so i guess it can take ~9 minutes to do a full build with 4 configurations

<damo22>i havent got the qemu test suite working yet

<nexussfan>Gooberpatrol66: Yes it was recorded

<Gooberpatrol66>do u have a link to it?

<nexussfan> https://www.youtube.com/watch?v=ik86RA9AAdI

<nexussfan>the video quality is really bad though

<Gooberpatrol66>thx

<damo22>Testsuite summary for GNU Mach 1.8 TOTAL: 12# PASS: 12

<damo22>\o/

<damo22> https://code.zammit.org/damo22/gnumach-sv/actions/runs/12/jobs/2/attempt/1

<damo22>20 minutes to run a commit e2e with 8 configurations

<damo22>including the test suite

<nexussfan>> Waiting for a runner with the following label: self

<damo22>yeah some are still running

<nexussfan>Also you should not have everything in one step

<nexussfan>If you seperate it you can then combine the i386 and x86_64 jobs together

<damo22>no its better to have 32/64 separated

<nexussfan>No, I mean through a matrix

<damo22>i am using a matrix

<nexussfan>Why do you have 2 jobs i386 and x86_64 then? Just combine them and add it as part of the matrix

<damo22>no because there are different params for 32 and 64

<nexussfan>Use if then

<nexussfan>For example

<nexussfan>> if: matrix.target == 'debian'

<damo22>thank you for your feedback, this is my first attempt at ci

<damo22>and its working

<damo22>on self hosted infra

<nexussfan>It could be made a bit better but it works for now

<damo22>patch welcome

<nexussfan>You can't really create an account here

<damo22>correct, its my personal one

<damo22>the main thing is we can all see the logs

<nexussfan>Obviously

<nexussfan>Otherwise it would be impossible to debug

<damo22>its not obvious, i could have made only me see the logs

<nexussfan>IIRC that isn't a feature with forgejo

<damo22>cool! i just rebased my branch on master and pushed a new ci-test

<damo22>this is already saving us time

<nexussfan>I'd love to send a patch

<damo22>we can put the ci script into master and then you could send a patch

<nexussfan>Maybe

<damo22>sorry i dont have bandwidth to allow external users on my site

<nexussfan>Makes sense

<damo22>forgejo is pretty easy to deploy, though

<nexussfan>I've set it up before

<damo22>youpi: this is master + a small fix, + something for gcc-10, and the ci script https://code.zammit.org/damo22/gnumach-sv/actions/runs/13/jobs/0/attempt/1

<damo22>aaand 64b smp failed in the ci as expected until i submit my updated patch

<damo22>bbl

<damo22>youpi: https://code.zammit.org/damo22/gnumach-sv/actions/runs/15/jobs/7/attempt/1#jobstep-2-1630 interesting, smp 64 fails on only one test and only with kdb enabled

<sobkas>GNU should provide such infrastructure

<gnu_srs1>sobkas: I've now tried your mesa patches on hurd-i386. Unfortunately glxgears crashes with bus error as it did for me with libdrm and my patches for mesa.

<gnu_srs1>ssh -Y works, but not in X windows. Still a failure due to shared memory problems.

<sobkas>gnu_srs1: which patches did you tried? One on freedesktop or pastebin?

<sobkas>what glxinfo shows?

<sobkas>ldd /usr/bin/glxgears

<sobkas>ls -lha /lib/x86_64-gnu/libGL.so.1

<sobkas>I also use amd64 hurd

<sobkas>But essentially in my patch there isn't anything that should depend on 32/64 bit

<sobkas>So maybe llvm?

<sobkas>An which version of gnumach/hurd you are using?

<sobkas>gnumach-image-1.8-amd64-up/unstable 2:1.8+git20251228-2

<sobkas>hurd/unstable,now 1:0.9.git20251029-2+b1

<gnu_srs1>I used patches from freedesktop. And added debian/ stuff from your pastebin.

<gnu_srs1>paste.debian.net failed, reports spam??

<gnu_srs1>ldd /usr/bin/glxgears

<gnu_srs1> libGL.so.1 => /usr/lib/i386-gnu/libGL.so.1 (0x01058000)

<gnu_srs1> libX11.so.6 => /usr/lib/i386-gnu/libX11.so.6 (0x010c3000)

<gnu_srs1> libm.so.6 => /usr/lib/i386-gnu/libm.so.6 (0x01219000)

<gnu_srs1> libc.so.0.3 => /usr/lib/i386-gnu/libc.so.0.3 (0x01321000)

<gnu_srs1> libGLdispatch.so.0 => /usr/lib/i386-gnu/libGLdispatch.so.0 (0x015e1000)

<gnu_srs1> libGLX.so.0 => /usr/lib/i386-gnu/libGLX.so.0 (0x0165c000)

<gnu_srs1> libpthread.so.0.3 => /usr/lib/i386-gnu/libpthread.so.0.3 (0x01697000)

<gnu_srs1> libxcb.so.1 => /usr/lib/i386-gnu/libxcb.so.1 (0x016a4000)

<gnu_srs1> /lib/ld.so => /lib/ld.so.1 (0x00001000)

<gnu_srs1> libmachuser.so.1 => /usr/lib/i386-gnu/libmachuser.so.1 (0x016d0000)

<gnu_srs1> libhurduser.so.0.3 => /usr/lib/i386-gnu/libhurduser.so.0.3 (0x016e7000)

<gnu_srs1> libXau.so.6 => /usr/lib/i386-gnu/libXau.so.6 (0x0171a000)

<gnu_srs1> libXdmcp.so.6 => /usr/lib/i386-gnu/libXdmcp.so.6 (0x0171e000)

<gnu_srs1>latest hurd and gnumach packages. Can be a llvm issue/or mesa?

<gnu_srs1>gnumach-image-1.8-486-up 2:1.8+git20251228-2

<gnu_srs1>hurd 1:0.9.git20251029-2+b1

<gnu_srs1>ls -lha /usr/lib/i386-gnu/libGL.so.1

<gnu_srs1>lrwxr-xr-x 1 root root 14 Dec 28 14:15 /usr/lib/i386-gnu/libGL.so.1 -> libGL.so.1.7.0

<gnu_srs1>dpkg -S libGL.so.1.7.0; libgl1:hurd-i386: /usr/lib/i386-gnu/libGL.so.1.7.0

<gnu_srs1>libgl1:hurd-i386 1.7.0-3

<gnu_srs1>I'll build on hurd-amd64 later.

<Pellescours>youpi: trying to bootsrap gnumach, and it fails to build due to «redefinition of 'struct in_pktinfo'»

<Pellescours>/.../include/bits/in.h:71:8: note: originally defined here

<Pellescours>I see that its now defined in glibc since 9307ff1073a9f071764cf7c401b6e72e1577d7a4

<Pellescours>what can I do to fix this?

<damo22>youpi: i think netbsd had a problem with pthread_cancel recently

<Pellescours>(bootstrap hurd actually)

<Pellescours>it fails to build pfinet

<damo22> https://gnats.netbsd.org/59135

<damo22> https://gnats.netbsd.org/59134

<youpi>Pellescours: pfinet probably now needs to drop its own in_pktinfo

<Pellescours>I commented it for now locally, and it compiled

IRC channel logs

2026-01-21.log