IRC channel logs
2023-07-17.log
back to list of logs
<damo22>youpi1: i am keen to hear sergey's plan to write a new bootstrap program, if he is really doing it, there may be no point further writing hurdhelper <damo22>also, with hurdhelper: the idea is to make it as little to remember to type as possible, if the default behaviour of bootstrap translators is not to bootstrap the system correctly i would consider that a bug (?) why do we need special options to start the system at all? <solid_black>haven't heard from you in a while; any news about those fs_base corruption fixes? <luckyluke>I have some incomplete patches, still need to clean up different build configurations (kdb, 64-bit, etc) <luckyluke>but it seems to work fine on my usual 64-bit config, I coudl finish debootstrap and boot from disk <solid_black>rumpdisk doesn't seem to work for me at all, it just hangs <luckyluke>I just used the same grub config as i686, without acpi for now <luckyluke>there are some issues with interrupts, that are probably fixed by the latest damo22 patches, but so far I only had issues when shutting down rumpdisk <luckyluke>and probably that was also the issue with network <solid_black>let me think this through, so you're taking Samuel's image (which I've always used as a ramdisk) and putting it on a disk, right? <solid_black>and then telling grub to load things from it... which likely won't work already since you haven't run debootstrap by that point <luckyluke>no, that won't work as the translators are not set up <luckyluke>I boot with Samuel's image both in a ramdisk and in another disk, then finish debootstrap in the ramdisk, mount the disk, chroot into it and finish debootstrap again :) <luckyluke>not the simplest setup, but so far it worked <solid_black>well as I said, I've been unable to even run rumpdisk <luckyluke>I didn't update it recently IIRC my image is 1 month old now <solid_black>and the gdb being unable to load debuginfo issue certainly doesn't help with investigating <solid_black>GDB on the host being unable to read detailed debuginfo from Samuel's/Debian builds <luckyluke>with rumpdisk, did you see at least the startup logs from netbsd? <solid_black>I don't quite remember, but I think it did print something out <luckyluke>what are you up to recently? I saw some mention of a new bootstrap procedure on the list <solid_black>other than that, I've done some VM changes, including solving the "gnumach vm map entry forward merging" thing <luckyluke>yeah, the vm map merge was a nice thing actually! It's on my queue to test, but I seem to have too many open things vs time :( <luckyluke>ah objective c! I never used it actually... is it only for gnustep or also other standalone apps? <solid_black>it's standalone, you only need an objc-capable compiler (GCC or Clang) <solid_black>and gnustep is this huge project with apps, gui, filesystem layout, so on <solid_black>ObjFW is just a single .so (well, two of them) that you link against, it doesn't impose any FS structure on you or anything <solid_black>it's very portable, the developer has ported it to all sorts of systems <solid_black>...but in general, I've found that lack of feedback on my patches doesn't help with motivation <solid_black>like if I post a patch that I think does something cool, and then it gets ignored by everyone, that really discourages me <luckyluke>sometimes it can take a while to have some feedback yes, from my side I try to follow but also a proper review takes time <solid_black>yeah, but a simple "hi, this sounds cool, but I won't have time to review this until next month" goes a long way and takes like half a minute <luckyluke>and I usually need to look up parts of the system that I don't know yet, (e.g. the vm code) to avoid saying silly things (but it still happens sometimes :p) <solid_black>I learned to not be ashamed to say I don't know or understand something if I don't <solid_black>oh another thing: did you ever look into why Mach console crashes without console=com0 <luckyluke>I think it was related to the lower ios memory not being mapped on 64-bit it might work now <solid_black>also I've been doing some GTK- and GObject-related work at $DAYJOB, so I'm thinking maybe I should go back to that GHurdFileMonitor thing I wrote back in December <luckyluke>I'm not familiar with GTK/GObject... is it something like a high-level inotify? <solid_black>yes, they have a GLib API for watching a file or directory for changes <solid_black>this API is then used by things like file manager apps and the file chooser dialog <solid_black>and maybe in other cases, like they may watch a font file for updates and reload fonts, or something like that <solid_black>and it has multiple backends, inotify is one of them, there's also kqueue <solid_black>and if none of those work, it just falls back to polling the file regularly, which works, but is of course suboptimal <solid_black>so I was trying to write my own backend for the Hurd, using Hurd's native file watching APIs <solid_black>the feedback I received last time was: they don't want any Hurd-specific code since they can't test it on a CI <solid_black>Samuel then suggested we could provide a Hurd CI to them <luckyluke>wouldn't be enough to provide a qemu image that they can use in the CI pipeline? or do they require containers or similar stuff? <solid_black>but a qemu image is not trivial to integrate into a CI pipeline either <solid_black>you don't want a CI pipeline that runs the image, you want a CI pipeline that runs *on* the image <solid_black>and I don't think they actually care enough to figure anything out, especially given the recent news about their macOS CI <solid_black>what they probably would take is if *we* provided and maintained some hardware that would run their CI pipelines