<Apteryx>how can I delete *only* the directories under a parent dir in a Guix phase? <pkill9>there's a delete-recursively command i think <Apteryx>I think I need to use find-files with a predicate that will match directories (using stat argument) *and* a regexp pattern against filename <Apteryx>pkill9: after I have the list, yes, delete-file-recursively will do it <pkill9>is there a list of commands to use during the build phase? <pkill9>that would be nice, i'd make it if I knew them already <Apteryx>you can use any Guile, but the usual utils come from (guix build utils). <pkill9>i'm gonna start documenting them <pkill9>i like scheme because it's so readable, just need to know the commands <pkill9>oh they're all basically documente <pkill9>documentation could probably be generated from it ***calvin is now known as Guest25571
<dustyweb>tried bumping the version for racket but getting a weird error.. <dustyweb>Error [GCING] 1780 in ./../src/number.c: Function minus_zero_p declared __xform_nongcing__, but includes a function call at __signbitf128. <atw>Currently git bisecting with git pull. I wonder if this will affect my energy bill <marusich>atw, why git pull? might be faster if you can do it from a local checkout. still slow though :/ I'm also doing this. <marusich>I'm confused. I thought you said guix pull. <alex-vivo>Does anyone use tlp on guixsd? How is the configuration supposed to work? I'm used to running sudo tlp start but it complains that there is no config in /etc/tlp that sets TLP_ENABLE? I'm fearful of adding it manually, so how am I supposed to run and configure it? <atw>marusich: I meant guix pull. I could probably find the failure via building locally but I guess I'm taking more of a black box approach <Steap>How does one completely "git pull" again? Like, to get a version of Nix that compiles? <Steap>do we have to submodule update or something? <marusich>Steap, I'm not sure what you mean. I don't think Guix uses Git submodules. So, "git pull" should work. <Steap>we used to have to synx the content of the nix/directory <Steap>"make" fails in nix/ on my box, so I assumed there was an issue with taht <Steap>0181df537ffb4e4273b2ca005738fdb7bd3d73f5 <Steap>I must say I had not pulled in a few months <atw>I may be running into the same issue. I'll let you know. <Apteryx>shouldn't that match all the subfolders of external_libraries: (string-match ".*external_libraries/[^/]*/$" filename) <Apteryx>ah, got it. Had to remove that trailing '/' before the end of filename: (string-match ".*external_libraries/[^/]*$" filename) <atw>commit cd5e084342de3d39951413e33491d70e579ad912 appears bad. guix pull --commit=f09cb93e3a2310f7726cb98fa5679c1a8483c39f should work, if my experience is representative. <atw>no, wait, that's wrong <atw>commit cd5e084342de3d39951413e33491d70e579ad912 appears bad. guix pull --commit=f09cb93e3a2310f7726cb98fa5679c1a8483c39f should work, if my experience is representative. <atw>(first message was actually right.) <dustyweb>I think I fixed the Racket upgrade issue <wigust->atw: Are you saying cd5e084342de3d39951413e33491d70e579ad912 is bad and f09cb93e3a2310f7726cb98fa5679c1a8483c39f is ok? <atw>wigust-: According to my bisect, yes <atw>and guix pull --commit=0458ab53f6ab58c42f379b8e7d55d130df4232e3 just failed. <mbakke>Is (scandir ...) the best way to test if a directory is empty? <atw>yep, that's what I'm seeing. But that looks like the second problem because of "Exception thrown while printing backtrace:" <atw>But because we can't see the backtrace, I can't say what the problem is. I will try building 0458ab53f6ab58c42f379b8e7d55d130df4232e3 locally <dstnou>Hey, how would I go about regenerating the grub config so that it would also look for other OSs on disk? <marusich>First time I've played with that; it's interesting. <dstnou>wigust-: I installed os-prober, that won't work? <wigust->dstnou: os-prober is for auto detection, but dunno what is the current situation with it <dstnou>wigust-: and I might have clobbered my /boot/grub/grub.cfg by not backing it up and manually running `grub-mkconfig -o /boot/grub/grub.cfg`. I forgot to back the old one up and the new file doesn't list any OSs, not even guixsd, thus my worry. Is there a way to properly set the bootloader back, while I'm still in the system and am not locked out by my stupidity? <dstnou>wigust-: I see your patch and I will try later, but at the moment gotta do something about this unnecessary situation I got into. Would something like `guix system reconfigure /etc/config.scm` rewrite modified system files like the grub.cfg with the correct version? <OriansJ>dstnou: even in a worst case, we still have the manual option <atw>I see a failure in guix pull, but I can't replicate it by checking out the commit and building locally <atw>guix pull compiles at the commit it checks out, but what else does it do that could be failing? <atw>wigust-: I just realized that what you meant. (system repl debug) should come with Guile, right? I guess it's not avaible during guix pull, though. <dstnou>OriansJ: you mean specifying boot parameters to grub by hand at the grub prompt during boot? <OriansJ>dstnou: No, I mean manually adding entries into /boot/grub/grub.config or /etc/grub.d/40_custom which will solve the grub boot problem until a better long term solution can be found <dstnou>OriansJ: so there isn't an automated way at the moment to fix the grub config after the initial installation? <mbakke>dstnou: If you can access the file system, you can try to locate the old grub config from the store and copy it to /boot/grub/grub.cfg . <mbakke>Actually, the latest grub configuration is available under "/var/guix/gcroots/bootcfg". <OriansJ>dstnou: there is only an automated way if automated detection can occur, what being said, I was assuming you already exhusted things such as rollback or as mbakke is suggesting. However if you are not on guixsd, we will need more information to be helpful <atw>The message is the same, but the message is from a few months ago and Ludo says it was fixed. On the other hand, my guix pull does say that it's using Guile 2.2.3. <atw>*the error message is the same, but the email is from a few months ago <dstnou>mbakke: sorry was away, would I find the old copy of the config in /gnu/store/xxxx-grub/... ? <dstnou>OriansJ: I am on GuixSD, I'm going to try to locate the old grub config in /gnu/store, how would I rollback though? I'm not sure that /etc/grub/grub.cfg is being tracked by anything... <dstnou>I have started a `guix system reconfigure /etc/config.scm` in the hopes that it would produce a favourable result, but it appears that it's compiling the whole system on my machine the without use of any substitutes, which is gonna take a while I suppose. <dstnou>didn't realize it would recompile everything <mbakke>dstnou: You can find the latest grub configuration under "/var/guix/gcroots/bootcfg". <dstnou>mbakke: the file you mention is a completely different file from /boot/grub/grub.cfg. Isn't the file located in /boot supposed to be the grub config? I suppose this is another particularity of guixsd <mbakke>dstnou: The "bootcfg" gcroot points to the generated grub.cfg to prevent it from being garbage-collected. <dstnou>mbakke: Ok, is the file located in /boot/grub/ used for anything at all then? <mbakke>dstnou: Yes, that's where GRUB looks for it. <dstnou>mbakke: but that file doesn't have my menuentry by the one in gcroots does, how does it find that one? <mbakke>dstnou: I thought your /boot/grub/grub.cfg was broken and you wanted to restore the last good version. <mbakke>`cp -L /mnt/var/guix/gcroots/bootcfg /mnt/boot/grub/grub.cfg` would do that, assuming the broken GuixSD system is mounted at /mnt. <dstnou>mbakke: oh, my ad got confused, so on a properly functioning system those files have the same data? Does the gcbootcfg contain the grub config from the current boot or the last successful boot or something along those lines? <mbakke>Yes, on a working systems those files are identical. The `bootcfg` gcroot contains the most recently generated `grub.cfg`, e.g. from when you last ran `guix system reconfigure` (or init). <dstnou>mbakke: I see, thank you very much for the explanation! <mbakke>dstnou: No problem, hope you get your system back up! <dstnou>mbakke: so.. using grub commands by hand is a bad practice I take it, judging from this experience, since everything doesn't follow conventions that the vanilla programs expect? <dstnou>I supposed I gotta get into the declarative mindset and trust the system to configure itself according to my specification. Years of unix/linux ideas are gonna take a bit to uncondition from... <mbakke>dstnou: Hehe yes, in GuixSD everything gets generated from your config.scm, so you should never need to edit other configuration files by hand. <dstnou>mbakke: I'm coming from arch/void land, so you can imagine how that's a big departure from the status quo over there where you do everything by hand, following the wiki and other docs. <wigust->dstnou: You could use Grub commands or any system commands by hand, but you should provide right arguments and think about that ‘reconfigure’ will probably rewrite your changes. <dstnou>On the positive note, running `guix system reconfigure config.scm` ended up updating my kernel to 4.15.5, and there I was thinking that 4.14.3 was where guix was stuck for now. I just thought that the original install process I did yesterday used the most recent version of software. I suppose it used what was on the .iso, but it took so long that I thought I was installing and downloading stuff from scratch and not using the stuff that <dstnou>Learning the ways of the land is tedious but exciting at the same time, thanks for the help in guiding me through this first majorish hiccup. <dstnou>wigust-: yep, gotta be more careful in the future, thanks <alex-vivo>While running guix pull this happened, not sure what the culprit is: <alex-vivo>In procedure public-lookup: Module named (system repl debug) does not exist <alex-vivo>Some deprecated features have been used. Set the environment <alex-vivo>variable GUILE_WARN_DEPRECATED to "detailed" and rerun the <alex-vivo>program to get more information. Set it to "no" to suppress <alex-vivo>builder for `/gnu/store/l4zlr66svshwhp5mmv597mr0s5rj3hvi-guix-latest.drv' failed with exit code 1 <alex-vivo>guix pull: error: build failed: build of `/gnu/store/l4zlr66svshwhp5mmv597mr0s5rj3hvi-guix-latest.drv' failed <atw>alex-vivo: I've been getting this too. I've been unable to figure out why :/ <alex-vivo>atw: alright, at least it's not the fault of my restless hands heh. Hopefully we can get someone with insight in here. <wigust->Hm, I've ‘guix pull’ 0181df537ffb4e4273b2ca005738fdb7bd3d73f5 successfully. <atw>alex-vivo: I observe guix pull --commit=f09cb93e3a2310f7726cb98fa5679c1a8483c39f to work. <atw>wigust-: what Guile version did guix pull say it was using? <alex-vivo>Building from Git commit 0181df537ffb4e4273b2ca005738fdb7bd3d73f5... <alex-vivo>so that same commit didn't work here strangely <wigust->atw: alex-vivo: Could you report this to bug-guix@gnu.org, please? <alex-vivo>wigust-: I can try, but haven't reported anything for this project yet so don't know the protocol, let me do a search before I commit. <atw>wigust-: will do. The fact that I can reproduce and you can't worries me though. <alex-vivo>atw: you're probably the better candidate to deal with this :) <atw>I'm on 4 cores, but I never had issues like this before... <alex-vivo>atw: I used the commit you mentioned working and didn't encounter any issues, so it must be something that was introduced by the other maintainers in the ~5 commits since that one, hopefully they can narrow down. <atw>f09cb93e3a2310f7726cb98fa5679c1a8483c39f is AFAICT the most recent working commit. But that doesn't make sense, because all the commits after that are just package updates. I don't see why they shoyld affect guix pull. <alex-vivo>atw: huh, that is indeed perplexing, I'm intrigued now about what the maintainers could discover. What a drama! haha <alex-vivo>I read it already, explains the issue at hand well. How long do you think until we get some response, judging by your prior experience with the guix project team? <atw>alex-vivo: I can't say. But many of the maintainers are in Europe, which is probably why they're not in the channel now. <Apteryx>interesting. When I enter a test module with Geiser such as (test-build-utils), Guile forgets about even its builtins such as 'define' or 'define-module'. uh? <atw>Apteryx: and test-build-utils is a module that doesn't exist? <Apteryx>oh, you've got it. the name of the module file doesn't match the name of its definition, and it must trip Geiser. The module-define says "(define-module (test-build-utils)" but the file is in (guix tests built-utils). <wigust->atw: I wonder why do you build successfully commits above f09cb93e3a2310f7726cb98fa5679c1a8483c39f <wigust->atw: They are just package updates most of all with a little bit “build phases” changes. <atw>wigust-: I think I can build them -- guix pull's compilation gets to 100%. Also, I can successfully build on that commit in my checkout. So I think the issue is in a part of guix pull that's not compilation. <atw>Apteryx: still odd...I can repro Geiser not auto-completing in non-existant modules. <Apteryx>I think this is a known gotcha. It's explained in the Geiser manual IIRC; but still stumps me sometimes. <Apteryx>I'm writing my first Guix unit test ever ;) <Apteryx>(I renamed the test module correctly and now Geiser is helpful again) and the Guix test runner (make check) still works OK. I'll include that renaming in my patch! <Apteryx>I'll have to pursue tomorrow though... good night :) <verisimilitude>This is the appropriate channel to ask some questions relating to GuixSD, right? <verisimilitude>My issue relates to my wireless card; I have an Atheros 9271 device from thinkpenguin, but if it works at all it only works for very short periods. I was wondering if this issue has a known fix. <wigust->verisimilitude: Or I should say not included this kinda firmware by default. <einarelen>Good morning people. I'm trying to learn how to write a package. How does one calcuate the hash of the downloaded file from a url-fetch? I.e. the part that goes into (sha256 (base32 ... )) :) <sneek>Welcome back einarelen, you have 1 message. <sneek>einarelen, marusich says: Alex ter Weele has been investigating how to make it so unprivileged users on foreign distros and GuixSD can run services easily using Shepherd. Currently you can do so by starting your own Shepherd instance, but sadly you cannot easily re-use GuixSD-style services when you do this. If you're feeling adventurous, I'm sure he'd love additional help! See: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047. <rekado>einarelen: you download the tarball (e.g. with wget) and then run “guix hash” on it. <rekado>that gives you the hash that you can use in a package definition. <einarelen>What would be the standard procedure for building something? I'm trying guix build -f filename.scm but that gives an error saying #<unspecified>: not something we can build <rekado>einarelen: the standard way is to create a Guile module containing the package definition, adding the module to the GUIX_PACKAGE_PATH, and then using “guix build the-package-name”. <einarelen>Doing so (GUIX_PACKAGE_PATH... guix build packagename) leaves me with a failed to load warning '(modulename)': no code for module (modulename), regardless if I'm using the thing im trying to write or a copy of one of the distributed build files (code.scm in this case) <pkill9>einarelen: what's the source code of the module you're trying to use? <einarelen>Either a copy of the code.scm-file which is distributed with guix (contains stuff like ag) or the GNU Hello-example from the manual <pkill9>is the name of the module at the top set to the same name as the .scm file? <pkill9>also, the .scm file needs to go under $GUIX_PACKAGE_PATH/gnu/packages/package_module.scm <einarelen>That final part seems to have resolved the issue <pkill9>yeah that one caught me out a while back <pkill9>unfortunately i don't think it's documented in the manual <einarelen>I feel like I've crawled through all of the manual a couple of times and I don't think that it is <einarelen>How does one control version requirements for a package? e.g. I'm trying to write a package which, say, requires gcc > 6 <pkill9>einarelen: '(native-inputs ("gcc@6" ,gcc))' <ng0>the @ is on the commandline, for package definitions it is "-" so gcc-6 <pkill9>ng0: is that because the "-" is actually a part of the name of the package definition? <pkill9>or does Guix look for a version specified after the dash? <ng0>it's the name of the package <ng0>read for example the gnu/packages/linux <efraim>It makes parsing at the '@' easier, while for packages it is just part of the name <ng0>What's with the qtoctave package Kei send a month ago? Would anyone like to review it a second time or merge it? <einarelen>How would one express a requirement of pthreads in a package? <mbakke>einarelen: pthreads is provided by glibc, so usually there's no need to do anything special. <einarelen>Aight, must be something messed up with how I'm using cmake in that case as it seems to not be able to detect it <verisimilitude>Well, I specifically bought the dongle as it was supposed to work with only Free Software, but oh well. Your answer is appreciated, wigust-. <Apteryx>einarelen: better than wget: you can 'guix download url-of-your-archive' <einarelen>I'm running into some trouble with packages that use python in one way or another. Getting warnins from patch-shebang along the line of patch-shebang: ./name/helper.py: warning no binary for interpreter `python' in $PATH. Any clue how to deal with this? Seems to be the cause of compile failures in later stages <ngz>You probably need python-wrapper <einarelen>Is that a package? Not usually doing stuff with python :| <ngz>python 3 is installed as python3 executable. <ngz>Yes, this is a package, that you can put in, e.g., native-inputs. <einarelen>Does similar wrappers exist for other interpreted languages? <ngz>I don't think so. This stems from the Python2 Python3 duality, which is pretty unique to Python. <szl>hi, I'm attempting to setup guix on a fresh debian strech image but guix package -u keeps failing to download the following package during the update process <szl>managed to get around it by guix package -i perl --fallback and then reruning the update <alex-vivo>I'm learning how the packaging works and I'm a bit perplexed by the (source...) sexp. In it we are able to use (uri (git-reference (url "xxxx.git") (commit "version"))). What is that commit version supposed to be? The git commit hash that I'm trying to use as the head? <alex-vivo>And later on for such a, git sourced packed, what would it want as the (sha256 (base23 "xxxx")) xxxx hash? For a normal package that uses `guix download` I was able to use guix download manually and it outputs that hash to use. Should I use the same `guix download` on the .git file, which ends up miniscule, and get that hash from that? <atw>re the second question: I think you'll want to invoke guix download xxxx.git, then copy the output of that into (sha256 (base32 ...)) <atw>s/a tag "v1"/a tag like "v1"/ <alex-vivo>atw: you're a legend, thank you for the info. <atw>well, let me know if it works! <Apteryx>ouf, srfi-64 tests are not exactly debug friendly <Apteryx>If I add a new function to (guix build utils), apparently that's a world rebuilding change :/ <lfam>sneek, later tell verisimilitude: That wifi chip *does* work with linux-libre. The fact that it stops working after a few minutes is a problem, but wigust's advice that it is not supported is incorrect <lfam>alex-vivo: To get the hash of a Git checkout, check out the desired commit, cd .., and then run `guix hash --recursive --exclude-vcs` on the repository