<lostcoffee>per the manual, I'm trying to build guix from source to edit a package. After guix environment guix, where do I cd? <lfam>lostcoffee: change to the Guix source code directory that you create with `git clone` <lfam>The calibre packge isn't working. Essentially, "ImportError: No module named QtWebKitWidgets" <jmd>How can I find out why a service is not starting. There is very little in the logs to help. <janneke>trying to run hydra i now get Evaluation errors on the web gui: file ânixpkgsâ was not found in the Nix search path (add it using $NIX_PATH or -I) <janneke>how do i parse this message, ie: what program says this, needs this env var, where do i point NIX_PATH, what is it supposed to point to? <janneke>when trying to debug rottlog, it was enough to just run the service command manually: it bombed out with because a directory was missing <jmd>janneke: Is there not a common way to see what services in general are doing? <janneke>jmd: possibly; if you find out, i'm happy to learn it ;-) <janneke>ACTION figures that `nixpgs' is: git clone git@github.com:NixOS/nixpkgs.git <jmd>janneke: It is a service which doesn't (yet) exist in git.sv.gnu.org/guix.git <ng0>I will release an update of gnurl today (just doing last fixes).. I think someone else should update the package in guix then because you either trust me that I checked my own gpg key or you want to be on the extra safe side that it is signed and good to go. otoh I would have no problem sending the update on the guix package. wdyt? <jmd>Is there a deactivation-service-type? IE, something which runs when a service is disabled? <taylan>if anyone else has 'guix pull' print stack traces, please let me know <jmd>What does "make-kill-destructor" actually do? <jmd>(YEs I did search for that in the manual) <ng0>oh joy... how do i remove a file from the store? I accidentally published the new gnurl without a configure file at first.. and now guix wants to load the old one -.- <ng0>'accidentally' because there were almost no guidelines, the ones i had left out 'do include configure in the distribution' <jmd>So far as I know the only way is guix gc -d <ng0>where after -d the filename follows? <jmd>I think so. I'd have to look up the details <ng0>at least the build for gentoo looks like i fixed it. i hope no one monitors gnurl releases so that the 5 minutes of missing configure went unnoticed :) <ng0>this was the first release i made ever.. so a tiny mistake is okay. <jmd>did you run make distcheck ? <jmd>make distcheck should have caught it. <ng0>ah. okay, that was missing from notes too.. thanks. I'll know for the next time. <ng0>it was very manual what i did. <jmd>It'll also catch a lot of other release problems. <ng0>gnurl/curl has no such rule though. must be somehwere else <jmd>That assumes that the package is automake generated. <jmd>If it is an automake based configure, then there should be a rule called distcheck, unless it was explicitly disabled. <ng0>argh. i updated it.. i checked for configure and even downloaded it again after i uploaded it. yet guix doesn't get the change oO can someone download gnurl 7.50.2 and tell me that the file is there now and I am not imagining things? https://gnunet.org/gnurl <jmd>Seems to have a ./configure from where I stand. <ng0>guix @ greendragon y u so weird. <ng0>could be that the other machine has the cached wrong file. <ng0>thanks for checking :) <jmd>It could be. That is one reason why the Soyuz method of making realeases is a very bad idea. <jmd>That was the name give to the early Soviet space missions. <ng0>i ran tests and bbuilds on guix and gentoo multiple times until everything checked out 100%. <jmd>They were numbered sequentially: Soyuz-1, Soyuz-2 .. Soyuz-N <jmd>But the "policy" was to make the mission public only after it had been succesfully concluded. <jmd>If Soyuz-5 ended in disaster, then it's very existence would be denied, and the next attempt would also be called Soyuz-5 to maintain an appearance of consistent success. <ng0>i see where you are getting with this. and i thought about naming the new upload 7.50.2.1 or something, but it was a 5 minute frame with no official announcement. next time i know better <jmd>So, I recommend, that if you make a mistake releasing gnurl-N - then accept your mistake and fix it with gnurl-{N+1} <jmd>or gnurl-N.1 if you like. <ng0>deleted everythin in /gnu/store/ on build + local machine .. still failing.. maybe it is some /tmp/ mistake.. <jmd>If you do that I think you'll end up with an unrepairable system. You'll have to re-install <jmd>ng0: If you delete everthing in /gnu/store then you'll have a broken system. <ng0>i did not deleted literally everything, i know that this is bad.. I just deleted the gnurl-7.50.2 tar related files with gc. <jmd>The gc will refuse to remove it, if it isn't "dead" <ng0>it was removed successfully. but i don't know why it keeps coming back <jmd>Use the --get-referrers option of c <ng0>head @ desk^2 ... I'll just do a new version now. <ng0>okay, i made no mistake, this was because of the conflicting file name that drupal renamed it. <dvc>Hi, so aliasing guix to $HOME/guix/pre-inst-env guix works well for using a custom guix version. But getting the custom daemon to work isn't quite as simple... <dvc>I'm running ./configure --libexecdir=/home/dvc/guix --localstatedir=/var && PREFIX=/home/dvc make <dvc>what should I be running? <dvc>substitute: error: executing `/usr/local/libexec/guix/substitute': No such file or directory <dvc>guix build: error: build failed: substituter `substitute' died unexpectedly <jmd>dvc: I'm not sure exactly what you're trying to do. But if you want to set prefix, then the correct way is --prefix= to configure. <dvc>I made some modifications to guix/scripts/offload.scm that aren't working <dvc>I noticed that that's because I'm using the 0.11.0 daemon instead of the compiled one <dvc>so I modified my systemd Exec line to ExecStart = "/home/dvc/guix/guix-daemon --build-users-group=guixbuild"; <dvc>but that causes errors like the one above - so I'm still missing something <jmd>guix doesn't use systemd <dvc>guixsd doesn't, but you can run guix anywhere <dvc>at least in theory ;-0 <jmd>Yes. But I don't understand why you are talking about systemd . <davexunit>ACTION finally has avr firmware compiling with avr-gcc <davexunit>still some issues to work out with our avr-gcc package, things definitely don't "just work", but at least I can compile now <dvc>jmd: I'm still running on nixos. So I have a systemd service that starts the guix daemon. I'm trying to use the guix daemon I compiled, but I think I'm missing some compile options, because doesn't it doesn't find guix substitute. <jmd>I'm afraid I don't know much about nixos. <dvc>It's not a nixos issue - nixos just runs guix-daemon <jmd>Did you actually run "make install" ? <dvc>guix-daemon is looking in the wrong places for stuff <jmd>That is probably why then. <dvc>I want to use the development version <dvc>but I don't know much about c <dvc>do I have to run make install always? <jmd>If you want to run it, at least. <jmd>The docs for make-kill-destructor say that it "returns a procedure". When and where is this procedure run? <dvc>it's called by herd stop - but I'm assuming that that's not what you mean? <jmd>Well stop referes to a gexp. <jmd>And that gexp, in most cases calls make-kill-destructor. <dvc>the gexp is evaluated at a different time than the make-kill-destructor call <dvc>the gexp is evaluated when the serivce configuration files are created <dvc>so it adds a file to /etc/shepherd/serivce <dvc>or is this still not what you meant? =P <jmd>I want to add a command to be executed immediately after the make-kill-destructor <jmd>Or, to be more precise, after the make-kill-destructor is called, I want another procedure to be called. <dvc>have you tried #~(begin (make-kill-destructor) (other-function))? <jmd>other-function appears either not to be called, or fails <jmd>I have a feeling there may be some undocumented restriction that only a single, simple procedure may be called within a gexp. <dvc>jmd: no that's not the case <jmd>So how can I debug the internals of herd start/stop ? <dvc>jmd: so it adds a service file to your store /gnu/store/*-shepherd-service-name.scm <dvc>if you add (display "hello") it should print to tty1 when you run herd stop <dvc>give me a sec to test that =P <jmd>How can I find out the exact name of this derivation? <dvc>it's not a derivation but the result <dvc>find /gnu/store/*-shepherd-service-name.scm <dvc>find /gnu/store | grep shepherd-service-name.scm <jmd>Do you mean literally 'shepherd-service-name' ? <dvc>service-name is what you added in the shepherd config <dvc>so sherpherd-term-tty2.scm for example <jmd>ok there are quite a few versions as a result of my prior attempts. <jmd>But, yes. The code is there which seems consistent with what I wrote. <dvc>I'm currently trying this <dvc> (stop #~(lambda (pid . args) <dvc> (kill pid SIGTERM)))))))) <dvc>it looks like make-kill-destructor returns a function that takes a pid and args <alezost>yes; or to make a direct wrapper for make-kill-destructor: <alezost> (apply (make-kill-destructor) pid args) <dvc>case closed - now I can go back to being unproductive with the guix-daemon =P <jmd> Right. So something must call (apply (make-kill-destructor) pid args) <jmd>What is it? And how can I influence it? <dvc>that just does kill pid SIGTERM <alezost>dvc: do you run guix-daemon with pre-inst-env? <jmd>How can I make a wrapper to directly run /gnu/store/.../*.scm ? <jmd>I'm trying to add a procedure to be run directly before make-forkexec-constructor and a corresponding one directly after make-kill-destructor. <dvc>alezost: That worked! Thank you! <jmd>Or, perhaps if I understand it correctly what I should be doing is to be adding these procedueres to be run before/after the result of make*-con-destructor have been evaluatied. <alezost>jmd: dvc showed you how to add a code before make-kill-destructor <jmd>alezost: I did that. and either the code failed or was never run. It is hard to be sure. <dvc>jmd: I tested it, it works... :) <alezost>jmd: can you show the resulting /gnu/store/...-shepherd-foo.scm file? <jmd>... and ... as I have pointed out several times already, this is probably wrong, because (make-kill-destructor) does NOT run a kill-destructor. It simply returns a procedure, which when run, will do the necessary actions. <jmd>Ipso facto adding a procedure directly after this call is probably not going to work. Am I wrong? <alezost>jmd: it looks incomplete/broken, what's the code for your service <jmd>alezost: You want to see the entire code? <alezost>jmd: you are right: make-kill-destructor returns a procedure (lambda (pid . args)...), and dvc's code should work :-) <jmd>I don't understand what he want me to do with that code. Adding it is to start/stop is clearly not the thing to do. What am I to do with it? <alezost>jmd: instead of (stop #~(begin ...)), use (stop #~(lambda (pid . args)...)) <alezost>for start it should be #~(lambda args (apply (make-forkexec-constructor #$gss-command) args) ...) I think <alezost>actually I don't think you need to do such special things, or is it just for testing? <jmd>Have you a better suggestion? <dvc>jmd: what are you trying to do? <dvc>why isn't the default make-forkexec-constructor working for you? <jmd>I am trying to add a procedure to be called immediately before make-forkexec-constructor and a corresponding one immediately after make-kill-constructor. <jmd>Because there are preconditions upon which the constructor relies. <dvc>what sort of preconditions? <jmd>Like pipefs has to be mounted <alezost>I think preconditions are handled during activation <alezost>but maybe your service is more complex <jmd>I looked at that possibility too. Unfortunately there seems to be no "deactivation" <jmd>There is no hook that runs on herd disable so far as I can tell. <jmd>Of course, one solution would be to add another service upon which this service depends, but I thought that would be overkill. <sajt_>hi, I'm in the process of installing the system <lostcoffee>speaking of herd, is there a way to list the herd services? <sajt_>first time setting up config.scm <sajt_>but I'm not sure what things can go into services <sajt_>and since I don't want to use gnome or xfce <sajt_>I want to look up what else there is <dvc>sajt_: I'm working on hawaii-desktop, but it's not ready yet. In the meantime xfce is probably your best bet <dvc>and slim should list it <sajt_>dvc: I prefer regular startx / xinit, is that an option? <dvc>without a graphical display-manager? <sajt_>dvc: slim was always too buggy for me <dvc>that doesn't work out of the box <dvc>but there is sddm service <dvc>it just doesn't work yet, because it's missing patches from core-updates <dvc>if you want to try that you can look for the enable wayland flags in core-updates <sajt_>any idea if I can skip the grub configuration as well? I have libreboot with the grub payload <dvc>sajt_: don't know, but there are a few people using libreboot <snape>sajt_: I think libreboot's grub will read your own grub's config file <snape>thus your config file has to be generated <sajt_>snape: yeah, but that way I'd have two grup menus <sajt_>I'd prefer to use libreboot_grub.cfg <jmd>Where is waitfor documented? <snape>there is a --no-grub option, let me check <sajt_>snape: thank you, everyone here is very helpful <sajt_>so I give that to guix system init? <snape>according to a comment in the code, <snape>grub.cfg will be built for other reasons <sajt_>I don't mind grub.cfg being built, I can copy it for libreboot <sajt_>so I still need the grub part in config.scm? I just deleted that... <snape>I don't think so, but I can't say for sure <dvc>alezost: using ./pre-inst-env guix-daemon fails when trying to get substitutes <dvc>does it work for you? <dvc>;;; Failed to autoload make-session in (gnutls): <dvc>substitute: ;;; ERROR: missing interface for module (gnutls) <dvc>the GUILE_LOAD_PATH is set... <snape>sajt_: config.scm:6:0: error: missing field initializers (bootloader) <alezost>dvc: you need to make sure that your systemd service uses the proper GUILE_LOAD_PATH (with gnutls) <snape>(I tried to run guix system reconfigure without the bootloader option and it fails) <snape>s/bootloader option/bootloader field/ <sajt_>alezost: thanks, I'll check it out <dvc>I already got it working <alezost>^^^ most likely that is not a working service but it's closer to it :-) <jmd>I did try something similar earlier. <jmd>Unfortunately mount and umout are not documented so I can only guess exactly what they do. <jmd>davexunit: Yes, I do realise that. <davexunit>and there are docstrings for these procedures <davexunit>so you can also inspect them at your repl without reading the source <jmd>ERROR: In procedure module-lookup: Unbound variable: mount <davexunit>you haven't imported the right module, then. <jmd>I would be tempted to ask which is the right module to import, but I fear I would be told to read the manual and stop asking annoying questions. <davexunit>a quick grep tells me that it's in (guix build syscalls) <sajt_>wow, installing away.... btw. I really wish there would be something like paredit for zile <alezost>dvc: I've just noticed that you changed syslog-service to make it accept syslog-configuration instead of keyword arguments. I probably missed a discussion, is it a convention now to use configurations in services? <dvc>ludo thought it was a good idea <dvc>sorry if it broke stuff for you <alezost>thanks for the info, I think I should update lirc-service to use configuration as well <dvc>Can someone explain to me why this doesn't work?ssh alarm@bbb.craven.ch 'guile --help' ~/guix <dvc>bash: guile: command not found <dvc>it works when I ssh and then run guix --help <dvc>is there a reason .bashrc isn't run? <dvc>random-nick: got it to work <dvc>had to enable PermitUserEnvironment in sshd_config <dvc>and add an environment file to .ssh folder <dvc>the problem is that ssh doesn't run .bashrc in non-interactive-mode <jmd>I need a code snippet which waits until a directory is non-empty. <jmd>is it better to use stat or some other method? <dvc>jmd: that sounds like pipefs should be a separate service... <jmd>dvc: I was wondering about that too. <jmd>But I can see that that approach is going to make startup almost as slow as SysV and seems like an overkill anyway. <dvc>I finally got my kernel to compile on my beagle bone! Setting up offloading and hacking offload.scm to work with openssh was a piece of work... <dvc>mmh, I jumped the gun - while unpacking the linux kernel - no space left on device, which isn't possible <jmd>Is there a "deactivate" action for services ? <dvc>herd disable service-name <dvc>I don't know - you'll have to check the source <lfam>dvc: You could have run out of inodes <dvc>lfam: I set TMPDIR to /home/alarm/guix-build-dir <dvc>I think that the tmpfs was running out of ram <lostcoffee>I symlinked ~/.config/guix/latest to my clone of guix and now guix package -i can't connect to the daemon socket. Do I have to make changes to the daemon to get my own build of guix to work for my user? <lfam>losfcoffee: When you built Guix from source, did you set a value for `./configure --localstatedir=???`? <lfam>On most installations, that value with be /var, meaning the local state is in /var/guix <lostcoffee>uh, pretty sure I just did a ./configure . Thanks, I'll redo it <lfam>The default value is /usr/local/var, but the Guix binary installation and GuixSD both use /var <lfam>lostcoffee: Does /var/guix exist? If so, I'd say yes <lostcoffee>alright, great, I think I can fix it. I also had to link ~/.config/guix/latest back to its original value to get guix environment guix to work again :P <lfam>A good learning experience, it seems :) <lfam>Wow, the sonata package on guix-devel. The last message on that thread was February 29. I had given up and archived the discussion. Very happy to see it. And it seems to be working just right :) <lfam>I guess we will need to graft the patch and update the package on core-updates <lfam>I guess you have to decide whether or not you treat CAs as (partially) hostile <lfam>Or, as potential attack vectors. I think the answer is "yes" <lfam>But in that case, all bets are off <dvc>how do I herd start cow-store /mnt without herd? <dvc>I'm trying to use guix system init from an arch linux arm install <dvc>can I just sync after guix system init? <jmd>dvc I would imagine that you could, but I've never tried it. <lfam>I know that at least civodul and mark_weaver have installed GuixSD on top of an existing distro like that. They could probably give you advice about how to do it <dvc>lfam: how do I apply the entire email using emacs-notmuch? <dvc>or do you have a different setup? <lfam>dvc: I don't know, I've never used emacs-notmuch. I use mutt, and while I have the message open, I press the pipe key '|', and then type 'cd ~/work/guix && git am' <edangor>Sorry to interrupt but I have a proble with the installation <lfam>edangor: Let's get it working :) <lfam>dvc: The pipe key in that context does what you'd expect. 'git-am' is reading on stdin and mutt passes the message on stdout <lfam>This is a super easy workflow and I will be unhappy if I have to stop using it :) <efraim>dvc: let me know if/how you get it working, I have an EFI laptop that I was thinking of going the same route <efraim>also, if git am doesn't work, sometimes git apply does <dvc>how is that easier than git remote add, and git fetch? <edangor>ok after doing everything on the manual and rebooting i get the grub rescue mode, and says: eroor: file not found. <efraim>did the installation complete successfully? <lfam>dvc: That could work too. I just don't want to have to use the security disaster that is a web browser to develop this operating system :) <edangor>efraim: yeah, well almost, openldap didn't installed at all it always stopped at 2.5MiB <edangor>running the same command over and over to install the other packages <lfam>dvc: Also personal bias against the mouse coming into play. But, the security issues happen to be a better excuse. <lfam>edangor: I'm a little confused. Which command did you have to run repeatedly? And, can you share the operating system configuration file that you used, and also the exact error message you are seeing? <lfam>You can share those files using paste.lisp.org <dvc>lfam: you use glibc, how is that not a security disaster ;) <lfam>All software is insecure, but some software is orders of magnitude worse than others. <paroneayea>dvc: what's a security disaster about glibc, aside from it being C? <dvc>have you checked the reported CVE's? tonns more than for other projects <paroneayea>dvc: it's also more central to the entire structure of everything <paroneayea>so it gets more analysis, and edges are more sharp <paroneayea>dvc: I bet if you plop in any C library with as broad adoption as glibc, <lfam>I think *allowing* contributors to use a web browser is a great idea. But it should not be required. <lfam>I'm all for a hybrid web / mail or git system <dvc>I think musl doesn't do to bad of a job in regards to security, but I don't know too much about this stuff... <edangor>uhm sorry, how do i get to my config file if i can't boot into the system? <lfam>edangor: Good question :) I assumed you would have a copy <lfam>Can you at least share the exact error message? <edangor>i did, GRUB said: error: file not found. <alezost>dvc: I installed GuixSD from ArchLinux – it was as simple as "guix system init" (I don't even know what "cow-store" is :-)) <lfam>I assume edangor's font doesn't show the difference :) <alezost>edangor: sorry, but I'm afraid this error message doesn't tell anything useful <lfam>edangor: I assume that your OS configuration specified the wrong device for the bootloader field, or that the partitioning was incorrect. It's very hard to say without seeing the configuration file <lfam>If you can mount the storage of the computer in question from another computer, you should be able to extract the configuration file, assuming you followed the instruction that recommends to copy it to /etc <lfam>If not, I would rewrite the configuration, keep a copy of the file, and try again <sajt_>how could I run the xorg-start-command procedure from the shell? <sajt_>I want to invoke xinit with it <edangor>lfam: ok then i'll text you when i'm done <lfam>AppAraat: I am almost certain that Nix requires a daemon. At least it does in my experience <lfam>It's a core part of the system <efraim>I think we've seen that grub error when the install doesn't complete <lfam>AppAraat: Can you share a link to the Nix document? <AppAraat>it's a "curl | bash" thing but in the script I found no daemon. <lfam>In any case, the daemon is the only process that can write to /gnu/store. It runs as root because you need root privileges for things like chroot, which is used to set up the deterministic build environment <alezost>sajt_: you can't use xorg-start-command in the shell, if you mean you installed X server to your global (system) profile, you can use /run/current-system/profile/bin/X <lfam>AppAraat: That script creates a single-user Nix installation, which apparently does not require root, and I have no idea how that works. We don't really support that use case <alezost>sajt_: oh, wait, X server should be setuid for using with xinit, if you did it then it is placed in /run/setuid-programs/ <lfam>AppAraat: We have diverged enough from Nix at this point that it's hard to keep track of all the differences. I can barely use the NixOS server I run <dvc>alezost: I thought X doesn't have to be run as root anymore? Or is that only when a display-manager runs as root instead? <AppAraat>lfam: ah ok, yeah that install part of Nix was what took my interest initially since I could basically make my own packages without the requirement of having root privs. <sajt_>alezost: yeah, I it's setuid <alezost>dvc: I don't know much about using rootless X server, but I'm sure it is started as root by display-manager <lfam>AppAraat: Once a privileged user has installed Guix and set the daemon to start at boot, users can do unprivileged package management <alezost>dvc: I think there is no way to use rootless X server on gos <lfam>You _can_ use Guix without the daemon, but you should not expect anything to work <dvc>just checked, it requires logind and I don't think our xorg-server is built with elogind <lfam>Using Guix without the daemon will mean that your build environments are unpure, and if a build process even completes, the resulting binaries will almost certainly fail to run due to trying to link against libraries from the host distro and Guix at the same time <sajt_>alezost: xserver is running! except I may be missing some input libs :) <AppAraat>lfam: in the use case of single-user Guix, would it be possible to create a store within a homedir and build all your stuff from source? Because the scenario you've mentioned must talk to the Guix build servers to make sure the hash strings coincide with Guix build environments, right? <alezost>sajt_: you can specify paths to libs in /etc/X11/xorg.conf.d/ <dvc>alezost: is rainin knowledge on to us today :) <sajt_>alezost: thanks, will try that <lfam>I'm interested to know if Nix addresses this issue <lfam>And if so, how! It could be useful for us <lfam>AppAraat: BTW, that Nix single-user installation method you linked to *does* require root <alezost>sajt_: I think the best would be to install required X modules (xf86-input-evdev, xf86-video-XXX, etc.) globally, and to point modulepath to "/run/current-system/profile/lib/xorg/modules" <AppAraat>lfam: ah, right, now I see it too. It invokes sudo. My bad :) <lfam>AppAraat: As for putting the store in your homedir, I would search the archives our mailing lists guix-devel and help-guix. There has been some discussion of unusual setups like that, and you might find something useful <lfam>Potentially also bug-guix, but I'm not sure <dvc>AppAraat: I think you can run guix-daemon without chroot, then you don't need to run guix-daemon as root <lfam>In any case, *once* Guix or Nix is installed, you can do everything unprivileged <lfam>dvc, AppAraat: Yes, but not only is not guaranteed to work, it's almost guaranteed to not work :) <lfam>Many build processes will look for things in /usr <AppAraat>hmm I see. I don't think it'll be a problem for me to install the daemon on my systems (I usually have root there anyway). I'm more interested in making my own definition files from which I can build things from source. In Nix it's called Nix expressions, how is it called in Guix? <lfam>edangor: Okay, that should install GRUB on /dev/sda, assuming it exists. And, it also assumes that there is a disk device whose label is "root". You can set and check those labels with the `e2label` program <lfam>AppAraat: We call them package definitions <lfam>Modifying, creating and installing your packages will be possible without root. <edangor>lfam: i remeber running this command mkfs.ext4 -L root /dev/sda1 <lfam>edangor: Okay that looks correct <lfam>edangor: When the installation completes, it will print a message saying that it completed successfully. Did you see that message? <edangor>lfam: no, because it didn't installed openldap so it wasn't exactly succesfull <lfam>edangor: It sounds like you didn't finish the installation <lfam>So, GRUB was probably not installed at all <edangor>lfam: i installed everything else 'cause i thought i could install openldap later, but grub did installed <lfam>edangor: Well, it really sounds like GRUB was not installed, since you didn't see the completion message, and because the system is not working now <edangor>lfam: so if i re-install the system, how do i make openldap's intallation complete? <lfam>edangor: It depends on why it failed. I am trying to build it now to see if it works <edangor>lfam: it said that some substitutes for the outputs of the derivation failed <sajt_>alezost: I think I'm a bit confused, since I didn't use this package manager before <sajt_>I'm getting the error unsupported manifest format <lfam>edangor: Right, that's what I thought. Whatever operation failed, you should add '--fallback' to that command. The effect of that argument is to build from source if something goes wrong with the substitutes <lfam>I wonder if you became disconnected from the internet <lfam>If you did become disconnected from the internet, --fallback won't help because you won't be able to download the source code to build things yourself <mark_weaver>dvc: I didn't read the whole log, but two things: pass --prefix=<PREFIX> to configure instead of setting the make variable, and to run guix-daemon uninstalled, prefix the command with /home/dvc/guix/pre-inst-env guix-daemon ... <edangor>lfa: no, i din't 'cause re-running the command installed other derivations <lfam>Okay, then --fallback should build openldap for you <dvc>mark_weaver: Thanks :) alezost said the same thing... <lfam>edangor: I would try again, and stay here while you do it so that we can help if you get stuck. <lfam>edangor: The GuixSD installation process is still somewhat brittle. Once GuixSD is installed, it's very solid, since you can always roll back to a previous generation of the system. But, getting that first generation built can be a little annoying the first time, especially if you are new to Guix <lfam>To make the installation more likely to succeed, you can try starting with the 'bare-bones' configuration template. That will need to download and build less, so it will complete more quickly. Once that's installed, you could reconfigure to the desktop system you want. But I understand if that sounds like even more complexity you'd rather avoid right now <edangor>uhm talking about my noobness, what command am i going to do the fallback? <lfam>edangor: `guix system init` <mark_weaver>sajt_: I didn't read the whole log yet, but I also run GuixSD on Libreboot machines. I recommend installing GRUB even though the only part of it that will be used is the grub.cfg <edangor>lfam: ok, it says: error: wrong number of arguments for action 'init' <mark_weaver>sajt_: the default menu item from Libreboot's grub.cfg should load the grub.cfg from Guix on the hard disk, which is probably what you want, because that will allow you to boot into older versions of the system in case the latest version is broken. <lfam>edangor: Please show us the full comand when sharing errors <mark_weaver>sajt_: otherwise, every time you update your system, you'll need to change the libreboot grub.cfg, and that means reflahsing, etc. <edangor>lfam: sorry it's "guix system init --fallback" <lfam>edangor: You have to provide the path to your OS configuration file as an argument <lfam>For example: `guix system init --fallback /tmp/my-config-file <lfam>sneek: The botsnack is moldy <edangor>lfam: i'm a little confused, i ran" guix system init /mnt/etc/config.scm /mnt" should i write the fist path or: /mnt/config.scm <lfam>edangor: You are right, sorry for the bad advice. `guix system init --fallback /mnt/etc/config.scm /mnt` <lfam>When in doubt, follow the manual, not me :) ***kelsoo1 is now known as kelsoo
<snape>is it a requirements for packages to be able to run in a guix environment -C? <sajt_>mark_weaver: thanks, I ended up with installing grub. the newer libreboot releases don't need reflashing btw. you can put a libreboot_grub.cfg in /boot/grub/ and the grub payload picks it up automatically <lfam>snape: Not really, since that command would not provide network access, and some software requires the network <mark_weaver>sajt_: *nod*, I worked with Leah to make that work long ago, and last I checked it will now check for normal grub.cfg in /boot/grub as well <mark_weaver>sajt_: but I haven't updated my Libreboot in a while, maybe it's different now, dunno. <lfam>snape: Ah, in that case, it's not a requirement for graphical applications, since they won't find an X server. Also, there may be elements of the filesystem missing <snape>if you do guix environment -C -N --ad-hoc git <sajt_>mark_weaver: ah, I see. not sure which one is in effect, since you can't really see while booting <snape>then you can't fetch ssh repos <lfam>snape: Well, that's to be expected, since that container won't have SSH <lfam>Try `guix environment -C -N --ad-hoc git ssh` <mark_weaver>sajt_: back when it would only check for libreboot_grub.cfg, I made that a *symlink* to grub.cfg, which worked well <mark_weaver>sajt_: every time you update your system with "guix system reconfigure", it will add new entries to /boot/grub/grub.cfg, so it's important to arrange to use that one without having to manually copy it somewhere else. <lfam>I think that SSH is one of those things that users should install if they want it. Git can be used locally. <sajt_>mark_weaver: did the same thing (the symlink), should have worked in the first place then <snape>so would that be a rule? git can be used without ssh, then ssh should not be an input? <lfam>I don't know git-review, so I don't really have an opinion. In general, I think that user application packages should not come with SSH <lfam>I don't know if it's a rule. But in practice, our Git package does not include an SSH client, AFAICT <lfam>Same with our rsync package <lfam>If you want to use SSH, just install it <lfam>If we change this practice, okay <lfam>But I'm fine with the current state <alezost>sajt_: how did you get that manifest error? I meant you specify 'xf86-...' packages in your system config the same way you did for 'xorg-server' package and then do "guix system reconfigure", after that "/run/current-system/profile/lib/xorg/modules" should contain all installed modules <sajt_>alezost: I'm not sure, must have messed something up. I guess I ran guix package as root, but without doing su - <sajt_>alezost: and instead just su <lfam>Read `man su`. The default invocation of `su` is usually not what you want <alezost>sajt_: when you run "guix package" you install packages in a user (root) profile which is ~/.guix-profile, while if you want to install packages globally, you need to add them to your system config file and run "guix system reconfigure" <sajt_>lfam: I know, it was just a mistake <lfam>Okay, just pointing it out :) I didn't always know that and I thought I was losing my mind until I figured it out <sajt_>lfam: yeah, I figured it out just now as well... at least I don't think it's beyond recovery ;) <dvc>back to school on monday :/ <dvc>is anyone getting paid for working on guix? =P <jmd>dvc: No but I'll send you my bank details and you can send me something. <dvc>I think rekado is getting paid partly... <dvc>and the gsoc guys got paid, just sayin <lfam>Hopefully next year GSoC is not just guys. That would be cool. <jmd>Train a few monkeys you mean. <dvc>don't mind girls - as long as they are as skilled as the competition... <ijp>an infinite number of monkeys in an infinite number of sandboxes installing an infinite number of packages <dvc>Ah jmd, had to check the memberlist to figure out who's behind the nick... <lfam>Anyways, that's *not* what I meant. <lfam>I meant that we should strive to welcome everybody, not just the ~50% of the population that are men. We lose a lot of talent if they think they don't have a place here. <dvc>lfam: no one thinks that <dvc>how is it guys fault if they don't like computers <lfam>Okay, I just wanted to make it clear, since comments about using monkeys in place of men might lead people to think the opposite <dvc>I interpreted that as a joke... <ijp>dvc: you are aware that prior to about 1980, and specific marketing of computers to younger males, computing was very female friendly <dvc>ijp: What are you saying? <ijp>I'm saying that it is certainly guys fault if women "don't like computers" <dvc>ijp: I don't know what the US is like <dvc>but in Europe it's certainly not <jmd>ijp: Yeah and it's womens fault that men don't like embroidery, shopping and Milland Boon novels too. Please be sensible. <lfam>I think women do like computing. But there are certainly areas of software development that seem bent on driving them away. <dvc>lfam: something like that needs an example <dvc>other than citing a crazy feminist who believes everyone is against her <jmd>lfam: I have never seen such areas, and I have never met any women who has claimed that. <ijp>you don't need to find "crazy feminists" to know that CS female paricipation rates are lower than every other STEM subject <ijp>and that unlike the others they haven't been steadily increasing over the past few decades <dvc>the women who screem the loudest about stuff like this are certainly not the ones who actually went through the process of obtaining a CS degree <lfam>So, when I see people make statements about men, I try to make a little friendly reminder about the women who are involved or who may be interested. That's all <dvc>lfam: Are you telling me off? I don't mind anyone who comes as far as this IRC channel man/women/monkey <dvc>I just don't believe that women are that discriminated (in Europe) <lfam>No, I'm not trying to tell you off. It's so hard to communicate tone in writing. <ijp>I'm in Europe (for now), no-one is actually going around saying "thou shalt not compute", that's not what the issue is <lfam>I'm just trying to explain why I made a follow up comment about GSoC with my hopes for the future of the project. <jmd>Of course there is gender discrimination in europe and elsewhere. the most obvious example can be seen in public conveniences. <lfam>And I do think that all projects lose out on talented contributors when, for whatever reason, they are all men, or women, or some other category <ijp>we can argue till we are blue in the face about which reasons matter most, but it is clear that they do not feel welcome, starting before university and carrying on through greater employment <jmd>ijp: Do you have any evidence to back up that claim? <ijp>look at the enrollment figures in cs programs <jmd>That is not prove in any way that they "feel unwelcome". There could be dozens of reasons. <dvc>ijp: I don't think that's fair. Gender equality is all good, but we should accept that there are differences - there is absolutely no judgement in this statement <dvc>girls prefer talking about their feelings than reasoning about code =P <dvc>some opinion in that statement <lfam>That is indeed an opinion <dvc>first is reasonable, second was a joke <dvc>I mean first and second statements <janneke>dvc: you prove ijp's point: that kind of `joke', thinking, talk is exactly what we mean by `women-hostile' environment <lfam>I will say, considering that software engineering is an excellent career in the USA, it's strange that ~50% of our society attempts it at such a low rate <ijp>that went down from 35% to 15% over my lifetime <ijp>I suspect EE may have suffered somethign similar, but it may be harder to tell since AFAIK EE is just lower overall <jmd>lfam: I dispute that it is such an "excellent career". I think - and this is just speculation - women value things other than high salary. <lfam>It's one of the better jobs, when you consider the education, licensing, and time-flexibility requirements <lfam>No degree, no license, no 40 hours, you can still make triple the median income <lfam>You might have to sell your sell to non-free software, but nothing's perfect :) <lfam>Now, I just have to figure out how to do that for myself :) <dvc>janneke: When I made the statement I meant it as a general rule and made no assumption over individual cases. The jobs that are popular among women make such general statements statistically correct. <dvc>The only way to analyse or make statements about such behaviour is through statistics - that doesn't account for individuals. Also statistics don't make assumptions as to motivation - which I did admittedly <lfam>BTW, janneke: what's the status of your mingw patches? Still waiting for review? <janneke>lfam: review is done, waiting to be merged <lfam>Oh, I did not realize that. <jmd>I suggest, that if there are any women on this channel at the moment, we see what they have to say. All others please let this subject drop. <lfam>janneke: I have to say, v10 might be the limit ;) <dvc>jmd: My mother agrees with me - she's pretty succesfull from a salary standpoint - although not in tech <lfam>janneke: I think it might have been forgotten by the people who are really qualified to push the patches. Can you ping them? <lfam>I'd like to get it out of my mailbox ;) <lfam>And I'm simply not qualified to address it <janneke>lfam: i asked civodul if there was anything i could do...he said no it's ready for merge <janneke>lfam: possibly wingo or civodul...but i guess they have quite a backlog <janneke>so not sure now if and who i should ping, see? <lfam>Hm, sounds like you know better than me <lfam>I saw on IRC on August 10, Mark said he would review it <lfam>But, that's earlier than your latest patch series <janneke>ah yes mark_weaver did do the last big review <lfam>There has been a huge amount of things to review lately <dvc>browsing IT jobs... when I read job descriptions I usually think mmh that doesn't sound like fun =P anyone care to share what their dayjob is like? <dvc>I guess work is work...