<danielszmulewicz>I've written a hello world module. Put it in a directory under the GUIX_PACKAGE_PATH. Now I would like to open it and establish a connection with geiser so that I can evaluate stuff in the REPL.
<alezost>danielszmulewicz: while working with a package file you need to use various modules which you put in a '(define-module ...)'. You can evaluate this clause to make these modules available, but it's likely that guix modules are not available for you right now. Try to evaluate this in the geiser repl: ",use (guix packages)". Do you have "no code for module (guix packages)"?
<NiAsterisk>./pre-inst-env guix environment + what appended is the best way to test a package build in a clean environment to get all direct dependencies to build again and see what's being linked etc and check functionality of a graphical application and daemon (gnunet-arm, gnunet-gtk) later on? I might have fixed it, but I can't be sure because I have like 10 15 or more build dirs of gnunet*
<alezost>danielszmulewicz: how did you install guix?
<detrout>Is there anything like GUIX_PACKAGE_PATH for the emacs M-x guix-all-available-packages?
<lfam>NiAsterisk: `guix environment` shouldn't have any effect on `guix build`. If you want to test the execution of the program provided by package foo in an isolated environment, you could use `guix environment --ad-hoc foo -- foo`
<alezost>danielszmulewicz: ah, ok to make guix modules available you need to set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly. I can think only of one way to do it: by installing guile and guix into your user profile (with "guix package -i guile guix"). Then you can source ~/.guix-profile/etc/profile which will contain all required environment
<alezost>danielszmulewicz: great, otherwise you would end up building old versions of packages. I think recently the manual was improved to recommend "guix pull"
<alezost>also you will probably have to use --no-grafts option for "guix package -i" command: there is a problem in the current master (not sure if it is fixed already) that may lead to building perl if this option is not specified
<alezost>danielszmulewicz: sorry for breaking the conversation, I really have to sleep :-)
<NiAsterisk>BÄM! i think i fixed gnunet-gtk to some degree.. i have not run gnunet-arm , but it's more fixed than the state ricado described on gnunet-dev
<mark_weaver>Jookia: I got an error like that once when reconfiguring. if that's when it happened for you, I guess it's a problem with the new code that means to restart existing services without rebooting.
<mark_weaver>Jookia: it might be that tor-service is already running, or else you might need to reboot
<robsyme>Hi all. When guix calculates the hash that is used to give the package's path in /gnu/store, what is provided as input to the hashing function? Is it the binary files of the dependencies/inputs, or some description of the package (such as the package definition, with inputs replaced by their hash values)?
<mark_weaver>but *.drv files are just text files, and if you look, you'll see that they include references to *.drv files, whose names include the hash
<robsyme>mark_weaver: That probably answers it then.
<mark_weaver>robsyme: note that the inputs don't form a tree, but rather a dag
<mark_weaver>treating it as a tree leads to massive duplication, and real performance problems in practice
<robsyme>mark_weaver: OK. Merkle DAGs are everywhere these days.
<robsyme>I'm looking to try my hand at writing package definitions. I wrote a fairly simple one: https://gist.github.com/robsyme/ac4888b34f84396eaf98, adding the file to a directory in GUIX_PACKAGE_PATH. When I run 'guix package -s codingquarry', it returns the error: "custom.scm:9:2: warning: extraneous field initializers (synposis)". Any pointers in the right direction would certainly be appreciated.
<marusich>robsyme, I think you've misspelled "synopsis".
<civodul>wingo: could you move the elogind tarball to the elogind/ subdir on wingolog.org? :-)
<wingo>civodul: done about 5 minutes before you asked :)
<wingo>ok it's wingo-idle-wishlist time. wouldn't it be AWESOME if you could "guix hack foo" and it would check out the source for foo, put you in an appropriate environment, and then any edits you make to the source get collected into a patch?
<Jookia>I wrote my own mail tools in part to make it so I could just drop some patch files in a directory and send them off
<df_>this leads me to a question about guix environment in general - is one expected to start a new emacs instance in the new environment?
<df_>because depending on what you're hacking and how it seems like that might be necessary
<civodul>df_: to make things nicer, i think we'd need an environment-aware M-x compile
<Jookia>Why is it that the builder can't edit the build directory?
<Jookia>I went to a broken build that was having permission errors, guix environment --container'd my way in and tried to run the script in general, and it failed to write to the build directory. I can't write 'touch 1' either, it fails
<roelj>Can I disable parallelized make jobs in a package description?
<JeanLouis>ringst: if I put "non-free" I am offered non-free software through apt-cache search. I am not running "non free" software. That was my main reason to use Debian in the first place. But now I see what I have missed.
<lfam>efraim: Thanks for adding the Jasper patches
<JeanLouis>basically, because of GNU Manifesto, there is free software, but as it cannot be "modified" in Emacs, Debian is excluding licenses from Emacs editor and putting it in non-free section, thus harming all users and instructing them to install other non-free software in that manner. What a nonsense.
<Jookia>I think regardless of what we all think about it (and believe me, I'm strongly anti-unmodifiable parts) it's not productive to have a discussion about it without offering 'solutions'. I think the best way would be to accurately split and license parts of things, including video games for instance
<rain1>Jookia, yeah mostly I was just learning about this new issue - I packaged a very nice GPL3 game but the levels sets are all a variety of very ad-hoc non-licenses.. I should really split it into two separate parts
<Jookia>rain1: You could package commercially free but non-derivative stuff (so people can put it on CDs)
<Jookia>rain1: I saw a level set that allowed this for TIles World
<rain1>I can sort of understand it (but I think I wouldn't use it for my own things..), and to me software is the really important thing - it's very surprising
<Jookia>Eh, it's very hard to pin down why software should be free but not other content
<phant0mas>hey guys can you access the repo? I am getting "fatal: Could not read from remote repository."
<JeanLouis>I don't care if that piece of text is removed -- but I do care if it is replaced with non-freedom references, such as "install from non-free". They could put a link to it, or anything, or completely remove the option. Right? But no, there was intention to point to non-free.
<Jookia>JeanLouis: Ironically the text they put up is free to modify, so you can change that ;)
<ringst>Would you rather have them not package it at all?
<JeanLouis>and we were speaking here of free software in Debian and how they thought GNU Manufst is not enough free, so they removed it. But Intel firmware is what? Free enough to be included in Debian...
<davexunit>I got lucky many years ago when I switched to GNU/Linux. I had a cheap Compaq laptop that just happened to use an Atheros wireless chip.
<Jookia>JeanLouis: If you think nonfree isn't part of Debian, then Intel firmware isn't part of debian
<JeanLouis>sure I want to watch, I have seen some slides, but rather I read it
<Jookia>JeanLouis: For the sake of specifying your dependencies accurately, so stability and integrity. Ever update your system on Arch and have it break your installed Haskell programs? Me too. Guix dependencies allow multiple package versions to be installed at once
<JeanLouis>Jookia: I never used Arch, and Debian is stable in that regards, normally packages are not broken. I see the point with all the node modules, and pip, cpan, it becomes all mess.
<Jookia>Arch once updated from Python2->Python3 and broke everything
<Jookia>Fantastic but also bad because all your scripts broke
<Jookia>The least you can do with Guix is set up an environment of packages that you can use for your development and use something like CPAN on top of it
<JeanLouis>not separate by version I guess, but for me as user, it is separate from Debian.
<Jookia>Guix has a 'guix import' command that can do that I think
<NiAsterisk>hm.. one aspect I like: debian can be affected by breakage with packages which bring in other package managers and you rely on the phase of the moon to hope your server application still runs when you installed it. with guix you can replicate why it broke and help. (gentoo same, even worse for picking solutions, it's not only the moon, it's the food your cat gets, number of jumping unicorns, moon, and which
<mik_>Anyone very familiar with the configuration of grub in guix system configuration? I can't be sure, but from the documentation it seems to only support MBR grub installation through (cannot specify a partition on a disk, just the disk)
<JeanLouis>mount |grep mapper -- is zero, so it is not mounted any more
<Jookia>mik_: Oh, I only ahve patches that work in the my-os-config.scm
<mik_>Jookia: I guess I was thinking a work-around at the moment would be to manually install grub2 in a efi manner and specify in my system configuration to mount that EFI partition at /boot (so that additional generations can be added to the boot menu)
<mik_>Jookia: is my understanding correct that your patches would support some additional syntax in the operating system specification file (e.g. my-os-config.scm)? So that the workaround wouldn't be necessary?
<mik_>Jookia: thank you. I'll have to do some extra reading; to my embarassment, I haven't even heard of coreboot before
<Jookia>mik_: The coreboot code just moves some files around in /boot/grub/ . For EFI support, I'm unsure where you'd put the partition. Perhaps reusing the device field and relaxing the requirements in the documentation would be okay. These patches aren't upstream yet though
<kqb>hi, I tried guix system vm-image $f, where $f contained the no-X example from the guix-manual. It updated the substitue lists about 20 times in a row and then dumped a stack trace to guix/mondas.scm line 317. The source-code at that location is "