<Apteryx>jamesrichardson: I've created bug#27222 to track this issue.
<reepca>I find myself having to constantly add to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to get it to search subdirectories of ~/.guix-profile/include. For example, gnash wants glib.h but I have ~/.guix-profile/include/glib-2.0/glib.h. Any easy way of dealing with that, or just lots of path modification?
<reepca>Also, before I go too deep down this rabbit hole, does icecat even support npapi plugins anymore? I know firefox ditched them awhile back
<platoxia>am I correct in assuming that X server config and window manager config should be done through the system configuration file?
<reepca>hm, even pkg-config is just giving me the top-level include directory for jemalloc, but gnash has #include <jemalloc.h> not #include <jemalloc/jemalloc.h>
<reepca>platoxia: the default slim-service that's included in %desktop-services generates an xorg configuration, you can replace that service with one with some custom stuff appended to the xorg configuration. See section 184.108.40.206 of the manual "X window" for exactly how to do that - basically you replace the slim service in %desktop-services with one you create yourself using (slim-service). slim-service takes an optional #:startx command,
<reepca>which takes an optional configuration file, which is generated by xorg-configuration-file, which has a #:extra-config section where you can append extras.
<platoxia>lolz, man what ever happpened to text configuration files
<platoxia>well...I guess it is exactly that isn't it
<civodul>i remember long ago Nikita tried hard to avoid that
<OriansJ>civodul: if I remember correctly, we needed someone to do a bunch of work just to either convert existing haskell compilers written in C or to extend the haskell interpreter written in lisp in order to solve that bootstrapping problem
<janneke>OriansJ: my plan now is to get a minimal program linked and running again, using something that resembles hex2
<janneke>after that, just go straight hex2 or write a trivial hex3->hex2 :-)
<janneke>OriansJ: I think I'll my `hex3' into an alist with text and data so that I can trivially reuse my ->elf, we'll see
<OriansJ>janneke: both are reasonable plans. I'll probably use this to cleanup the makefile more
<janneke>OriansJ: OK, we'll learn what works best as we go
<janneke>OriansJ: one question: i'm currently using the trick outputting `label #f #f #f' for a 4 byte label and `label #f' for a two byte label, so that before as well as after the lengths/addresses will be the same
<janneke>OriansJ: that seems OK for simple CALLs but i'm wondering how to do that with JUMPs, it would be nice not to hard-code the type of jump together with the jump label size beforehand?
<janneke>sort of intermediate between assembly and hex...
<janneke>i can keep the hardcoding for now, that has been working ok, but...hmm
<OriansJ>janneke: you can treat jump displacements the same as call displacements and you always will have to encode a separate hex instruction for 16 and 32 bit displacements since they don't map to the same opcode
<OriansJ>but I must be honest here, I'll probably be sending you a patch for making the output in hex2 and for the sake of simplicity I'll probably fix all displacements at 32bits as program density isn't a priority at this time
<efraim>i'll have to come back to it later, my linux-libre package doesn't have a bzImage for qemu to load
<efraim>linux-libre on x86_64 has bzImage, on aarch64 it doesn't
<mbakke>civodul: you're right, but I don't see why :)
<mbakke>also, just using grub-efi in (gnu system install) won't work, because it will fail to install without a UEFI qemu firmware
<mbakke>using --no-bootloader should still produce a uefi compatible disk image though
<adamvy>So I've been trying to run guixsd from an encrypted nvme rootfs, but the nvme device nodes show up _after_ the boot process tries to run cryptsetup (which fails because the device isn't there yet). Any advice on this?
<civodul>adamvy: it may be a bug on our side: the luks-device-mapping code seems to assume that the "source" device is ready when it spawns cryptsetup
<civodul>see open-luks-device in (gnu system mapped-device)
<civodul>could you email the problem to email@example.com?