IRC channel logs


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>let's see if this works
<luckyluke>hi solid_black
<solid_black>hi luckyluke!
<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>I actually have no idea how to boot from disk
<solid_black>rumpdisk doesn't seem to work for me at all, it just hangs
<solid_black>(on x86_64, works great on i686)
<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
<solid_black>so what do you do?
<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 :)
<solid_black>oh, I see
<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>speaking of which: are you seeing the same issue?
<solid_black>GDB on the host being unable to read detailed debuginfo from Samuel's/Debian builds
<luckyluke>I didn't tried with gdb yet
<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>yeah, I loged onto IRC to discuss it with damo22
<solid_black>other than that, I've done some VM changes, including solving the "gnumach vm map entry forward merging" thing
<solid_black>which the wiki says is impossible / very hard
<solid_black>but nobody seems to care :|
<solid_black>I also helped get ObjFW ported onto the Hurd
<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 :(
<solid_black>yeah that is certainly an issue :|
<solid_black>I still need to get wl-clipboard 2.2.0 out, argh!
<luckyluke>ah objective c! I never used it actually... is it only for gnustep or also other standalone apps?
<solid_black>ObjFW is unrelated to GNUstep
<solid_black>it's standalone, you only need an objc-capable compiler (GCC or Clang)
<solid_black>it has all things from strings to an http server
<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 it was still using PATH_MAX
<solid_black>well, not anymore :)
<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>so now I'm saying that a lot :)
<luckyluke>that's a good approach :)
<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>hm, I'll re-test it then
<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>point is, this is an important API to support
<luckyluke>ah nice
<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>which was also not exactly encouraging
<solid_black>Samuel then suggested we could provide a Hurd CI to them
<solid_black>but it's unclear how that would happen
<solid_black>they did break the Hurd build recently by the way, and I submitted a fix
<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>I don't know, we'd have to ask them
<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