<mray[m]>civodul`: why doesn't inkscape show up there?
<Apteryx>Hi! I'm adding python as a native input, but still getting: patch-shebang: ./test/rule-syntax-check.py: warning: no binary for interpreter `python' found in $PATH. This is because the python package provides "python3" but not "python" in the PATH.
<Apteryx>Probably switching to python-wrapper instead.
<Apteryx>sneek: later tell alezost: what variables do I need to configure guix-emacs so that M-x guix e edits files from ~/src/guix instead of from ~/.config/guix/latest/... ? I've followed the doc and used (setq guix-guile-program '("~/src/guix/pre-inst-env" "guile")) as well as (setq guix-repl-use-latest nil). "~/src/guix" is also in my load-path: (add-to-list 'geiser-guile-load-path "~/src/guix")
<Apteryx>(setq guix-guile-program '("~/src/guix/pre-inst-env" "guile")) doesn't seem to add ~/src/guix to the %load-path of the Guile REPL spanned by M-x guix. Is this normal?
<Apteryx>oh wait, it does. But guix/latest appears before, so I really had to use: (setq guix-repl-use-latest nil)
<sadiq[m]>when I run evolution-calendar-factory, I get the following error:
<sadiq[m]>./evolution-calendar-factory: Relink `/gnu/store/b9ww6qv1ii9v6n45kin7543vkf6jfnd3-libpng-1.6.29/lib/libpng16.so.16' with `/gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'./evolution-calendar-factory: Relink `/gnu/store/1jp44pfmqcj3zycclvmmva3xcwinyg7l-freetype-2.8/lib/libfreetype.so.6' with `/gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libpthread.so.0' for
<sneek>alezost, davexunit says: I got the email but I haven't been able to look at the issue yet, though I can say that where compiled guile modules are supposed to go has never been clear and I copied from other devs.
<sneek>alezost, Apteryx says: what variables do I need to configure guix-emacs so that M-x guix e edits files from ~/src/guix instead of from ~/.config/guix/latest/... ? I've followed the doc and used (setq guix-guile-program '("~/src/guix/pre-inst-env" "guile")) as well as (setq guix-repl-use-latest nil). "~/src/guix" is also in my load-path: (add-to-list 'geiser-guile-load-path "~/src/guix")
<sneek>alezost, Apteryx says: nvm, I found it in the doc: (setq guix-directory "~/src/guix")
<alezost>Apteryx: hi, did you figure out those emacs-guix settings, or is there anything unclear?
<nee``>Hello, thanks everyone for fixing the boot-parameters bug. I pulled and reconfigured and everything is working again!
<pmikkelsen>when updating many packages (such as the haskell packages as i am working on right now), is the preferred way to send a patch for each update? or is it normal to send a patch updating all the packages, and a patch fixing all the inputs and so on
<civodul>pmikkelsen: it may be that upgrades depend on each other, and thus that would be a single patch
<civodul>i personally wouldn't mind a massive upgrade, as long as it's well tested
<sadiq[m]>Hi. why does 'guix gc' remove guix bootstrap binaries? can I make it not to?
<thomasd>civodul: pedagogical post, I learned a thing or two :). Are the namespaces actually essential, or could one build a “poor-man's guix” relying only on chroot and setuid?
<Apteryx>alezost: what worked for me was to define guix-directory but also to add the git checkout to my load-path with 'geiser-guile-load-path (I just want this in Emacs, not system wide).
<Apteryx>sneek: later tell alezost what worked for me was to define guix-directory but also to add the git checkout to my load-path with 'geiser-guile-load-path (I just want this in Emacs, not system wide).
<Apteryx>sneek: later tell alezost Otherwise setting (setq guix-guile-program '("/home/maxim/src/guix/pre-inst-env" "guile")) *and* (setq guix-repl-use-latest nil) also worked, but only from M-x guix commands, not say, when using the shortcuts from guix-devel-mode such as "C-c . b". This happens because those use a second REPL which must be manually started; I usually start it using C-c C-a from the module. When doing
<Apteryx>sneek: later tell alezost Also, when using guix-devel-mode, it seems that I need to recompile the module containing the package I'm working on with 'C-c C-k' before I can rebuild it with C-c . b, this is time consuming.
<Apteryx>I wonder what would be the better approach... Symlink all those binaries in /bin or patch shells so that they do process the shebang line specially... 1st option seems simpler, no? I'm not embarking on a quest, just brainstorming ;)
<davexunit>jonsger: I had an argument on the #gnu channel where someone told me that using a static site generator for my blog was stupid because I should be using a makefile that adds header/footer html to pages or apache server side includes instead.
<Apteryx>civodul: on another matter, do you successfully use emacs-guix to interactively develop packages? I'm close to having it working well, but fail somewhat. There doesn't seem to be a way to run Geiser REPLs with the pre-inst-env script.
<Apteryx>Thanks for sharing. It's a shame that there's an easy way to configure Emacs-Guix REPL to use pre-inst-env but not for Geiser (for Emacs-Guix, you can set this in your .emacs: `(setq guix-guile-program '("/path/to/guix/pre-inst-env" "guile"))')
<Apteryx>OK. So you probably noticed something similar to what I'm seeing; upon changing the description of a package, if I simply do 'C-c . b' to rebuild it, it rebuilds the last *compiled* version rather than the newly changed source version.
<Apteryx>So I keep having to C-c C-k to tell Geiser "compile that again".
<Apteryx>(a quick test would be messing the hash of a package and rebuilding it with "C-c . b". if it builds without errors, we're in the same boat)
<Apteryx>I think you probably have "(setq guix-repl-use-latest nil)" too. Otherwise it puts ~/.config/guix/latest earlier in your %load-path.
<Apteryx>(unless you retargetted that symlink to ~/src/guix, i.e., you don't use guix pull)
<civodul>Apteryx: use "C-c . u" instead of "C-c C-k"
<sadiq[m]>ok. I'm trying to package gsound. I added the package using define-public, and when I insteall (guix package -i) several files (like .a, .h) are present in .guix-profile instead of just gsound.pc
<elc79>GuixSD it's very very very very slow to install, really annoying
<elc79>my question is... i will see this running or i will run out of desperation?
<civodul>elc79: you should definitely be getting binaries for most of the things you install
<civodul>if you email firstname.lastname@example.org with enough details, we should be able to investigate
<civodul>but we really need to more about exactly what you're doing
<cehteh>civodul: happens for me often enough that i dont get binaries as well, imo guix pull should be somewhat staged (head, nightly, devel, stable)
<elc79>well, i'm on a vm of virtualbox, one core, 1,5g of ram, 17g of disk.. trying to install GuixSD with an Xfce4 DE...
<elc79>this takes 30 minutes on Trisquel, but i'm here with nothing after two days...
<cehteh>and compiling (esp the guile stuff) on a old netbook i have here takes ages. i just start it and then look at it few days later
<cehteh>sad but true, but many things in guix are way to slow
<elc79>i know Guix is a beta, but this is very bad.
<civodul>i think this has already been said :-), but this is a serious problem, and one we're working on
<elc79>Why i waited for one whole day to get the last packages and i don't have binutils binaries? It's compiling that stuff right now.
<cehteh>possibly because the 'pull' got the latest head and the buildfarm building the packages lags behind
<elc79>wow, next time i'll try linux from scratch lol
<cehteh>thats what i saied above, pull should have some staging and at some point (nightly or devel and beyond) the distribution servers should enforced to have packages else the stage isnt bumped to the next level
<cehteh>to my understanding (maybe not correct) the build infrastructure on the server still lacks some resources, old packages are garbage collected new ones are not availabe early enough
<cehteh>so you often get packages on the wrong foot, too old, too new, not there yet
<elc79>tell me if i understood well... 0.13 distro don't works due this old packages and the new packages are not compiled?
<cehteh>i dont know if the 0.13 packages are pinned (kept available) i hope they are! .. but when you 'guix pull' you leave 0.13 land
<rekado_>elc79: we are *constantly* building packages, because of updates
<rekado_>substitutes for the last release should be available
<cehteh>it would be really nice to have some semi stable heads with pinned packages, even for a rolling distro
<elc79>i did this because the original 0.13 install stopped too early
<sneek>alezost, Apteryx says: what worked for me was to define guix-directory but also to add the git checkout to my load-path with 'geiser-guile-load-path (I just want this in Emacs, not system wide).
<sneek>alezost, Apteryx says: Otherwise setting (setq guix-guile-program '("/home/maxim/src/guix/pre-inst-env" "guile")) *and* (setq guix-repl-use-latest nil) also worked, but only from M-x guix commands, not say, when using the shortcuts from guix-devel-mode such as "C-c . b". This happens because those use a second REPL which must be manually started; I usually start it using C-c C-a from the module. When doing
<sneek>alezost, Apteryx says: Also, when using guix-devel-mode, it seems that I need to recompile the module containing the package I'm working on with 'C-c C-k' before I can rebuild it with C-c . b, this is time consuming.
<alezost>Apteryx: right, emacs-guix variables don't (and shouldn't) control the behavior of a general Geiser REPL, so setting `geiser-guile-load-path' is the correct thing (I prefer to set GUILE_... environment variables though).
<alezost>Apteryx: As for "C-c C-k", I never use it; I use "C-c . u" instead (it is much faster AFAICT). Anyway using a guile module in one way or another is needed, otherwise you can't work with this module in Geiser.
<alezost>And when you are working with the package definition using Geiser, you can re-evaluate it with C-M-x
<alezost>Apteryx: BTW `geiser-guile-binary' can be a list as well, so you can set it to '(".../pre-inst-env" "guile") or whatever
<Apteryx>alezost: OK! Thanks for the hints. Does it matter how I start Geiser? C-c C-z, C-c C-a, run-geiser, etc., which one do you use?
<sadiq[m]>how can I search for a package that provides some binary, say like I need to find the package[s] that provide the binary gnome-shell (say, for example)
<alezost>Apteryx: I use C-c C-z, but there is no difference
<rekado_>sadiq[m]: you cannot. This would require a central service that builds all packages and then indexes their files.
<alezost>sadiq[m]: the only way is to search in your store (like: "find /gnu/store -name ..."). If you don't have a package with that binary in your store, then you can't find it, I'm afraid
<rekado_>sadiq[m]: the build farm could do this, but we wouldn’t want to tie Guix to any server.
<sadiq[m]>hm.. found the file. My guess was right. :)
<sadiq[m]>with magit or diff-hl is there a way to create a git commit with hunks in the active region only (the other changes in the same file shall be left uncommitted)
<sadiq[m]>eh, I get No space left on device, while I still have 6.3 GiB free
<ng0>oh speaking of 90s.. I had an 2 hours chat in university today with an entrepeuneur/businessman who studied computer science back in the 70s.. talked about stuff, mostly the two sides we are on (him proprietary financial success based software etc, me in for ideals and ideas etc) and difficulty of financing projects in the long-run. also about GNU stuff, and I've got the impression he didn't even know GNU or
<ng0>that Linux went anywhere ("hasn't been in the press for a while") :O fascinating.
<ng0>businessmantypeperson: in case you should read this: sorry I was just internally a bit confused by those facts as I'm using GNU for almost 20 years now *on desktop* in the *decades of the GNU Desktop*
<janneke>...and neither have some other beautiful things
<ng0>as an anticapitalist it was quiet interesting to meet someone who thinks that everything needs to be profitable. He was nice. I've only met such capitalist focused personalities 2 or 3 times before and the other ones were a nightmare I couldn't stand very long talking to.
<ng0>It's very funny for me to use German terms, even if I still end up using 50% english terms, in a conversion for topics I talk about more often in english. Like "Quelloffen". Last time I heard, nay, read, Quelloffen was in one of the Linux Magazines wayy back (meaning something like "the sourcecode can be read (freely)")
<cehteh>methinks first of all guix has already way to much issues to fix before reaching farther
<Apteryx>I can't use substitute* in a snippet when I need to substitute an input, right?
<Apteryx>cehteh: Emacs is a good example of GNU running on Windows
<Apteryx>And it's raison d'être is worded as a gateway to FOSS on the Emacs website, IIRC.
<cehteh>back in times (NT3.51?) microsoft released a resource pack which included a posix subsystem with gnu tools
<cehteh>now they have a even more functional posix/linux subsystem and much of the hostility against free software is gone
<cehteh>i dont want to be pessimistic about this ideas, i just feel that guixsd is still slow and hard to use, and binding developer resources to make it work on windows wont benefit the project as much. but thats my opinion, just as user/lurker here, if anyone picks that idea up and works on it no one would stop him/her
<dustyweb>cehteh: I didn't say it was something we should dedicate efforts to
<dustyweb>cehteh: though if someone wants to that's fine
<dustyweb>cehteh: I was just asking/wondering about feasibility, if anyone has treid.
<cehteh>i have currently the problem that i would like to have some 'somewhat windowish' development environment to compile and test some software, tried reactos in kvm which just doesnt work pretty stable
<cehteh>some time ago i had some success with mingw crosscompiling and testing under wine
<rekado_>I don’t think it’s accurate to say that Guix is “still” slow; this is a recent regression and it’s one that people are currently working on.
<rekado_>davexunit: so, if GNU packages can choose to use something other than CVS … why do we still bother with CVS? Surely this means that we would have to host the site ourselves?
<cehteh>rekado_: i dont see it negatively, just a bit critizm and i know that people work on it, i admit i am a bit pessismistic and delusioned so far, but i am here (since some time) and i wont give up on guix
<rekado_>cehteh: heh, I appreciate the clarification.
<rekado_>cehteh: I just want to avoid having #guix fall into frustration
<cehteh>i suspect a lot people have the experiences i have (being slow, not easy to grasp) and i feel these things should be handled with utter priority, because many people dont have patience, when it fails they wont give it another chance anytime soon
<rekado_>fixing the speed and memory problems we have with “guix pull” are very important to us; alas they are to be fixed in the Guile compiler and that’s an area that few of us are equipped to understand.
<janneke>cehteh: what do you mean exactly by `guix is slow?'
<cehteh>2 or 3 years ago i thought "oh guix is awesome, people add new package in a constant inflow, looks easy to package for it, cool features" .. but whenever i try to do something it feels like i am stuck in some molases
<davexunit>rekado_: yes, you would have to host it yourself.
<cehteh>janneke: guile compilation for once, grasping scheme for another, having a rather 'alien' system adds to the point and also because of favor of gnu tools (lsh instead openssh for example) there are just a lot hurdles
<davexunit>"you don't *have* to use CVS, you can use whatever you want! (if you use another web server)"
<ng0>though this is just to make intermediate scripts work, for the real deal I have a guix-install.scm which makes use of a Makefile and installs the scripts I need into $out/bin etc, giving me the correct shebangs all the time ;)
<ng0>2 virtual full CPUs and 4 GB RAM where 3.7 of it can be used up by 'guix pull' would in theory be enough to make guix pull succeed, or does someone have contrary experiences? With full dedicated, physical, CPUs I had 3 GB RAM and it was enough. The last time I tried pull on the second server 2GB RAM wasn't enpiugh.
<ng0>the virtual CPUs are with KVM on Xen hypervisors iirc