<lfam>If you cancel `guix pull` before it finishes, it will have no effect <lfam>The reason not to do it now is that we tested the 0.11.0 release tag as an installer, whereas he haven't tested the current HEAD in that way. <lfam>One reason to do it is that you will get the recent security updates from the first generation of your system. <lfam>And we do strive to keep HEAD in order <lime_>#/gnu/store/zy5aanymkq37l91yh0xa6rddv1skl6s-hello-2.10 <lfam>Great, did you try it without the '-n' option? <lfam>And it downloaded the built package instead of building from source? <lfam>Great. You should be on your way. If there are errors during `guix system init` as before, then there is probably a problem with the OS configuration file that you are using <lfam>If so, feel free to share it and we can help you fix it up <lime_>previously I specified sda1 as my root filesystem <lime_>it wants a hard path I presume <lfam>Yes, it needs an absolute path <lime_>spent too long on BSD clearly <lime_>think I'll make some tea whilst that runs <sapientech>im thinking of integrating guix environment to projectile, so its easy to manage project profiles <lime_>build failed, database or disk s full <lfam>How large is the partition you used? <lime_>guix system: error: build failed... <lfam>There is no other output describing the failure? <lime_>it had just finished doing evince <lime_>error (ignored) aborting transaction: cannot roll back - no transaction is active <lfam>The disk is not actually full, right? <lfam>That would really be something! <lfam>Even 45G should be a lot more than enough for a big GNOME system <maurer>lfam: If he has not gc'd it'd be pretty easy fill a disk, but if it's 420gb, that's not his problme here <lfam>maurer: I believe that lime_ is initializing a new system, so there should only be one generation of packages going into the store <lime_>ACTION performs a sacrifice and does a blood sacrament to the GNU Gods <lfam>lime_: Can you share your OS configuration file? <lime_>i just did guix build netcat <lime_>netcat is then not a commnd my system? <lfam>lime_: No, you need to do `guix package --install netcat` <lfam>`guix build` is primarily a tool for developing Guix <lfam>Wow, I can see how all the "updating list of substitutes" messages could look like a bug. The desktop environments are sooooo big <lfam>unionfs 2750328 2750072 256 100% / <lfam>lime_: I don't fully understand it, but that seems like an issue ^ <lfam>You started the cow-store service as directed in the instructions, right? <lfam>I wonder if mark_weaver has some insight <lfam>lime_ Is it possible to get the last screenful of the failed build onto termbin? <lime_>I mean, does it log anywhere? <lime_>there's nothing on my hdd fs <lfam>lime_: I'm pretty sure this is wrong: (title 'Gnuix) <lfam>lime_: Check manual section 7.2.3 for an explanation of "title" <sapientech>getting URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)> with python script <sapientech>i think issue is because it looks for certs in /etc/ssl/cert.pem, which probably doesn't work for guix, since it doesn't have access to /etc right? <lfam>sapientech: Are you trying to use some software installed by Guix, or are you building a Guix package? <lfam>Guix software can look in the normal places on your filesystem <sapientech>lfam: using guix environment --pure, i think that might have something to do with it to <lfam>sapientech: --pure simply unsets your environment variables. Use --container to actually limit the filesystem access <lfam>In this case, you probably unset the variable that says where to look for certs <sapientech>lfam: okay cool, trying without --pure to see if things are fixed <lfam>lime_: I think you want (title 'device), since your (device ...) field contains a device node (/dev/sda1) <lfam>lime_: If you want to refer to your disk by the label 'Gnuix', then do (device "Gnuix") (title 'label) <lime_>restarted the live usb and it's chuntering along again <lime_>lfam: the changes to my .scm config got reset <lfam>lime_: What do you mean? <lime_>well, I redid the usb to get some space back, i remounted the hdd, cat'd the desktop.scm <lime_>and it had reset to yhe default again <lfam>When I am installing GuixSD (which doesn't happen often except for testing), I usually install rsync and ssh in the installer and pull the OS config from a remote machine. It's not designed to persist in the situation you describe <lime_>you mean it isn't meant as a daily driver 'yet' ;) <lfam>The installer image? No :) <lime_>but *Linux with the Guix package manager <lime_>I am guessing, is production ready <lfam>Guix on a foreign distro? I'd say so. But we are still calling GuixSD "beta". It still lacks some features that we consider important <lfam>However, many of us use it on our primary machines. <lime_>it's certainly more polished than hurd, let me tell you athat <lfam>Although GuixSD doesn't have all the features of more established distros, I think it's already more reliable. Being able to roll-back the entire system if an upgrade goes bad is a life-saver. <lime_>I actually had a kernel panic on boot <lfam>I thought you didn't finish installing it yet? <lime_>I think I'll do the rtfm thing, in the morning <lfam>When I said that it's not expected for your OS configuration to persist on disk, I thought that you were still using the installer image, not an installed system. Of course your files should persist once the system is installed. <lime_>no i Intend on using it for my laptop <lime_>do i run guix system configure from within a chroot? <lfam>lime_: No, you run it as the root user in a regular environment. <lfam>Assuming you mean `guix system reconfigure`. There is no `guix system configure` command <lime_>there is no guix in my chroot <lfam>lime_: I don't understand what you are trying to do. Why are you in a chroot? <lfam>Okay, have fun and let us know what's broken :) <ng0>that's the manual, why should it be linked in the manual itself? or do you refer to other install instructions? <ng0>but the link: Install Instruction leads to section 2.2 of the manual. do you think the manual top needs to be linked additionally? <ng0>wow. this is weird. A build fails when I offload it and succeeds when I build it locally <ng0>offloaded rounds=5: same outputs <ng0>now offloaded succeeds too. <lime_>so I'm going to bootstrap this from a debian live usb <ng0>is GuixSD-logo.png the logo we want to have linked when the option is given at applications which list the systems with graphics, or is there another one for just the package manager? My choice would be GuixSD-logo from the artwork repo <efraim>i don't have the artwork repo cloned on this machine, is that the one with the 3 pieces into a circle? <ng0>it's the logo which can be seen on the first page of our web site <ng0>i used this in the email i just sent to tor <ng0>this might be bad on white ground though.. <ng0>is there a better one? <efraim>and it looks better on a white background :) <ng0>okay, i'll send a correction email once my first one to tor-dev is through <ng0>but the SD logo would look better with the other logos on there <efraim>I don't feel too strongly one way or the other, I guess its more of guixsd vs guix <ng0>well.. it's guix, not just guixsd, so i like your idea better <ng0>bavier: i think the markup for "t/*.t" and "t/test_manifest" is @code{} as well? <ng0>The detail with perl-xml-rss test which does not run is: I enable it, it gets ignored. I disable it, same. <ng0>I'll get to fixing those later. <ng0>nice progress update on GuixSD/Hurd :) <Petter>"It is correct that there is no "sudo", it's no typo." :) <ng0>well the other examples have sudo, on the /download.html page <Petter>Yes, I like it. In fact I was looking if you set the terminal prompt to $ or #. <ng0>any improvements on the text which should land on the download site, or do you think it's good? <Petter>I noticed a typo, but it's not important. "the dar kvariant" <Petter>It's a nice way of getting the system "out there" I think. <ng0>guix' mosh should be added to mosh.org <ng0>or did you mean that? <Petter>And I mean that getting Guix on such download pages is a nice way to let new people know there's a thing called Guix. <ng0>i'll make a blog/news post on guix (and gentoo) package when I consider guix' gnunet packages (+service) 99.99% done <ng0>well, gentoo was almost a year work.. and guix is still going on <ng0>so it's not inappropriate to make a small post about it :) <ng0>shouldve been just appropriate. <ng0>no, gnunet.org means precisely just that <ng0>i fdoregot to add that <ng0>it will be a post on gnunet.org <Petter>Are you involved in gnunet beyound packaging? <ng0>more or less.. I got in through packaging but packaging takes up so much time that the other works and projects do not get so much attention <ng0>doesn't seem necessary though <ng0>but debian and rpm distros have articles <Petter>I don't really see a need either. <ng0>on gnunet, I've spent some time reading gnunet papers to understand the intention and direction of secushare, where my main interest in gnunet is. this, and discussions with the other developers involved helped <Petter>I have only barely looked at gnunet. Don't know much about it at all. <ng0>the strategy with secushare changed as perfectionism was too slow, so my intention to package psyced for guix will be of use there too :) psyced will soon be able to federate native over gnunet <ng0>and i'm looking into guixsd and nixos for "liveusb" systems for secushare. <ng0>i tried nixos before, but this time i have to say guix is easier.. i have not managed to boot into X11 with thei documenttion <ng0>it's a sandboxed chatserver, providing xmpp, irc, psyc, telnet, etc. almost 20 years old and still running. used to be a big network. PSYC0.99 (1) is not like PSYC2. there's a wiki on it, although a bit messy. <ng0>or just www.psyced.org <Petter>Yeah, hope to see a package for Guix at some point :) <ng0>i'm working on both, psyclpc and psyced <ng0>the sandbox can be compared to webbrowsers sandbox. if you manage to gain "root" in the application, you can not escape it to damage te system. <ng0>so it's not difficult to package, but difficult to apply to guix. <ng0>at least a service will be needed <ng0>well web browser or chroot. <Petter>How is it more difficult on Guix than other GNU distros? <ng0>it needs read+write access to its "world" files <ng0>default is /opt/psyced/ for those <ng0>some are symlinked into it <Petter>Is the problem then that Guix doesn't have /opt? <ng0>neither does Gentoo by default or Debian. <ng0>psyced -u needs to read and write updates <ng0>there's a posix shell script install.sh, the ebuilds just copy that <ng0>I was thinking, a service let's name it psyced-service, could populate /opt/psyced on first run.. <Petter>I see those .ebuilds use hardcoded absolute paths <ng0>yeah, some of those paths need to be adjusted, there's something like ${EROOT} for gentoo. i only fixed minor things in those ebuils <jlicht>just saw some NixOS folks having a coffee at the university coffee corner ;) <jlicht>and seeing their nice shirt had me wondering, how can one get one of those nice GuixSD shirts? <ng0>I prnted GuixSD buttons myself <ng0>it's svg, so tshirts should be easy <ng0>sneek: later tell lfam: gnurl failng test reported in #gnunet, no email to pass on: grothoff ng0: I've passed your remark about gnurl onto Jeff, he'll likely fix it once he has a chance. <ng0>sneek: later tell lfam: well.. i can write an email with a link to the timestamp of the irc log on gnunet.org <Petter>#mosh is interested in adding Guix to their site. Now, just to be clear since I've only used GuixSD, you can install mosh with Guix on a foreign distro and run it, right? <Petter>So it's better that they add Guix rather than GuixSD. <davexunit>do you use via a GuixSD service or something? <davexunit>if all you need to do is install a package, then it should work anywhere that Guix works <Petter>No, I just type "mosh some-server" <Petter>Btw. how do you run a program installed with Guix on a foreign distro? <Petter>What happens when a user has installed the same program with the native package manager and Guix? <davexunit>on a foreign distro, a Guix user needs to make sure that PATH includes their profile <Petter>Can someone join #mosh and help me answer questions, I'm out of my element here. <Petter>"Does guix use containerization"? <bavier1>does anyone else use epiphany and have missing icons? <bavier1>no, packages are built in a chroot, not a container <mark_weaver>bavier1: I used epiphany and haven't noticed any missing icons. <bavier1>mark_weaver: I'm using it in the meantime too <mark_weaver>bavier1: well, it's more than just a chroot. for example, network access is not available in the build environment. <bavier1>is there an icon package I need to install? <mark_weaver>bavier1: I am in the habit of calling it an "isolated build container", although I confess I'm not 100% sure if that's the right term for what we're doing. <mark_weaver>but we are using Linux namespaces to isolate the build environment in several ways. <bavier1>mark_weaver: right, I didn't go into details. that term seems to be the best <mark_weaver>bavier1: you seem to be asserting that what we are doing is *not* a container. are you sure of that? <davexunit>mark_weaver, bavier1: the term "container" is ambiguous, but it would be correct to call the build environment a container. <mark_weaver>davexunit: that's what I thought too. thanks for confirming :) <davexunit>Petter: np, got a little weird there, but I'm glad the issue seems to be resolved. <Petter>Yeah, it took a unsuspected turn there, I expected more questions about Guix as in people being curious about it. <Petter>Better would be one without the name I guess. <bavier1>ng0: I wrote a package for celestia a while back, but there is some concern about the copyright on some of the images and data <ng0>it looked interesting.. occasionally i read reddit, and this came up <ng0>my graphics card is probably too slow <ng0>well at least the one which does function with guixsd without me reconfiguring the system <ng0>created by one person from scratch.. i'm interested in just looking at it <wgreenhouse>mark_weaver: since you were discussing the guix build environment, is it reasonably possible to [ab]use "guix environment --container" as a sandbox for processes interacting with untrusted data? <ng0>ooooh. i think i know now how to fix lispf4 <davexunit>wgreenhouse: yeah, as ng0 said, to some degree you can do this. <ng0>maybe.. I don't know much about C.. so i need to think about this <davexunit>wgreenhouse: we use a chroot (pivot_root technically) + linux namespaces <davexunit>so whatever that gets you in security is what you get with 'guix environment' <wgreenhouse>davexunit: nod. and specifically it's using the network and mountpoint namespaces, I guess, based on what it's able to do <davexunit>the network aspect is limited. you can either have access to loopback only or not use the namespace at all and have access to the host network <davexunit>so you can't make some sort of virtual network device to bridge the host and container <davexunit>you'd have to use a UNIX domain socket that both the container and host have access to or something. <wgreenhouse>davexunit: hm, yeah, that's the missing knob that some of the setuid sandbox things being tried nowadays have (option to use bridge or veth or vlan network) <davexunit>wgreenhouse: yw. I'd like Guix to have the same capabilities. <davexunit>and we'll get there... some day. so far no one besides myself has really hacked on call-with-container <wgreenhouse>davexunit: yeah, some intermediate stage between --network and not would be handy <wgreenhouse>e.g. allowing for the container to have its own iptables rules <davexunit>I would really like to see someone that knew the low-level networking interfaces well to send a patch set :) <davexunit>wgreenhouse: yeah, it's just much more complicated than implementing everything else. :) <wgreenhouse>that person with low-level interface knowledge is not me :) but guix seems like one of the projects using namespaces that is not being done by crazy people, so might be a reason to learn <davexunit>guix containers have some distinct advantages over things like Docker <davexunit>that are a major source of complexity for Docker and friends <wgreenhouse>what is the filesystem technology getting used for guix environment --container --share? <davexunit>everything shared from the host, including the dependencies in /gnu/store, is done with simple bind mounts. <davexunit>gnu/build/linux-container.scm has all of the juicy implementation details <davexunit>the file 316 lines long with plenty of comments and docstrings <sneek>Welcome back lfam, you have 2 messages. <sneek>lfam, ng0 says: gnurl failng test reported in #gnunet, no email to pass on: grothoff ng0: I've passed your remark about gnurl onto Jeff, he'll likely fix it once he has a chance. <sneek>lfam, ng0 says: well.. i can write an email with a link to the timestamp of the irc log on gnunet.org <lfam>ng0: No need to add a link to the IRC log <lfam>Re: mosh: I use it with GuixSD and with Guix on foreign distros. If there are issues with PATH when connecting to the remote, you can pass something like '--server=~/.guix-profile/bin/mosh-server' to your local invocation of mosh <lfam>And, I do have issues with things like PATH and remote locales with mosh. I didn't figure out how to make it start the remote with my "login" environment. I actually rebuilt a GuixSD system with a modified glibc to make it work again since the glibc we released 0.11.0 with has some locale issues <bavier1>any recommendations for a harddisk clone tool? <Petter>lfam: And this worked fine with SSH? <lfam>Petter: What worked fine with SSH? <Petter>These PATH and remote locale issues <lfam>I didn't have PATH issues with mosh. I only had issues with locales. Mosh will not run if it can't find a UTF-8 locale. Our glibc is supposed to hard-code the location of these locales, but the variable name was changed upstream in glibc-2.23 and we didn't notice until we'd already rebuilt everything. <lfam>I could not make mosh read my login shell startup files and honor GUIX_LOCPATH <lfam>So, I rebuilt the world ;) The patch I used is on the core-updates branch <lfam>While I was rebuilding, I made a wrapper script for mosh that exports the variables, and passed that to '--server=' <lfam>There must be a better way than what I did, but we needed to fix the glibc thing anyways <ng0>gcc -o $@ $(M32) -O $^ -lm there's a lone above that in a Makefile, but what doeshappen after $@ ? $(M32) is something like -m32? <Petter>lfam: I like your attitude; if it doesn't work like you want, make it :) <lfam>Lol! Like I said, the glibc issue was an oversight that needed to be fixed anyways. <lfam>One nice thing about computers is that we can (mostly) make them do whatever we want :) <lfam>To the degree that the software system is free, that is <ng0>the search results make me assume that $(M32) is similar to -m32 and that I can leave it out <lfam>ng0: $(M32) looks like a variable. Perhaps it is set somewhere? <ng0>but i don't understand the rest <ng0>not really... no configure script <lfam>Perhaps it comes from the environment? <ng0>but now it's commented <ng0>so it's just leftover <ng0># compile for 32 bit machine (works on 64 bit machines too) <ng0>what's -O $^ -lm then? <lfam>-lm is linking with libm <lfam>-O is setting the compiler optimization to... something. Not sure what <ng0>there should be a duckduckgo option which deciphers the switches <ng0>I was looking for something in the makefile which might've cause root:root in lispf4 file and this to be the very simple reason that it is broken <lfam>Just like $@, in this context <lfam>I mean, $@ is also a Make variable. I don't mean that it's the same as $^ <ng0>just $^ i did not know <ng0>but why would it end up as root:root ? <lfam>I don't know. I don't think anything in the command we are dissecting would case that <lfam>I thought the problem with lispf4 was that it tries to use libraries from /usr <lfam>Did I remember that incorrectly? <ng0>no idea.. my idea is that the problem is with the code. and i can set some search paths in source code.. i just thought i revisit things i have not looked at before <ng0>but now the problem is also that it's root:root in owner group when you do guix apckage -i lispf4 <lfam>Is that a problem? All the files in my '~/.guix-profile/bin' are either root:root or root:guixbuild <ng0>no,in /gnu/store i mean.. i thought it should all be guixbuilder <lfam>I don't know exactly what it should be. In my profile, it seems that everything I built with `./pre-inst-env` is root:root <ng0>i don't know if there would be permission problems.. <ng0>all the file in profile are root, but in store it is different <ng0>but nothing that would cause such a problem <ng0>lispf functions in gdb though <ng0>maybe i just overlooked something the last time <lfam>Does it work in gdb when there is not /usr directory available? <lfam>For example, on GuixSD, or using `guix environment --ad-hoc lispf4 --container`? <ng0>this is on guixsd currently <ng0>when I start it as lispf4 SYSATOMS, it segfaults <ng0>when i start it without any, or just --help, it complains about SYSATOMS not being there <ng0>i know too little C to change the code <ng0>maybe the lispf42.c can get some minor patch to fix this <ng0>this would be gdb -- args lispf4 SYSATOMS <ng0>and gdb lispf4 without any aruments runs <lfam>ng0: Have you asked the upstream maintainer for help? <ng0>yes.. never came back to me <ng0>said "in a few weeks i can help" <ng0>also "many people use it daily" etc <lfam>ng0: Our package list page *is* too big. I stopped sharing links to it for that reason <ng0>okay.. then I won't do this next time <lfam>I mean... it's nice to have the links. But it does make my browser unresponsive for a while when I load it <ng0>but imo gentoo can wreck your system in no time, and it's on the list. archlinux broke often many years ago when i used it. why do people view beta as unstable, does not work? <paroneayea>I've wanted to give clojure's functional datastructures a try <lfam>As for the beta question, I don't know. They have a point. I would just wait until we aren't beta. Then they have no excuse :) <rekado>I like that guix web has pretty pages for individual packages. <rekado>but it also loads pretty slowly now that we have so many packages (and it loads their info in one big json file) <davexunit>it's been like 2 years since I made this... how time flies. <davexunit>I think we could get something roughly equivalent to this into core guix sometime <lfam>Oh, we should deploy that! <davexunit>I'd want to rewrite some of the frontend code, though. I'm not happy with that Kefir library I used for FRP <rekado>davexunit: do you have any other recommendations for web development with Guile + JS? <rekado>I’m tasked with writing a web frontend for a bioinfo tool <davexunit>I just wish I could use only Guile and compile to JS <ng0>i think i will reply something like pointing out how unstable other systems are at times, but that feedback is good and we'll improve on it and we'll ping them when it's no longer beta if that's what scares them off.. i mean curl has guix listed, but everybody has their standards and views <ng0>s/we/I (where appropriate) <ng0>i dislike the collective "we" <paroneayea>it's interesting that webassembly uses s-expressions <davexunit>rekado: 'guix web' should be changed such that the frontend asks for "pages" of packages from the server, but then searches become a server-side thing, too. <rekado>ng0: I wouldn’t make any apologies or comparisons. I’d just thank them and move on. <lfam>ng0: I think it's better if we don't insult other distros while speaking about Guix. Even if the "insult" is just saying that they can be unstable or stop working <lfam>With time, one of the Tor devs will probably learn about Guix / Nix on their own, and that person can convince the rest of them that it's okay to link to us <ng0>my personal experience sometimes leads me to not diplomatic answers based on facts i experienced. thanks for the feedback <davexunit>rekado: the other thing I really wanted for 'guix web' was a login page that works like the CUPS web UI where you login as your system user <rekado>davexunit: I found a bug a while ago; if you go to, say, page 9 and then restrict the number of packages (e.g. by typing “blender”) you won’t see any packages, probably because you’re stuck on a non-existing page 9. <ng0>lfam, see trac search for "Nix" <lfam>ng0: I don't disagree that Guix / GuixSD is already more stable than some other more established distros <rekado>davexunit: I actually never liked that CUPS login :) <rekado>davexunit: I think authentication is up to the web server. <davexunit>so you could run it as a system service and any user can login to it with their credentials <rekado>in the web server settings you can authenticate with whatever backend is supported (e.g. LDAP) and then set some variable (e.g. REMOTE_USER). <davexunit>rekado: okay yeah something like that would be nice. <lfam>ng0: That person makes a good point. <davexunit>rekado: I'm not sure how to get from there to updating user profiles, though. <davexunit>the web server should run as some unpriviliged user <davexunit>but then needs to be able to acquire privileges to do things on behalf of any given user <rekado>I haven’t found a single application that does this well. <wgreenhouse>ng0: I think atagar was pretty mild and diplomatic in that tor-dev post <rekado>Galaxy, for example, uses a sudo helper. <davexunit>maybe 'guix web' is best left unfinished then <davexunit>this is a must-have feature as far as I'm concerned <lfam>I think we need *something* that can provide hyperlinks to packages <rekado>davexunit: I think there are two parts to it. <rekado>one is for public deployment, like we do at guix.mdc-berlin.de <rekado>the other is for users who want to install packages <rekado>among the default services we could have a guix-web service which can be used by people who don’t like the command line interface. <davexunit>okay, I understand both use-cases. would be good to accomodate both. <davexunit>but the latter component doesn't seem feasible to me now. <davexunit>but it would be a big usability boost if we could figure it out. <rekado>multi-user support is quite hard to achieve in a secure manner. <rekado>you’d always need that little something with sufficient privileges to spawn processes as other users. <davexunit>the other complication: different users may use different versions of guix <davexunit>rekado: you could take the nginx approach with a master process that runs as root <davexunit>while keeping the web server itself unprivileged <rekado>davexunit: I’d be a little anxious to run some part of guix web as root, to be honest. There’s just so much that could go wrong. <ng0>why is setuptools removed from the pypi importer? <davexunit>rekado: it wouldn't be the web server, though. <ng0>the patch which just arrived i mean <rekado>davexunit: is it really necessary, though? This is only needed to modify profiles, i.e. the last step. <rekado>davexunit: we can talk to the daemon, ask it to build things (including profiles). <rekado>guix-web would need to have write permission on profiles – how about group write access? <rekado>(it’s a bit sad that Linux doesn’t offer any finer control over user identity, unlike the Hurd) <davexunit>so I built the clojure package but there is no binary to run <rekado>this problem only exists when you want to have *one* instance for all users on a shared system. <rekado>davexunit: yes, I’ve noticed that, too. I think you’d need to do something like “java -jar /path/to/clojure-*.jar” <rekado>(I have never used it before, so I don’t know what to expect) <davexunit>rekado: if each user ran their own instance, they would each have to pick a different port <davexunit>rekado: what package should I use to get java? <lfam>phase `patch-source-shebangs' succeeded after 236.1 seconds <rekado>davexunit: could we use not a port but a socket file? <lfam>ISTR that Andreas was looking into it. I don't know what progress he made <bavier1>debian has a lot of nice documentation about how they deal with latex/texlive <bavier1>I read through it a bit, but it does indeed seem like a lot of work <davexunit>rekado: I suppose so, but how would the user know to connect to it? <davexunit>I could imagine a system where the user runs an executable that launches 'guix web' and then opens a web browser automatically <davexunit>maybe we can take a page out of the nodejs book: launch a native GTK window that just has a webkit widget <rekado>or there could be a central web service at a single port that only keeps track of user sessions and forwards requests to the matching socket. <rekado>(this would require user authentication in the browser, though, so it’s not suited for single-user scenarios) <davexunit>rekado: this will get you a clojure repl: guix environment --ad-hoc icedtea -- java -jar $(guix build clojure)/share/java/clojure-1.8.0.jar <catern>so, can I install guix fine without privileges? I want to use it to install software on this system I don't have root on <davexunit>catern: you need root currently, for the daemon. <lfam>catern: Check the manual section 2.4.1 Build Environment Setup <davexunit>once it's installed, you can install things as an unprivileged user. <catern>davexunit: well, I mean compiling guix from source <lfam>You can install and run it but it won't really work properly <davexunit>but to actually run guix in practice you need to run the daemon as root right now <catern>do you know of anyone running guix without root? <catern>I am not sure I see why this must be true <lfam>catern: Did you read 2.4.1? <davexunit>you can run the guix daemon as any user, but you won't get build environment isolation <catern>yes, that's what I was thinking, and was about to say :) <davexunit>and our CI system doesn't test guix in that way, and neither do us devs <davexunit>we're thinking about ways in which we could remove the root requirement by using some trickery with Linux user namespaces <catern>user namespaces aren't a great way to remove the need for root, since they're so insecure and will probably never be turned on anyway on any distro <catern>(so... if I'm on a system that doesn't even have guile installed, is there a particularly easy way to bootstrap my way up to guix? ofc I can just compile guile and other guix deps but just curious) <davexunit>I'm not super persuaded by the anti-user namespace arguments <catern>but they've had tons of vulnerabilities reported <catern>it's a big project to make them secure <bavier1>catern: GSRC can help you get a guile up and running <rekado>I wonder: if you never build things from source and only used substitutes, would it matter much if the daemon ran as an uprivileged user? <bavier1>I've tried the unpriveleged guix thing a few time off and on <bavier1>catern: building packages without root doesn't really work atm <catern>rekado: well you can't use substitutes if you don't have root right? <catern>since you can't put things in /gnu <bavier1>the best I've come up with in an unpriveleged env is to set up 'guix publish' on a machine I do control, which serves substitutes for a storedir that I have write perms for on the unpriveleged system <davexunit>bavier1: yeah but the store would *have* to be /gnu/store <davexunit>which usually requires root access to create :) <catern>oh? I remember from when I tried nix that you couldn't use their precompiled packages if you didn't put them in the well-known path /nix/store (or whatever) <bavier1>yeah, you just have to build the substitutes yourself, somewhere else <davexunit>the store directory is part of the identity of a package represented by those base32 hashes you see everywhere <catern>bavier1: oh huh... that is an interesting idea... <davexunit>bavier1: yeah okay, I see what you mean. that is definitely possible. <catern>bavier1: anyway what do you mean about building packages without root doesn't really work? what problems did you encounter? <bavier1>catern: impurities galore mess up things <davexunit>without root the daemon cannot chroot or create namespaces <janneke>we could also make packages relocatable... <catern>but it's plausible that the impurity doesn't matter <catern>bavier1: does that actually cause problems? <catern>the reason I am trying so hard to use guix is because if it's not guix that I use, I'll have to use some other thing, pkgsrc maybe <bavier1>e.g. some packages install libs into lib64 because of some system file they found, then upstream packages that are pointing to "lib" can't find libraries <davexunit>catern: the impurities introduced *will* cause problems somewhere <catern>what if I did the only-use-substitutes thing? <janneke>davexunit: is there a downside to that? <bavier1>catern: if you can run your substitute server with root, sure <rekado>I find service extensions hard to understand. Extending shepherd-root-service-type with just one other shepherd service is easy, but how do I extend it with two services? <davexunit>janneke: look at the shebang for a script in /gnu/store somewhere, it refers to a precise, absolute file name for an interpreter <catern>bavier1: yeah I can just use any of my normal servers <rekado>(service-extension shepherd-root-service-type my-new-shepherd-service) <catern>now I'm wondering how to avoid hard-coding my home directory location, /home/user/gnu/ into the path of the store <davexunit>dunno, haven't looked at services in some time <catern>and thinking about, what is a path that any user on any system has access to write... <rekado>I want one system service to append two shepherd services to the shepherd-root-service <janneke>davexunit: ah no, sure i would allow for dynamically allowing '/gnu/store' to be prefixed with, say '/home/janneke' ... keep all hashes in place of course <bavier1>catern: my org usually has large /ptmp partitions on the linux workstations it gives to employees <davexunit>janneke: but don't you see how that could cause problems? <davexunit>you couldn't blindly patch the store directory from the binaries either unless the string was the exact same length <davexunit>so I don't know how you'd even implement such a thing <janneke>davexunit: not really...i can see how mv /gnu $HOME could fix some if you don't have root <janneke>i don't understand 'blindly patch store directory' -- why would anyone want to do than? <davexunit>janneke: how else could you make everything relocatable? <davexunit>shebangs *must* refer to the absolute file name for the interpreter, for example <catern>can I use a remote build server with guix? <davexunit>catern: yes, but you still need to use the exact same store directory otherwise things won't work. <janneke>davexunit: everything is a lot, but we wrote patches for the whole lilypond stack to make things dynamically relocatable <janneke>ah, yes /bin/bash ... i can see that <davexunit>offloading builds or using substitutes is more of an optimization than anything else <davexunit>and a store directory that works on the unprivileged machine <catern>the offloading even copies prereqs over to the machine, right? <catern>so the machine doesn't even need network access? <davexunit>I think you just want to use substitution rather than offloading <rekado>how would that work? The binaries from the remote machine would have to be installed on the local machine at /gnu/store. Am I missing something? <davexunit>rekado: the remote machine would have the same store directory configured. <catern>rekado: no, i'd configure the remote machine to have the same store, like davexunit says <davexunit>and then the unprivileged local machine can use those substitutes <catern>davexunit: the problem with substitution is that then I have to build everything in advance <davexunit>it's a more expensive process, but should work <catern>am I correct in saying that the offload machine doesn't need network access? <catern>other than being accessible over ssh from my local machine <davexunit>I think the source code is downloaded on the local machine <rekado>ah, I missed that the store dir should be something other than /gnu/store. <bavier1>sounds like a useful service that could be offered in the future, offload server that would build substitutes for a variety of store prefixes <rekado>re service extension: got it. For one shepherd service it’s this: (service-extension shepherd-root-service-type (compose list thing)) <rekado>for two it’s: (service-extension shepherd-root-service-type (lambda (stuff) (list (thing1 stuff) (thing2 stuff)))) <bavier1>another feature I'd like our guile-guixdaemon to have: runtime configurable store prefix <davexunit>bavier1: hmm, that would be cool, but tricky! <davexunit>the database would need to be changed significantly, I think. <bavier1>yeah, that would need some consideration <rekado>I thought we had some undocumented environment variable that affected the store prefix at runtime…? <bavier1>I ran into difficulties running two guix-daemon on the same GuixSD machine <bavier1>rekado: I think our daemon officially doesn't support that since some time <catern>I had a further great idea. my company (I just started) is pretty paranoid about security (that's why I don't have root on my own machine and need to use guix to get packages) and they might not even be willing to give me a VM with root and no network or anything. But! There are tons of job-running services that give programmers an isolated environment. Maybe I could use one of those to do the builds! <bavier1>rekado: I might be wrong, our test-env uses a NIX_STORE_DIR <lfam>Holy crap, there are so many patches on guix-devel! ***kelsoo1 is now known as kelsoo
<taylan>ACTION feels kinda bad for taking kind of an extended vacation, but is happy guix development is so active! <davexunit>maybe it's just fine to mix store dirs with a single daemon <lfam>mark_weaver: It looks like many of the "Newly failing jobs" on the latest wip-python evaluation are caused by failures in guile-2.0 and subversion. But, I just downloaded substitutes for those packages from wip-python, so I guess that those issues have resolved themselves. <lfam>mark_weaver: Is it possible to start another evaluation? Or do you think I am missing something? <lfam>Also, shepherd failed on x86_64 and i686, but I just got a substitute for it. Another thing that appears to have been fixed <lfam>I mean, I just built it from source. No substitute. <Petter>I assume the problem is with this 'rc', but I don't know what that is or why it doesn't work with this version. 
