IRC channel logs
2024-03-01.log
back to list of logs
<nckx>adamnr: The logs are there, but under the wrong month (29 Feb). Known bug. Sorry. <etno>It took half a day, but I have vim=9.1.0016-1 built ! :-D <etno>uh, you are going to be disappointed... that is without the testsuite; but I take any progress as a victory <youpi>I don't understand, isn't vim already available? <youpi>ah, no, version skew of the arch:all package. I thought I had uploaded vim-runtime to unreleased to avoid this, but apparently not <etno>I am not sure I understand everything about the tables in the debian system, but I think that this version timedout, and the common packages for the former version are no longer available <etno>My bad, this was not in the tables, it was in the failed packages in one of your custo, txt files <etno>Without DMA, and with rumpdev_disk, it would take a real beast to pass the tests under 180mn <youpi>yes, the testsuite is failing, thus why newer versions don't get uploaded <youpi>i.e. no output at all from the tests <youpi>some testsuites such as gcc take a day, that's fine as long as they progress (i.e. emit output) <etno>Ok, this is an important distinction. In my first attempt, I reached to a test failure. <etno>Once I have rebuilt librumpdev, troubleshooting this could be the next step <etno>I also had several crashes of tmpfs during the build <youpi>do you have /tmp mounted as tmpfs? <etno>And crashes of ftpfs "during" the tests... :shrug: <etno>I will replace tmpfs with a build that has symbols and respawn vim's build <etno>That should provide us with some stacktrace, I think <etno>But now, I really need DMA 😀 <etno>rumpkernel is a really impressive piece of software <etno>pick some name and it is part of it <etno>I just unleashed the power in my GNU/Hurd box : Ultra DMA mode 6 !! Lightning speed ! <gnucode>etno: what is DMA? Direct Master Acceleration ? <gnucode>etno: are you running on bare metal? <etno>The laptop I have was moving like a slug because it was not able to make use of this DMA thing; the CPU had to copy 2 by 2 the bytes through a legacy system to and from the disk <etno>And enabling it makes a world of a difference; thankfully, a patch was already there <etno>gnucode, yup, baremetal mobile pentium :-D <etno>now rumpdisk is consuming only half the CPU amount of ext2fs, which is a relief <gnucode>etno: bare metal mobile pentium? That sounds like interesting hardware... <etno>This is a polite way to say low-end CPU. <etno>Well, even with a slow CPU, if you want to convince someone that the Hurd is fast, just have them use PIO for one day 😀 <gnucode>I'm using a T43 for my bare metal experiments. It's fairly slow... <etno>a T43 is equiped with a mobile pentium as well: Pentium M 730 (1.6 GHz), 740 (1.73 GHz), 750 (1.86 GHz), 760 (2.0 GHz), 770 (2.13 GHz) <etno>mine is a pentium dual 2.1GHz, so this is really comparable <anatoly>I was runnning it on asus eeepc 900, it was ok <etno>gnucode, you may have the same limitation as I had. An easy way to verify it is to look at the 'top' output whe doing some disk I/O; if rumpdisk goes to 99% easily, then you might be running on PIO <etno>anatoly, those are nice machine <etno>With DMA enabled, my laptop builds vim (gtk + motif + tiny + nox) in a few minutes, while it took the whole night with PIO <gnucode>etno: I don't think I am using rumpdisk actually. <etno>gnucode, then it has to be gnumach's built-in linux driver. Looking at the boot logs should tell it. <gnucode>When it boots up, it something something like "not using rumpdisk."