IRC channel logs

<damo22>Pellescours: http://paste.debian.net/plain/1251172

<damo22>that should probe for a USB host controller on hurd

<damo22>you need to build rumpkernel with debug symbols in the static .a files

<damo22>luckyluke: that problem where you can boot proc and auth but not a shell, it could be the same bug we are experiencing on latest glibc

<damo22>mine hangs at proc auth.

<damo22>latest debian glibc

<youpi>please specify "latest", and the hurd version as well

<youpi>cf my mails on debian-hurd

<damo22>ok

<damo22>luckyluke: see https://lists.debian.org/debian-hurd/2022/08/msg00009.html

<Pellescours>damo22: I had the bug, but I updated yesterday hurd and the problem did not appear anymore to me

<damo22>could be due to new hurd package being uploaded

<damo22>i have the bug on a second and third hurd system and still havent recovered it

<damo22>because i only saw the instructions just now

<damo22>it will be good to fix it since i have only 10GB on this working hurd

<damo22>10G is not enough to develop rump drivers

<Pellescours>you can still extend your image ;) (but indeed recover your images is better)

<damo22>my main hurd install is on a raw disk

<Pellescours>damo22: do you pass some special options to your qemu for USB

<Pellescours>oh i SEE

<damo22>Pellescours: you can experiment with "-usb"

<damo22>i dont know if it passes through host

<damo22>or emulates the controller

<Pellescours>ok cool

<damo22>hurd-prof : Depends: hurd-libs0.3 (= 1:0.9.git20220206-1+b1) but 1:0.9.git20220818-1 is to be installed

<damo22>nm i removed that package

<youpi>bleh, I forgot to build hurd-prof

<Pellescours>I sometime have my hurd VM that does not shutdown when I do reboot. My ssh look like it’s executing the command (does not give me hand but when I type text, it appear on the line) and on the console, I cannot login

<Pellescours>(I don’t know if it’s clear or not but I had to hard kill my VM)

<damo22>i seem to have to press ctrl-c twice every time i log into a shell before i get a prompt

<Pellescours>I don’t have this problem

<Pellescours>I have the "illegal hardware instruction" with your test file, great

<damo22>sudo

<Pellescours>I’m running in root

<damo22>?

<damo22>ok

<damo22>yes the usb crashes

<damo22>but the acpi one works as root

<Pellescours>with gdb I have the stack trace

<damo22>does it have full symbols?

<damo22>or empty parameter lists in function calls?

<Pellescours>On the console I can see uhci0 at pci0 dev1 function2: vendor 8086 product 7020 (rev. 0x01)

<damo22>yes

<Pellescours>empty parameter list

<damo22>it fails to probe

<damo22>thats all i know

<damo22>you need to compile rumpkernel with DEB_BUILD_OPTIONS=nostrip or something like that

<Pellescours>or to install the package with gdbsym

<Pellescours>I have all the package with dbgsym installed, maybe that’s not enough

<damo22>last i checked, that was not enough for statically linked binary because it strips the .a files

<damo22>but it does not seem to link properly when you use .so

<Pellescours>Ok, I will rebuild rump then

<damo22>because there are no explicit symbols at compile time so it drops the whole linkage of the shared object

<damo22>im not sure if you can force it to dynamically link with ld

<damo22>i dont know how to load the dbgsym symbols in gdb for a binary that loads the shared object at runtime... i guess that is the problem

<damo22>but also, the usb controller does not get probed when you compile without -static

<Pellescours>they should be located at a place where gdb looks by default for loading them, otherwise there is a simple command to say to gdb to load a symbols

<Pellescours>I building rump with nostrip, that will be easier

<damo22>yes i wanted to do that at some point

<damo22>but have been stuck

<Pellescours>damo22: what does your work with acpica will unlock? better irq? (there is still a lot of component that are still obscure to me in a computer)

<Pellescours>I know that acpi handle power managment and is needed to do plug and play

<damo22>in essence, it allows one extra function, to look up IRQ of PCI device from the hardware

<damo22>and reads the correct shutdown sequence from the hardware

<damo22>so 2

<damo22>but if someone wants to implement more there will be that translator available

<Pellescours>okay

<damo22>i only did this work because it was necessary to move forward with APIC interrupts

<damo22>since there is no other way to obtain the IRQ number of a pci device

<Pellescours>And IRQ of pci is mandatory for stuff like USB is suppose

<damo22>yes you need to know which interrupt to use for usb

<damo22>for the host controller on pci

<Pellescours>Build complete, I have the full stack trace with args

<damo22>woot

<damo22>i cloned rumpkernel using rumpdisk-backed storage without a page fault

<Pellescours>this is this line that page fault: __asm__ __volatile__("out %0, %1" :: "a"(v), "d"(addr));

<Pellescours>file src/sys/rump/dev/lib/libpci/rumpdev_bus_space.c:190

<damo22>page fault? do you mean illegal instructoin?

<Pellescours>illegal instruction yes

<damo22>what address is it trying to out to

<damo22>like what is the value of addr?

<Pellescours>in bus_space_write_2 (bst=0, bsh=49216, offset=4, v=0) at ./buildrump.sh/src/sys/rump/dev/lib/libpci/rumpdev_bus_space.c:190

<Pellescours>so 49220

<damo22>so 0xc044

<damo22>that sounds familiar, like qemu reserving that i/o port

<Pellescours>how can I check that

<damo22>i think 0xc000 to 0xcfff is a reserved range in pci-userspace?

<damo22>PCI_CFG2

<damo22>i cant remember if i removed that or not

<damo22>check pci-user_gnu.c

<damo22>in pci-userspace in rump

<Pellescours>yes start 0xC000 end 0xcFFF

<Pellescours>damo22: are you sure about this line in pci_user-gnu:

<Pellescours> /* 0xd000-0xffff */ if (ioperm(PCI_CFG2_END+1, 0x10000 - (PCI_CFG2_END+1), 1))

<damo22>i added some commits in git.zammit.org

<damo22>im trying to pull them but my rumpkernel tree did not sync

<damo22>tmpfs ran out of space

<damo22>and crashed

<Pellescours>aie

<Pellescours> https://salsa.debian.org/hurd-team/rumpkernel/-/blob/master/pci-userspace/src-gnu/pci_user-gnu.c#L112

<Pellescours>I’m not sure if it’s normal in this line to not use the START and use END 2 times

<damo22>Pellescours: http://git.zammit.org/rumpkernel-debian.git/log/?h=develop

<damo22>this branch might have better results

<damo22>we should not be carving out the PCI_CFG2 hole

<Pellescours>I’m testing with the last commit of this branch

<damo22>cool

<Pellescours>process exited normaly

<damo22>can you pastebin the full log

<damo22>with the RUMP_VERBOSE=1 and RUMP_NCPU=1

<Pellescours> https://pastebin.com/CDMigfny

<damo22>no it should dump something to console

<damo22>even without gdb

<Pellescours>in the qemu console (cannot copy easily) I have normal stuff + 1 WARNING

<Pellescours>WARNING: 1 error while detecting hardware; check system log.

<damo22>it would be great to see that full log

<damo22>you could attach a serial console

<damo22>or just run -curses and copy paste from the terminal

<Pellescours>bad news, my VM does not respond

<damo22>:|

<Pellescours> https://i.imgur.com/mCyObN6.png

<damo22>uhci0: init failed: error 12

<damo22>but it probed something

<damo22>so got further

<damo22>it also registered an interrupt handler for irq 11

<damo22>argh i uncompressed a 900M tarball and sync'd and now my shell is frozen

<Pellescours>Ah I think the irq is conflicting with my ssh connection and that’s why I got freeze last time

<Pellescours>because on the qemu console I still have hand

<damo22>i dont remember if we support irq sharing anymore

<Pellescours>I remember having irq sharing issue in the past

<Pellescours>Ah I tried to kill rump and my VM got completely frozen

<damo22>you probably killed the disk driver too

<Pellescours>but I’m on the linux driver

<damo22>ok

<Pellescours>by running it from qemu console (not gdb) I had some logs about irq ("released 1 unpacked irq ...", "release 1 dead port ...", "remove entry ..."), normal cleaning stuff

<damo22>interesting

<Pellescours>and here my ssh is working

<Pellescours>uhci_init() in buildrump.sh/src/sys/dev/usb/uhci.c

<Pellescours>this is where the return 12 comes from

<Pellescours>the error code 12

<damo22>see if you can figure out why its erroring

<damo22>and what 12 means

<Pellescours>it seems to be an allocation failure

<Pellescours>all returns relates to that (ENOMEM, USBD_NOMEM)

<Pellescours>it can be USBD_TODEEP

<Pellescours>it can be USBD_TO_DEEP which has the value 12 (USBD_NOMEM is 5)

<Pellescours>i’m trying to check with gdb

<damo22>i still cant copy or clone rumpkernel package without freezing up my hurd

<damo22>:|

<damo22>do i need swap?

<Pellescours>try to copy in your fs and not in your tmpfs

<damo22>im not using tmpfs

<Pellescours>it seems to be this line that cause issue, still investigating https://salsa.debian.org/hurd-team/rumpkernel/-/blob/master/buildrump.sh/src/sys/dev/usb/uhci.c#L476

<Pellescours>I confirm the error 12 is ENOMEM and is due to uhci_alloc_std() failling

<damo22>step into that function

<damo22>git checkout does not seem to cause sync to disk often enough

<damo22>and eventually it fills up and cannot sync

<damo22>i was able to check out my branch on rumpkernel by manually syncing periodically during checkout

<Pellescours>wow tricky

<damo22>i dont have any swap space configured

<damo22>maybe that is the problme

<Pellescours>I hate that keyboard configs with qemu console, I never get the letter I want

<damo22>Pellescours: dpkg-reconfigure keyboard-configuration

<Pellescours>still having qwerty… rebooting to see

<Pellescours>things changed yay, but still not what I want

<damo22>im compiling rump with my changes

<Pellescours>usb_allocmem failed to usb_block_allocmem

<Pellescours>usb_bloc_allocmem fail due to bus_dmamem_alloc (usb_mem.c:170)

<Pellescours>I’m getting to a point where i’m too deep in the stack to think the problem is deeper (I’m in bus_dmamem_alloc)

<Pellescours>bus_dmamem_alloc (t=0x20, size=8192, alignement=16, boundary=0, segs=0x20019280, nsegs=1, rsegs=0x200498d0, flags=0)

<Pellescours>I enabled the print in https://salsa.debian.org/hurd-team/rumpkernel/-/blob/master/buildrump.sh/src/sys/rump/dev/lib/libpci/rumpdev_bus_dma.c#L535 and the message before failure is strange "dma allocation 10 0 1", it shouldn’t be 10

<damo22>maybe the units of alignment is in log2(bytes)

<Pellescours>Ah ok, It’s because it’s l*x* the formatter

<Pellescours>and just before this "dma allocation 10 0 1" message there is another one "dma allocation 1000 0 1"

<Pellescours>can this one take all the space?

<damo22>hmm

<damo22>im asking upstream what the units are

<klys_>w00t

<Pellescours>I changed the print to display the size and the alignement in number and not in hexa

<damo22>i think its 0x10

<damo22>and 0x1000

<damo22>so the alignment is to the nearest 16 bytes etc

<damo22>that actually makes sense

<damo22>maybe rumpcomp_dma_alloc has a bug?

<damo22>in pci-userspace

<Pellescours>it first does a dma allocation of 4096 with an alignment of 4096 (that succeed) and then a dma allocation of 8192 with an alignment of 16 (which failed)

<damo22>are we able to do dma allocs of more than one page?

<Pellescours>I don’t know

<damo22>check gnumach in vm_allocate_contiguous

<damo22> if (vm_allocate_contiguous (master_host, mach_task_self(), &vma, &phys, size, 0, 0x100000000, align)) {

<Pellescours>FIXME if(palign != PAGE_SIZE) return KERN_INVALID_ARGUMENT;

<damo22>that would be it

<Pellescours> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/vm/vm_user.c#L594

<damo22>well we need to fix that

<damo22>what we could do, is if palign < PAGE_SIZE and PAGE_SIZE is divisible by palign exactly, we could just use PAGE_SIZE

<damo22>it will still be aligned to 16, but at a page boundary

<damo22>do you want to try that?

<Pellescours>yes

<damo22>i dont know if that will cause issues, i can only see if it gets called a lot with a smaller alignment, it might be wasteful if we need lots of them

<Pellescours>it worked… kinda

<damo22>what happened

<damo22>did you modify pci-userspace or the kernel?

<Pellescours>instead of allocation failed I got 3 more allocations (so 5 dma allocation in totoal) and then "usb0 at uhci0: USB revision1.0" and then

<Pellescours>panic: kernel diagnostic assertion "xfer->ux_bus->ub_usedma == fa..."

<Pellescours>I modified the kernel

<Pellescours>So the modification worked

<damo22>that is not a gnumach panic, its just rump panicking

<damo22>you can dig into that with gd

<damo22>gdb

<damo22>cool

<Pellescours>the crash happen in usbd_alloc_buffer (size=8, xfer=0x200a0020)

<damo22>it may be easier to turn on #if 0 in pci-userspace and compile with debugging in the rump hypercalls

<damo22>for example, it would have mach_printed vm_allocate_contiguous

<Pellescours>rebuilding with mach_print enabled in pci-userspace

<Pellescours>it does not helps, I have no more message about allocation

<damo22>it will only appear in console

<damo22>not on the terminal over ssh

<Pellescours>yeah, I’m running the test only with console (ssh irq sharing issue) and I have some more message but no one usefull for alocation

<damo22>it should help a little

<damo22>maybe the newest bug is not related to allocation

<Pellescours>I don’t think it’s allocation related

<Pellescours> https://salsa.debian.org/hurd-team/rumpkernel/-/blob/master/buildrump.sh/src/sys/dev/usb/usbdi.c#L515 this is this assert that fails

<Pellescours>looks like the variable NUSB_DMA was 0 during the build

<damo22>interesting!

<damo22>there are config files that have #define NBLAH_BLAH 1 in them

<damo22>eg in ahcisata

<damo22>maybe we are missing some config for usb in there

<damo22>file needs to go in here: https://salsa.debian.org/hurd-team/rumpkernel/-/tree/master/buildrump.sh/src/sys/rump/dev/lib/libusb

<damo22>i got this:

<damo22> [ 1.0200050] uhci0 at pci0 dev 29 function 0: vendor 8086 product 2934 (rev. 0x03)

<damo22> irq handler [10]: new delivery port f6267620 entry f677df48

<damo22> [ 1.3200050] uhci0: interrupting at pausebreak

<damo22>HANG

<damo22>but irq 10 is my AHCI disk

<Pellescours>yeah irq sharing stuff, I had to use the console and stop using ssh to be able to get there

<damo22>why cant we share irqs?

<damo22>that might be the next thing to look into

<Pellescours>I removed this # if to check If I progress but if it’s working we should just add -DNUSB_DMA=1 to the build.sh invocation

<damo22>dev/usb/usbdi.c:#if NUSB_DMA > 0

<damo22>thats the only place i could find this

<Pellescours>yes

<damo22>there are two checks

<damo22>in the same file

<Pellescours>1 for the allocation and 1 for the dealloc

<Pellescours>so for now there is 3 changes, your patch for iocomp, the gnumach vm_allocate_contiguous and the NUSB_DMA to define

<damo22>yeh but they are all independent changes

<damo22>im compiling a rump with that now

<Pellescours>ANND it works

<damo22>\o/

<damo22>log

<Pellescours> https://i.imgur.com/pjAt3TJ.png

<Pellescours>I left the dma allocation changes in my build

<damo22>nice one

<Pellescours>I let you send the patches, I got to bed (7h24 AM hehe)

<damo22>lol

<damo22>nn

<Pellescours>And so after, what will be the next step?

<damo22>im not sure yet, exposing the controller as a node?

<Pellescours>The irq sharing also probably

<damo22>and then compiling yet another rump driver to attach the per-device drivers to it

<damo22>eg, uaudio

<damo22>umass

<damo22>what im not sure about is how to split the usb stack into two, so we dont duplicate the host controller driver for every device we want to connect

<damo22>this is an issue because usually everything sits in the kernel

<damo22>biblio: thank you for your help with ACPI a while ago, it is coming to fruition soon

<damo22>ive just mailed in some patches that get USB probing

<biblio>damo22: welcome. If you need any further patch let me know.

<biblio>damo22: I am trying to read OS books to fix pending 64bit issues. Meanwhile, I wrote a script to install and configure openstack on debian: https://dynamicmalloc.com/cgit/debian_openstack_installer.git . My idea was if we can create a 32-bit Hurd image that can run on OpenStack.

<biblio>damo22: if we can run Hurd 32 bit on Openstack it can be used by many people for simple live projects. :)

<damo22>nice

<damo22>biblio: see luckyluke's work, he is working on 64 bit support

<biblio>damo22: yes I am checking his code time to time.

<biblio>damo22: creating openstack image for Hurd wont be so difficult. https://docs.openstack.org/image-guide/create-images-manually.html if hurd 32 has some extra drivers.

<damo22>extra drivers?

<damo22>i think acpi shutdown already works

<biblio>damo22: I tried to install debian hurd installer CD in a qemu VM but it failed to boot.

<damo22>yes i had a similar problem, but i was able to work around it

<damo22>it needs some special qemu options i think

<biblio>damo22: ok. I am not sure - which things are pending if we want to create a Hurd 32 image using damo22: in general - https://docs.openstack.org/image-guide/create-images-manually.html

<damo22>also, it matters which version of the installer you trie

<damo22>d

<biblio>damo22: I downloaded latest Debian CD.iso for HURD

<damo22>from where

<biblio>damo22: I think it was from debian repo

<biblio>damo22: https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/

<biblio>damo22: cd-1.iso

<damo22> https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/

<biblio>damo22: ok

<damo22>stable, not latest

<biblio>damo22: ok sure I will test

<damo22>i followed the debian hurd installation guide

<damo22>it points to stable version of the installer

<biblio>damo22: ok

<damo22> https://www.debian.org/ports/hurd/hurd-cd

<biblio>damo22: thanks will try this one. :)

<damo22>im not sure which version of qemu you need, but compiling it on the latest commit is probably a good idea

<biblio>damo22: i am using Debian Test on that machine. So, qemu is not so old. But yes if it fails then I will try latest qemu

<biblio>damo22: yes it works :D

<damo22>youpi: how do i create a new debian package?

<biblio>damo22: you may check https://www.debian.org/doc/manuals/debmake-doc/index.en.html

<youpi>damo22: one can force dynamic link by using e.g. -Wl,--undefined=foobar to force requiring the foobar symbol, and thus the linking of the .so that contains it

<youpi>damo22: dbgsym symbols are automatically loaded, through the build-id

<damo22>cool

<youpi>concerning the out accesses of rump, it should instead use libpciaccess

<youpi>poking at pci cfg ports will get mixed with other accesses from other translators ; that has to go through the pci-arbiter

<damo22>no, pcicfg2 is not used for configuration of pci, it is legacy and no one uses it

<damo22>qemu maps these io ports to actual hardware like ahci

<youpi>damo22: we have support for shared irq in the gnumach irq notification

<damo22>i think ive seen hardware use these io ports natively too

<youpi>Pellescours: when using the curses console, you have to tell qemu which keyboard layout you have on your *host* side

<youpi>so that qemu knows which scancode to send to the guest

<youpi>and then you can configure what you want in your guest

<youpi>(-k option)

<damo22>something is not working regarding sharing of irqs, we need to look into that

<youpi>damo22: I didn't know about debmake, I usually use dh-make

<Guest79>damo22: I think youpi meant implementing lines 605 to 610 of https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L605 but I might be wrong

<biblio>youpi: ok I think it is newer. My last package I used dh-make as well.

<damo22>thats interesting... why does the libpciaccess hurdish method of .read and .write go through x86 way?

<damo22>does anyone use read32 and write32

<damo22>etc

<damo22>sorry i mean .read and .write are ok but the ones with numbers following like .read8

<damo22>they should indeed be implemented if they are being used at all

<damo22>but i dont think that is related to the PCI_CFG2 registers

<youpi>that's odd indeed, that should be fixd

<gnu_srs>youpi: Build logs from e.g. llvm-toolchain-13/14, gcc-12: undefined reference to `pthread_once. What's up?

<youpi>I don't know

<youpi>pthread_once is of course provided by libpthread

<youpi>possibly there's a -lpthread missing there, no idea why suddenly that'd be so

<youpi>aka, needs investigation

<damo22>-rw-r--r-- 1 demo demo 314812 Aug 21 21:31 libacpica-dev_0.0.0-1_hurd-i386.deb

<damo22>youpi: http://git.zammit.org/libacpica-debian.git/

<bo>Can someone recommend reading material like end-user handbook? I'm not an experienced user, but managed to install debian hurd distribution, but from that moment I'm completely lost, since there are no tutorials on how to set up X

<damo22>bo: welcome, its a bit tricky to get X working in hurd because it only supports one graphics driver currently, the VESA one

<damo22>you could try "sudo tasksel" in a terminal and select to install the relevant environment

<damo22>goondnight

<damo22>goodnight*

<Pellescours>youpi: yeah I know for -k option but It was not working for me, and I use bépo configuration which seems to not be supported so that was more complicated

<Pellescours>goodnight

<youpi>Pellescours: then contribute to qemu the support for that layout :)

<Pellescours>I saw a patch https://qemu-devel.nongnu.narkive.com/aHlbgRt6/patch-add-bepo-french-dvorak-keyboard-layout, it seems to be applied 12 years ago, interresting

<Pellescours>AH ok the keycode is not fr-bepo but just bepo ahhh

<Pellescours>why the keycodes are all different depending on the software…

<Pellescours>It’s definitely not my layout, bépo == ge:q

<Pellescours>for the llvm-toolchain pthread stuff it’s probably related to the change of glibc2.34, the pthread library was integrated into glibc and -lpthread is not needed anymore https://abi-laboratory.pro/index.php?view=changelog&l=glibc&v=2.34

<youpi>bo: https://www.debian.org/ports/hurd/hurd-install

<youpi>bo: though IIRC X currently has an issue that prevents it from starting

<youpi>it shouldn't be hard to fix

<youpi>just nobody has taken up the task yet

<youpi>damo22: it's not tricky to get X working (when it is working :) ) since X already defaults to using the vesa driver

<youpi>Pellescours: because it's all different depending on the hardware, for a start

<youpi>Pellescours: no, the libpthread library was not integrated into libc.so in the hurd case

<youpi>so -lpthread is still needed

<youpi>and I don't think gcc has already switched to avoiding passing -lpthread, since so many OSes still require it

<Pellescours>it’s said in the readme the -lpthread continue to work but does nothing (backward compat), but I was not aware of the hurd case

<Pellescours>s/readme/changelog

<Pellescours>youpi: is the package construction package still running? I can’t use apt because the rump dbgsym packages are making conflicts

<Pellescours>package construction of rump*

<Pellescours>librump0-dbgsym depends on librump0 (= 0~20211031-1) but 0~20211031-2 is installed

<youpi>I don't know about a version 0~20211031-2

<youpi>that must be something you have built yourself

<youpi>and just didn't install the dbgsym piece

<youpi>note: librump0 and librump0-dbgsym are always built at the same time

<Pellescours>I removed the dbgsym packages and that fixde the stuff

<Pellescours>but yeah the rump packages installed are the one I built for usb tests

<Pellescours>except th dbgsym ones which comes from apt

<youpi>damo22: use an "upstream" branch to keep the upstream source, and a tag there to know which commit is used as upstream source

<youpi>version: rather than 0.0.0, use the date, like acpica-unix does

<youpi>your debian/control is missing various build-dependencies. To detect which, you can use "sudo pbuilder create" to easily create a minimal chroot and then "pdebuild" to build the package within that chroot

<youpi>You don't need the debian/libacpica-dev.dirs file, debian/rules's dh_auto_install already creates what it needs

<youpi>README.source talks about Makefile.refreshsrc, but it's not there

<youpi>You can remove all the post*.ex pre*.ex, they're only examples

<youpi>in debian/rules, use install rather than mkdir and cp

<youpi>ah no there's no missing build-dep

<youpi>I'm surprised :)

<youpi>apparently build-essential is enough, good :)

<youpi>it does not build on linux, though, you're missing -DBUILDING_ACPICA in the Makefile

<youpi>and thus we get ./include/acpi/platform/aclinux.h:18:2: error: #error "Please don't include <acpi/acpi.h> directly, include <linux/acpi.h> instead."

<youpi>Mmm, it'll be tricky to build it on linux anyway

<youpi>since it uses linux/ctype.h and various kernelish stuff

<youpi>so we can as well not bother

<youpi>and just upload it to debian-ports' unreleased

<youpi>still the Makefile could go upstream

<bo>youpi: thanks for the article, I saw it, but cannot follow it, since dpkg-reconfigure does not exist in my system for some reason. Apt install dpkg-reconfigure says it was "Unable to locate" this program. So I'm stuck

<Pellescours>install debconf

<Pellescours>and maybe also debconf-i18n

<Pellescours>(the second one is not mandatory it just brings translations)

<bo>Pellescours: debconf is already the newest version

<bo>But reconfigure has somehow appeared. Weird.

<Pellescours>a typo in the previous command maype

<youpi>bo: make sure to use sudo -i

<youpi>not just sudo

<youpi>otherwise you don't have sbin in your PATH

<youpi>about gcc's pthread_once, possibly what happened is that it links against -lrt, and that used to bring libpthread in, but that's not the case any more

<youpi>so a -lpthread is really missing then

<youpi>we have the same issue in faketime

<jab>youpi: Have you heard that prescheme is being ported to guile?

<jab>Looks like we could have another "systems language" in guile...I think they are calling it guile-steel

IRC channel logs

2022-08-21.log