<davexunit>how does one make a dmd service start/stop gexp that imports modules? <davexunit>I need to use (ice-9 match), so I have something like (begin (use-modules (ice-9 match)) (match ...)) <davexunit>use-modules doesn't complain, but it seems that 'match' isn't treated as syntax. <davexunit>I had to do a gross hack, but I have a working user-file-service that can be used to manage things like SSH keys in home directories ***Guest8918 is now known as Digitteknohippie
***Digitteknohippie is now known as Digit
<fps>hmmm, interesting things happen :) <fps>1] in the old kvm i have running on our root server i get a decent X resolution with -vga=std <fps>2] session is xmonad but when i login i get this weird ancient windowmaker it is i suppose.. <fps>weird. this time around it game me xmonad <fps>pressing f1 to change the session does nothing. <rekado>fps: there's a weird bug when you input the wrong password the first time. You'll always get a windowmaker session then. <fps>rekado: ooh, i think i hit precisely that <fps>since i entered the wrong pw the first time around <fps>i didn't even know i had windowmaker installed :) <Digit>ACTION listens to a benjamin mako hill talk about finding errors, n it almost sounds like he's talking about the reason for something like guix, that encourages users to learn their software <Digit>found it locally on my fsf trisquel card, playing on my netbook that's not currently connected to the net either. ^_^ sry <xd1le>Digit: any chance it's called "Revealing Errors"? <xd1le>if you know the name that is <fps>hmm, guix environment guix still doesn't give me autoreconf <fps>[on guixsd with rather current system] <rekado>fps: works for me. It adds autoconf-wrapper's bin output to the PATH. <civodul>fps: what does "guix package -A guix" return? <fps>civodul: hold on. gotta ssh into my irc box :) <fps>fps@raksha ~/guix$ guix package -A guix <fps>guix 0.9.0 out gnu/packages/package-management.scm:64:2 <fps>i had the same issue yesterday and thought a guix pull might fix it.. <fps>for completeness' sake and since traffic is low; <fps>fps@raksha ~/guix$ guix environment guix <fps>fps@raksha ~/guix [env]$ ./bootstrap <fps>+ exec autoreconf -vfi <fps>./bootstrap: line 5: exec: autoreconf: not found <civodul>fps: "guix package -A guix" should show a second guix <civodul>guix 0.9.0.43c082b out gnu/packages/package-management.scm:199:4 <civodul>guix 0.9.0 out gnu/packages/package-management.scm:64:2 <fps>1fps@raksha ~/guix$ guix --version <fps>guix (GNU Guix) 0.9.0 <fps>12:39 < fps> fps@raksha ~/guix$ guix package -A guix │········································· <fps>12:39 < fps> guix 0.9.0 out gnu/packages/package-management.scm:64:2 │········································· <fps>or maybe i miss something? <civodul>so it returns only one guix package? <fps>fps@raksha ~/guix$ guix package -A guix <fps>guix 0.9.0 out gnu/packages/package-management.scm:64:2 <fps>also emacs doesn't have guix-edit.. something's fishy.. <fps>i don't rule out having the system messed up bady <civodul>so you need to run "guix pull" for that account <civodul>this account is stuck at 0.9.0 currently <civodul>and 0.9.0 doesn't need autoconf etc. to build <fps>oh, do i have guix in my profile, too? let's check <fps>fps@raksha ~/guix$ which guix <civodul>it's not a good idea to install Guix in your user profile <fps>/run/current-system/profile/bin/guix <fps>hmm, i guix pulled a few times and reconfigured, too <fps>will report back in a couple of hours ;) <fps>civodul: but just to clarify: the guix i use is the system one, not in my user account's default profile.. <fps>if i read that right? <fps>so, sudo guix pull and then a reconfigure should fix it? <civodul>'sudo guix pull' updates your user's guix, not root's one <fps>um, since my user doesn't have guix installed in the profile, what is it updating? :) <fps>the one in the directory i'm in? <fps>[which is a git clone] <fps>hmm, files owned by fps:users.. consider /me confused <civodul>actually no, "sudo guix pull" updates root's thing, forget it <civodul>fps: 'guix pull' just populates ~/.config/guix/latest <civodul>and this thing takes precedence over anything else <civodul>so even if guix is not in your profile, guix pull gives you the latest guix <fps>fps@raksha ~/guix$ ls `which guix` -l <fps>lrwxrwxrwx 2 root guixbuild 71 Jan 1 1970 /run/current-system/profile/bin/guix -> /gnu/store/1hzscsj8bxsvahm1n4fvbh03dw4dpkcj-guix-0.9.0.43c082b/bin/guix <fps>fps@raksha ~/guix$ find ~/.config <fps>/home/alice/.config/gtk-2.0 <fps>/home/alice/.config/gtk-2.0/gtkfilechooser.ini <fps>ah ok, /root/ has .config/guix-latest <fps>oops, i mean .config/guix/latest <fps>civodul: sooo, what is the fool proof way of updating the system's guix version? <civodul>but for your initial question about 'guix environment guix', you prolly want 'guix pull' as your user <fps>civodul: ok, i totally don't get why, but i'll do so :) <fps>ok, after this round of sudo guix pull, reconfiguring, etc, there was no guix pull necessary as user. environment now works as expected ***exio is now known as E4xoi
<civodul>mark_weaver: i'd like to get tk-update built, wdyt? <civodul>there's 116 arm builds queued currently <sneek>mark_weaver, you have 1 message. <sneek>mark_weaver, paroneayea says: how do we distinguinsh between ports that work with (select) and those that don't? Is there a way to add new port types that fit with (select) if useful? <rekado>one ruby gem I want to package uses "git ls-files" in the Rakefile to generate the gemspec. <rekado>so I thought I could just read the existing gemspec, copy the file list and paste it into the Rakefile. <rekado>however, the gemspec file contains #\\nul and Guile's regexp-exec complains about this. <rekado>Is there a way to tell Guile to ignore the #\\nul in the read string and move on? <rekado>(or should I not do this and just use the existing gemspec?) <civodul>you could hack around it by replacing nuls in the string, maybe <rekado>I tried that with (regexp-substitute/global #f "#\\nul" contents ""), but that's the same problem, of course. <civodul>yeah, you'd need to use string-map or similar <civodul>why does it contain nuls in the first place? :-) <civodul>isn't it supposed to be a text file? <rekado>it is. But it happens to contain nuls in a comment. <fps>hmm, ok, i hacked a little in doc/guix.texi. i wonder how to view the compiled output file <fps>./pre-inst-env info guix seems to give me the old one <fps>info -d doc/ info guix <fps>seems to do the trick <mark_weaver>and it will ask for a filename of an *.info file to open <fps>mark_weaver: oh, cool. thanks <fps>first attempt at hinting the reader to specification->package <fps>make seems to modify files in the guix git clone <fps>namely the .po files.. <fps>is it supposed to be that way? <mark_weaver>be careful to avoid including those changes in your commits. <mark_weaver>I guess that civodul periodically takes care of that. <sebboh>So, all the binaries live in weird places. Uh <sebboh>visudo failed, looking for /usr/bin/vi <rekado>sebboh: visudo probably won't work anyway. <rekado>I think it's better to specify a sudoers file in the config.scm and reconfigure the system. <rekado>Hmm. Since a couple of days I'm no longer able to abort "guix build" with C-c C-c in Emacs shell-mode. I have to use send a signal to the process with kill or M-x proced instead. Does anyone else have this problem? <rekado>(could be my Emacs config doing weird things, of course) <sebboh>oh? ... why is /etc/sudoers readonly? .. ok. fine. Ok, next question, I want a guile repl so I can see the value of these %some-default-stuff variables that are used in config.scm.. Where do I get that? <sebboh>rekado: you could do a find / in shell-mode and then try to C-c C-c out of it. For testing. <rekado>sebboh: /etc is populated from the store on boot. Changing it in the running system won't persist across reboots. <rekado>yep, C-c C-c is indeed broken in my shell-mode, independent of guix build. <rekado>must get all my emacs packages guixified. <sebboh>I'd like to see the value of %base-user-accounts, a variable in use in config.scm. I imagine it is a list like '((user-account ...) (user-account ...) ...). Where's a repl? <fps>here's what i thought might work: ls -l `which guix` to find the place of guix in the store <fps>then GUILE_LOAD_PATH=/gnu/store/...../share/guile/site/2.0 guile <rekado>sebboh: %base-user-accounts is defined in gnu/system/shadow.scm <fps>then (use-modules (gnu system)) <fps>but the file system.scm lives in the store and has the value of the %base-packages <rekado>fps: does (use-modules (gnu)) work? <fps>but (gnu packages) does for example <fps>scheme@(guile-user)> (use-modules (gnu)) <fps>While compiling expression: <fps>ERROR: Throw to key `srfi-34' with args `(#<condition &message [message: "ath9k-htc-firmware-binutils.patch: patch not found"] 3466fe0>)'. <rekado>fps: I think you'd have to define the patch path first. <rekado>I had a similar problem, but I don't remember how I fixed it... <rekado>fps: I think I remember now. What's the value of %patch-path and what is the value of %load-path? <rekado>and what is %distro-root-directory? <sebboh>ACTION grumbles about installing a system-wide emacs just to get this thing usable <fps>%patch-path is unbound. but maybe that way is wrong to start with <fps>ACTION must resist expressing his opinion about emacs <rekado>fps: have you loaded (gnu packages)? <sebboh>rekado: because I have no idea what I'm doing and every reference to a guix repl I've seen online seems to be happening in emacs. <fps>rekado: i just tried first loading (gnu packages) and then (gnu). same error.. there must be some magic i'm missing :) <rekado>fps: as someone who used vim for many years before coming to Emacs I must say that Emacs is really great once you get it. It's not a mere editor. <fps>i will not discuss emacs :) <rekado>fps: well %patch-path is defined in gnu/packages.scm. Something's wrong when it's undefined. <fps>rekado: yeah, i'll look around a bit.. too bad, i thought i had found an emacs-agnostic way for sebboh :) <rekado>sebboh: are you using Guix on top of another GNU system or are you using GuixSD? <rekado>you don't need to use Emacs to use Guile's REPL. <sebboh>I guess I haven't asked the right question... :) <fps>a guix REPL is just a guile REPL <fps>if i understand correctly.. <sebboh>anyway, I don't mind installing emacs! it's just that on most systems, I finish setting up my user account first. ;) <sebboh>fps, well presumably it is a guile repl in which some guixy stuff has been loaded into the environment... <sebboh>there is a background process that you connect ot. <sebboh>"accepted connection from pid 259, user root (trusted)" <bavier>sebboh: if you run `guile', then '(use-modules (gnu system))'? <rekado>that's the thing that creates the build environment and switches to a build user. <rekado>it doesn't offer a REPL or anything. <fps>bavier: without setting GUILE_LOAD_PATH manually that even seems to work <sebboh>bavier, ok. rekado, that sounds good! Next question, Can I safely do that while a guix install is in process? <rekado>most of the "guix" commands talk to the guix-daemon on your behalf. <bavier>fps: yes, on GuixSD the guix module dir is already in GUILE_LOAD_PATH <rekado>"do that" = start guile and load modules? Sure. <fps>bavier: great.. then evaluating %base-packages tells you what you want sebboh <fps>sebboh: i'd presume so <rekado>or rather: %base-user-accounts (that was the question above) <fps>oh, %base-user-accounts is still unbound.. hmm <sebboh>This must be what people feel like. <fps>i suppose the real fix would be to incude those default values in the documentation? <fps>maybe it is already? <sebboh>well... something could modify them. Checking them at runtime is a fine idea, in my opinion. Either way, <rekado>How would something like %base-user-accounts be modified at runtime? <rekado>the value exists only at system configuration time. <rekado>once a system has been reconfigured the definition of the value no longer matters. <sebboh>it's a global variable? My config.scm could set it to null in the first line... <sebboh>these aren't exactly config files... they are code. <sebboh>sorry, s/null/'()/ or F or whatever they do in guile land. :) <fps>but then starting a new REPL and loading the modules and inspecting the values there won't give you any hint about possible modifications done when reconfiguring the system. you'd have to evaluate your system config in that new REPL <sebboh>There. That's it. That's what I want. <sebboh>A repl which is connected to the environment that config.scm would be evaluated in. <sebboh>(btw %base-user-accounts will be populated in such an environment.) <fps>hmm, you're asking good questions :) sadly i'm a noob, too.. but i'd suppose there's a way to evaluate your config scheme file from withing that new REPL <sebboh>oh I wonder if I can just (break) in config.scm itself. <fps>that might be the most simple thing in the end :) <bavier>sebboh: (load "/path/to/my/config.scm") <rekado>(define c (load "/etc/config.scm")) <fps>"break" is a REPL command :) <rgrau>Hi guixers, I'm manually compiling openresty, and on the ./configure phase, I get: "ld-wrapper: error: attempt to use impure library "/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so" which is added by guix's ld-wrapper, but is kina cryptic to me. :/ Any tips or pointers? <mark_weaver>to run a guile REPL with access to all the guix things, you need to first add "$HOME/.config/guix/latest:/gnu/store/...-guix-.../share/guile/site/2.0" to the front of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. <mark_weaver>rgrau: when compiling software, you must ensure that either you are using ONLY toolchain/libraries from your host OS, or ONLY toolchain/libraries from Guix. You cannot mix them. <mark_weaver>in this case, they are getting mixed. you seem to be using the toolchain from Guix and maybe also some libraries from Guix, but also some things from your host OS. <mark_weaver>hmm, or maybe you're somehow using gcc from your host OS and ld from guix. <rgrau>aha. makes sense. I'll try to compile it for me using host OS toolchain (need to get it working) and then maybe try it guix-style and package it (if lucky) <paroneayea><rekado> dear Guilers, for FOSDEM 2016 we currently only have four talks for the Guile devroom. <sebboh>I don't seem to have a /gnu/system directory. Earlier, someone mentioned that some files live in there. ...What is going on? <mark_weaver>sebboh: gnu/system/* was mentioned, without a leading slash, and that's within the Guix source code. <mark_weaver><rekado> sebboh: %base-user-accounts is defined in gnu/system/shadow.scm <mark_weaver>while hydra-evaluator is adding jobs to the postgresql database on hydra, all other attempts to perform postgresql transactions are prone to starvation. e.g. I asked to restart a job via the web interface, and it's been spinning for 15 minutes. <mark_weaver>but the hydra-evaluator is making progress on adding jobs at a reasonable rate <civodul>well, having something do i/o on this machine is already crazy <sebboh>oh, fine. A relatively well known noun. ***davi_ is now known as Guest70988
<fps>hmm, i have a package here that just uses plain gnu make and uses the variable $(CC) which per default is cc <fps>which is not in PATH <fps>i'm using the gnu build-system and wonder with a deleted configure phase <fps>i'm using the gnu build-system with a deleted configure phase <fps>and wonder if i can just set $CC to gcc in the gnu build system <bavier>fps: you can probably use #:make-flags '("CC=gcc") <sebboh>The docs for 'password' in 'user-account' say that I should put an encrypted string in there. But for the root account (gnu/system.scm) the string is "" and I log in without a password. What's up with that? <fps>bavier: oh, ok right, there's #:make-flags. thanks :) <sebboh>For context of my question, I intend to disable password-based login for the root account. I like the "sudo only" paradigm of ubuntu/debian land. <sebboh>I believe setting the password hash for the root account to "*" or "bananas" will acheive this. <sebboh>(assuming I also configure a proper user account in the wheel group or whatnot.) <sebboh>oh, I've just read that maybe "" is different than "*"... <civodul>sebboh: above all, the docs say you should put nothing in the 'password' field :-) <sebboh>you folks know what "apt-file" does? It contains an index of installed files for all packages. it allows me to figure out which package provides some file like /usr/bin/some_utility. Is there something like that for guix? <sebboh>"Passwords set with passwd are of course preserved across reboot and reconfiguration." oh. Fine. <sebboh>was passwd modified to acheive that? <sebboh>guix pull seems to pull down packages over http. Probably there are sigs at the package level, eh? Still, using TLS would prevent an observer from telling what packages I choose to install. <civodul>sebboh: 'guix pull' downloads the package recipes, not the packages themselves, but yeah it's a bit sloppy currently <sebboh>does guix identify my CPU and such and tell gcc et al about it so those tools can ... take advantage of cpu instructions I have? Sorry if this question isn't well formed, I have been using binary distros for a while.. :) <civodul>no it doesn't, because that would prefer redistribution of binaries <civodul>sebboh: re apt-file, there's nothing like this, n <sebboh>Prefer redistribution of binaries? I don't understand. Maybe I misunderstand. Let's say my CPU has SSE2 and yours does not. If I compile locally and use locally... I might as well employ those instructions. But my bins aren't useful to you... My understanding was that a distro (let's say debian) simply configures their compilers to include only the least-common-denominator of instructions. Did I get this wrong? <fps>emacs doesn't like me <fps>and i don't like emacs :) <bavier>sebboh: using the lowest-common-denominator is effectively what we do at the moment <bavier>I believe civodul meant "preclude" <sebboh>ok, that edit resolves my question. Yes. :) <fps>interesting question though :) <sebboh>oh this vm is configured for one core. gah! That explains a lot. <bavier>sebboh: incidentally, SSE2 is the lcd that we target for x86_64 <fps>[the one about using finer grained architecture information in the binary substitutions] <fps>why do these interesting questions always come up when i should sleep for half an hour already or so? <sebboh>no man halt, no info halt, halt --help suggests I use arguments but doesn't specify them. ... halt without args works. <sebboh>fps, channel is logged! Perhaps interesting questions come up while you sleep, too. <fps>soooo, how exactly does the lookup for the availability of a substitute work? 3.3 is a little light on the details <fps>*section 3.3. Substitutes <fps>civodul: there has to be a mapping from a package definition to a substitution archive, right? <fps>e.g. hash of guix source tree plus package name -> some path to retrieve the archive from the substitute server <fps>or something like that? <civodul>fps: there's a mapping from package recipe to /gnu/store file name <civodul>and then the daemon just asks the substitutes servers for those store file names <fps>civodul: oh, allright. and the recipe is more than the package object? <fps>soo, if two guix versions contain the same recipe (which i suppose transitively incorporates the whole dependency graph) it still maps to the same store path? <fps>soo, thinking this one step further, if somewhere in this graph there would be a point for a user to "inject" extra compiler flags to make use of particular architecture features [i.e. a recipe itself] <fps>then there's in principle no obstacle to prividing finer grained substitutes than the four major architectures <sebboh>I don't suppose there is some sort of 'short' reconfigure. ...it takes a really long time to alter a single line in a single file in /etc... <fps>this gets interesting only with a more powerful build server or a distributed build server/CAS where users provide their binaries.. <fps>content addressable storage.. <bavier>fps: the daemon has support for multiple substitute urls <rekado>fps: you are not limited to fetching substitutes from hydra. <bavier>so anyone could serve those substitutes <rekado>with guix publish you can serve substitutes that you have built. <fps>bavier: yeah, i envision it to happen automagically though.. i need a particular build and it doesn't exist. once i have built it my binaries would be pushed to the DDS/CAS/DHT <mark_weaver><bavier> sebboh: incidentally, SSE2 is the lcd that we target for x86_64 <fps>and the next user needing it would be lucky <mark_weaver>x86_64 includes SSE2 as part of the base architecture. <mark_weaver>i.e. there does not exist any x86_64 processor without SSE2 <rekado>fps: eventually we should be able to share builds over GNUnet. <fps>rekado: yeah, i know :) <fps>this will enable many good things.. <sebboh>mark_weaver: ok, neat. Sorry, showing my age. The last time I actually studied a CPU before buying one was PII. <fps>rekado: and that's exactly what i'm getting at.. <sebboh>Ever since then, they've all just been "faster than me". <fps>think gentoo's USE_FLAGS combined with guix's substitutes and magic happening if you happen to share USE_FLAGS with many other users.. <fps>if i were the guix core team i wouldn't collect money to get another hydra server up <fps>i'd pay someone to make the magic happen instead ;) <sebboh>fps, well hydra-like servers will still have users... My employer's firewall lets me talk to any http server, but no peer to peer networks. <fps>sebboh: oh ok. well, one can gateway services like morphis. i once nginx'ed the morphis network.. <sebboh>Oh, sorry, I meant any http server that doesn't have an IP that matches some "is this russian??" function. *sigh* <fps>ipfs has the same feature.. <sebboh>fps, yeah but at that point I'd just use hydra. ;) If it's up! "unexpected end of file" message needs some work, by the way. Probably catch this in http.scm..? Or handle. Whatever guile calls it. <sebboh>yeah I need a fast-reconfigure. I shouldn't have to talk to an external resource to change a file in /etc. ...I mean, what if my network is down and changing /etc is the solution?? <fps>oh, there actually is some useful gnunet docs it seems. it just hides in the "developer manual" section ;) <sebboh>yep, was just suspecting that! Thank you mark. <fps>sebboh: a distributed data store