<damo22>youpi: is there a particular process we need to go through to get libacpica debian package included in hurd? <damo22>since im not a debian developer or maintainer, i guess someone else needs to put their name on the package? <youpi>since it'll be a hurd-only package, we'll upload it to debian-ports' unreleased anyway <youpi>I have my key in the debian-ports keyring, so I can upload it <damo22>i think it would be a good idea if i become involved in the debian packaging too for hurd, you cant possibly do everything yourself <youpi>well, uploading is a very quick thing to do :) <youpi>the long work is committing what's correct in the repository <youpi>which you're already doing :) <youpi>you're very welcome helping with other hurd packages <damo22>i saw the broken list that you provided, its daunting <damo22>but if i pick off some low hanging fruit it might get easier <youpi>the broken list, you mean of the debian packages in general ? <youpi>it's daunting yes but no need to work it all through <youpi>rather focus on the top packages in graph-top.txt <youpi>and whatever you rather want (e.g. vim ;) ) <youpi>I don't know what you meant by "that you provided", but it's probably along it <damo22>oh yes, i may start with vim and git <biblio>damo22: youpi: I was able to fix compilation issue of latest iptables on HURD. but when I run iptables -L . it says xtable lock error or something like that. another process is blocking. <damo22>i dont think iptables makes sense, you can filter ports using a translator? <youpi>but it's completely different from iptables <damo22>im trying to upstream a patch into netbsd kernel for accurate buffer reporting in the audio driver, by filtering time with a delay loop <youpi>also, emacs is currently uninstallable <damo22>does anyone know a deb-src that works for hurd? im getting W: Skipping acquire of configured file 'main/source/Sources' as repository 'http://deb.debian.org/debian-ports unstable InRelease' does not seem to provide it (sources.list entry misspelt?) <biblio>damo22: as far I know one entry for deb and another deb-src for source <damo22>InRelease at the end does not work <damo22>that last deb-src you provided works, but its not ports <damo22>wow building vim takes ages for the test suite <biblio>damo22: there is an env variable you can set to skip tests. if you just want to build and run. <damo22>no i am trying to fix the debian package so it does not fail <damo22>the only reason we have vim is because youpi uploaded a binary <damo22>emacs apparently does not build either <biblio>damo22: i will try to have a look. <damo22>git is also broken because git-man is not updated or something <biblio>damo22: git is also broken in latest release as far I remember <damo22>biblio: you can fix emacs and i'll fix vim and git <damo22>youpi: what command do we use for route? <biblio>damo22: currently, in openstack I am use hard coded password. but to make it cloud like cloud-init package need to add route to make metadata accessible from VM. without iproute2 cloud-init wont work. <biblio>damo22: but not a big issue you can still use hard coded password for hurd on openstack - it works. <youpi>damo22: nobody has contributed it so far <damo22>is there a concept of routing table in hurd? <damo22>i dont understand the network stack enough <youpi>just nobody has plugged the right ioctl/netlink/whatever needed to add a route <damo22>i cant find vim in the failed packages list, but im building it now, it seems to be stuck for a long time on Executing Test_mouse_alt_leftclick() <youpi>to be able to have it installable in the latest iso I built yesterday <youpi>you can look at the old build logs from buildd.debian.org/vim <damo22>strange, i thought to give up on the hung test to look into it, but when i pressed ctrl-c it continued to the next test <damo22>one of the vim errors im looking at is obscure, it literally creates a dir via a vim command and fails... but it works locally in my vim <damo22>this is way harder than i thought it would be ***biblio_ is now known as biblio
<mhatta>So I'm now trying to use Digital Ocean for running Debian GNU/Hurd <mhatta>Digital Ocean can accept img, so I'm trying to use debian-hurd-20210812.img <mhatta>Looks like it went as expected, but seems failed to mount root fs <mhatta>start ext2fs: ext2fs: device: hd0s2: No such device or address <mhatta>Should I generate raw or qcow2 image by myself? <youpi>mhatta: it rather looks like your virtualization software is emulation a sata disk, while the image was configured to use an ide disk <youpi>possibly you can just switch the emulation from sata to ide <biblio>mhatta: please click edit metadata of your image and search hw_disk_bus set this option to ide <biblio>mhatta: search hw_vif_model set as e1000 <youpi>as a reminder: contribution welcome on the wiki, to write down such tips <mhatta>As far as I could see I can't change the setting of virtual machine on Digital Ocean <biblio>mhatta: not the virtual machine. you need to edit metadata of your image. <biblio>mhatta: where you uploaded debian-hurd-20210812.img there will be a "edit" button. <mhatta>biblio, unfortuenately there's no "edit" button or such <mhatta>Where do we usually specify the (virtual) hardware on cloud environment? <mhatta>I mean, I guess we need to specify specific hardware (ide, e1000, etc.) somehow but I don't know where we can set them <mhatta>DigitalOcean Web or CLI API seems not provide such settings <biblio>mhatta: in openstack it is defined with image as far I understood. <biblio>mhatta: let me show you an example... <mhatta>biblio, yeah, that's what I thought <mhatta>So I guess I have to generate img or qcow2 by myself (not stock debian-hurd.img) <biblio>mhatta: that metadata is included in cloud provider. not with image (sorry for the confusion) <biblio>mhatta: i am sending you a link of a screenshot <mhatta>Hmm, then I can't run HURD on DigitalOcean, can I? <mhatta>cloud providers don't allow changing the virtual machine spec such as disc controllers or NICs <biblio>mhatta: if it is standard openstack they will have this options. <mhatta>biblio, no, they might use openstack but I guess they heavily customize it <biblio>mhatta: ok I will also try to test other hosting providers. <mhatta>I'm still confused. If I generate images with metadata specifying hw_vif_mode etc., then should it work? <biblio>mhatta: this is not metadata with binary. this is metadata (some specifications) for openstack. <youpi>damo22: also, thinking about testsuites, in the qt* packages, it looked to me like there is a common build failures about GL context <youpi>possibly fixing that would fix various qt packages ***FragByte_ is now known as FragByte
