<vagrantc>it appears to have worked... but i don't understand how <vagrantc>e.g. i was grepping the contents of the unpacked source during the build, after the unpacked phase, and it didn't have the substitutions <noobly>so when using guix, I don't have to use any emacs specific package management? do I still use use-package? <civodul>noobly: i highly recommend using emacs-guix instead of package.el & co <civodul>i'm sure you'll love it like many of us do :-) <vagrantc>sometimes it seems guix packaging updates seem to be as much about fixing/disabling/workaround test suite breakages as anything <g_bor>vagrantc: yes, and sometimes you can dig up something really interesting, like: this test uses random stuff, and does not pass at a chance of 1:1000, and stuff like that... <g_bor>good night, I have to go now <noobly>civodul: I heard about it but wasn't quite sure what it replaces within my .emacs, definately looking forward to using it and using guix over pip and friends <sykloid>Is there any way to specify a package's source without the hash? I want to test my first package definition out, and the sha256 in url-fetch is giving me guile errors I don't understand. <pkill9>sykloid: yes, with '(source #f)' <pkill9>sorry i misread the question, that won't fix it <pkill9>i don't think you can. What are the errors exactly? <mange>I think you could download it yourself and use (local-file ...) as your source, but I'm not sure of the details. What's the error you're getting? <mange>It would be better if we could fix your error. :) <sykloid>Specifically, "In procedure url-fetch: Invalid keyword: #vu8(...)" <sykloid>right, let me find a way to post my package definition. <sykloid>Er, oops. copy-paste error. Removing that and the error still stands. <amz3>invalid keyword has nothing todo with the hash <amz3>Usually, that's the point where I can not help, but it gives time for knowlegeable people to do their own thing, so I hope it was helpful <vagrantc>sykloid: download the file manually and compute the hash with: guix hash FILE <vagrantc>does it need the (define-public ripgrep (package (... bit? <sykloid>I wouldn't think that matters? I can add that, but I'd need to select specifically the ripgrep package to build (`guix build -f ripgrep.scm' wouldn't cut it) <sykloid>I don't seem to be doing anything particularly different from other uses of url-fetch, so I have no idea where the bug is. <ArneBab>does scribus build for you? I get make[2]: *** [scribus/plugins/import/pdf/CMakeFiles/importpdf.dir/build.make:117: scribus/plugins/import/pdf/CMakeFiles/importpdf.dir/slaoutput.cpp.o] Error 1 <amz3>sykloid: sorry, I don't say anything wrong with you package definition <sykloid>For me too. Thanks amz3, I'll try posting to help-guix later. <Swedneck>hi, i'm trying to learn to configure guix in a vm, how do i specify a keyboard layout in the config.scm file? <Swedneck>i tried adding `(console-keymap-service "sv-latin1")` to `(services (cons*`, but that doesn't seem to work <ebrasca>How to make guixsd to save kernel in boot partition? <ebrasca>I have 1 boot partition and root encripted. <vagrantc>a separate /boot partition isn't well supported at the moment <vagrantc>if you're using luks encryption, you can have the bootloader get the kernel from the encrypted disk <vagrantc>you'll have to type your password twice (once to unlock from grub, once for the kernel to mount the root filesystem) <ebrasca>vagrantc: How I can make it to start? <vagrantc>ebrasca: have to go soon, but a number of people use that setup. good luck! <Misha_B>hello, I'm having this problem with icecat where all the characters are the square symbol <Misha_B>unicode of not being able to display the font maybe <nand1>refer to the guix manual: Installation > Application Setup > 2.6.3 X11 Fonts <nand1>maybe you have to install some font packages <mange>sykloid: If you're still around, I just got a chance to look at your problem. You're pulling in (guix build download), but you want to pull in (guix download). <reepca>mange: nice catch! I didn't realize they both had a url-fetch. <mange>Either did I! Certainly makes the issue hard to debug. <ebrasca>Because I like lisp I program some parts of Mezzano OS ( OS writen in cl ) . <bavier`>here's a good one: webkitgtk ftbfs when using '-j1', needs at least '-j2' :/ <reepca>sneek: later tell civodul: did your 'guix download' of texlive ever finish? It'd be nice to confirm it's not just some bizarre network problem on my end. <graton>Will a default GuixSD install (plus Xorg, Emacs, EXWM, and Icecat) work on a Thinkpad T400 with the default BIOS if I have the RYF-certified WiFi dongle? <ebrasca>I can't update with "guix system reconfigure /etc/config.scm" due to linux-libre don't compile. <ebrasca>And if I install with "guix packages -i package" I can't call "% package" <mange>Normally to update you'd do something like "sudo guix pull && sudo guix system reconfigure /etc/config.scm". Did linux-libre fail to compile for you? <mange>Often there would be substitutes for packages, but depending on when you pull and what has changed recently the substitute servers might not have finished building everything yet. <ebrasca>Why in GuixSD compilations fail ? In gentoo I can compile and don't get compile errors with linux. <ebrasca>mange: My last error is due to "download failed of linux" <mange>Does it print the URL that it was trying to download? <mange>You can't disable reproducible builds, but they also aren't enforced. It's just that the build is done in an insolated build container so the rest of the machine's state doesn't affect the build. <ebrasca>I have installed curl but I can't call it. <mange>How have you installed curl? <mange>Hmm. What's the value of $PATH? Does it have $HOME/.guix-profile/bin in it? <mange>Oh, then it will be part of the root profile, not your user profile. <mange>If you run "guix package -i curl" then you'll install it for your user, and you'll be able to use it. <ebrasca>Why I need to install 1 package multiple times? <mange>It's actually just adding some symlinks to your user profile, not downloading it again. <mange>But your user profile is separate to the root user profile - each user can have their own packages installed. <mange>You can also have arbitrary other profiles/environments with different packages, all without interfering with each other. <ebrasca>I like to have my own dd and destroy all data of owner. <mange>It's not something that Guix is particularly designed to do. In theory it's possible, but you might be treading some new ground in doing so. <mange>You'd definitely be sacrificing substitutes to do that, but if you're coming from Gentoo that might be something you're okay with. <mange>Okay, well, I can understand that failing given that file doesn't exist in all the places it tried. It looks like the most recent version in the guix repository is 4.20.2. Did you "sudo guix pull" before trying to reconfigure? <mange>What's the output of "sudo guix describe"? <ebrasca>guix describe: error: failed to determine origin <mange>Okay, that's interesting. Do you have a symlink in ~root/.config/guix/current? If so, can you try running "sudo ~root/.config/guix/current/bin/guix reconfigure /etc/config.scm"? <mange>There was a change in the pull mechanism a bit ago which changed where pulls went, and there are some issues that come up in the transition that I'm unfamiliar with. <mange>Once you've got the new one it's sweet, but moving from the old one to the new one can go wrong in ways that I don't *really* understand. <mange>So the ~root/.config/guix/current symlink exists, and running that command gave you that output? <mange>That is a surprising outcome. <mange>Unfortunately I have to go now, so I can't help you to work this out. ***rekado_ is now known as rekado
*rekado builds a patched ghc on berlin <rekado>once the new ghc is built I can push the patch to master <rekado>civodul: I forgot to mention this yesterday, but I’ve already rebooted a bunch of build nodes (up to hydra-guix-15); they could all be used as build nodes for aarch64 / armhf. <civodul>rekado: awesome, i'll update machines.scm so we can start using a few of them <civodul>rekado: could it be that you forgot (guix-support? #t) for qemu-binfmt? <civodul>i don't see the long list of --chroot-directory flags on the guix-daemon command line <Swedneck>hi, i'm trying to learn to configure guix in a vm, how do i specify a keyboard layout in the config.scm file? <Swedneck>i tried adding (console-keymap-service "sv-latin1") to (services (cons*, but that doesn't seem to work <civodul>Swedneck: what error message do you get? <Swedneck>yeah i looked there but it's not really easy to figure out for a newbie <ebrasca>When I guix pull & guix system reconfigure /etx/config.scm <civodul>Swedneck: so what command did you run? <Swedneck>that's my config, which i just run `guix system vm` on <civodul>this config is valid and 'guix system vm config.scm' works for me <civodul>what do you mean by "it does nothing"? <Swedneck>it doesn't actually change the layout in the VM <civodul>well that only changes the layout for the console, not for Xorg <civodul>setting the layout globally is something we're working on <ebrasca>Why if I have guix-0.16 when I run "guix system reconfigure /etc/config.scm" it tries to downgrade to guix-0.15.0 ? <janneke_>i want to have my X listen on tcp, how do i do that? ***janneke_ is now known as janneke
<ebrasca>If I update my /etc/config.scm , What I need to make to update my system and don't downgrade it? <roptat>ebrasca, you'd need to run "guix pull" I think <roptat>what does "which guix" tell you? (as root) <ebrasca>/home/ebrasca/.config/guix/current/bin/guix <roptat>what about "sudo guix package --show=guix"? <ebrasca>/run/current-system/profile/bin/guix <ebrasca>I have miss my pass when running "su root" ... <roptat>the issue is that root is not using the right guix <roptat>system guix is 0.16.0, and can only know about past self, so that's why you downgrade your system everytime <ebrasca>I have install it today from GuixSD image... <roptat>I'm not a user of sudo, but I think I remember you should use "sudo -E guix system reconfigure ..." <roptat>ah cool, then you should update root's PATH like that: export PATH=/root/.config/guix/current/bin:$PATH <roptat>then you'll be using the guix from your last pull <roptat>which is more recent than system's <roptat>(you may have to run "hash -r" for your shell to find the new guix) <ebrasca>Why it tries to downgrade by default? <ebrasca>Everyone know numbers need to go up and not down. <roptat>that's because you were using system guix <roptat>when you upgrade, it simply reads the list of packages it knows <roptat>and guix cannot know about newer versions than itself, so system guix knows only about an older guix, which it will happily install <roptat>the issue is that "guix pull" will create a separate profile for guix, but you were not using it <roptat>I don't know why, there must be a mistake in the manual or the way it's installed <roptat>I know, but guix works differently <roptat>there no notion of a version actually <ebrasca>manual recomend to run guix pull & guix system reconfigure ... frecuently <roptat>yes, but root's environment was not properly set up for that, so guix pull had effectively no effect at all <roptat>civodul, do you think we should had a warning when users are not using guix from a guix-current profile? I think it would prevent this kind of issue <ebrasca>You need to make it more clear how to update systeam and more clear when it tries to downgrade ... <roptat>civodul, when you use guix from the system profile and try to run "guix system reconfigure", it actually downgrades the system, ignoring any update made with guix pull <roptat>same with user profile, when it's not configured to use your guix-current profile and you use guix from your user's profile, it actually downgrades your profile <civodul>on GuixSD, ~/.config/guix/current/bin comes first in $PATH <civodul>same for root, but the problem may be that people have to run "hash guix", and they don't <roptat>"sudo which guix" returned " /run/current-system/profile/bin/guix" on ebrasca's system <ebrasca>Now if I add firefox to my config.scm , How I update my system to add it and don't downgrade? <tune>was just going to ask about the process of adding polybar to the wishlist for stuff to be packaged. did a search and it's been packaged since I last looked. very nice surprise. <roptat>ebrasca, if you're root and you use guix from /root/.config/... then it's just "guix system reconfigure ..." <roptat>(note that we don't have firefox, but icecat though) <civodul>roptat: hmm, i think "sudo which guix" returns the same thing as "which guix", no? <roptat>I don't know, I never use sudo, but it didn't seem to be the case here <civodul>i just checked "sudo env | grep PATH" on a bare-bones VM <cnmne>on my vm, `sudo which guix` and `which guix` yield the same path <ebrasca>I was thinking it is my error `sudo which guix` and `which guix` give same result. <rekado>civodul: oh, that’s embarrassing! I did indeed forget (guix-support? #t). <cnmne>neither `guix pull` nor `guix pull --fallback` are working on any user for me; building info-dir.drv seems to fail because of "no code for module (guix build utils)" <cnmne>the solution seems to be to recompile `guix/profiles.go` <rekado>I’ll add a little escape hatch to our ssh service configuration, so that one can append extra text to the bottom of the config file. <rekado>this is useful for things like scoped rules, e.g. allowing root logins only from certain networks. <rekado>the patched ghc has been built on berlin; I’m letting it build all the way to ghc-pandoc before pushing the patch. <pkill9>how do you run `guix build` and prevent it using substitutes for only the package you're trying to build? --no-substitutes makes it try to build the package inputs from source as well <rekado>pkill9: you can do “guix environment foo” first and then use “guix build --no-substitutes --no-grafts foo” <pkill9>rekado: hmm when i rna that (with --no-grafts) it just returned the store path for hte package, didn't try to build it <rekado>you can build it once more with “--check --no-grafts” <janneke>ah, the documentation says `xserver-arguments' <janneke>but my slim-configuration does not like it <janneke>i need to provide the whole xorg-start-command <doctorworm>Can anyone explain to me how you edit files in a store? For example, if I want to add a line to /etc/pam.d/i3lock in the i3lock-color store how would I go about doing that? I can't edit the /etc/pam.d/i3lock in the system as it's read-only, and I can't edit it in the Guix profile because it's hard linked to the store. <civodul>doctorworm: the store is immutable, you should never edit it <civodul>immutability is what guarantees that you can eventually rollback, and so on <doctorworm>Yeah, I get that. I just need to figure out what to change in order to edit the file <doctorworm>Is it a case of editing the actual config file and rebuilding it? <civodul>yes, you edit /etc/config.scm and then run "guix system reconfigure /etc/config.scm" <doctorworm>Ah so it has to be done at the config.scm level. Got it. Thanks! <pkill9>the thing that confuses me kinda is needing to add --no-grafts to get the package to build with --check <pkill9>without it it does say it's grafting the package onto something, it confuses me a little <roptat>grafting creates a derivation (I think), so --check only re-runs that derivation <sisyphe_>I'm struggling with my first guix package, is this the right place to seek help ? <roptat>with --no-grafts, it ensures that --check replays the derivation that builds the actual package <roptat>I might be mistaken, I'm not completely sure how grafts work <sisyphe_>the tool I try to wrap is using /usr/bin/env during build steps but I don't know how to provide it <rekado>sisyphe_: what comes after the “/usr/bin/env”? <sisyphe_>it's a call to python executable prefixed with environment variables definitions <rekado>sisyphe_: then it’s enough to add Python to the package inputs. <rekado>Guix provides build phases that replace shebangs with references to executables in /gnu/store automatically <rekado>so “#!/usr/bin/env python” would be replaced with “#!/gnu/store/…/bin/python” <rekado>if it’s not a shebang you would need to patch this yourself in a build phase. <rekado>you can add build phases with the “modify-phases” macro. <rekado>you can search for “substitute*” under gnu/packages/ to see examples of patching files in build phases. <sisyphe_>ok I understand, but what about the environment variables set using /usr/bin/env, they won't exist for the executable once I remove them <rekado>ah, I see. Well then you can simply replace “/usr/bin/env” with (which "env") after adding “coreutils” to the inputs. <rekado>you may also want to substitute the plain “python” executable name with the result of (which "python") <rekado>well, I mean the procedure, not the “which” shell command. <jlicht>I know the current texlive packages have seen quite some nice changes recently, but does anyone know how/where to find a certain missing .sty file? As in, pdflatex complains about a lack of "biblatex.sty" and I don't even know where to begin to look for it. <rekado>jlicht: you can look things up in “share/tlpkg/texlive.tlpdb”, which is provided by texlive-bin. <rekado>jlicht: looks like we don’t have a package for biblatex yet. <rekado>sisyphe_: it’s best to show an example <rekado>sisyphe_: in the guix source tree open gnu/packages/python-xyz.scm <rekado>search for “define-public python-pexpect” <rekado>sisyphe_: there you see that a phase “prepare-tests” is added <rekado>sisyphe_: in the phase some files are edited so that all occurrences of “/bin/ls” are changed for the result of “(which "ls")” <rekado>(which "ls") would evaluate to something like "/gnu/store/…-coreutils-…/bin/ls" <rekado>so the result is that the plain “/bin/ls” in the file is replaced with an exact file name of “ls” in the store. <sisyphe_>thanks, I will try to make it work for my case <rekado>jlicht: looks like this package does not have any source files, so packaging it should be rather simple: you just need to copy texmf-dist/tex/latex/biblatex and texmf-dist/bibtex/{bib,bst} to the output directory. <sisyphe_>what tool/IDE do you use for package development ? what do you use to navigate to definitions ? <rekado>you can use “./pre-inst-env guix edit foo” from a source checkout to open the definition of “foo” in $EDITOR. <rekado>many of us use Emacs and the Emacs Guix interface. <jlicht>rekado: I get the part about 'latex/biblatex', but how did you reach the conclusion that parts of the bibtex folder are also required? <rekado>jlicht: that’s what texlive.tlpdb told me. <rekado>jlicht: when you search for “^name biblatex” you’ll see a field “runfiles”, which lists all the files you’ll need. <rekado>(I only learned about texlive.tlpdb recently thanks to Pierre) <jlicht>ah, that is what I meant; how did you decide which files are required to run it. Thanks rekado (and by extension Pierre) :-) <sisyphe_>ok I will try to build the source to get pre-inst-env <rekado>sisyphe_: I recommend using “guix environment --pure guix” to get an environment for Guix with Guix. <jlicht>since this afternoon (European time), I am getting a "guix environment: warning: ambiguous package specification `guix'" <sisyphe_>thanks for the tip, nice to see how guix ease guix build <rekado>jlicht: do you have something on GUIX_PACKAGE_PATH or did you enable some channels? <jlicht>rekado: I do, but `guix package -A guix' show the same (non-channel) entry twice <cnmne>I've been unable to resolve "...-info-dir.drv" derivation building for any of `pull`, `package -u`, or `reconfigure ...`, for the past few system generations that I've tried to roll back to in hopes of fixing <rekado>cnmne: you can’t do that when you’re using “guix pull”, I’m afraid. <rekado>cnmne: your best chance is to use an older Guix, if available. <rekado>cnmne: try ~/.config/guix/current-*-link/bin/guix <rekado>this is due to a bug in Guile that leads to miscompilation :-/ It’s really a bad problem. <cnmne>you mean to pull using that pathed guix ? <rekado>the problem lies with your current version of Guix. So I’m suggesting to use a different one. When pulling with a working version you might be able to get a working version of Guix to replace your current broken version. <cnmne>rekado: only "~/.config/guix/current" existed, but following the link i successfully used (via sudo) `/var/guix/profiles/per-user/root/current-guix-5-link/bin/guix` to pull and reconfigure. however, `guix describe` gave me origin errors and `guix system list-generations` listed the wrong kernel. I've since pull+reconfig+rebooted a few times, and at one point I was able to simply `sudo guix pull`, but then i got the same info-dir error <cnmne>afterwards. not sure if there's an obvious sequence i should be following ? <bgardner>Good morning #guix, I'm trying to use '#$' but I can't figure out where 'ungexp' is defined to bring it in properly ("error: ungexp: unbound variable"), can anyone point me in the right direction? <rekado>bgardner: it’s defined in (guix gexp) <bgardner>I have that in use-modules already, do I need to do something else? <civodul>bgardner: #$ can only be used within a gexp, i.e., within #~(...) <bgardner>In the end, I overthought it. I was setting a user shell with (shell #$(file-append zsh "/bin/zsh")), but I didn't need the #$, I had just copied that from elsewhere. (shell (file-append zsh "/bin/zsh")) works as desired. This brings up another question I had, though - what is the guix-y method for dealing with shabangs that break because the shell is not actually where indicated? e.g. #!/bin/bash <cnmne>rekado: I ended up doing a pull+reconfig with the "/var/.../guix" until I could just use the current guix linked in $HOME again; like last time, `sudo guix pull` ran fine and for whatever reason, unlike last time, `sudo guix system reconfigure /etc/config.scm` didn't raise the info-dir error again. <cnmne>almost everything seems to be in order now, thank you! <civodul>bgardner: you can use the special-files-service to add extra files like /bin/bash, /usr/bin/env, etc. <bgardner>:) figured "fix the scripts" would make the cut. Thanks for the pointer <cnmne>so it may not be fully resolved... pulling and reconfiguring with sudo works fine, but when I'm actully root (with `su`), i get the same error from before. trying to repeat what i did before when i fixed it for sudo <roptat>cnmne, make sure your guix comes from /root/.config/guix/current <cnmne>roptat: currently: `$ which guix` == `$ sudo which guix` => "~/.config/guix/current/bin/guix", whereas `# which guix` => "/run/current-system/profile/bin/guix" <rekado>“guix download” doesn’t have an “-o” option. <roptat>rekado, it does according to the manual <rekado>oh, but it doesn’t say so in the help output. <roptat>invoking guix download, "Save the downloaded file to FILE instead of adding it to the store." <kmicu>(Now everyone wonder about the version/hash of rekado’s guix.) <roptat>no, rekado used --help which doesn't tell anything about -o <kmicu>The source code is always right. <roptat>weird, my version doesn't either <eubarbosa>guix download -h, says nothing about output=FILE <rekado>kmicu: I’ve got a Guix from the future, actually ;) <kmicu>It must be a bug cuz I see -o even in 0.12 <rekado>so you’re saying … that source code might not always be right…? :) <rekado>the problem is with “#f” instead of “#t” <kmicu>To bring us toghether at this very moment! ヽ(*＾▽＾)／ <rekado>(format #f "…") produces a string, whereas (format #t "…") outputs a string to (current-output-port). <kmicu>The ‘joy' of stringly typed lisp. <roptat>I'll be able to fix it in an hour or two if you don't do it first :) <eubarbosa>why there are two download.scm files? one at /guix, and /guix/scripts? <rekado>kmicu: well, to be fair, in this case it’s all side-effectful anyway. The procedure does not return a value but is evaluated purely for its side effects. <rekado>eubarbosa: everything under guix/scripts is for executable scripts. They handle command line options and the like. <rekado>the real work is done in other modules. <cnmne>ok I'm not getting anywhere with this, so I'm going to reinstall and hope it never happens again :] But just to clarify, in the future i *should* expect identical behaviour between `$ sudo guix ..` and `# guix ..` ? <roptat>cnmne, not really because they don't have the same environment <cnmne>is that where `sudo -E` comes in ? <roptat>but the right environment should be sources when you login as root <rekado>cnmne: a reinstallation is rarely ever a good idea. <cnmne>roptat, wait would the -E flag actually do the opposite of what I want? meaning it would keep user environment variables while running as root ? I guess i would need to login instead <cnmne>rekado, I'll give it another go then :] <cnmne>that's as much as I get from the man page, I also don't really know <roptat>to be clear, I manage root's and user's guix separately <roptat>hm.. maybe you need to use "su -" for the right environment to be sourced? (that's what I use) <cnmne>roptat: i've been using `su` only, so maybe there's conflict there... I'll try it out. Any reason you personally don't use sudo ? just curious. <roptat>I'm used to su and sudo is confusing for me <cnmne>eubarbosa: I've got half the manual memorized by now ! :] <rekado>cnmne: “su” alone won’t give you a login shell, so root’s environment won’t be loaded. <cnmne>oh no.. this is almost comical. I get four different outputs for `guix describe` (depending user, sudo, su, 'su -') <cnmne>so I'm just going to stop using `sudo` and `su` from now on to ensure environment <cnmne>i'm apparently on generation 2, 4, and 16 (at the same time), so I'm going to take a break from the computer for a little bit. thank you all for advice/help and bearing with me ! <eubarbosa>rekado: guix download help has a false value (format #f (G_ ", while all others (format #t (G_ " <rekado>eubarbosa: yes, that’s already fixed. <ng0>hm. how do you deal with the 'configure.ac:15: error:possibly undefined macro: GUILE_PKG' on other systems? (for guile-sqlite3) <rekado>GUILE_PKG is defined in Guile’s share/aclocal/guile.m4 <ng0>I did not mention I had guix running :) I'm looking for a way to get it running here <ng0>okay, I'll read into the file and see if I can find the issue. <rekado>on some systems you may need to install a “-dev” or “-devel” package for Guile <rekado>but it may be easier to get Guix running by installing it with the installer script. <ng0>wow, okay thre's the problem, pkgsrc guile22 did not include the m4 file <ng0>trying to see if the linux compat layer is enough. <ng0>and if not, just a small excercise. got sidetracked <ng0>okay, location was off <ng0>thanks for the file name. <janneke>kernel module not found "shpchp" "/gnu/store/z7y8gk0bwk7g1dpfakmg6b4dngb5rwca-linux-libre-4.20.2/lib/modules" <janneke>/home/janneke/src/guix-janneke/dundal-luks.scm:115:11: error: you may need these modules in the initrd for /dev/nvme0n1p1: shpchp <janneke>hint: Try adding them to the `initrd-modules' field of your `operating-system' declaration, along these lines: *janneke considers running --skip-checks <pkill9>is there any work on making it possible to download git repositories with `guix download`? (or to match the guile interface, `guix git-download`) <amz3>pkill9: why would you do that? <samplet>pkill9: It’s been talked about a bit, but I don’t think anyone is working on it. <adfeno>Doesn't downloading git checkouts break reproducibility? <pkill9>adfeno: you can use git sources in package definitions so I guess not <roptat>and it looks like an sbt-build-system would be simpler than a maven-build-system <adfeno>Oh.... actually, I remember now, I didn't hear about the checkouts.... But of downloading the automatically premade tarballs or compressed files. <roptat>now I need a scala compiler to bootstrap scala (I'm using the binary release for now) <adfeno>So if one woudl, say, use the automatically premade tarball from say GitHub, that would be unreproducible <roptat>well, the first thing my sbt does is to download a binary release of itself :/ <adfeno>Here in Brazil, "SBT" is the name of a television station. <roptat>and gradle will also do that once I can build and run it <roptat>that's just how these tools are made <pkill9>adfeno: all the premade tarball sources are being changed to git checkouts because those sources are known to change apparently <pkill9>and you can specify a git tag in the commit field <roptat>but I have hope that inside the build environment, we can replicate what they expect and prevent them from downloading themselves <pkill9>but i don't think those sources are inheriently unreproducible, unless you were referring to their tendency to change serverside <pkill9>but if that happens guix will just fail with an error anyways <adfeno>pkill9: I did saw a discussion in guix-dev mailing list some time ago about the premade tarballs <adfeno>Although it's a long time I don't even see the topic being discussed <adfeno>If you don't mind, I must go, there is a storm comming. <asterope>building blender is failing for me (Guix is c4aa1eb). <asterope>it throws "make: *** [Makefile:166: all] Error 2" and a backtrace <roptat>asterope, this error is not very useful, it means something went wrong, but not what <roptat>usually the actual error is a few line before that <asterope>before are just other make calls, which are succeded just fine <asterope>"make[1]: Leaving directory '/tmp/guix-build-blender-2.80-beta-0.3c3d80e.drv-0/build'" <pkill9>put the last 50 lines or something in debian.paste.net <pkill9>well probably more lines than that <efraim>Especially useful if you can get the lines before error 1 <asterope>I mean - I didn't connect the dots that there must me an error 1 <roptat>I could build blender from guix 1704367 <asterope>I'll run the build again and collect the logs <roptat>I've just guix pull'ed and rebuilt blender: it's been built by hydra already <asterope>I'll stop the build and do guix pull instead <_tibbe>Hi, what can cause a derivation to have invalid outputs? The message is generated by the daemon (build.cc) and is not really descriptive. <samplet>_tibbe: Could it be a hash mismatch for a fixed-output derivation? <_tibbe>samplet: Could be. The bug appears when I check that a certain derivation is reproduceable but is not the typical error message from guix build --check. <_tibbe>samplet: guix build: error: build failed: some outputs of `/gnu/store/x78z90difn3y61kscz7vvx4yapa959lw-pwsafe-3.48.0.drv' are not valid, so checking is not possible <_tibbe>I've done some changes to the definition. The error is the result of `make && ./pre-inst-env guix build --check --rounds=2 pwsafe` <bavier>_tibbe: don't use '--check' and '--rounds=...' together <bavier>_tibbe: '--check' expects the output to already be present, so in this case, the error is just saying that it is not. <_tibbe>bavier: Thanks. The other error was that guix build would always just graft the build instead of rebuilding with --check but this is probably another effect of using the options together. <bavier>_tibbe: yeah, I wish '--check' forced '--no-grafts' <samplet>Thanks bavier. I find those options very confusing. <eubarbosa>a glorious day would be the day we can configure all the system config with only a single language, even third-apps configs <eubarbosa>prolly we already can do with Guile Scheme and I dont know hehe <rk4>what are you wanting to config at the moment that you can't? <eubarbosa>So I wont have to version control hundreds of config files <pkill9>so more like user-packages rather than system-packages/services <pkill9_>i think one way that could be done, for some packages at least, is to create guile functions that take a package, generate a config for it, and wrap the package to run with that generated config, e.g. if an executable takes a config as a CLI flag like --config, a wrapper could be generated thatruns it with --config </path/to/generated-config> <pkill9_>or there could be a tool that just creates symlinks to the generated configs in all the correct locations, a bit like gnu stow <joshuaBPMan>Does anyone know why there isn't a substitue of icecat available? I keep having to pass "--do-not-upgrade=icecat" to guix package -u <eubarbosa>pkill9_: the first one is really interesting! <asterope>strange, it's still trying to build a blender derivation <pkill9_>oh sweet, the blender interface bug was posted last month, and is fixed with the update to 2.8 apparently <lfam>It is fixed with 2.80-beta <pkill9_>i worked around that bug by installing a blender built with an earlier guix revision - one of the many wonders of guix <pkill9_>i don't actually use it much though, lol <asterope>it's my best bet at rendering films for guix <asterope>I mean in guixSD. Every other rendering GUI software I tried was unstable <asterope>yeah, it works. And it looks amazing too <eubarbosa>Hey, most Scheme begginers books were wrotten before R5 standard, still most people recommend Little Scheme and SCIP. Are those two or any other compatible with Guile Scheme? <sisyphe_>I tried to build a pack depending on perl for arm-linux-gnueabihf and it failed with the error in the following paste. Is this a known issue ?