<damo22>youpi: PCI_CONF2 access method was deprecated in PCI v2.0, meaning we only care about reserving access to these ioports on hardware that was created circa 1992-1993 <damo22>i think we should just open up access in gnumach to these and forget they ever existed <damo22>or if someone really wants to support it they can add some kind of special case <damo22>it only affects 80486 and early pentium1 <damo22>i think the people making motherboards dont care about reserving 0xc000 to 0xcfff they just use those ioports these days <damo22>so if we block them in gnumach we will have problems <biblio>Hi, I am trying to create a Hurd OpenStack image. I setup Hurd stable as qcow2 and followed https://docs.openstack.org/image-guide/create-images-manually.html. But after I deploy in openstack I could not see any console output. I also tried with GRUB param console=tty0 console=ttyS0,115200n8. Openstack is showing hurd is running fine. But I could not ssh. I am not sure what is the root case as there is no console output yet. <biblio>Is there any Hurd specific settings I need to adjust which is equivalent to console=tty0 console=ttyS0,115200n8 ? <damo22>biblio: my guess is that when you installed it, it has wrong fstab <damo22>yeah but when it runs in openstack its not using the ide driver most likely <damo22>so it probably needs to be changed to sd0? <biblio>damo22: in my local I am running using guix-hurd-latest as host - it works for far. <biblio>damo22: i will first test with grub and fstab. <biblio>damo22: but the good news is cloud-init package is available in hurd. <damo22>is there a way to share the openstack image with others? <damo22>i mean once you create one that works, is it generic enough that anyone can use it? <biblio>damo22: yes, but the minimum one i was able to build is 2 GB <damo22>is there an official openstack repository of images? <biblio>damo22: it is same like regular OS except it has some mechanism to inject your selected ssh key from openstack while you boot the system. <damo22>so you could select it for use with Amazon EC2 for example? <biblio>damo22: it wont work directly. openstack image can be converted for ec2 <biblio>damo22: as far I know. But there are many hosting providers for openstack. <biblio>damo22: just to be clear. openstack support many hypervisors. I am trying to run hurd on openstack using qemu as hypervisor. <youpi>biblio: the gnumach paramater for console is console=com0 <youpi>damo22: ok so we can as well just make gnumach forget about cfg2 <biblio>youpi: thanks I will try with com0. I will also check faq. <damo22>youpi: yes that will solve it for most modern hw <damo22>youpi: should upstream/0_DATE tag be the date of the upstream commit? <damo22>or the date i committed the code <damo22>youpi: do i use debian/tmp explicitly or is there some kind of $DESTDIR i should use in the install command? <damo22>dpkg-buildpackage sets DESTDIR=/ somehow <youpi>usually your Makefile should just obey to DESTDIR <youpi>and dh_auto_install will set it <youpi>but on install it's set to $PWD/debian/tmp <damo22>can i override it during build otherwise it will force it into my / ***jlledom1 is now known as jlledom
<damo22>DESTDIR=debian/tmp dpkg-buildpackage ... ? <youpi>you don't need to force anything <youpi>just make your makefile installation rule obey DESTDIR <youpi>dh_auto_install will automatically set it <damo22>yes but during building the package it tries to install the files into / and fails because its not root <youpi>during building the Makefile is not supposed to install anything <youpi>since building is usually done as non-root <youpi>usually the upstream makefile has an install target <youpi>so that you don't need to hardcode these in debian/rules indeed <youpi>perhaps there's a misunderstanding here <youpi>when I say "build", I mean just the compilation <youpi>when I say "install" I mean just dh_auto_install <youpi>not the installation of the package <damo22>i need to put an install target with DESTDIR in the actual makefile <damo22>then i dont need anything special in rules <damo22>one thing that is missing is a libacpica0 package with a .so do we need it as well? i dont know how to compile a shared object <youpi>why 0_ in the upstream tag? you shouldn't need it <youpi>building a shared object is a matter of building .o with -fPIC, and linking them altogether with -shared -Wl,-soname=libacpica0.so.0 <youpi>rather than hardcoding /usr, use $(PREFIX) <youpi>and use libdir=$(PREFIX)/lib <youpi>so that dh_auto_install etc. can override it to /usr/lib/i386-gnu <youpi>why || true for the acpi headers installation ? <damo22>because it finds the platform directory and fails <damo22>i dont know how to use install recursively <damo22>so i cheated and let it skip the dir <youpi>use *.h , that'll avoid the directory <youpi>yes, define a libdir variable to $(PREFIX)/lib <youpi>so that dh_* can override it to /usr/lib/i386-gnu <youpi>not sure how exactly dh_auto_install will pass libdir, but it's the idea <youpi>at worese you can override_dh_auto_install: dh_auto_install -- libdir=/usr/lib/$(DEB_TARGET_MULTIARCH) <damo22>how do you refer to /usr/include in hurd with variables <youpi>possibly dh_auto_install is not setting PREFIX that way, but you can force with the override as well <youpi>usually PREFIX and libdir are defined during dh_auto_configure <youpi>and recorded for the make install to find them <youpi>but you can as well just pass them on fro moverride_dh_auto_install <damo22>ah thats probably why, theres no configure step <damo22>but i thought PREFIX is / in hurd <youpi>PREFIX in / in GNU-GNU-GNU-hurd <youpi>but it's /usr in debian hurd <damo22>gcc -Wall -g -D__GNU__ -I../src/include testacpi.c acpi_init.o -lacpica -o testacpi <damo22>-rwxr-xr-x 1 demo demo 608980 Aug 22 22:10 testacpi <damo22>i pushed a working package to my git <youpi>you also need to create a libacpica0.so symlinks that points to libacpica0.so.0 <youpi>possibly ldconfig happens to create it, but better shpi it