IRC channel logs


back to list of logs

<drewc>Hello All! I just recently started trying GuixSD on my thinkpad. Everything seems to work great save for the wifi. I am assuming it is a nonfree firmware, and googling finds me a number of .scm's, so where should I start?
<buenouanq>I don't know if the official people as part of gnu can help with nonfree terribleness - It's something they explicitly do not support. I would start with whatever Debian says about your chip. I would suggest getting something like the freedom respecting Think Penguin dongle.
<buenouanq>That is an interesting question - Are you guys bound to not help with nonfree drivers and stuff?
<drewc>Fair enough. Please allow me to follow with a question that does not invalidate anyones freedom. I have a linux-social.scm which I found on google, which contains a number of packages that are not in the mainline, as they are kernel patches that are not for the light of heart, to make it run on hardware that only I possess. What is the simple way to use that .scm to test it out?
<mange>I think you should be able to replace the "kernel" field in your operating-system declaration with a package that specifies a different kernel.
<drewc>Makes sense, I've seen something similar in my search results. In order to do that where/how should I place/import the "linux-social.scm" file that I found so that `guix system reconfigure` will have the packages available?
<cbaines>drewc, it just needs to be on the GUILE_LOAD_PATH, in the correct directory structure
<cbaines>at the top, there will probably be a line begining (define-module (... e.g. (define-module (gnu packages linux)
<cbaines>I believe you will need to place the file in a directory structure matching each module namespace, e.g. gnu/packages/linux.scm for the above example
<mange>It's hard to say exactly what you have to do, because it depends a bit on the contents of linux-social.scm, but cbaines is right about the load path. You can also add directories to the load path with the --load-path= argument to `guix system`.
<drewc>awesome, that should point me in the right direction. Thanks a bunch!
<nextos>lfam: thanks. makes sense, texlive is huge and most files are not being built
<lfam>nextos: There's been discussion on guix-devel of breaking the big texlive-texmf package into modules, but it's complicated
<nextos>lfam: yes, texlive is a huge beast
<buenouanq>anyone here set up an nginx server on guixsd?
<buenouanq>nginx: [alert] could not open error log file: open() "/gnu/store/np656cjgc87rv18klcr2vwxk6g0kjhbz-nginx-1.11.6/logs/error.log" failed (2: No such file or directory)
<buenouanq>looks like I should be doing this from the guix system reconfigure service rather than as a specific user
<buenouanq>the guix way still hasn't sunk into my core yet
<atw>so...are some things meant to be run as plain old programs whereas others really should be used as services?
<buenouanq>I think it's not just that they're meant to, but have to because of the nonstandard file hierarchy.
<lfam>buenouanq: That nginx log error should be harmless. Nginx will always print that error while starting, before it reads the configuration file.
<lfam>If you want to run an nginx server on GuixSD, doing it in the OS declaration is the supported method, but I don't think it will be impossible to do it another way
<buenouanq>I'm going to try the supported way.
<lfam>Okay, let us know if you get stuck. I did it recently so it's fresh in my mind
<buenouanq>will do, thank you
<buenouanq>should gnunet be installed and run as a service in the OS config?
<lfam>I don't think we have a service yet. ng0 has been working on gnunet in Guix. I think there is discussion in the guix-devel archives about the work so far
<lfam>It's also possible to have unprivileged user services, but for now you have to write them yourself.
<lfam>They can be very simple
<buenouanq>lsh or openssh?
<lfam>It's up to you. Of course OpenSSH is more established, but they can talk to each other if you convert the keys.
<buenouanq>lfam: should I be setting all the nginx things in the system configuration, or leaving them to be the defaults and doing everything I want later through the nginx config?
***atw` is now known as atw
<lfam>buenouanq: I just put everything in the nginx config, by adding this line to the services field of my OS declaration:
<lfam>(nginx-service #:config-file "/etc/nginx/nginx.conf")
<lfam>It would be better to include the configuration in the OS declaration itself, but I didn't try that yet
<buenouanq>why would that be better?
<lfam>buenouanq: I'd rather have the configuration controlled in the same place
<buenouanq>I get the unified one true way for package installation, but I don't know if I'm there yet with configs.
<buenouanq>I'll get there, only a matter of time and experience surely-
<buenouanq>nginx: configuration file /etc/nginx/nginx.conf test failed
<buenouanq>shepherd: Service nginx could not be started.
<buenouanq>any ideas? is it maybe a permissions thing?
<lfam>buenouanq: Try running `nginx -t -c /etc/nginx/nginx.conf` and look for the problem it reports
<lfam>The -t argument tests the configuration file
<lfam>Hi bldtg
<bldtg>I'm seeing if I can manage to package something.
<bldtg>Hi lfam
<lfam>I'm sure it's possible :)
<buenouanq>lfam: I get -bash: nginx: command not found
<lfam>buenouanq: You need to make nginx available to yourself somehow
<lfam>I recommend `guix environment --ad-hoc nginx`
<buenouanq>I'm doing this all as root - Should I switch to a dedicated nginx user?
<buenouanq>will that add it to my env forever, or will I have to run that every time?
<lfam>buenouanq: I'm suggesting you set up an ad-hoc environment with nginx available in order to test your configuration, which appears to have a bug in it
<lfam>For system services, you don't install the packages into any user's profile. The necessary package is automatically provided for the system service
<lfam>`guix environment` is documented in the manual, section 6.10 Invoking guix environment
<bldtg>Hey lfam, do you happen to know about packaging for guix?
<lfam>bldtg: Sure, go ahead and ask your questions
<bldtg>lfam: What is the guix source tree?
<lfam>It's located here:
<bldtg>The packaging guidelines says to store the package definition in the guix source tree.
<bldtg>So I need to use git before I test my package?
<lfam>bldtg: Yes, you'll need to obtain a copy of the source code with Git, and then follow the instructions in the manual, section 8 Contributing
<lfam>It is possible to use the package another way, using the GUIX_PACKAGE_PATH environment variable.
<lfam>This is mentioned in section 7.5 Package Modules
<lfam>But it's best to check out the source code and try integrating your package into it if you intend to submit your package for inclusion in GNU Guix
<bldtg>thanks, I guess I need to read more documentation.
<bldtg>Why is arc-theme in gnome.scm?
<buenouanq>lfam: [emerg] 5406#0: getgrnam("nobody") failed
<buenouanq>it gets past this if I add user root; to the config - But that is not something I want to do I don't think. Doesn't work with other users, only root.
<lfam>Do the other users exist?
<lfam>I created an nginx user for my use case
<buenouanq>yes, it just replaced nobody with the user name in that message
<buenouanq>except for when it was root, making me think it was an owner/permissions thing
<buenouanq>but I still encountered it if I changed those to the given user
<lfam>getgrnam looks up a group. I bet you'll also need to make the group for the user
<lfam>`man 3 getgrnam`
<buenouanq>No manual entry for getgrnam
<buenouanq>well, it got past that now when the user was nginx
<lfam>Hm, I guess we aren't shipping the Linux man pages by default on GuixSD
<buenouanq>I obviously have no idea what I'm doing - Thanks for bearing with me.
<buenouanq>I'm having fun though, and learning lots.
<lfam>buenouanq: I have to go, so here's a basic configuration that sets a bunch of paths that won't be writable in their default locations (in /gnu/store) on GuixSD.
<lfam>I'm not an nginx expert, but this did work in my tests last week
<lfam>If you don't override those paths, the nginx config test will fail
<lfam>IIRC, the mime.types won't be found, but that's not a fatal error
<lfam>You'll need to chown the /var/run/nginx and other directories to the nginx user
<lfam>Good luck
<buenouanq>thank you
<bldtg>Hello buenouanq
<bldtg>I have a feeling it's going to take me all day to understand everything that goes into changing 4 characters for a package I want to update.
<buenouanq>there's an emacs mode for that
<bldtg>what mode is that?
<buenouanq>┐( '~')┌
<bldtg>M-x understand-everything
<sneek>baconicsynergy, you have 1 message.
<sneek>baconicsynergy, rekado says: When building things with Guix it doesn’t matter what you have installed locally. All that matters is what the package expression declares as inputs, as these are the only things that appear in the build environment.
<baconicsynergy>rekado: im not quite sure i follow
<jmd>Starting the cow-store service seems to corrupt /tmp
<davexunit>lfam, buenouanq: nginx has default log and run directories set at build time, and upon install time it creates those directories, therefore without some hackery you cannot set the defaults to /var/log/nginx and /var/run/nginx because there is no /var in the build container.
<davexunit>this is why you currently have to configure them manually.
<davexunit>why are we using mesa 13?
<davexunit>it's an unstable development series.
<davexunit>maybe someone really wanted to use opengl 4.4 :)
<jmd>Is there a way to find out which Guix os is currently running?
<drtan>Hi! I am playing with Guix SD inside a VM (QEMU KVM). I've tried the installation on an encrypted partition (LUKS) and everything worked well until reboot. GRUB can't see the partition. When I boot back the install image and try to open the partition it is not recognised by cryptsetup. Is there anything I could have forgotten?
<drtan>jmd: Maybe guix --version? :)
<jmd>drtan: That doesn't actually tell me which os.
<drtan>jmd: Maybe then 'uname -a' do?
<jmd>That just gives the kernel version
<davexunit>jmd: there is no such version
<drtan>Could you give me an example of what you understand as the os.
<jmd>Well there are various oses defined in the guix source. To name a few: guix, guix-devel, guix-0.12.0, current-guix and installation-os.
<jmd>I'd like a way of finding out which one I'm booted from.
<davexunit>you're not "booted" from any of them.
<jmd>... then to be more precise: Which of those images is the currently loaded system.
<davexunit>none of them, most likely.
<davexunit>I think the question is still too vague.
<jmd>davexunit: How would you phrase it?
<davexunit>you can never know which version of guix produced a store item
<davexunit>it's a one-way transformation
<davexunit>guix produces derivations which are built by guix-daemon and they produce store items. in the case of GuixSD one of those store items is a new GRUB configuration that gets installed upon 'guix system init' and 'guix system reconfigure'
<davexunit>you can't look at anything produced and know which version of guix produced it. does that make sense?
<jmd>sort of...
<davexunit>even the word "version" is incredibly vague here.
<davexunit>it's a one-way function. think a singly linked list vs. a doubly linked list.
<jmd>davexunit: ... which is why I did not use the word.
<davexunit>jmd: not saying that you did.
<davexunit>I used it and was pointing out that the rabbit hole goes deeper.
<jmd>I guess I'll just have to use a heuristic then.
<davexunit>I think you need to re-think what you're trying to do, not brute force another way.
<jmd>I don't regard it as "brute force". Rather if I cannot go over the mountain, tunnel through it or eliminate it, then I'll go around it.
<davexunit>it's not clear why you want to know
<davexunit>and what good it will do
<davexunit>if you're after OS metadata, there are things we can do to provide that.
<davexunit>there's a file that has been somewhat standardized due to the popularity of systemd that contains such metadata
<davexunit>we could generate the same type of file
<jmd>That might be useful.
<davexunit>does it fit your use-case?
<davexunit>I think if we could better understand the end goal, the right path to get there would be more clear.
<jmd>I'll have to read spec in full to be sure.
<jmd>As for the "why" question, I can think of various motivations..
<jmd>but my current requirement was to know what to use as a /tmp directory.
<jmd>... since in the installer-os /tmp doesn't play nicely with cow-store.
<davexunit>has a bug been filed?
<jmd>I'll see if I can make a reproducible test case and file a bug.
<jmd>... but right now, I must find a way around this mountain ...
<roelj>Is there a convenience function in Guix to get the size of a file?
<roelj>Or is it easily done in Guile anyway?
<jmd>ls -l <filename>
<davexunit>roelj: you can stat the file and get the file size
<davexunit>in bytes
<roelj>davexunit: Right. so stat:size :D
<roelj>Any suggestion for getting the size of all files combined in a directory?
<roelj>davexunit: Thanks again
<ng0>let's say I want to update rust to 1.14.0, what is "one version below the released version" then? 1.13.0 ?
<ng0>previous release is really 1.13.0, so I suppose 1.13.0 is what I'll use
<geemili>How do I use boost as a dev library?
<geemili>Do I just add it as a package to `guix environment`?
<rekado>I’d like to give the Hurd a try again. Do you know how I could play use it with Guix at this point?
<rekado>ISTR that Manolis hosted substitutes for the Hurd.
<jin>hi rekado, i use Debian GNU/Hurd for tests!
<rekado>jin: do you use Guix on top of Debian GNU/Hurd?
<jin>yes, an old version of Guix/Hurd
<rekado>I would like to know how far we are away from building GuixSD based on the Hurd.
<jin>I see that Manolis has updated the repository!
<jin>I'm only test some applications,
<atw>jin: latest commit on wip-hurd was in February
<jin>atw: there is a new branch, wip-hurd-native, i have not tried yet. In a moment!
<atw>I'm not seeing it on
<jin>this is:
<rekado>phant0mas: hi there!
<phant0mas>hello rekado !!
<phant0mas>how are you?
<rekado>a little under the weather, but fine otherwise. And you?
<phant0mas>too much work, trying to finish all my forgotten patches during the holidays
<phant0mas>rekado, what I said in the mail, most of my guix-hurd work is in guix proper
<phant0mas>either in master or core-updates
<phant0mas>next time we merge those two, we will be able to start cross-building for hurd through hydra
<rekado>phant0mas: do you know how much work it would be to build a GuixSD system with the Hurd?
<phant0mas>there's still work to be done, but I will get there
<phant0mas>the problem is that with the latest guix updates some things broke
<phant0mas>like cross-compilation for the Hurd
<phant0mas>but with my latest patches this is fixed now
<atw>exciting work!
<phant0mas>rekado, I hope I will have more things to report soon
<phant0mas>rekado, btw if it is okay with you I will push the latest hurdish version of glibc to master
<phant0mas>atw :)
<rekado>phant0mas, is there a patch that we should have reviewed?
<phant0mas>not for now, I think
<phant0mas>I will have look though, because I forget sometimes
<braunr>phant0mas: o/
<ng0>rustc 1.14.0 compiles, I can send in the update once it finishes... hopefully today
<ng0>this should solve most of the current "oh noes, rust package does not compile" problems on the lists
<rekado>braunr: hello!
<phant0mas>hello braunr
<ng0>I have 2 more hours I think.. how long does rustc normally take to compile?
<geemili>I think it's between 1 1/2 hrs and 3 hours
<geemili>Going by the CI times
<ng0>ah, then it'll finish before 21 UTC
<geemili>I'm assuming it means time to build in minutes
<ng0>doc ... hm could be done soon
<ng0>will send it any minute
<ng0>apparently updating rustc did not fix the rust-libc build and I need to look at cargo or the build system again
<ng0>ah, 1.13.0 based... released 2016-11-07
<ng0>I should package cargo on its own
<amz3>I have an old package.scm file that use (source ".")
<amz3>I have the following error when I try ot guix -f package.scm
<amz3>what's the new syntax for (source ".")
<amz3>I can also install manually the dependances
<alezost>amz3: something like this: (source (local-file (string-append (dirname (current-filename)) "/<your-source-file>")))
<roptat>I have a device with no internet connection
<roptat>is there a better way to install software than to transfer all source files?
<lfam>roptat: You can use `guix archive` to export substitutes and transfer them to another machine
<roptat>oh, I'll go look in the manual then, thanks :)
<roptat>would it work for cross-compiled packages though?
<lfam>roptat: Assuming you build the substitutes with the correct cross-compilation settings, I don't see why not. But I've never tried it
<buenouanq>lfam: your nginx config worked, thank you - But that service packaging needs work. There's a bunch of default files and things that should be, but are not installed.
<lfam>Yes, it's a work in progress
<buenouanq>aren't we all
<lfam>You should send a message to the mailing list explaining what needs to be done
<buenouanq>well, having never set this up on a normal distro, I don't actually know (;-___-)
<buenouanq>one thing someone else shared with me was the mime.types file it wants
<lfam>If I understand correctly, that file is included in the package, but it just needs to be copied into the appropriate location
<buenouanq>which it can't because that default location is owned by root?
<buenouanq>but I guess you're running system reconfigure as root, so that shouldn't be it
<lfam>There's a difference between building packages and reconfiguring the system.
<lfam>Building a package can't and won't put the file in place. But reconfiguring the system requires root privileges and it can do stuff like that
<lfam>Most of /etc on GuixSD is managed by GuixSD, so it's definitely possible to improve the aspect of the nginx service
<lfam>this aspect
<lfam>My understanding is that we added the minimally viable nginx service, and now we can improve it as necessary :)
<drewc>What are the proper ways to use GuixSD yet run a bunch of shebang scripts (like #!/usr/bin/env bash )? Is there a simple trick I am missing when `whereis env` says what it says?
<lfam>drewc: What do you mean by "Is there a simple trick I am missing when `whereis env` says what it says?"
<lfam>In general, if you don't care that your scripts won't get the benefits of Guix, and might break randomly like on a "traditional" distro, you could just symlink the env binary to /usr/bin/env
<lfam>The question of shell scripts on Guix has been discussed many times, and I'm not sure if anyone came up with a good solution in the last few discussions. You might check the guix-devel and help-guix archives
<buenouanq>`Warning: untrusted X11 forwarding setup failed: xauth key data not generated'
<buenouanq>I can't get ssh -X to work from a GuixSD machine, though it will work from a Debian to a GuixSD machine.
<lfam>buenouanq: Did you check to see if there's already a bug report?
<drewc>lfam: Yeah, that is what I am doing, but I was hoping there was something simpler. I am trying to build chromium, and hoping to do a chromium.scm you see. The docs require a bunch of dependencies which may or may not require /usr/bin etc, which is probably not what is wanted or even allowed for a GuixSD package. Thanks for the confirmation :)
<lfam>drewc: The Guix build systems automatically patch shebangs. So if you are making a package, it shouldn't be an issue
<lfam>If you want to try building it outside of a Guix package (by hand), you could try using the patch-source-shebangs Guile procedure on the source tree manually
***propumpkin is now known as copumpkin
<drewc>oh, does it automagically do so? That sounds so wonderful! I'll look at the docs at try the manual procedure thing as well. W00t!
***jonsger1 is now known as jonsger