<OriansJ>civodul: I think of Flash the same way I think of the infocom Z-machine, it is just another medium for art. And I see no reason to forbid people from continuing to play zork <Apteryx>When running ert-runner I always get "Invalid reporter: dot". Guess it broke with the recent changes to emacs-build-system. <Apteryx>Indeed, there is no subfolder "reporters" in the store. <Apteryx>jamesrichardson: I'm investigating, but only have 30 minutes before going afk <civodul>OriansJ: yes, though it's a medium that's always been almost inaccessible to free software users <OriansJ>sneek: later tell janneke that the hex2 linker is uploaded <lfam>sneek: I guess we ran out of botsnacks <lfam>sneek doesn't trust my snacks <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 <lfam>Are you using the gcc-toolchain package? <lfam>Okay, that's the end of my suggestions :) <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 6.2.7.5 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 <platoxia>reepca: so, if I want to change the font for exwm would that be through slim or something else? <platoxia>It could be through x server, exwm, or even emacs as far as I know... <reepca>platoxia: I'm not sure, how would you do it outside of guix? <platoxia>reepca: okay, so the guide for exwm on the git page shows configuring both xinitrc as well as .emacs <platoxia>and I guess the rest is through slim like you said <platoxia>a lot of the config in .emacs has to do with getting emacs to auto start when you start exwm...but all that is already handled by whoever made the guix package <platoxia>so ultimately, it must be through slim and xinit <reepca>platoxia: well, what you'd configure through slim would be the xorg.conf file <reepca>for server-side settings. xinitrc, if I understand correctly, is for client-side stuff and is basically just a shell script, right? <platoxia>hmm. I think I can just copy xinit and put in home as a dot file <platoxia>I think that is how exwm handles it anyways <reepca>and I just realized I should be using modify-services in my configuration instead of that big chunk of code <lfam>I was going to suggest modify-services :) <OriansJ>and with that stage0 release 0.0.7 is now available and with build times under 30 seconds on multicore systems ***Piece_Maker is now known as Acou_Bass
***Piece_Maker is now known as Acou_Bass
<sneek>janneke, you have 1 message. <sneek>janneke, OriansJ says: that the hex2 linker is uploaded <janneke>OriansJ: great! and congrats on the fast 0.7! <janneke>oh, `failed to start service console-font-tty1' C-c C-c Exiting shepherd -- hmm? <epronk>janneke: I'm using a /sbin/init that does not more than sleep 99999. Then I use lxd exec to launch shepherd as root so I can see the output. <epronk>janneke: The image is still the usb-installer. <epronk>janneke: The C-c C-c is is actually ctrl-c in Emacs shell buffer on the Ubuntu host. :-) the process runs inside the lxd container. <janneke>it would be nice if shepherd could give some more verbose/debugging info <janneke>wondering why filesystem-/gnu/store cannot be started <epronk>janneke: Maybe I can install this on an ARM server tonight. ***Piece_Maker is now known as Acou_Bass
***Piece_Maker is now known as Acou_Bass
<jlicht>catonano: I have no clue why what I sent over the ML seems to 'work', I just remember running into a similar issue once, finding this solution and then giving up. <catonano>jlicht: ok, thanks. I'll leave it there. If I don't clarify this thing I don't feel comfortable in going forward, with this <jlicht>Is there a nice way to pass on arguments to the build phase of the python build system? <efraim>Before I start asking around on #Debian-ports what was the deal with free Pascal? <rekado>efraim: the free pascal compiler needs the free pascal compiler for building <rekado>efraim: the usual way to port it is to cross-build to a new architecture. <rekado>efraim: I tried packaging the GNU pascal compiler in an effort to build an older version of FPC, but that didn’t get far. <efraim>I was going to try to create a GHC for aarch64 by cross-compiling from x86_64 using qemu <civodul>i forgot how we bootstrapped ghc on other arches <OriansJ>janneke: hopefully you like the hex2_linker <rekado>for GHC there’s still hope. It involves going through Hugs. <efraim>civodul: for the x86_64 and x86 we start with the downloaded binary from haskell <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 <civodul>OriansJ: rekado worked in this direction <civodul>but that wasn't as fruitful as one might hope <OriansJ>civodul: well one programmer, even one as skilled as rekado, can't compete with the dozens of programers working on GHC <civodul>well for Java bootstrapping that worked much better <rekado>It may still be possible to patch the GHC sources a little to allow building them directly. <rekado>I tried to avoid this but then had to patch the nhc sources anyway <rekado>we could cut that intermediate step and go straight to a patched GHC. <rekado>the only problem was that Hugs does not like modules that reference one another. This could be patched. <rekado>I’d like to give this a try after working on Texlive. <rekado>OriansJ: I’m not familiar with this, but I’ll watch the video. Do you mean bootstrapping a more modern GHC by implementing a simpler core language first? <rekado>hmm, the 2017 Texlive’s latex-base no longer compiles :( <rekado>I guess that’s because I’m using texlive-bin from 2016 <rekado>but there’s no new release tarball for that. <rekado>maybe I’ll have to fetch the texlive-bin sources from SVN too <rekado>ah, it’s not on the tug.org servers <janneke>OriansJ: i have just pushed a WIP commit for mlibc/mini-libc-mes.c + scaffold/m.c that procudes an ad-hoc `hex3' format -- without lambdas but still an sexp <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>the great lie of x86 assembly is that a single x86 assembly instruction can map to more than a dozen opcodes <janneke>oh? i'm very new at x86, i only ever did z80 (and some 6502) <OriansJ>yep, an add in x86 has 17 encodings if I remember correctly <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 <OriansJ>janneke: also I'm making a couple steps of the build process parallelizable, which with -j $(nproc) should speedup up the build on multicore systems <janneke>OriansJ: i finally have the feeling things (stage0/mes) are coming together, truly exciting <platoxia>is it a bug that it says installing for i386 after doing system reconfigure or did I not install for x86-64? <quigonjinn>platoxia: i think that is the grub-install output, and i386 is the correct target for x86_64 <jlicht>I just found out that python-apsw has a bundled copy (?) of sqlite :O <nee````>crawl has a problem with upgrading some cached files in it's ~ <nee````>~/.crawl save dir when the timestamps in the datadir are all on 1970. The strings database cache doesn't notice that there are new files in the DATADIR in /gnu/store <nee````>Would it be okay to change the timestamps of those files to the unix timestamp of the crawl version? <efraim>how do I force the install image to only use grub-efi and not grub? <mbakke>there is an odd "ruby-ansi" failure on staging <mbakke>the install phase seems to create some dangling symlink, which in turn breaks the "validate-runpath" phase <mbakke>oddly, the symlink is normal in the build directory, so it's somehow mangled during install <mbakke>efraim: is using grub-efi in the system declaration not enough? <efraim>i've changed grub in gnu/system/install.scm to grub-efi and it still tries to build grub <efraim>i also changed it in gnu/bootloaders/grub.scm <civodul>efraim: i think it needs the two GRUBs to build the image <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 bug-guix@gnu.org? <chatter29>to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger <rekado>I’ve seen this spam on other channels before. It’s almost always chatter29, always the same messages. <janneke>rekado: yay, guix is doing well...or something <rekado>it’s also been on #hurd, I think <civodul>reepca: i thought i'd look more closely at your patch today, but i think i failed <mbakke_>I'm about to merge staging and start a new evaluation <rekado>hmm, the texlive update complicates things a bit. I now have to use luatex for the build system and that means I need to package more things. <mbakke_>added workarounds for the ruby-ansi failure, and one more package with the same problem <janneke>OriansJ: got my first tiny hex3-compiled program to run: ./doit on my wip-hex2 branch <civodul>mbakke_: merging staging sounds good to me <civodul>i was about to reply to your message