IRC channel logs

<damo22>youpi: maybe we could make a separate repo for old linux drivers for gnumach, so it would still be possible to compile them with gnumach for debugging, but then we can purge them from the main source

<youpi>for debugging what?

<youpi>I mean, i386 is deemed to be the past

<youpi>I don't really see the point of spending time on this since we'll just drop it

<nexussfan>x86_64 hurd is pretty good

<damo22>well id prefer to drop it

<damo22>but networking with rumpnet is not quite ready

<nexussfan>Yes it is(?)

<damo22>i experienced a bug

<nexussfan>?

<youpi>we have netdde

<damo22>when i was trying to clone go dependencies my rumpnet crashed repeatedly

<damo22>but works with netdde

<youpi>(actually we can most probably just drop the in-gnumach linux net drivers, since netdde is essentially always the default nowadays)

<damo22>can we drop all linux/

<nexussfan>Rumpnet on real hardware has no problems for me

<youpi>damo22: not disk drivers yet

<nexussfan>Does the debian installer use rumpnet by default? Or does it still use the old drivers

<damo22>ok

<youpi>nexussfan: it uses nedde

<damo22>netdde is actually more complete set of drivers

<damo22>rumpnet only supports intel nics

<nexussfan>youpi: ok

<damo22>until someone fixes rump

<nexussfan>damo22: Yes, but I use ThinkPads for my Hurd, so rumpnet is supported

<damo22>there is e1000{,e} missing from netdde

<damo22>which is why i wrote rumpnet

<azert>damo22: did you figure out how one rumpify a netbsd driver?

<damo22>not exactly, its some makefile foo

<youpi>damo22: ? netdde has a e1000 driver

<damo22>youpi: ok it must be the e1000e then

<youpi>that's the one I use with qemu

<youpi>possibly

<azert>I read that in theory you can load directly netbsd binary modules with rump

<azert>so it shouldn’t be hard

<damo22>but maybe netdde can have e1000e added

<azert>nobody is maintaining netdde

<youpi>better fix rumpnet

<damo22>ok

<damo22>but it may be simple like adding a pci id to netdde to extend the functionality, might be worth doing

<damo22>if it needs more than that then i agree not to waste time on it

<youpi>I guess the addition of "e" is more than just that

<damo22>rumpnet has libmiiphy with pretty much every PHY that has been produced

<damo22>but the cards are in separate drivers

<damo22>so we need separate makefiles to compile them

<nexussfan>Time to add rumpnet to my T43

<azert>maybe we should adopt netbsd binary modules instead

<damo22>azert: i dont see how that is preferred, then we need a netbsd target toolchain

<azert>yes that’s bad

<azert>but you wouldn’t need to send patches to bsd people for things that are probably not their priority

<nexussfan>does t43 use /dev/wmX cards?

<damo22>the main issue is that netbsd dont want more old style makefiles and rump has not been ported to use configuration style makefiles

<damo22>so some refactoring of rump is needed

<damo22>nexussfan: lspci -nn

<damo22>nexussfan: sudo lspci -nn|grep net

<nexussfan>Nope, `BCM5751M Gigabit Ethernet PCI Express`

<damo22>what is the [pci:id] ?

<nexussfan>`[14e4:167d]`

<azert>damo22: that looks like a daunting challenge

<azert>rewriting the makefiles

<damo22>yeah

<damo22>they are supposed to be autogenerated from a config

<damo22>but currently they are manually written

<damo22>so you can imagine how they dont want to maintain manually written ones

<nexussfan>Somebody should port PyHurd <https://savannah.nongnu.org/projects/pyhurd/> to Python3

<damo22>2to3

<nexussfan>Not perfect

<damo22>does most of the work

<nexussfan>> abort: HTTP Error 502: Bad Gateway

<nexussfan>Can't clone the hg repo

<damo22>what hg repo

<nexussfan>For PyHurd

<nexussfan>CVS works though

<nexussfan>I don't know why there is both CVS and hg

<nexussfan>Hmmm. The only folder in the CVS repo is `CVS`

<nexussfan>Luckily it's on PyPI so I can download that

<damo22>how did you go with jkd7?

<damo22>jdk7*

<nexussfan>I installed your gcj thing

<nexussfan>Still says `/bin/sh: 3: /java/re/j2se/1.6.0/latest/binaries/linux-i586/bin/java: not found`

<damo22>btw netdde does not seem to have 14e4:167d

<nexussfan>damo22: Networking works.

<damo22>oh ok

<nexussfan>Just hurd magic

<azert>damo22: in regards to rump handmade makefiles, we should hope for agentic AI to pay that technical debt. It’s the kind of job they might be able to do

<nexussfan>Where can I get `/java/re/j2se/1.6.0/latest/binaries/linux-i586`

<damo22>nexussfan:its not magic, its here linux/drivers/net/tg3.c: {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751M)}

<damo22>nexussfan: you can set JAVA_HOME perhaps to point to your gcj-6

<azert>otherwise passing to netbsd binary modules is maybe the way to go. Building a netbsd tool chain takes time but it’s something that people already do

<damo22>nexussfan: you need to install gcj-6-jdk

<nexussfan>ok

<damo22>probably libecj-java-gcj and ecj as well

<nexussfan>Those 2 packages aren't installable

<damo22>ok you might not need them im not sure

<damo22>but you need to figure out where that path is coming from

<damo22>and set JAVA_HOME to override it

<damo22>then it wont look for that /java/re/j2se..

<nexussfan>> ALT_BOOTDIR - JDK used to compile agent java source and test with

<nexussfan>> BOOTDIR=/java/re/j2se/1.6.0/latest/binaries/linux-i586

<damo22>set those to /usr/lib/jvm/default-java

<nexussfan>> '/usr/lib/jvm/default-java': No such file or directory

<damo22>ok

<damo22>whats in /usr/lib/jvm?

<nexussfan>java-1.5.0-gcj-6-hurd-amd64, java-gcj-6

<nexussfan>java-gcj-6 is symlink to java-1.5.0-gcj-6-hurd-amd64

<damo22>set it to /usr/lib/jvm/java-gcj-6

<damo22>you can use environment vars to override

<nexussfan>Still says `*** An XSLT processor (J2SE 1.4.x or newer) is required to bootstrap this build`

<nexussfan>Tries to do `/usr/lib/jvm/java-gcj-6/bin/javap javax.xml.transform.TransformerFactory > /dev/null 2>&1; \`

<damo22>interesting

<nexussfan>javap doesn't exist

<damo22>there might be a missing tool, or symlink

<nexussfan>What does javap do?

<damo22>preprocessor

<damo22>hmm no, it seems to be a disassembler

<damo22>maybe the debian package forgot to include it?

<nexussfan>Seems like gcj-6 is only available on Hurd?

<damo22>yes i packaged it

<damo22>nobody else wants it because openjdk is available everywhere else

<damo22> https://code.zammit.org/damo22/gcc

<nexussfan>It's published on unreleased, I assume?

<damo22>yea

<damo22> https://code.zammit.org/damo22/gcc/src/branch/hurd-gcc-6-debian-gcj/debian/rules.d/binary-java.mk#L78 i think its missing from a few places

<nexussfan>Yeah, you need javap

<damo22>everywhere javah is mentioned it could add javap as well

<damo22>i dont know if gcc has the javap tool

<nexussfan>circular dependency

<damo22> https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcj/Invoking-jcf-dump.html#Invoking-jcf-dump

<damo22>jcf-dump --javap

<damo22>you could alias that to javap

<nexussfan>Okay

<damo22>curious to know how that goes

<nexussfan>The command is jcf-dump-6

<nexussfan>> jcf-dump-6 --javap $@

<nexussfan>Compiling...

<nexussfan>> /home/nexussfan/jdk7-hotspot/src/share/vm/adlc/adlparse.cpp:4452:17: error: ISO C++17 does not allow ‘register’ storage class specifier [-Werror=register]

<nexussfan>> cc1plus: all warnings being treated as errors

<nexussfan>This is why I hate `-Wall -Werror`

<damo22>CXXFLAGS=-stdc++11

<nexussfan>Compiling again..

<nexussfan>> 5797 problems (4823 errors, 974 warnings)

<nexussfan> https://paste.debian.net/hidden/0f5177bb

<damo22>classpath is probably not set

<damo22>-cp /home/nexussfan/jdk7-hotspot/agent/src/share/classes/ or a relative path that points there

<nexussfan>Here are the make options https://paste.debian.net/hidden/30da4902

<nexussfan>`/home/nexussfan/jdk7-hotspot/agent/src/share/classes/` exists

<damo22>JDK_IMPORT_PATH

<nexussfan>`ALT_JDK_IMPORT_PATH=/home/nexussfan/jdk7-hotspot/agent/src/share/classes/`?

<damo22>yeah you could try that

<nexussfan>Still 4823 errors

<damo22>play with the make options, see if you can get it to work

<damo22>maybe it doesnt like ALT_

<damo22>it wants the non ALT_ param

<nexussfan>Reading the help make options ALT_ is an override for the default

<nexussfan>But even without it, still failing

<damo22>the error messages seem to indicate it cant find the imports

<nexussfan>> JDK_IMPORT_PATH must refer to a compatible build, not all past promoted builds or previous release JDK builds will work.

<damo22>so its not looking in the right place

<Gooberpatrol66>i think guix builds java from gcj, you could look at that

<nexussfan>> --- Examples ---

<nexussfan>> make ALT_BOOTDIR=/opt/java/jdk1.6.0

<nexussfan>> make ALT_JDK_IMPORT_PATH=/opt/java/jdk1.7.0

<damo22>so the BOOTDIR needs to point at your gcj headers?

<damo22>and JDK_IMPORT_PATH the new source

<nexussfan>Right now I'm doing `make ARCH_DATA_MODEL=64 ALT_BOOTDIR=/usr/lib/jvm/java-gcj-6 ALT_JDK_IMPORT_PATH=/home/nexussfan/jdk7-hotspot/agent/src/share/classes/`

<damo22>no, thats not the path to the gcj headers

<damo22>is it?

<damo22>ah might be

<nexussfan>The folder has `bin include jre lib man`

<damo22>that looks more like a JAVA_HOME

<damo22>maybe you need to append "/include"

<nexussfan>> Missing /usr/lib/jvm/java-gcj-6/include/lib/tools.jar file. Use 1.6.0 or later version of JDK

<damo22>ok my suggestion was wrong

<damo22>but where are the headers? include has hardly anything in thre

<damo22>libgcj17-dev ?

<nexussfan>Not sure

<damo22>gcj-6-source

<nexussfan>Installing

<damo22>then you go into /usr/lib/jvm/java-*/ and sudo unzip src.zip

<nexussfan>Done

<damo22>try now

<nexussfan>Still errored

<nexussfan>You may want to contact the original maintainer

<damo22>how many errors?

<nexussfan>5797 problems (4823 errors, 974 warnings)

<damo22>hmm it didnt find them then

<damo22>its the same number of errors

<damo22>ALT_BOOTDIR=/usr/lib/jvm/java-1.5.0-gcj-6-hurd-amd64

<nexussfan>The /usr/lib/jvm/java-gcj-6 is symlinked to that

<damo22>okay

<damo22>maybe you can disable hotspot

<nexussfan>Hotspot?

<damo22>according to jk's notes he had trouble compiling hotspot

<nexussfan>How to disable it?

<damo22>but the normal java toolchain worked

<damo22>i dont know, dig into his notes

<nexussfan>> error: sun.jvm.hotspot.tools cannot be resolved

<nexussfan>But /home/nexussfan/jdk7-hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/ exists...

<damo22>ok, maybe you can point ALT_BOOTDIR to that

<damo22>/home/nexussfan/jdk7-hotspot/agent/src/share/classes

<nexussfan>No, BOOTDIR is like the JAVA_HOME

<damo22>ok you can try deleting the files you extracted from the src.zip and copying the dirs from agent/src/share/classes/* into the java home?

<nexussfan>Okay

<nexussfan>5797 problems (4823 errors, 974 warnings)

<nexussfan>Seems like classes are just broken

<nexussfan>The port is most likely contains bit rot

<damo22>what do you mean? jdk7 is old and the port is from that era

<damo22>what is your make line?

<damo22>i am struggling to get the include paths right for the c++ component

<damo22>ok got i

<damo22>same errors

<damo22>11569 problems (1108 errors, 10461 warnings)

<nexussfan>Even worse somehow

<nexussfan>Wait no

<nexussfan>Less errors

<damo22>no, less erorrs

<nexussfan>Hmmm

<damo22>the classpath is not being passed in

<nexussfan>Did you modify the makefiles?

<damo22>no

<nexussfan>Oh

<damo22>the source is supposed to go in JAVA_HOME/lib/classes

<damo22>and that is supposed to be set as classpath

<damo22>i tried overlaying the gcj java source with the openjdk7 source

<nexussfan>Cursed

<damo22>i dont think they have any conflicting files

<damo22>although i might be wrong

<damo22>the source is missing sun/jvm/hotspot/jdi ?

<damo22>utilities, runtime

<damo22>seems to be there but its not finding it

<damo22>agent/src/share/classes/com/sun/jdi

<damo22>not there

<damo22>tools.jar is supposed to have com.sun.jdi

<damo22>but the one in gcj doesnt have JDI

<damo22>nexussfan: mv agent agent.disabled then try again

<damo22>i get a chunk of c++ errors

<damo22>heres something dumb i saw in a java makefile: mkdir -p .

<nexussfan>What? Why?

<nexussfan>I guess it's a sane environment check

<damo22>well you are always in a directory called `.` so creating it is useless

<damo22>ive almost compiled jdk7

<damo22>make LP64=1 CFLAGS="-std=c++98 -fPIC -fpermissive -DCOMPILER1 -DCOMPILER2 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_ARCH_x86 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_FAMILY_linux -DTARGET_COMPILER_gcc" ALT_BOOTDIR=/usr/lib/jvm/default-java ALT_JDK_IMPORT_PATH=/usr/lib/jvm/default-java/lib/classes GAMMADIR=/part3/git/jdk7-hotspot Platform_arch=x86 $@

<damo22>Linking vm...

<damo22>/usr/bin/ld: jvmtiEnterTrace.o:(.data.rel.local+0x0): multiple definition of `JvmtiUtil::_error_names'; jvmtiEnter.o:(.data.rel.local+0x0): first defined here

<damo22>is there a way to tell the linker to drop duplicated symbols/

<rrq>multiple definitions is not good.. need "extern" on the declarations and a single definition

<damo22>make[4]: Leaving directory '/part3/git/jdk7-hotspot/make/linux_amd64_compiler2/product'

<damo22>All done.

<damo22>what is libjava.so

<damo22>the binary cannot locate it

<damo22>ive compiled libjvm.so

<rrq>on my attempt to boot (unstable hurd amd64) I get from ext2fs:" $actualuuid: Gratuitous error" ... what does that mean? I couldn't find it in the source

<youpi>it's EGRATUITOUS

<rrq>ta. ok. got scripted syslinux priming of a crosshurd filesystem to boot

<sobkas>What "BDB0126 mmap: No such device" do?

<sobkas>Ok have working sbuild

<sobkas>libgl1-mesa-dri:

<sobkas> Installed: 26.0.0~devel-11

<sobkas> Candidate: 26.0.0~devel-12

<sobkas> Version table:

<sobkas> 26.0.0~devel-12 500

<sobkas> 500 http://miniserver.lan/mesa experimental/main hurd-amd64 Packages

<sobkas> *** 26.0.0~devel-11 500

<sobkas> 500 /var/lib/dpkg/status

<sobkas> 20.2.6-1+hurd.1 500

<sobkas> 500 http://deb.debian.org/debian-ports unreleased/main hurd-amd64 Packages

<nexussfan>damo22: how is openjdk

<nexussfan>It would be nice if there was a new openjdk hurd repo

<nexussfan>for apt

<azert>sobkas: I’ve seen the feedback on your pull request https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39277

<azert>my opinion based on my understanding of English, is that you have a chance to get the first two patches included

<azert>but they aren’t going to pull the third

<azert>their comment about illumos and haiku sounds like: if we managed to get them to port libdrm, you should probably do the same. Which is a pity since they don’t realize that for the Hurd porting DRM is more hard

<youpi>I don't think they requiring hard illumos/haiku work

<youpi>but just asking to follow the same paths

<youpi>I don't think they requiring hard illumos/haiku work

<youpi>but just asking to follow the same paths

<azert>Yes but their path has been porting libdrm

<azert>when they could have also just opt for software only rendering

<youpi>ah ok

<azert>that is something that mesa perhaps explicitly don’t want to support (I don’t know but I am left wondering)

<youpi>I'm rather thinking that they don't realize all this

<azert>possible

<youpi>remember that most of the time they don't work on that part of the code, so may have no idea what you are at

<youpi>that yes, the hurd case is really different

<sobkas>I'm more optimistic, being able to use dri instead of xlib "solution" is a success in itself

<youpi>because it's not about porting libdrm

<youpi>but really using the software renderer

<azert>indeed they might need some explaining

<sobkas>The look on my face when choosing xlib and it produced a libGL that contained llvmpipe...

<sobkas>This work is a stop gap before we do drm, that can be reused for xlib case and drop xlib "solution"

<sobkas>ajax mentioned xlib too

<azert>sobkas: maybe you can split that patch, the meson/plumbing part and the libsync part. And expand explanations for the pumbling part

<sobkas>At least #1125979 was fixed

<sobkas>good night

IRC channel logs

2026-01-25.log