IRC channel logs

2025-04-10.log

back to list of logs

<ZhaoM>morning
<ZhaoM>If I understand correctly, if we want to try rumpdisk, we need to let qemu attach a sata disk
<ZhaoM>like what's mentioned here
<damo22>"-M q35" is probably needed
<ZhaoM>so the qemu bootstrap script is different to what's mentioned here https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index1h1
<ZhaoM>damo22: ah cool, so '-device ahci' is not neccessary
<ZhaoM>and the issue I mentioned about the printing of `wd0d: device timeout reading fsbn` after poweroff does not exist anymore when I use -M q35 rather than '-device ahci'
<damo22>i think changing the machine type to q35 makes a lot of changes to the machine layout
<damo22>eg what peripherals are connected
<ZhaoM>damo22: thanks, I will submit the patch to add the trying rumpdisk qemu script to the webpage
<damo22>good idea
<ZhaoM>hi some license questions. I'm writing an article introducing Guix childhurd service. Can I use GFDL1.3+ to publish it? If yes, there's only a single markdown file, how to do it?
<youpi>using 1.3+ should be fine yes
<youpi>you can just send the .md file
<ZhaoM>I mean all the work is done on a single markdown file
<ZhaoM>should I just add the license script in the comment
<ZhaoM>or have a paragraph for it
<ZhaoM>i.e. should I show the whole notice from https://www.gnu.org/licenses/fdl-1.3.html#addendum in the article
<ZhaoM>or put the whole notice in the markdown comment and add a line like "this article is published under GFDL1.3+" at the end of the article
<ZhaoM>or the either is fine
<youpi> https://pastebin.aquilenet.fr/?160614b32742bac7#FakJQvqkiLCwKSnERkXv3N2smN1Gs3TtGzbRSwtdWvH5
<youpi>this is a trivial wiki page example
<ZhaoM>thanks :)
<yelninei>hi youpi, janneke told me to ask you here. I have been trying to investigate failing guix hurd packages with glibc 2.41. I found that glibc commit 8ef17919509e909746b0ad6465e9c6c952a3fe34 is breaking the gnulib test-symlink/symlinkat test in many core packages because it now returns ENOTDIR instead of EINVAL
<youpi> https://sourceware.org/bugzilla/show_bug.cgi?id=32569
<youpi>please investigate which exact case should be doing what
<youpi>(gnulib being pedantic on errnos does not really help :) )
<yelninei>this assert https://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-symlink.h#n70 is returning ENOTDIR
<youpi>I understand that
<youpi>but the thing is
<youpi>somebody asks me to fix something one way
<youpi>then somebody asks me to fix the same thing another way
<youpi>that needs to be reconciled
<youpi>i.e. the question needs to be considered globally
<youpi>not just one specific case
<youpi>i.e. check both the test you see in your case, and the test that triggered the fix, detailed in the bugzilla
<youpi>to come up with a desired behavior that meets both expectations
<yelninei>in the symlink test gnulib accepts EEXIST or EINVAL (or ENOENT). From the bugzilla it looks like EEXIST would work for both?
<sneek>yelninei, you have 1 message!
<sneek>yelninei, janneke says: seen the remark above about asking youpi about the glibc commit that breaks the symlink test? possibly mailing bug-hurd is even better
<youpi>yelninei: possibly, tested patch welcome ;)
<Pellescours>what is the Linux behavior on this case? Does it return EEXIST ?