<mark_weaver>to make the changes that 'usemod' would perform, edit your OS configuration and then update the system with "guix system reconfigure <config>" <ng0>could it be that the instance of patchwork we use is outdated? i see no bootstrap based fancyness <ng0>i'll try phabricator and see if it's better than the outdated patchworks we have. <mark_weaver>hmm. gnome-session is wrapped to prepend a 'glib:bin' directory to PATH. this propagates to all the subprocesses run within gnome. not ideal <Akko_Teru>ACTION will need to stay on Trisquel while read the new manual for GuixSD <gnerfon>is it a good idea to install it and read the wiki, a topic everyday, to learn step by step, or it is better to read the whole manual and install it after? <Acou_Bass>i just installed it by following the installation guide, then learning to do stuff as i needed to (ie. 'hmm, ive not updated in a week, lets see how im supposed to do that) <gnerfon>Acou_Bass, that's what i thought to do <ng0>I'm tempted to set up an VM with GuixSD and see what happens when it's not updated for n number of years <Acou_Bass>probably nothing terrifying, unless after those years theres a HUGE update that renders the old guix command obsolete in some way :P <ng0>I still plan to do the comparison between gentoo and guix development/usage, but it will come much later i think not after 1 year this november as I planned to <gnerfon>on the main website page, there is written that it's not production ready. Does that mean that for common tasks like surfing on the web, watching movies/serials, it is unstable? <Acou_Bass>i use guixSD as my daily laptop driver for that use case <Acou_Bass>some people might find the packages 'unstable' in the same way that arch linux is 'unstable', because theyre basically always new and fresh <gnerfon>Acou_Bass, i'm using Arch/Parabola since a while. And never had real problems : ) <Acou_Bass>i use arch on my desktop, never tried parabola xD <gnerfon>Acou_Bass, the same but totally free : D <Acou_Bass>guix is my first 'free' distro, im pretty happy with it <Acou_Bass>i used nixOS for a bit so the way it works appeals to me hehe <Acou_Bass>im still wanting to set it up with full disk encryption though, when i originally installed i couldnt get that to work =\\ <Acou_Bass>and well, sort of important for a laptop i reckon hehe <gnerfon>i think i will first re-install Parabola on my desktop comp', learn how to use my comp' in TTYs/tmux and after GuixSD : ) <ng0>gnerfon: i'd say it depends on your needs and your definition of stable <ng0>I've switched my Gentoo systems over to GuixSD and only run one Gentoo system because there are some last applications which I have not finished porting to Guix. For me personally it fits, but I use it more for development of the system itself. The computer which just uses for no particular purpose is for music/videos/web browsing. <Acou_Bass>im gonna have a go at creating some guix packages at some point... i made a couple of nixOS ones once, but i prefer the guix way <ng0>I'm seriously considering to write packages for guix which I can fit outside of the tree which are needed for gentoo development, so i can test with repoman here. <ng0>but it's low priority. <Acou_Bass>i know nothing of gentoo so dunno what repoman is <ng0>gentoo specific software <ng0>you would not need it as a user, but as a developer of gentoo/for gentoo <ng0>checks syntax, fetches and generates manifests checksums etc etc <ng0>I just need it for manifest generation usually. <Acou_Bass>in some ways i imagine gentoo would suit me pretty well on the desktop... in other ways, i only just not-lzay enough to keep arch running <ng0>repoman manifest does what guix download does here .. while repoman needs to be run with write access to the portage dir and writes into a file "Manifest" in the current directory of the overlay you are in. <ng0>gentoo with more than 1 system is pain. gentoo not maintained for some time is pain if you are not very experienced in debugging emerge problems etc. <ng0>I used to have 5 systems + about 25 test vms. <ng0>guix vm does it much better <ng0>Well, for isolating target systems from my own system I needed to create new systems which were not necessarily reflecting my own architecture. <Acou_Bass>guix vm is such a nice feature (as is the container one too) <ng0>And of those VMs they sometimes needed to differ in only certain packages or versions <ng0>so I created blueprints to clone from <ng0>with guix I moved this to having many checkouts with different branches I work on, but the checkouts usually don't break so dramatic that you need hours to fix one of them <Acou_Bass>i sometimes wonder if guix could be used purely as a container runtime similar to how people use docker... upload, for example, 'nginx.scm' to the guixcontainerhub, people pull it, run guix container on it, boom we have an nginx container ready to go <ng0>guix devops or what it was called, the equivalent to nixos one, is being worked on i think <Acou_Bass>then again i suppose with guix being the way it is, we probably dont really need a specific container scm for nginx, because the standard nginx.scm will build a full OS underneath it if needs be anyway XD <ng0>I also lack any actual experience with docker, so I just assume this is what you meant <Acou_Bass>well essentially (very high-level explaination here), docker is a runtime for containers, you pull an image from the dockerhub (dumb example, a 'skype' container) and run it atop docker, and you get a container with nothing but skype in it running <Acou_Bass>but i guess again like i said, guix basically already does this <ng0>i know how it works in theory :) <ng0>i just said i never used it in practice <Acou_Bass>im struggling to find a whole lot of difference between docker and using guix containers via the system-images you can make <ng0>and the only time i had to use nodejs so far was when I thought the browser "Brave" would be something useful (which with consideration now it is not) <Acou_Bass>isnt brave the one with the new ad network built-in <ng0>replacing ads through ads and no transparency how their server side works so included data grabbing for 5eyes assumed. <ng0>short version of what i think. <Acou_Bass>yeah thats pretty much what i got out of it too <Acou_Bass>'ads are terrible, and spyware, and all this bad stuff... so weve built a browser to support the web via ads, but were different, honest!' <ng0>We follow too much authority figures who promote things many people don't question. <Acou_Bass>my main problem is this weird assumption that ads are somehow the only possible way to pay people for building websites <ng0>that too, it's also a white bubble just asking to explode ...hopefully very soon... at some point <ng0>advertisment industry i mean <Acou_Bass>also ties into this just-as-weird assumption that just because someone has a website they deserve to be paid for it, even if it means all the bad crap that comes with adverts... <Acou_Bass>which leads to this weird idea that adblocking is somehow a horrific injustice because the poor site owner wants moneys for his site <ng0>some so called "newspapers" here start to lock themselves up behind for people blocking javascript or ads, which is good. our "BILD" is similar to the "SUN" newspaper <Acou_Bass>yeah a few here do it too... thankfully there is adblocker blocker blockers (why the hell is that even a thing) <ng0>*behind contentblockers <ng0>If capitalism, or better: society, could come up with an sustainable payment model for people like independent artists, programmers, software maintainers, etc.. maybe even helped by the webbrowser extension which Taler will implement. <Acou_Bass>i made plenty of money as an independent artist years ago, this isnt a problem that needs solving, it just needs the artists to understand that not all of them will make a living, and thats OK xD <ng0>Not involving artists now or only to some degree: It's an expect free to be gratis and no work involved problem which is rooted deep in this system. Some things are just expected to "be" ... if all the package maintainers of core packages used in for example the internet infrastructure stepped down tomorrow and no one came forward to fix it, you'd have an continous mess. <ng0>they don't see it so it's expected to be "magic" which keeps it alive <ng0>I'll be off now. good night ***Digitteknohippie is now known as Digit
<sturm>Is there any downside to forcing `guix pull` to fetch the 0.10.0 tarball, then running `guix system reconfigure` to downgrade a system previously running against master? I'm doing this because I'm currently stuck not being able to build gnutls. <sturm>hmm, that didn't work, XML-Simple-2.20 doesn't seem to be available from CPAN <jeffers-media>hi everyone, trying to build guile-emacs per the instructions on the emacs wiki. <jeffers-media>I have all the packages but im getting unskippable errors. I was wondering if i could use guix to create the proper environment to build it <jeffers-media>simply, i thought that $ environment guile-emacs would work, since it would give me all of guile-emacs dependencies, however it didn't work <jeffers-media>im thinking this may have been because the environment only included runtime dependencies instead of build dependencies? <jeffers-media>note that I do not want to make my own guix package configuration file to install my modified version of guile-emacs, since I don't want to wait 2 hours to test minor changes (i want to use make) <lfam>sturm: What machine architecture are you using? I know that Hydra has a substitute for gnutls at least for x86_64 <sturm>lfam: I thought I had x86_64 - how can I check on a running Guix? <lfam>jeffers-media: If you used `guix environment guile-emacs`, then you got the build dependencies of guile-emacs, but it was piled on top of your pre-existing shell environment. Try it with --pure or --container for better isolation <sturm>lfam: nevermind - found it - is x86_64 <lfam>The issue with gnutls is that there are some test certificates for the test suite, and they've expired. <sturm>I saw the revision go in to fix it, but then there's a reverted gnutls change. <lfam>Yes, it was pointed out that my fix wasn't actually going to help :) <lfam>It's difficult to make changes to gnutls, since ~1000 packages must be rebuilt when it is changed. <lfam>I tested that Hydra could serve a substitute for x86_64 at both the HEAD of the Git master branch and also at the 0.10.0 tag <lfam>So, if you are in that range, you should at least be able to get a working system, although it's really disappointing that we can't build it from source right now <sturm>Wow, yes that's a lot. Better to have the dependencies explicit though. <lfam>Normally we fix bugs in core packages with grafts, but that requires being able to build the un-fixed package as well <sturm>lfam: Ok, thanks. I had other problems when I went back towards 0.10.0. Not sure why my system wasn't picking up the gnutls substitute and falling back. Currently reconfiguring against a revision from 5 days back to see if that works for me. <sturm>(other problems being missing substitute for XML-Simple-2.0 that didn't have source available to rebuild) <lfam>That was from the 0.10.0 tag? <sturm>CPAN mirrors seemed to have dropped that package <lfam>The problem with using 0.10.0 is all the security updates you'd miss. Not that it matters if you couldn't get gnutls at all from HEAD <jeffers-media>lfam: actually got a ./configure error after $ guix environment --pure guile-emacs <lfam>jeffers-media: An error in what? <lfam>But, when configuring what package? <sturm>lfam: sounds like a really interesting project <lfam>jeffers-media: Something's wrong if the compiler doesn't work :) <lfam>Can you build the guile-emacs package with Guix? That is, `guix build guile-emacs`? <lfam>I'm wondering if it's a problem with our package or if something is going wrong in your environment <jeffers-media>i did that originally, but now want to do some hacking on it <lfam>Did it download a substitute or build from source? To force a source build now, `guix build --check guile-emacs` <lfam>It might fail due to non-determinism at the very end, I'm not sure <lfam>That's what the --check is looking for <lfam>As for the potential issue with your environment, go back into the --pure environment and run `env`. The results should be extremely spartan <jeffers-media>lfam: just to make sure, this does not need to be within a guix environment? <lfam>`guix build` and `guix package` do not use your environment at all. Roughly, they pass a request to the guix-daemon, which sets up an isolated environment elsewhere <lfam>`guix environment guile-emacs` is for when you want to build guile-emacs by hand, typing `make` etc <mark_weaver>jeffers-media: the "config.log" file will include the details of what went wrong with "error: C compiler cannot make executables" <mark_weaver>one common problem that defeats "guix environment" is when people set environment variables in their .bashrc (or equivalent) <jeffers-media>lfam: cool got it, `guix build --check guile emacs` is still running. this will go through the 2 hr build? <lfam>Is that how long it takes? :o <mark_weaver>since .bashrc is read for *every* interactive shell, it will override whatever environment variable settings were put in place by "guix environment" <mark_weaver>environment variables should instead be set within .bash_profile (or equivalent), which is only read by login shells <jeffers-media>mark_weaver: i noticed that, i was getting x binary does not exist since i use it in bashrc <jeffers-media>however, i noticed that many of the environmental variables for the environment were set correctly, and overrode the ones i defined in bashrc <mark_weaver>most likely, that error is caused by having a mixture of Guix and non-Guix libraries and/or toolchain. <mark_weaver>when building software, it's important to use *only* Guix toolchain/libraries, or *only* the host toolchain/libraries. a mixture leads to problems like this. <jeffers-media>thanks for the tip mark_weaver, ill move them to .bash_profile <mark_weaver>jeffers-media: note that on some distros, .bash_profile is not read at all when logging into X via a display manager. in that case, you may need to explicitly source .bash_profile from .xsession <mark_weaver>I formerly used Debian, and seem to recall needing it, so you probably will as well. <sturm>lfam; If it's any help, my `guix system reconfigure` based on master is looking for gnutls "bi5s5f", which is different to the latest substitute. <sturm>(which I assume is why it's trying to recompile) <jeffers-media>mark_weaver got .xsession working great now, and it definitely had a good impact on my guix environment. <jeffers-media>now, it says that i can turn it off, which i am assuming is what was done with the guix guile-emacs? <lfam>sturm: If it's recompiling gnutls, it's also going to recompile a lot of other stuff <jeffers-media>lfam: i stopped the build after a while, it seemed to have gotten a lot further than when i did make, so i assume the error was due to a mixed environment <mark_weaver>jeffers-media: giflib is included in the inputs to our 'emacs' package, which is inherited by our 'guile-emacs' package, so giflib should have been included in the environment. <mark_weaver>can you look in config.log to see what went wrong with the configure test that tried to find giflib? <mark_weaver>typically, it tries to compile a test program that links with the library <mark_weaver>and if anything goes wrong, it simply assumes that giflib is not present. <mark_weaver>the precise test program, compile command, and error messages should be in there somewhere <mark_weaver>it could be that one of the early build phases in our gnu-build-system is important for that test. <mark_weaver>those phases are done when guix-daemon builds a package, but not when building manually within "guix environment" <mark_weaver>gif_lib.h is in /gnu/store/...-giflib-5.1.4/include, which should be in one of the environment variable settings within the shell spawned by "guix environment" <lfam>sturm: From commit 72fb1b24d9, `./pre-inst-env guix build gnutls` gives me /gnu/store/by87llzxn9vg5x0wqb0c94svvnr5zc77-gnutls-3.4.7 <jeffers-media>mark_weaver: sure. sorry, how exactly do i check this? i did `set | grep GIF` and a few other permutations <sturm>lfam: I'm a bit of a Guix noob, so am probably out of my depth here <lfam>That commit is the current HEAD of the master branch. If you build Guix from that Git commit, you will ahve the script 'pre-inst-env' which changes your environment to run the Guix you just built. You should be able to download a substitute for gnutls from hydra by building gnutls from that commit <lfam>My /gnu/store has this file in bi5s5f9i0p7ybjr7kzpangnwqan38sma-gnutls-3.4.7-doc <mark_weaver>jeffers-media: can you paste the output of "export" within the "guix environment" shell? <lfam>sturm: But the gnutls-3.4.7-doc that I get by building from my Git checkout is p864h6nn...-3.4.7-doc <mark_weaver>and tell me the "guix environment" command you used? <sturm>lfam: ah, good find, sounds like I may have misread <lfam>I wonder why yours is different <sturm>lfam: So just to make sure I'm following - I grab the guix source from git, then within the source tree, run `./pre-inst-env guix system reconfigure`? <sturm>lfam: great, thanks very much <mark_weaver>jeffers-media: ah, okay. I didn't realize that "guix environment" has started generating profiles. nice :) <mark_weaver>jeffers-media: can you look in /gnu/store/kiglzxz70mhsk4kknqmkzagikjw6g9l2-profile/include and see if gif_lib.h is there? <mark_weaver>can you paste the contents of /gnu/store/kiglzxz70mhsk4kknqmkzagikjw6g9l2-profile/manifest ? <mark_weaver>and what was the "guix environment" command that you used? <mark_weaver>and what was the "guix environment" command that you used? <mark_weaver>it included the "bin" output of giflib instead of the "out" output <mark_weaver>and I guess that might be because in the 'outputs' field of giflib's package definition, "bin" is listed first, which is probably unusual enough that no one noticed this bug. <mark_weaver>well, I'm not familiar with this code, but there seems to be a bug in "guix environment" <jeffers-media>mark_weaver: thanks a bunch for taking the time, taking a look at it too <mark_weaver>jeffers-media: it's getting late here, so I'm going to have to put this down for now. but can you email bug-guix@gnu.orf about this? <mark_weaver>please mention the "guix environment" command you typed, attach a copy of the profile manifest, and mention that the giflib "bin" output was included instead of the "out" output. also mention that the "outputs" field of the giflib package definition lists "bin" before "out", and I guess that oddity is what's causing this bug to express itself. <mark_weaver>jeffers-media: in the meantime, you might be able to work around the problem by prepending "/gnu/store/...-giflib-5.1.4/include:" to C_INCLUDE_PATH after running "guix environment", where the "..." is copied from the output of "guix build giflib" <mark_weaver>you'll need to run that "guix build" command outside of the "guix environment" shell <jeffers-media>mark_weaver: quite tired as well, will do the above in the morning. I was unable to get you above recipe to work. one difference is that i have giflib-5.1.1 <heuuuoui>i planned to install GuixSD today, i thought make a 20GB partition for root, like on my Parabola, will it be enough? ***kelsoo1 is now known as kelsoo
<sturm>heuuuoui: in my experience, 20G root will be tight, go more if you can <heuuuoui>i have a 128GB SSD and a 1TB HDD. No so much place then on my SSD <sturm>it's no heavier than other distros really - I find in Trisquel that 20G starts to get tight for me with large packages like TexLive plus some databases in /var/ plus some room to download new packages. <heuuuoui>if i put my /home on my HDD, softwares that work with files in /home (like config files), will they work as fast as on my SSD? <heuuuoui>in my /home i put everything but videos. <MaliRemorker>i have a 30Gig virtual image of GuixSD, it's comfy enough, so far <frafra>I'm trying to modify my package for guix and when I run guix lint I get a VM Stack overflow error: what I could do? <frafra>my system has not been updated for 2 months and I'm using guix from master <MaliRemorker>i tried to change/create the xorg config file by using something like: (run-with-store .... (computed-file-gexp (xorg-configuration-file ....))) <MaliRemorker>of course it didn't work; so i guess i'm fundamentally misunderstanding the relationship between the Guix REPL and build, or file creation activities <MaliRemorker>why can't i just run any gexp in that run-with-store routine and expect things to get written to the /gnu/store as expected? :) <heuuuoui>is it necessary to create other repository as /home at the partionning step when we have more than / ? Or it is created later with the config file? <MaliRemorker>heuuuoui: i'm only just starting to use guix, but don't you first create all the partitions with a partitioning tool and then define them within the configuration scm file? somewhere in the file-system section? <heuuuoui>MaliRemorker, my question is about mountpoints, but with the option 'create-mount-point' in the config file normally it will be created if it doesn't exist <MaliRemorker>heuuuoui: i only have a simple setup with a single , root mountpoint <heuuuoui>MaliRemorker, i always do a /home partition, in case of reinstallation : ) <MaliRemorker>heuuuoui: and what if you want to go to btrfs system in the future? :) <heuuuoui>MaliRemorker, hmmm never thought about that. <heuuuoui>i guess i can make a backup of my home repository on my hdd and create only a root partition <amz3>héllo, can someone knowledgeable about guix, can try to download an url for me using guix https facility. <amz3>I have something to do that in guile, but it's buggy, I'd like to know if the bug comes from my implementation of gnutls or it's a gnutls bug ***kelsoo1 is now known as kelsoo
<davexunit>civodul: wow, thanks for implementing compression in 'guix publish'! <civodul>davexunit: as i wrote, it turned out to be much easier than i thought <civodul>hopefully we can put it to good use on the new server that Andreas has been setting up <civodul>nice, i'd be glad to hear how well it works for you <davexunit>and I have a chef recipe for building VMs that serves as my benchmark <civodul>do you run it behind nginx or similar? <davexunit>right now the chef recipe takes ~5 minutes to run to completion <civodul>currently it compresses on-the-fly, so you'll want to watch the CPU load <civodul>at low compression levels gzip is pretty fast though <davexunit>I can give the VM more resources if needed, too <Akko_Teru>ACTION civodul and wingo are legendary like steele and sussman <catonano>civodul: ehy, I read youre reply on the help mailing lsit. Now I have to go, I'll be back later tonight. Thank you SO much <davexunit>civodul: do I need to update my guix client to use gzip compressed substitutes? <civodul>davexunit: no, the client should work just fine; however, compression is enabled only if zlib is found <civodul>you can check the "Compression" field of its .narinfo to be sure <civodul>yet those URLs are advertised in .narinfo, right? <civodul>oh i see, that's because zlib isn't found, yet narinfo advertises the /nar/gzip URLs <civodul>the client pipes to the 'gzip' program <civodul>see the top of (guix zlib) for the dynamic-link call <civodul>so you need to change LTDL_LIBRARY_PATH or to rebuild Guix <MaliRemorker>a newby question: when do gexps come into action? can you invoke them directly with store functions in REPL and they write stuff to the store? <civodul>MaliRemorker: you have to use 'gexp->derivation' to turn them into a "buildable" thing <MaliRemorker>mark_weaver: does download also write a minimal package definition? i think i read something like that from the docs <mark_weaver>MaliRemorker: no, but it imports the downloaded file into the store <davexunit>MaliRemorker: packages are just one of the many things that compile to a "derivation" <efraim>the upstream url also isn't valid <mark_weaver>basically, since hydra's disks failed, and we lost its entire store, it's taking a while to repopulate it <mark_weaver>anthk_: you might try again now, or in a few minutes. it might take a bit for the negative cache entry on mirror.hydra.gnu.org to expire <anthk_>guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/izpi9g74jd84l01yy9359l750mc5g2y5-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <anthk_>fetching path `/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0' failed with exit code 1 <anthk_>building path(s) `/gnu/store/3lx2069qdr8m9647qcbp58z7fza6jd08-guile-bootstrap-2.0' <mark_weaver>anthk_: thanks, I see what the problem is, trying to fix it now <catern>hello, #guix! I am wondering what code (input at a guile repl) would do the equivalent of "guix environment", outputting a list of pairs of environment variable/values <catern>I looked at the implementation of guix environment but it seems very complex! surely there is an easy pre-existing function? <mark_weaver>catern: nowadays "guix environment" builds a profile as well, so it's not a simple as just setting the variables. but I don't know that we have something easy that does what you're asking for. maybe ask on guix-devel? <davexunit>catern: you'd want to look at the code in (guix profiles) that can tell you about the profile environment variables <mark_weaver>you might look at 'set-paths' in guix/build/gnu-build-system.scm <catern>(that means I told someone some incorrect information... I said guix environment just output environment variables without anything existing on-disk) <mark_weaver>well, davexunit knows this area better; he wrote "guix environment" <catern>davexunit: mark_weaver: okay, so what i'd want to do is first create a profile, then get the environment variables for that profile? <catern>(if I wanted to encapsulate the full functionality of guix environment) <bavier>catern: have you look at the implementation of 'guix package --search-paths'? <davexunit>'guix environment' is basically a special UI for generating profiles on-the-fly <catern>not yet, but I was just thinking that would be useful, yes <davexunit>and running an arbitrary program within the environment that the profile creates <catern>is the profile deleted after the program closes? <davexunit>in guix, store items are not deleted until the garbage collector is run <catern>sorry, what I meant was, is the profile no longer a root after the program closes? <catern>but what if the gc runs during the program's execution? <davexunit>I'd need to ask civodul, but we keep a daemon connection open for the purpose of protecting the profile from gc temporarily <davexunit>but if not, I just recommend not running the gc. <mark_weaver>the daemon connection is kept open until the spawned program exits? <davexunit>mark_weaver: yes. IIRC, civodul explained that doing so would protect the derivations that we asked to be built. <mark_weaver>actually, this could be a problem when running any program in the store that is not currently protected by GC <davexunit>mark_weaver: I took his word for it, never tested because I only rarely run the GC. <catern>mark_weaver: then maybe the answer is that you should never run a program in the store that isn't protected by GC? <davexunit>you can create symlinks to store items in it <catern>you'd have to manually go to the store and run the program, rather than go through a profile <catern>no no, I meant "run a program without it being protected", not "protect something from GC" <mark_weaver>it's only writable by root, but you can create a symlink in there to another directory for your per-user gcroots <mark_weaver>catern: you can run programs directly from the store, e.g. type /gnu/store/.../bin/foo at the shell <catern>yeah, indeed, but maybe you shouldn't? <mark_weaver>also, while a long-running program is running from you profile, you could update your profile and then delete the generation that contained the program currently running <catern>because it could be garbage collected away from you at any time <davexunit>catern: but you are in control of when the gc runs <mark_weaver>maybe there is some magic in the daemon that detects these things. it could use the equivalent of lsof, for example <catern>mark_weaver: oh, yeah, that's even more interesting... <davexunit>so, if you understand the risks, then why not? <efraim>I use it for testing new programs mostly <davexunit>I don't like rigid rules like "never run stuff from /gnu/store" <catern>just kind of academically concerning <mark_weaver>actually, I do have some recollection of seeing guix-daemon use lsof <catern>anyway, the reason I ask about all this is because I'm working on supporting guix environments in Emacs <catern>which would not be a child process of the "guix environment", so I'd need to just open my own connection to the daemon to keep the on-the-fly-constructed profile alive <mark_weaver>catern: as a hack, you could use "guix environment" to run a program that simply prints out the environment variable settings. <mark_weaver>you could even arrange to leave the program running until you no longer need the environment <mark_weaver>so, the program could print the environment variables, and then wait for a command to exit <davexunit>I remember hearing that emacs has a way to do an "environment excursion" <catern>mark_weaver: oh, true, I could just keep the guix-environment-child-program running, yeah <catern>davexunit: oh? I have not seen anything like that! that is very interesting to me if you remember any more. <davexunit>for me, I'd like to be able to manage multiple environments in emacs <davexunit>and do things like run arbitrary elisp in the context of the environment <catern>currently my planned implementation (the result of a little consultation on emacs-devel) unfortunately ties each environment to a directory on disk (a project) <davexunit>that would move more of my workflow back into emacs <davexunit>right now I create an environment in my terminal, and then run 'guile --listen' to make a repl server <catern>anyway, to start off with I won't do any of the profile-construction stuff, and will instead just enter a user-specified profile <catern>davexunit: couldn't you run guix environment [some args] --- guile --listen? just curious <davexunit>my point is that I wish emacs would just do it <catern>I'll report back with my progress :) <MaliRemorker>where are all the guix modules stored in an installation? <Kooda>MaliRemorker: you have a link to them at ~/.config/guix/latest <MaliRemorker>Kooda: thanks! is this mentioned anywhere in the docs yet? <MaliRemorker>i think i've got a case of documentation-blindness by now :) <Kooda>I… don’t know. I think I found that by accident. <Kooda>By doing guix edit maybe, I can’t remember. <MaliRemorker>my approach to finding anything structural for the moment is "find /gnu/store command pattern" <Kooda>Heh, I use that as well. /o\\ ***lumidify_ is now known as lumidify
<frafra>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <frafra>why is that? /var/guix/daemon-socket doesn't exist, but the systemd service is on <avoine>frafra: what about /var/local/guix/ ? <frafra>I'm trying to reinstall guix on Fedora 24 <frafra>avoine, yes, and when I try to run guix archive I get this error: warning: failed to install locale: Invalid argument <frafra>avoine, no, but I'm trying to reinstall it, so maybe there are some files left; I tried to remove everything, but this unix socket is missing <avoine>frafra: maybe you left the ~/.guix-profile directory <avoine>but that would not explain the socket missing <rekado>about the prince of persia reimplementation: the legacy levels are the originals, but they are not needed to use mininim. <rekado>so I think removing the files is all that’s needed here. <rekado>I find it a bit difficult to understand the rules here. <rekado>obviously the goal here is to produce something that has at least the same features and style as the original. <rekado>it looks just like the original — when the images are the same, pixel for pixel, does it mean this is a derived work? <rekado>if someone sat in front of the original game, froze the frame, and then redrew the pictures in gimp — would it be any different from extracting the images from the original binary? <frafra>avoine, no, I tried to remove everything again, same error <rekado>frafra: the warning is not an error. <rekado>frafra: the socket file is created by the daemon. <mark_weaver>rekado: if the images are the same, pixel for pixel, I don't see how it wouldn't be considered a "derived work", or even simply copied. <rekado>mark_weaver: I think so, too. After going back and forth on this I think it should not be part of Guix. <rekado>but if they are derived from the original game we cannot assume that the license actually gives us permission to copy and redistribute. <mark_weaver>the requirements for non-functional data is much less stringent than for functional works (e.g. code and documentation) <mark_weaver>rekado: right, if the original copyright holder didn't grant those permissions, then we can't have it in guix <rekado>“It can be included in a free system distribution as long as its license gives you permission to copy and redistribute, both for commercial and non-commercial purposes.” <frafra>rekado, the systemd service is up, but the daemon is down... something is not working as expected; if I run ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild it works <rekado>frafra: does journalctl tell you anything about the service? <rekado>(there is no practical difference between running the command directly and using the service) <frafra>ExecStart=/gnu/store/3g6zn8y5sfwywr4pqiwqrab735a0x4zl-guix-0.10.0/bin/guix-daemon --build-users-group=guixbuild (code=exited, status=203/EXEC) <rekado>“As the author and copyright holder of this source code, I personally have no problem with anyone studying it, modifying it, attempting to run it, etc. Please understand that this does NOT constitute a grant of rights of any kind in Prince of Persia, which is an ongoing Ubisoft game franchise.” <mark_weaver>rekado: that doesn't look promising. note that he doesn't mention whether he has a problem with redistribution, but also the disclaimer at the end sounds troublesome as well. <rekado>so I think it takes someone to ask for explicit permission. <rekado>given that the game can be played in the browser at archive.org maybe it won’t be hard to get permission. <mark_weaver>the permission would need to be something solid enough that it would hold up in court if they changed their mind later <mark_weaver>and the permission would need to be granted not just to the Guix project, but to anyone else who got a copy directly or indirectly <mark_weaver>civodul: can you help me add /gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0 to hydra's store? <mark_weaver>it's the patch for coreutils, and apparently the .narinfo is on hydra but not the .nar, so it's causing "guix pull" to fail for at least one person here (anthk_) <jeffers-media>mark_weaver: btw, tried preprending giflib to C_INCLUDE_PATH to no avail. paste of export if youre interested: paste.lisp.org/+6VJV <mark_weaver>jeffers-media: I later realized that you'll need to prepend something to LIBRARY_PATH as well: the same thing but with /lib at the end instead of /include <bavier>I'm getting a 550 error for texlive's source <mark_weaver>civodul: the file is sitting in hydra's home directory <mark_weaver>I just can't seem to add it to the store with that file name. <bavier>it looks like they did a sort of inplace upgrade at ftp://tug.org/historic/systems/texlive/2016/ <bavier>the -source and -texmf tarballs have a "b" version suffix now <mark_weaver>bavier: 550 when trying to fetch from upstream, or from hydra? <mark_weaver>bavier: if they added a 'b', I would call that a version number bump, not an inplace upgrade. <bavier>mark_weaver: well, inplace, in that the old tarballs aren't available <civodul>mark_weaver: the file is now in the store, but i think we cannot download it as a nar because of the '?' <mark_weaver>oh, hmm. anthk_ reported here that "guix pull" fails, trying to download that substitute <civodul>i just added it to the store, so probably it wasn't there before <jeffers-media>mark_weaver: that didn't work, but now im thinking it might be the wrong giflib. after `guix build giflib` i get two store entries, one with ...giflib-5.1.1 and another ...giflib-5.1.1-bin. the have different ... <mark_weaver>jeffers-media: those are two outputs from the same package. you want the one without "-bin" at the end. <mark_weaver>jeffers-media: insight will be gained from looking at config.log again <mark_weaver>jeffers-media: ah, I see, the prefix you added to C_INCLUDE_PATH starts with "/gnu/store/gnu/store". doubled <mark_weaver>civodul: there are several .narinfo files with no corresponding .nar files, in the caches I guess. I wonder if we could purge those. <mark_weaver>or maybe better to generate a list and repopulate the store <mark_weaver>(I finally updated my i686 GuixSD system, but still running into issues trying to upgrade my user profile) <mark_weaver>the issues being .narinfos with no corresponding .nars <civodul>we could purge the narinfo cache on mirror.* <mark_weaver>it will lead to a lot of load on hydra for a while if we do it wholesale like that <civodul>so maybe just on mirror.* to be begin with? <civodul>hydra doesn't cache narinfos for too long, IIRC <mark_weaver>speaking of which, I've noticed that hydra does perform a *lot* better now than it did, but the load still spikes sometimes when someone is downloading a lot of stuff that's not cached. <mark_weaver>I increased the maxconcurrent on a bunch of things because the load was low, and then it eventually went up to 22 so I changed them all back <mark_weaver>civodul: anyway, maybe you're right, maybe clearing the entire .narinfo cache is the way to go <mark_weaver>even if we have to stop the queue-runner for a while, it might be worth it in the short term, for the sake of our users :) <mark_weaver>hmm, well, except for the builds that are recorded as being done according to the postgresql database, but no longer in the store. <mark_weaver>but users having to locally build things is better than them getting fatal errors <Steap>civodul: yeah, see my comment <mark_weaver>civodul: chapters.gnu.org ran out of disk space while trying to build 'font-adobe-source-han-sans'. I was trying to build it on hydra to populate the missing .nar <Steap>gotta fix that function, but it is a bit of a pain because of the multiple URL schemes we have to support <davexunit>is it just me or are we seeing a lot of new contributors lately? <mark_weaver>civodul: the ENOSPC happened while trying to register the GC root, I think. <mark_weaver>guix offload: error: failed to register GC root for ... <mark_weaver>ERROR: In procedure symlink: No space left on device <mark_weaver>davexunit: last I checked openhub, it said we had almost 100 contributors in the last 12 months <civodul>we need people to absorb the patch stream ;-) <civodul>mark_weaver: running the GC now on chapters <bavier>the patch stream killed my inbox a few weeks ago already <mark_weaver>I wonder if we should make another mailing list for devel-related discussions+patches for things other than new packages. <mark_weaver>I confess I've given up on keeping up with the devel mailing list. I rarely even look anymore. it's too much. <davexunit>hmm, separating packages from other things might help. <davexunit>I scan subject lines and selectively look at things that seem to be in my wheelhouse <civodul>separating packages could help, but i fear nobody would look at them ;-) <frafra>I initialized my guix system with guix system init <civodul>frafra: you should be able to run "chroot /path/to/guixsd/root /gnu/store/path-to-bash/bin/sh" <catern>so... are there any search paths that actually *don't* use ":" as a separator? <catern>because I see that the search-path-specification struct-thingy has a separator field... but it's ":" in all of my variables <catern>also, I recommend using gmane to keep up with fast mailing lists :) <bavier>catern: I think there's one package that uses a space character <catern>anyone familiar with the guix Emacs interface? anyone know whether it's possible to do a completing-read with the "list of available profiles"? <catern>(i.e. to provide an interface to interactively choose from a profile) <bavier>rekado: weren't you working on a recursive cran importer? <rekado>bavier: yes, I’m currently reworking the patches. <rekado>and I want to generalise this to be used by other importers. <rekado>needs a little more time. Work was too busy last week. <rekado>and next week I’ll travel… I hope I can send a revised version of the patch set soon. <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs 