IRC channel logs
2026-01-28.log
back to list of logs
<rrq>Hmm, I get: "The following signatures were invalid: BADSIG 3AF65F93D6FBC5B9 Debian Ports Archive Automatic Signing Key (2025) <ftpmaster@ports-master.debian.org>" <rrq>does that mean: "please wait a bit" <youpi>do you have the latest version of the debian-ports-archive-keyring package? (2025.12.30) <damo22>jdk needs OTHER_CFLAGS but the jvm needs EXTRA_CFLAGS, now it seems to compile if i dont touch CFLAGS <rrq>I'm doing crosshurd. Maybe that one is old... <rrq>hmm; it's 1.7.64 (unstable) <rrq>right; debian-ports-archive-keyring is updated.... <rrq>hmm same issue with debian-ports-archive-keyring=2025.12.30 <rrq>i.e. first complaint, then for "unstable InRelease" as well <rrq>I'll opt for "wait a bit" :) <youpi>rrq: is the time of your system correct? <youpi>the key expires on february 1st <youpi>then they'll switch to the 2026 key <rrq>yes, clock is fine. And as it's bedtime here, I'll look into this tomorrow <damo22>ive built jdk6 but it wont "export", theres something fishy with the makefiles <damo22>make BUILD_FLAVOR=product VM_SUBDIR=product \ <damo22>make[3]: Entering directory '/part3/git/jdk6/hotspot/make' <damo22>make[3]: *** No rule to make target '/part3/git/jdk6/hotspot/build/linux/export-linux/docs/platform/jvmti/jvmti.html', needed by 'generic_export'. Stop. <damo22>it seems to be a mismatching path so it doesnt have a rule to install the file into the jdk output dir <damo22>like, all the files are built but it needs to harvest them all and create a jdk deploy tree <rrq>try touching that file; it's "just" a doc file <damo22>the makefiles are horrifically complex <rrq>maybe that file is by: xsltproc hotspot/src/share/vm/prims/jvmti.xml <damo22>ive built the file and i can see the rule that tries to install it, but i cant figure out why it fails because its all hidden in 10 nested variables <damo22>is there a make command that prints the rule in full before it executes it? <rrq>well, "-d" is pretty verbose <damo22>strange, the makefile for the tools in jdk/make/tools does not build the prerequisite class files for the tools, so they cannot be built <damo22>its almost like they expect you to have those classes in the previous jdk <damo22>but the source is all there in jdk/src/share/classes <damo22>i might have to write a new makefile to build those classes and add them to the tools <damo22>damn this is harder than i thought, the 1.5.0 java we do have is missing a bunch of classes, so i have to reorder the compilation of 1.6.0 so it compiles the classes as needed <damo22>maybe i can find tools.jar from a real 1.5.0 <jab>It's kind of annoying that so much software is hard to build from source. :( <llp-devr>Hi, how is the current Rust support on GNU/Hurd? <sobkas>Well I see rustc/unstable 1.91.1+dfsg1-1 <sobkas>I will look into it, but maybe someone knows why with latest hurd(git) I'm getting login: Invalid password <sobkas>I can login remotely with password, and passwd works with password <gnu_srs1>How do I remove/re-enable the tmpfs translator on /run and /run/lock? <youpi>you have the mount_run function in /usr/lib/init/mount-functions.sh, you can put an exit 0 after read_fstab <jab>sobkas: I didn't realize that we had cargo working on the Hurd... <youpi>you don't really have the choice nowadays <youpi>otherwise a lot of software is not available <sobkas>There is always possibility of rewriting hurd in it... <youpi>if port reference counting and such is properly encoded in rust, that can make it safer to work in, yes <sobkas>Well rewriting it in modern C would also make it better... <youpi>it'd be little better for the effort spent <bjorkintosh>we clearly like how it is, or someone would change it. <bjorkintosh>all the rust warriors would have fixed it all at a go already, if they didn't like it. <gnu_srs1>youpi: startx fails with with the new xserver-xorg-input-kbd: The keyboard driver is now at: <gnu_srs1>/usr/lib/i386-gnu/xorg/modules/input/kbd_drv.so instead of: /usr/lib/xorg/modules/input/kbd_drv.so <youpi>you can report the issue to the package <youpi>ideally you can submit a patch <sobkas>gnu_srs1: Had same problem, the joys of sid, looks like it might be part of broader move to multiarch paths <sobkas>Changelog: Fix multiarch modules path <sobkas>Done by mysterious person named Samuel Thibault <youpi>yes, probed by the maintainer for a build fix <youpi>I assumed they knew that the path change would entail <youpi>again, that'd to be discussed with the maintainer, not me <sobkas>By my experience it's normal to have such breaking changes in unstable, probably more packages will follow that also switch to multiarch directories <cosine>what's the status of x64 smp? just I should take a look at damo22's git commits? <cosine>looks like it builds and runs on one cpu (nice!), but doesn't boot on two <damo22>cosine: everything i have written is in master i think <damo22>i have built parts of jdk6, like javac and the jvm, but the jdk classes are difficult to bootstrap when they are missing in gcj-6 <cosine>I've been looking at zammit/ci-full-smp <damo22>oh goodie, the CI script is merged, i can do a full build on master