<marusich>Apteryx, if you find any good tricks for debugging tests like that, I'd like to know... <alex-vivo>lfam: thank you very much, this is working well at the moment, seems to be building correctly. <alex-vivo>atw: damn man, only just noticed your message from like 10 hours ago, I'm gonna look into it right now. <alex-vivo>atw: I would try to do a guix pull right now, but I got the system reconfigure building a new generation at the moment and I don't know if it's advisable to start both of those commands at the same time even though I guess they are logically separated into a system and user acations. Unless I get confirmation that that would not be a problem, I'm gonna wait another ~30 mins for the reconfigure to finish compiling stuff and then test <alex-vivo>first with a clean `guix pull` to see if the issue magically disappeared and then the sequence you specified in your bug update. <atw>If you're doing guix system reconfigure as root, then running guix pull as non-root should be independent. <Apteryx>how can I use `string-match' inside a build phase? I tried adding the module (ice-9 regex) but I get: unknown location: source expression failed to match any pattern in form (quote ((ice-9 regex))). <Apteryx>marusich: best advice I have so far is to redefine the name of the module to something that matches its real name, then you can evaluate the test functions in Geiser to run them. <Apteryx>Output is as spartan as any Guile output, but at least that's better than having to look into test-suite.log all the time. <alex-vivo>atw: just cleanly updated to eddb9dacd2943301c7d1bc3cbad8df6ddab09c5a. The issue is gone, surprisingly. What an elusive bug! <alex-vivo>guix (GNU Guix) eddb9dacd2943301c7d1bc3cbad8df6ddab09c5a <alex-vivo>This is free software: you are free to change and redistribute it. <alex-vivo>There is NO WARRANTY, to the extent permitted by law. <alex-vivo>atw: didn't have to revert to an older commit or anything, just straight up `guix pull` from the commit you suggested as working yesterday. <atw>A heisenbug -- disappears on observation <axg>So, I'm currently running a fairly virgin guixsd install and judging by these lines in my config (see below) I should be able to set-up a connection to my wifi using wicd-curses. However, the user doesn't have wicd access, I'm still not sure how to query shepherd to see if the service is actually running and my root can't even run ls due to the os not setting up anything correctly for root, not even the path. What's the best way to <axg>proceed? I suppose I can install wicd for the user and then have access, but I'm not sure if that the correct way to aproach this. Any help appericated. <axg> ;; Use the "desktop" services, which include the X11 <axg> ;; log-in service, networking with Wicd, and more. <axg> (services %desktop-services) <atw>axg: I don't personally use wicd, but if sudo is working for your regular user then you can run sudo herd status. In the list that outputs, hopefully you'll see an indication that wicd-service is running. <axg>atw: alright, so wicd is not in the list of running services (and there are 2 stopped services for some reason: term-auto and user-homes even though I didn't touch them). I'm gonna read herd man page to see how to start wicd, but how would I interface with wicd if it's not in my path? Also do you know anything about my root situation? Is it supposed to be essentially disabled on guixsd? <atw>I think those two stopped services are fine. If wicd does not appear at all, that seems to indicate that wicd-service is not part of the currently configured system. Have you done a reconfigure yet? <axg>atw: Yeah I definitely did, very recently ran it again as well. I'm using the minimal install that uses i3 as my template (one of the two template configs provided during install) and services looks like the line I printed out above, where the comment implies wicd would be started. What do? <axg>atw: wpa_supplicant is in that list as running as well which I suppose is needed for wicd to work. <atw>I'm afraid I don't know what's wrong. I'll let someone more knowledgeable chime in :) <atw>If you don't get an answer tonight, try asking during European daytime. You can also post to help-guix@gnu.org <axg>atw: that's alright, you've been helpful regardless, so thank you. Would you know of a way for me to check if wicd is installed at all? guix package -I seems to only show manually installed stuff for the user profile. <atw>axg: you can inspect the output of guix gc --requisites /run/current-system. For you, it should include wicd. <axg>atw: huh, interesting. So running `guix gc --requisites /run/current-system | grep wicd` comes up with nothing. I just have the default module declaration: <axg>(use-modules (gnu) (gnu system nss)) <axg>(use-service-modules desktop) <axg>(use-package-modules bootloaders certs ratpoison suckless wm) <mbakke>Woow, IceCat 52.6 comes with WebRTC enabled, and have somehow solved the IP address leak. <mbakke>That means I can ditch my almost complete Chromium effort... <mbakke>axg: %desktop-services was recently changed to use NetworkManager instead of Wicd. <atw>and thanks for the merge! I might have agda's emacs mode working <axg>mbakke: now that's an important detail! Thank you. Is there a git version of the manual that has updated information or something along those lines? Also, I run a pretty light system usually and in the past avoided network manager since wicd was enough for my needs and was light from what I understood. From your experience, is there a good reason to prefer nm over wicd even in non gnome, etc. environments? <mbakke>axg: Unfortunately there is no git version of the manual online to my knowledge, but you can build it by checking out the git repo. <mbakke>Hm, maybe we could actually offer it as a package. <mbakke>Not a fan of networkmanager either, but have been too lazy to switch back. <atw>axg: personally I use connman and I don't feel like I'm missing anything <mbakke>Actually I've been looking for an alternative, considering packaging SuSEs "Wicked". <axg>atw mbakke: I haven't heard of Wicked or connman, could be good to check out. I definitely had some problems with wicd-curses interface recently, so maybe there are good alternatives. Thanks for the suggestions. <axg>mbakke: So a "rolling-release" of the guixsd manual _does_ exist if one just gets the git project? I just thought that there might not be such a thing at all. <mbakke>On NixOS I just used wpa_gui, not sure why I haven't done the same in GuixSD :P <mbakke>axg: the online manual is generated from the git sources when a release is made :) <axg>mbakke: makes sense, thanks <mbakke>atw: Is the emacs crash easily reproducible? ***axg` is now known as axg
<atw>mbakke: on my machine, yes. The paste above shows an immediate crash after attempting to start <atw>How can I figure out the exact source used to build my emacs? How should I go about debugging this? <mbakke>Also, does the same happen if you run `$(guix build --no-grafts emacs)/bin/emacs`? <atw>Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz <atw>With your no-grafts, I get the same error message, but with the store path /gnu/store/76dj7sxkp06bkigbbgkmmfj328ppjrd0-emacs-25.3/bin/emacs-25. <axg>I'm trying to start guile repl in the cli, and I'm getting a long backtrace and this at the end `no code for module (ice-9 readline) <axg>`. How would I go about making this module load everytime I try to launch guile? <axg>installing the package guile-readline eliminated the problem <einarelen>Trying to install cfitsio-package causes some odd errors for me, are other people able to install it? <einarelen>Errors along these lines: guix/ui.scm:1489:12: In procedure run-guix-command: substitute: Bad Read-Header-Line header: #<eof> <einarelen>There is no ui.scm on my filesystem as far as I can tell <einarelen>Additionaly, if I wish to to create a package which, for some awful reason, is packaged along the lines of package.tar.gz which unpacks into package/{configure,dir1/configure, dir2/configure} and the actual package that I'm interested in is located in dir2, how do I tell guix to begin the build process in dir2 rather than the base directory? <wigust>einarelen: Do you use Guix builded from Git? <g_bor>We will have an Outreachy twitter chat today, and I have two questions, that I think would worth discussing. <g_bor>I think that this question especially : Q6: For alums and mentors: What is your advice for prospective applicants? How can they stand out? #OutreachyChat is asking for a community standpoint. <g_bor>As I am quite new in this community, I would like to ask what do you think about this? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, Apteryx says: alex-vivo reported that the substitute served for Icecat fails with some error related to gzip reaching end unexpectedly. <civodul>Apteryx: fixed now (ENOSPC on mirror.hydra.gnu.org :-/) <civodul>g_bor: how can they stand out, like in terms of knowledge and experience? <civodul>for the UX improvement topic, i think we'd appreciate people who've already played with Guix or other package management tools <civodul>if they can show they have a good idea of what it would take to improve the UX, that's great <civodul>then of course having experience programming CLIs would be great, and Scheme is a nice plus <g_bor>civodul: I'm comentoring the guile build system project. I think scheme is the most important there. <civodul>for the 2nd topic (build systems with Guix), experience with Guix and build systems is required, i think <civodul>i suppose applicants should at least get familiar with Guix before applying <civodul>so they can understand what this is about <g_bor>I was also thinking about what non-technical skills would be desirable. <civodul>i think communication is the most important one, IME <civodul>that is, the ability to talk with mentors and with the wider community <civodul>to ask for help and guidance, to get people involved in discussing choices that need to be made, etc. <g_bor>In Outreachy we will have interns who are somewhat familiar with the project, as an applicant will need to have accepted contributions to be selectable. <g_bor>It would be also nice to point applicants to issues where they can make these initial contributions. I think that packaging is an obvious one, but if you have any other good first time contribution candidates, that would be nice. <civodul>i always suggest packaging as a contribution to get started <g_bor>I have problems reaching hydra. Anyone else notices this, or is this a local issue here? <civodul>there are a few (too few) issues marked as "easy" in bugs.gnu.org/guix, too <g_bor>Ok, well I will also communicate that. <g_bor>but it seems to be working now... <civodul>looks like a problem on your end :-) <g_bor>Most probably my network connnection.... <civodul>or maybe check with "herd stop nscd", just in case <g_bor>I will write my answer according to that. <g_bor>Would you mind if I pointed Alex to read this discussion in the IRC log, so that he knows what we discussed here? <rekado_>FWIW I told the two people who contacted me about initial contributions that the best way to start is to install Guix, build “hello”, and then create a package definition. <g_bor>rekado_: I also see installing GuixSD in a vm, and then doing the same a good start. I guess it depends on the environment at your disposal. <g_bor>It was easy for me to do it that way, as I already separate my projects into virtual machines... <rekado_>g_bor: for these two projects I think installing GuixSD is too much work for too little gain. <g_bor>rekado_: You might be right about that, it is just an option that might get you faster to a working Guix. It was really nice for me the fist time to just fire up the downloaded and resized vm image we are providing. <g_bor>rekado_: :) but it's true, that I've already had everything set up to that anyways... <g_bor>I was also thinking about creating a vagrant box for GuixSD, or for Guix on another distro. I don't know if you find it a good idea. WDYT? <g_bor>We might get some developers involved more easily by providing that... <rekado_>atw: is this on i686 or somewhere else? <g_bor>rekado_: You filed a bug against java-testng recently, because some tests were failing. It seem that this has been fixed, Julien upgraded the package, and that seems to have fixed problem. <g_bor>I'm currently running a build --rounds=30, and it seems to be all right so far. <g_bor>Could you also check this? What is an acceptable threshold for these undeterministic test failures? <atw>going to work, back on soon... <roptat>g_bor: with the older version I had 3 failures in 4 attempts, and no failure on 3 three attempt for the newer version <roptat>so there's definitely an improvement here :) <roptat>if your test succeeds, we can close the issue I think <g_bor>roptat: Ok, if it succeeds, i will close it. <rekado_>roptat, g_bor: I don’t have time to test this today, I’m afraid, but if there hasn’t been a single failure in 30 builds that’s a good sign. <rekado_>it’s fine to close the bug in this case. <civodul>g_bor: np, you can point people to the log of this channel (it's prominently advertised as public) <davexunit>civodul: do you know how I could get some guix/guixsd stickers in time for libreplanet? <civodul>davexunit: you should check with cbaines, who purchased the fancy Guix(SD) stickers that we had a FOSDEM/GHM :-) <snape>Guix getpwuid doesn't work with Debian sid updated nsswitch.conf ('passwd: compat systemd' instead of 'passwd: compat files'). Thus lots of binaries don't work (screen, emacs, dbus-launch...). <mbakke>snape: Installing 'nscd' alleviates that. <mbakke>Alternatively you could remove 'compat' from nsswitch.conf. <snape>mbakke: thanks! I used a my GuixSD nsswitch.conf and it works fine now. <snape>(with files instead of systemd) <mbakke>Haven't tried sid yet, but I wonder what the systemd name service does. <mbakke>I believe installing nscd would work in any case. <snape>yes, but it's another daemon running on my machine... I don't really like that <rekado_>nscd is part of the libc; this might help justify running it. <atw>So it looks like I was bitten by https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27476. I should be able to avoid it with a --cores=1. What's weird to me is that I've used Guix on multicore for a couple months, and only over the weekend did I experience the bug. And I didn't hit it once, I hit it a couple times in a row. <atw> There's another thing that I can't figure out. Whenever I saw a failure, it was always after "compiling... 100.0%". Could that be significant? <mbakke>Nice comment from the Chromium source code. <mbakke>// We don't want this fetch to set new entries in the cache or cookies, lest we alarm the user <civodul>bavier`: looks like requiring 2.0.13 works as well with that patch, so i'll go for it! <bavier`>civodul: great, thanks for checking! :) <civodul>i know you can complain if something goes wrong ;-) <bavier`>does the daemon use all machine threads when updating the store database? <civodul>the daemon spawns one child process per active client connection <civodul>each guix-daemon process has one thread. <civodul>but each of these may access the database <civodul>so if you have --max-jobs=4242 and effectively create 4242 client processes, then they may all access the database concurrently <bavier`>I just noticed, while watching htop, that at the end of a build, all cores became active for a split second <verisimilitude>Hello; I've just installed GuixSD and have installed several packages I normally use. <sneek>Welcome back verisimilitude, you have 1 message. <sneek>verisimilitude, lfam says: 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 <verisimilitude>That's what I'd thought, but wigust had left and so there was hardly point in arguing about it. <verisimilitude>Anyway, perhaps the most important package I use, Emacs, is failing for some reason. <bavier`>ok, I've seen the same on i686 for a few months now <bavier`>but haven't had a chance to debug it <civodul>atw: it could be; so if the failed backtrace message isn't in the build log, then it's 'guix pull' failing <verisimilitude>The backtrace is rather uninformative; would a single line of it suffice, instead? <verisimilitude>That's interesting; the backtrace is the same every time, I've just now noticed. <atw>verisimilitude: I've been getting an "Illegal instruction" message in my recent emacs builds. Are you getting that? PM is fine <atw>civodul: thanks, I'll respond to the email when I get home <verisimilitude>The version of Emacs I'm currently using only brings a PM buffer when I receive a response; once you respond, I'll submit it, atw. <atw>Hmm, that looks different from my trace <atw>haha well, I found a generation that had a good emacs and switched to that. Not ideal because all my other packages are now at their versions in the old generation. But I get emacs ☺ <verisimilitude>So, I'm supposing I should simply compile and install a more complete Emacs manually, later. <verisimilitude>While I'm asking questions, I'm also having issues issuing the herd command. <atw>verisimilitude: sounds like you want sudo herd <verisimilitude>For whatever reason, I've no issue using su, but sudo isn't working. <verisimilitude>However, the root account has no access to these various tools, complicating the matter. <verisimilitude>I just tried through a pseudo-terminal, however, and it works fine now. <verisimilitude>Once I get my system working well enough, I won't need to touch it for a time; there's simply one more thing I need help with. <verisimilitude>I want to start tor at boot; I tried this in my system configuration: <verisimilitude>Anyway, there is no tor-service; would you or anyone else happen to know what I should use here? <atw>To provide a little detail on herd vs sudo herd, sudo herd will talk to the instance of Shepherd running as PID 1. That's what manages your system services. You can also run an instance of shepherd as a regular user. If you do that, then running herd (without sudo) will talk to your user's shepherd <bavier`>verisimilitude: is the (gnu services networking) module loaded? <verisimilitude>I don't believe so; the use-service-modules only currently has desktop as a parameter. <verisimilitude>Now, I'm currently editing this file as root, straight from /etc; is this considered bad practice? <thomassgn>verisimilitude: maybe you've done this - not sure what problem you have with sudo; but to be sure: sudo rights is managed with the wheel group in guixsd also, add your user to it in the config or otherwise and reconfigure/reboot. Maybe. :) <bavier`>I'm not sure about others, but that's was I usually do <verisimilitude>I'm running a reconfigure, but I'd not yet run a guix pull, which earned me a warning. I'm supposing this won't be an issue, though, since this is a fresh install, or am I mistaken? <atw>you can keep your system config file anywhere that makes sense. On my personal machine I keep in ~/config.scm. As it's owned by my user, it's easy to edit. <verisimilitude>This is only the second GuixSD install I've run, but it's been long enough to forget some details. <verisimilitude>Again, all of the help is appreciated; I'll be rebooting soon, now. <thomassgn>I'm trying to package sway and wlc which uses cmake, and I'm getting errors about variables set to "NOTFOUND"; yet the dependencies are all there. Anyone have experience with this? <axg>So, I'm trying to set up exwm, and I don't want to use the package emacs-exwm from the repo since it's outdated, how would I go about creating a desktop file correctly? I tried putting stuff in ~/.guix-profile/share/applications/xxx.desktop but the directory is write protected and won't let me add stuff. How should I go about trying to use exwm? I'm adding exwm as a package inside of emacs, the 0.17 version from elpa. <ng0>thomassgn: I can rebsae and send you my take on sway + wlc. There's an open (closed?) ticket someone in sway responded to <ng0>ACTION is compiling Xonotic \\o/ <ng0>you probably have to try a different gcc version <ng0>I hope I can send Xonotic in..I haven't checked the codebase yet for issues, but they say it's all GPL2. <thomassgn>Ah, cool. Trying to build it now. Think maybe adding cloudef's chck utility/lib fixes it. Will look some more at it today. <ng0>damn. I "dropped" sway and moved it to my pre_packages repo. In that case: git clone git://c.n0.is/ng0/guix/packages/pre.git iirc <atw>then put that package definition on you GUIX_PACKAGE_PATH <atw>Or, you can clone guix, update the definition of exwm, and send in a patch :D <thomassgn>haha, right. I see. Thanks ng0. Will see if I can do something else in the meantime then :) <ng0>it's in the "mystery/hack/sway.scm" file there <axg>atw: would that go in the system config and require a system reconfigure? It just takes forever to do that every time if that's the case. <atw>axg: if you're using a display manager (e.g. SLiM, SDDM) then WMs go in the system config. So yes, in that case a system reconfigure is required <atw>also, if you do a series of operations like "sudo guix pull ; sudo guix system reconfigure ... ; sudo guix system reconfigure ..." then I would expect the second reconfigure to be fast because it's using stuff that's already in the store <axg>atw: Alright, I will try that. I have a question for you about the root user, if you don't mind. On my system he was left uttern broken with unset up path, etc. I'm not sure if the root profile is proken or what. Is this something that went wrong on my system or the normal way and I'm supposed to set it up myself? <atw>axg: I'm unsure. Root user works on my machine™, but I can't remember if I had to do something special <ng0>q: install-file implies mkdir-p for the folder the file goes to? I haven't used it in a while <axg>atw: I think the root user isn't running /etc/profile upon loggin in or something. I'm using su or sudo su to do that from the wheel user, which might have some effect. <efraim>ng0: yeah, if its just one file then install-file works, otherwise its mkdir-p and copy-recursively <axg>atw: you know that's exactly what is going on. Since I just logged into root from a tty2 and it has the PATH and everything set correctly. Should I source /etc/profile from the root's .bashrc/.bash_profile or something? <axg>atw: and this happens both ways. If I'm logged in as root and I su to axg then I also can't run any commands. Seems like unwanted behaviour, surprised there isn't a set up in place that deals with this use case, unless I'm using su wrong. <atw>axg: not sure what you should do re sourcing <ng0>I don't like FPS games that much now, but I'm excited to see how Xonotic will perform on this laptop :) <axg>atw: does su'ing into a different user work without a hitch for you? Did you modify something about sourcing? <atw>I don't believe I modified any sourcing. I believe that sudo -i worked last I tried. Not on Guix right now so I can't test <atw>ng0: looking forward to xonotic! <ng0>i thought I was finished, but some parts are still missing <ng0>also I don't know if they use darkspaces with changes or not, so far I'm just using what Archlinux did there. <axg>rekado_: Oh, they aren't segregrated, I just thought there would be a file per package. Alright, thank you. <axg>wigust: I guess, there is only one repo for guix, the main one, I haven't really looked into alternative repos so I don't even know if that's exactly easily possible <verisimilitude>I'm considering creating a /usr/bin/env so I can more easily run sh scripts; do any of you do this? <verisimilitude>That also raises the question of which env to use; I have three different ones, but they all seem to be the same version. <nckx>verisimilitude: I have done in the past. <verisimilitude>Did you do roughly what I intend to do, which is simply to make a symlink to any env in particular there? <nckx>Oh, no. I used special-files-service-type. <nckx>It's documented in the manual IIRC. <nckx>Manual symlinking will break sooner or later when you GC the symlinked env. <verisimilitude>I can continue from the manual, now that I know where this is; it's appreciated, nckx. <nckx>Happy to have been of service. <nckx>Clear-cut answers like this are a pleasure to dole out. <ng0>I just played xonotic singleplayer <ng0>all that doesn't work is sound <davexunit>I would check that game out again if there's a package for it :) <pkill9>i use the downloadable bundle tho <ng0>Nix elf-patches curl, libogg etc in it. Is this acceptable for us? <ng0>hm, I think this is fixable in the darkplaces directory <ng0>yep/no/maybe/won't fix it in the next 7 days. <ng0>With luck I'll send a first draft in after the 5th. Can't promise anything, and I can't link to my repo here (so no preview) <axg>Alright, I'm trying to build exwm-emacs manually and I'm getting an error that reads `xhost: unbound variable`. The recipe has it as one of the inputs. If anyone knows what this might be about, info will be much appreciated. <snape>axg, what do you mean, by building it manually? <ng0>okay, sound works :) <ng0>but I've got something coming up, so I can only continue working on it on 5th of march <axg>snape: well, I copied the recipes for emacs-exwm and emacs-xelb from the git repo (the define-public stuff), put them into my system_config.scm and included (guix build-system emacs) to my (user-modules ...) and added emacs-exwm to my (packages list). My goal is to eventually update emacs-exwm to 0.17 and exacs-xelb to 0.13 as per the latest stable version, but at the moment I'm not even modifying them to see if building works. <rekado_>you can’t just paste things from other modules without also taking care of their dependencies. <snape>axg: so your goal is to have a custom emacs-exwm package that inherits the official one, with a different version? <rekado_>“xhost” is a package that is defined in a different module <rekado_>that module is imported by emacs.scm, but not by your config file. <rekado_>I recommend not to do it like that, though <rekado_>simply update the package definition in emacs.scm. <axg>rekado_: I thought that the recipe defines its dependancies and can find them. I didn't git clone the entire guix project, so can't just go ahead and modify emacs.scm as far as I understand. I don't know how to overshadow the package from the remote repo. <axg>snape: I suppose so. I'm not really sure what the inheritance thing does, but bumping up the versions to the latest ones is what I'm trying to do. I don't think that build option will have changed between those releases. I haven't really had much experience with packaging anything really, let alone a somewhat alien system like guix. <snape>But, if the change could be useful to other people, it's better to update the Guix repo, as rekado_ said, and contribute the change, so we can use it too :) <axg>snape: and for that I need to fork the repo and make a pull request? <snape>axg: you need to send a patch to guix-patches@gnu.org <axg>snape: oh alright, I will look into that. Thank you for the suggestion. Gotta log off now, but if you have any other suggestions, I will look over the logs in an hour or so, once I'm back to a spot with internet. <snape>axg: note that packages can inherit other packages, which is very useful if you want a slight modification of an official package, and you don't think that it will be useful for anyone else. <ngz>Hello. I tried installing cdogs-sdl recently. Although it builds correctly, I get a floating point error whenever I try to run it. Has anyone successfully run this game? <rekado_>but now I also get the floating point exception. <rekado_>ngz: could you please file a bug report? <ngz>Would sdl-union help here?