<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
<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:
<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).
<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?
<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
<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?
<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