***mampir_ is now known as mampir
***Afterlith[m] is now known as SovereignBleak
***SovereignBleak is now known as Afterlith[m]1
***Afterlith[m]1 is now known as Afterlith[m]2
***Afterlith[m]2 is now known as Afterlith
<adamvy>I'm running GuixSD, and I've made some changes to my git clone of guix. What's the right way to install my modified guix as the system one? <adamvy>the README suggest its just make install ? but I'm not sure I believe that ***Afterlith is now known as Sovereign_Bleak
<ryanwatkins>Hey guys, has anybody managed to automount some given storage from a GuixSD machine via SSHFS? <ryanwatkins>For some reason mine seems to be having problems, even when I do ssh-copy-id remote, it still requires password? <lfam>Use the 'pre-inst-env' script to use the Guix you built <lfam>You don't need to run the guix-daemon in that way unless you made changes related to it <reepca>Hm, reset-timestamps in (gnu build install) emits a "clearing file timestamps" for each thing... do we want that for every invocation of register-path? <Guest91985>Hmm, as of a recent `system reconfigure`, I just get a blank background when I log into Gnome. <Guest91985>What's the best way to troubleshoot Gnome? Where would it's logs go to? <Guest91985>I saw a message on virtual terminal like `[1443.875886] .gnome-session-[1640]: segfault at 0 ip 0000f7... sp 000... error 4 in libgtk-3.so.0.220.15[7fa0...]` <Guest91985>Also getting a 404 on livemedia-utils source, live.2017.05.24.tar.gz, when running `guix package --upgrade` ***Guest91985 is now known as sturm
***andreh1 is now known as andreh
<reepca>wow, the default font for emacs on guixsd (at least on my system) has the exact same appearance for 1 (one) and l (L). <reepca>That's strange. Think the window manager has anything to do with it? <reepca>according to M-x describe-font I'm using "Nimbus Mono L" or something like that... <efraim>Glib is failing on my odroid but built no problem on my firefly <Apteryx>Hello Guix! I'm about to select whether my next ISP will be ADSL or cable. Both would be 15 Mbps downstream, 10 Mbps upstream. With ADSL I have the option to have a static IP address (for 4$ extra/month). What would you recommend between the two for a DIY hosting solution? <Apteryx>On paper it seems like ADSL would be nicer since I might get a use for a static IP address; but I'm a bit worried that real performance might drift from those advertise numbers, especially in the case of ADSL upload sppeds. <Apteryx>(sorry for the rather off-topic question; I hope to be hosting some Guix related stuff eventually :) <reepca>For a class my brother and I had to set up a server and went with a DIY solution at home. I've still got the DNS server running on the same server it resolves to - the ip address hasn't changed in the 6 months since we set it up, and we didn't get a special static address or anything. <Apteryx>reepca: Oh! That's good to know. I guess I could do without. <reepca>ACTION frantically searches wikipedia in an attempt to soudn up-to-speed <reepca>It's a bunch of wires twisted together and taped over with electrical tape ever since the lawnmower ran it over, not sure what the connection technically is. Wireless thingy out in the country. <Apteryx>reepca: that would match the typical phone line (copper) ;) <Apteryx>Might go with cable again. In the case of a server upload is what you want. ADSL is typically skewed heavily for download. Good for consumers, not so for servers. <bytes83>i am trying to set up a dual boot with Arch + guixSd in Uefi mode. However i can not seem to get the config right so either the grub doesnt list my arch installation or it doesnt list guixSd <bytes83>is there anything *special* that I should be doing ? <quigonjinn>how can one force a package source to be redownloaded, even if it already resides in the store? <efraim>guix build foo -S --check --no-substitutes <rekado>quigonjinn: do you need this because you fear the sources may be corrupt? <quigonjinn>rekado: I modified the source uri for a program i'm packaging, and I wanted to check whether the new uri works <rekado>quigonjinn: I think you can use “guix download” for that <efraim>rekado: that wouldn't check the logic from the package <rekado>no, but if the thing has the same hash it wouldn’t matter <Laki>hello, I've been having troubles with the latest version(s) of elogind and I'd like to make sure I'm not doing something wrong before I'd file a bug... basically the issue is, I'm running a Manjaro install with iwlwifi as my wifi driver, and since version 228.3-1 of the elogind package I get permanent disconnects for the wifi since I suspend <Laki>when I start up the system the wifi works fine, then I suspend, resume and I can't connect to wifi and the wifi led is permanently "off", no matter whether I toggle it or not <Laki>I downgraded to 227.2-1 and it doesn't have this problem, after suspend wifi is fine <jsierles>how are guix modules versioned beyond the version number of the module? for example if a module is changed without changing the version number. is it just the guix git repo hash? <jsierles>i've got a strange error untarring the 0.13.0 release on my macbook "tar: ./gnu/store/h7mx27bl0wynlz8vjszzykqqldccfwm5-ncurses-6.0/share/terminfo/a/a210: Cannot open: Permission denied" <roelj>If I install a guile package, and afterwards run 'guix package --search-paths', it doesn't include the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables. So, normally, you'd install guile into the profile, and then it works as expected. But, I have a guile package that adds a subcommand to Guix. So, the dependency on guile is already resolved by the guix command. How can I make this work? <bavier`>roelj: guile still needs to be installed in the profile <bavier`>otherwise guix doesn't consult it's native-search-path, afaik <jsierles>what are all the files for inside the per-user profiles? <roelj>jsierles: which files do you mean? The symlinks? <jsierles>roelj: i mean the profile itself. it has etc/, lib/, etc. <jsierles>is this literally where all a user's packages are installed when using 'guix package'? <jsierles>just trying to work out whether i need to worry about this profile if i'm only using 'guix pack' at the moment. <jsierles>i'm also seeing that 'guix pack' tries to change ownership of /gnu/store. any way around that? <jsierles>i'm mounting the store into a docker container, so the mount point's owner can't change <roelj>jsierles: Inside a profile are a lot of symlinks pointing to the store, which makes up a UNIX-like filesystem envrionment (bin/, lib/ and the like) for which you can then set the PATH and LIBRARY_PATH environment variables. <roelj>So for example, when you install grep into a profile, a symlink for grep will be added to that profile directory. <jsierles>OK, i see that now looking around in there. <roelj>For 'guix pack', it creates a profile for whatever you are packing. <jsierles>ok. makes a profile based on my current profile right? <roelj>No, based on the packages you provide with the pack command <roelj>so 'guix pack grep' will pack grep and all of its dependencies for you, but not anything in your user profile. <jsierles>guess the only snag i have now is the ownership of the store. <roelj>Yes, so, when packages are being built, they are owned by the build user (guix uses separate users to build things, because users can be isolated nicely in Linux) <jsierles>yeah, that makes sense. but i don't see why the store itself would need its ownership changed <roelj>When the package has been built, the ownership is transfered from the build user to root. <jsierles>i've seen some people are mounting the store over NFS. but guessing there they already have the users synced up across the hosts. <roelj>So, I guess that's what you mean by changing ownership of the store. <roelj>jsierles: On our cluster, we centralized user management indeed. <jsierles>well, 'guix pack' appears to want to change the owner of this path: /gnu/store <jsierles>guix pack: error: build failed: changing ownership of path '/gnu/store': Operation not permitted <jsierles>i'm running on coreos, where everything runs in docker. so this shared volume would be mounted into docker with root ownership <roelj>Is that upon building a pack, or extracting a pack? <jsierles>maybe setting build user group to root would work <roelj>I don't think that's a good idea <jsierles>the user/group is irrelevant here. these are not machines people will log into <roelj>Oh I see.. It changes the ownership of everything in the pack to root:root. <jsierles>my use case for guix is strictly about running the daemon that will accept remote builds using 'guix pack'. <jsierles>i thought the guix-daemon was responsible for writing to /gnu/store, and that it would be OK to mount read-only <roelj>jsierles: Maybe you can look into the 'guixr' wrapper that can connect to a remote daemon <jsierles>so the guix command line doesn't connect to a remote daemon already? <roelj>You'd also need a listener (Here's a one-liner command: socat -d -d -d -d TCP4-LISTEN:9999,su=nobody,fork,range=10.100.7.235/32,reuseaddr UNIX:/gnu/daemon-socket/socket) <roelj>jsierles: Only over a UNIX domain socket <roelj>jsierles: This wrapper turns that UNIX domain socket into a TCP socket <jsierles>ah ok. i thought it was already possible to use a TCP socket or SSH <roelj>I might have missed something :) <jsierles>guix://master.guix.example.org:1234 - from the docs <jsierles>The ability to connect to remote build daemons is considered experimental as of 0.13.0.314-a8d0c <dTal>Hm, so I installed IceCat but it's not showing up in GNOME <roelj>dTal: Have you tried Alt+F2 r <enter>? <roelj>(this restarts the gnome-shell) <dTal>But surely this is a bug. <jsierles>is there a guide somewhere for installing guix from git? <davexunit>if it is a bug, it's a bug in GNOME, not Guix. <roelj>davexunit: Well, this automagically shows up when you install something in Fedora.. <davexunit>in guix, you are installing to a profile that may or may not be on $PATH, and you may or may not be using GNOME. <dTal>I have never used an OS that behaved that way. Even Windows 95 didn't require restarting the shell to make menu items show up. <roelj>Yes, that's right. But when you install IceCat in your profile, and you are logged in as the same user in gnome, then it should be able to detect that.. <davexunit>at least, that's not the responsibility of Guix. <roelj>Oh.. gnome-shell is not in your user profile, so that changes things <davexunit>it's the responsibility of GNOME to poll the directories in XDG_APP_DIRS or whatever that env var is called <dTal>It works in Debian. If Guix's approach causes a feture regression, then I would say its the responsibility of Guix <dTal>so this is intended behviour? if you *could* "fix" it you wouldn't? <dTal>You keep saying that I'm missing context, that I'm misunderstanding, that I'm confused... pray explain? <davexunit>what I'm saying is that it's not as simple of a thing that you are claiming. <davexunit>first of all, why does it work in debian? we need to know that before a solution can be found. <rekado>I don’t think it makes much sense to discuss where the bug is before we have investigated this. <rekado>dTal: could you please send an email to bug-guix@gnu.org? <davexunit>what I'm trying to stop is people blaming Guix for stuff. <rekado>dTal: someone could then take a closer look <dTal>rekado: according to davexunit it's not a bug, so I don't think that would be appropriate <rekado>dTal: if it turns out not to be a bug we can close it :) <rekado>Guix does things differently, so it could be that it’s a missing feature in GNOME that is not necessary on most systems, but that is exposed by Guix. <rekado>I guess we won’t know without someone taking a closer look <davexunit>I would expect that gnome-shell would poll periodically for changes to the .desktop files in XDG_APP_DIRS <davexunit>and maybe that feature isn't working in our build. <dTal>I don't understand how it works on stateful systems but I believe apt at least runs some post-install scripts that update menus and icons etc <rekado>i.e. after installing something into a profile we generate files based on the contents of the profile <dTal>I don't know enough about guix's model yet, that's why I'm installing it to play with <rekado>we do this for ibus, for example. <rekado>the key is that none of these things change global state <dTal>before I submit any bug reports though I'll see if the behaviour is consistent with all graphical programs <rekado>dTal: that’s appreciated. Thank you. <davexunit>it's been this way for as long as I can remember. <dTal>aw, roelj left, wanted to thank for solving my immediate problem of "not being able to launch IceCat" <rekado>we have a little bot here that can do this for you. Say hi to sneek <rekado>e.g. sneek: later tell roelj Hi roelj! <dTal>sneek: later tell roelj thanks for the shortcut to restart GNOME <sneek>dTal, davexunit says: hello! <jsierles>rekado: hey again. what would be the right way to check out the latest guix so I can run guix-daemon with remote job support? <rekado>jsierles: did you install via the binary installation method? <rekado>jsierles: in that case you could update the “guix” package in the root user’s profile, I guess. <jsierles>rekado: yes. actually what i did was extract the tarball, and mounted /gnu and /var/gnu into a docker container where guix-daemon runs. <jsierles>inside that container, guix pack throws a permissions error mentioned above. <jsierles>but i thought maybe submitting a remote job would work around that <jsierles>i see the root profile points to /gnu/store though. which i thought I wasn't support to modify. <rekado>all profiles end up in /gnu/store <rekado>you only ask guix to build a new generation <rekado>that, too, would end up in the store <rekado>only the link to the current profile will be updated. <jsierles>ok so i need to use 'guix build' with the --with-source option? <jsierles>sorry, i don't understand what you mean by 'build a new generation' of the guix package from git. <rekado>no, build a new generation of the profile <rekado>that’s what happens whenever you “modify” a profile <rekado>guix will just create a new generation (and keep the old one untouched) <rekado>any time you do “guix package -i” or “guix package -r” you just get a new generation <rekado>the binary installation method gives the root user a profile with guix pre-installed. <rekado>you’d have to just “guix package -u” as root <jsierles>running guix package -u will update from git? <rekado>it will just update to the latest version that’s defined in your version of guix <rekado>“guix pull” gets you the latest version of guix (whatever is in the master branch) <jsierles>ok, sorry for not being clear. i want to know how to install the latest guix from git so I can run 'guix-daemon' that will accept remote connections. <rekado>that change to guix-daemon was part of the 0.13.0 release, was it not? <jsierles>i saw 0.13.0.314-a8d0c. i thought that meant after 0.13 <jsierles>regardless - all the guix commands i'm running report an error: changing ownership of path '/gnu/store': Operation not permitted <rekado>and what are the permissions on it? <jsierles>how can i run the daemon so it accepts connections on a TCP socket? <dTal>Okay so say I have a sha256 hash in base16 format - can I use it directly in a package definition? <dTal>I tried it, but neither putting it in directly (result: "expecting bytevector") or extrapolating from the manual with a (base16 ...) form work <dTal>In particular, putting it in "naked" and getting the "expecting bytevector" error reveals that the exception is thrown in procedure bytevector->base16-string, which seems to imply that base16 is the canonical form anyway <bavier`>dTal: what didn't work about using (sha256 (base16 "..."))? <dTal>"Unbound variable: base16" <bavier`>dTal can you not get a base32 representation? <dTal>I could, probably - I could even write a function in scheme to do it for me - but upstream publishes the hashes in base16, like everyone else on the planet; there must be a clean way of doing this. <dTal>While I'm at it, is there a reference for what functions can be found in the guix module namespace? Currently I'm left guessing from examples <dTal>like, for instance, "guix hash" - what's in it? <bavier`>dTal: 'guix hash' is a program you can run that prints out the base32 of a tarball or directory <dTal>or did you mean the command line tool, not the scheme namespace (guix hash) <dTal>right right, and if I felt like downloading a tarball twice I might do that, but is base16 seriously not supported? <bavier`>dTal: you could use (guix base16) and (guix base32) to verify that its output matches the published base16 <dTal>what's the function of the (base32 ...) form anyway? what else can go in that spot? <bavier`>dTal: just a string or something that evaluates to a string <bavier`>its syntax that's defined in (guix packages) <dTal>I put a string in, it said it wanted a bytevector <dTal>which is fair enough, and I understand that somewhere there's a base16-string->bytevector function, but I don't know where <dTal>so where do I go in future for that info? <bavier`>dTal: if you have the tarball already, you don't need to download it again for 'guix hash'; it'll happily hash a local file <dTal>other way around, if I download it to hash won't it redownload it again I want to actually install it? <bavier`>dTal: geiser can help, but honestly I most often just browse the '#:export' lines of the modules <dTal>there's a bytevector-base16-string but that's in (guix utils)? honestly I'm just grubbing around google at this point <bavier`>dTal: no, 'guix hash' puts a copy in the store, so it will be there next time it's needed <dTal>ah, that answers my question about what "guix hash" does that sha256sum doesn't <dTal>where are the modules stored? <dTal>I considered doing that but I couldn't find the actual scheme files <bavier`>dTal: do you have a ~/.config/guix/latest? <bavier`>dTal: you have a git checkout of guix? <dTal>not as far as I'm aware, I just follwed the installation instructions from the manual <bavier`>you can install guix to your user profile, and the modules will be available in ~/.guix-profile/share/guile/2.2 (or something like that) <dTal>I would suggest, by the way, that (base16 ..) be made an alias to (base16-string->bytevector ..) for an easy usability win <bavier`>dTal: it's not needed often, but you could make a case for it on the mailing list <dTal>thanks for all your help bavier` <jsierles>those aren't supported on my FUSE volume. does it use hard links for anything besides deduplication? <cbaines>jsierles, the only use of hard links I know of is in the store daemon, and yes, it uses hard links <jsierles>ok thanks. i started the daemon with '--disable-deduplication' which helps <cbaines>that looks to be an issues with fetching substitutes, do you get the same error when you run the command again? <jsierles>i already have an ncurses directory with that name <jsierles>so maybe it's an issue turning off deduplication <cbaines>If it is, its a bug, either in the store service, or in Guix <Laki>hello, I've been having troubles with the latest version(s) of elogind and I'd like to make sure I'm not doing something wrong before I'd file a bug... basically the issue is, I'm running a Manjaro install with iwlwifi as my wifi driver, and since version 228.3-1 of the elogind package I get permanent disconnects for the wifi since I suspend <Laki>when I start up the system the wifi works fine, then I suspend, resume and I can't connect to wifi and the wifi led is permanently "off", no matter whether I toggle it or not <Laki>I downgraded to 227.2-1 and it doesn't have this problem, after suspend wifi is fine ***luto__ is now known as luto
<reepca>dTal: the codebase is small enough that if you're not sure where something is defined, you can just grep for stuff that sounds similar. For example, `grep -r "base16" ~/.config/guix/latest/guix | grep "define"` will get you the lines that define stuff involving base16. Not a particularly pretty solution, but it works. <dTal>I don't have one of those yet :) <dTal>which goes some way towards explaining my difficulty with finding the scheme sources <reepca>that's strange. Do you have guix installed in your user's profile ("guix package -i guix")? <dTal>No, I just installed it as explained in the manual, and have been running as root since <dTal>(I don't intend to do that forever, I just tend to do that when playing with a new system) <cbaines>~/.config/guix/latest will be created by running guix pull <cbaines>I have it symlinked to a clone of the guix git repository <reepca>but now I wonder, where does the guix command find the code before that? It has to be somewhere... <dTal>it's binary-bootstrapped, isn't it? <cbaines>You'll have guix installed somewhere, try reading the guix script <dTal>I don't see the mystery here, I'm not using some exotic setup <dTal>I followed the installation instructions <cbaines>I don't think there is a mystery, but its good to explore how things work <reepca>dTal: the mystery is I'm in the process of learning <cbaines>have a read of the guix script reepca, it includes a hardcoded "prefix", and is also the place where the ~/.config/guix/latest directory is used <reepca>Ohhhhh it's in share/guile. I kept looking in share/guix for some reason. <reepca>~/.guix-profile/share/guile/site/2.2/guix/ should have the source. <dTal>And the system level profile dir is at /var/guix/profiles/system/profile/ <dTal>making the final answer /var/guix/profiles/system/profile/share/guile/site/2.2/ <cbaines>I believe the system profile will only be involved if you don't have guix installed in your user profile <cbaines>If you have guix installed in your user profile, then I think the system profile state will be ignored <dTal>ah, so when I switch to my user account all the stuff I installed will be unavailable BUT it won't have to be rebuilt or redownloaded when I do install them because they will already be in the store - yes? <dTal>I was wondering how the "user" and "system" stuff interacted <dTal>this sure is a learning curve :) <cbaines>The user profiles can be seen in /var/guix/profiles/per-user/ <cbaines>e.g. I see chris and root in that directory <cbaines>each user can have multiple generations of their profile, which corespond to symlinks in those directories <cbaines>profiles are created by symlinking to other things in the store <cbaines>and as you say, if it already exists in the store, because its present in another users profile, installing it just means, generate a new generation of my profile, including the thing you are installing