<mray[m]>strange - looks like there is no blender. also no inkscape (which I installed, too) - but the program "hello" is there <civodul`>"guix package --list-installed" will tell you what's installed <civodul`>don't confuse "guix build", which just builds, and "guix package --install", which actually "installs" <mray[m]>civodul`: aha - so that is probably why i don't see belnder here! <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>sneek: later tell alezost: nvm, I found it in the doc: (setq guix-directory "~/src/guix") <Apteryx>sadiq[m]: I think because rebase would break the pgp signatures on the commits. <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 <brendyn>Can one use `alsactl store' on guixsd? <cbaines>Going ok. I love that there's now a vcsh package, I can tick that one off my list, and I didn't even have to do anything! <cbaines>Also, I submitted a talk about Guix to a conference in Bristol/UK called Freenode live, and it got accepted :D <civodul>i think John Sullivan of the FSF is giving a talk there, no? <cbaines>It's in just over a month, so plenty of time <sneek>alezost, you have 3 messages. <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? <civodul>jonsger: right, i think it's a bug in guile-commonmark, that's weird <rekado_>civodul: should we add a “jobs” section? Or should I just add it to the “Join us!” section? <civodul>rekado_: we could add a "Jobs" section, if we have at least two offers :-) <rekado_>ACTION created a separate xxd package, rebuilds dependent packages <civodul>it's true that building all of Vim just for xxd is a bit of a sledgehammer <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 <civodul>but we'll have to see what others think <mekeor>pmikkelsen: cool! so, you're working on upgrading haskell packages? <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>so it doesn't use guix-guile-program. <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. <thomasd>htgoebel1: for now, there's no way but to manually remove /var/guix/profiles/system-n-link <htgoebel1>thomasd: IC Thanks. I thought I have overlooked something <mray[m]>when i install software (teeworlds in my case) and it does not start - where would i file a bug report? <mray[m]>a second question would be: isn't an install supposed to create .desktop files for the respective package? ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://guix-hpc.bordeaux.inria.fr/'
<Apteryx>What's the way to do a proper shebang for e.g. bash in GuixSD? #!/bin/bash doesn't exist. <Apteryx>OK, maybe #!/run/current-system/profile/bin/bash <civodul>ACTION embarks on a fight against CVS-controlled GNU web pages <civodul>the perfect fruitless troll for a Friday afternoon <davexunit>civodul: remember that time I was an FSF employee and GNU webmaster and I proposed a change and everyone said no? good times. <davexunit>I couldn't even convince people that apache server side includes were bad. <civodul>though i couldn't name you in my message ;-) <jonsger>the "ultraconservative" side of software developement :P <civodul>at this point it's not even conservative, it's wasteful IMO :-) <civodul>(it's about gnu.org sysadmin, not actual software development) <Apteryx>But isn't it bad practice to conflate #!/bin/sh with #!/bin/bash? <Apteryx>(If I'm using bash specific extensions, say) <civodul>but then it depends on what you're doing <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. <davexunit>and they insisted that a makefile that adds header/footer html was *not* a static site generator <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>davexunit: thanks for that. Any way to automate these things into the usual C-c C-z or C-c C-a convenient Geiser shortcuts that start/switch to the REPL? <davexunit>but I just run that to start the REPL and then C-c C-a works as normal <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"))') <davexunit>if there is maybe it can be buffer local and set from a .dir-locals.el file so it "just works" <Apteryx>I checked the sources, I found I can configure this: geiser-guile-binary, but it doesn't seem to accept arguments <davexunit>I usually use the REPL for things other than guix like games where I first start the game and then connect over a tcp socket. <davexunit>Apteryx: make a 'guix-repl' executable script that does `exec ./pre-inst-env guile $@` <Apteryx>I was trying this earlier and it failed misteriously, but relaunching Emacs seems to have resolved it. I'll experiment some more. Thanks! <civodul>Apteryx: i do use emacs-guix, i customized a couple of variables so that it uses my Git checkout <civodul>mostly (setq guix-directory "~/src/guix") <Apteryx>Right, this one helped to make M-x guix e (edit) find the right sources. <civodul>and also adding ~/src/guix to geiser-guile-load-path <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" <civodul>it's documented in the emacs-guix manual <Apteryx>oh, OK. I'll read the fine manual then! <sadiq[m]>A library that would use glib will go to gnome.scm, right? <davexunit>civodul: I'm writing a follow-up to your post about rsync-over-ssh <davexunit>I've had feelings that I didn't feel comfortably expressing 3 years ago that I feel very comfortable with expressing now ;) <civodul>sounds like we're going to have fun :-) <civodul>sadiq[m]: if it's part of GNOME, gnome.scm sounds like the right choice <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 <sadiq[m]>eh, why do commit message titles end with a period? <civodul>gnu-build-system doesn't pass "--disable-static" by default, which is why you get .a files <civodul>you can add it as #:configure-flags if you think it makes sense <civodul>as for .h files, that's because by default packages have a single "output" where "make install" puts everything <sadiq[m]>civodul: hm.. Thanks shall submit soon. My first contribution :) <civodul>double-check with 'guix lint' and all, but at first sight it's perfect :-) <davexunit>aaaaaaand of course someone responds with a justification for the current system <civodul>davexunit: yeah, maybe don't reply right away, for your own sanity ;-) <davexunit>I won't be replying for at least a day, if at all <elc79>Hi guys, so... basically i'm here after a whole day of "guix pull", yes, one whole day... <elc79>and now "guix system init" is on, checking a lot of things, i don't know if is checking to compile binutils... <elc79>i expected to work with binaries :-\\ <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 help-guix@gnu.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>Welcome back alezost, you have 3 messages. <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 <roptat>sadiq[m]: maybe the device is /tmp? <sadiq[m]>may be I didn't get that. /tmp is shared with /. and my / has about 6 GiB free. <civodul>davexunit: the CVS thread is "a success" :-) <davexunit>ah, using a version control system for rollback of build artifacts! why didn't I consider this incredibly important use-case that isn't at all at odds with the intent of version control? <davexunit>"no one uses cvs" "I read everything literally, and since netbsd is still using cvs that means that someone is still using it and you are wrong" <davexunit>didn't realize the benchmark for modernness was what netbsd uses. <davexunit>they are all reinforcing my point that this part of gnu is toxic <civodul>let's hold a referendum on Oct. 1 among package maintainers to see who's in favor of CVS <davexunit>civodul: cvexit? cvs-exit? okay this is too hard to turn into a brexit joke <ng0>what are you talking about? <civodul>ACTION is sympathetic with the people of .cat <davexunit>the thing about internal gnu stuff is that it's terrible. make a proposal to get gnu out of the early 90s and you will be met with resistance. <ng0>ah. yeah I can imagine <davexunit>and now the conversation has gone entirely sideways, people arguing about cvs vs. git when really the proposal is using rsync-over-ssh <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>GNU hasn't been in the news much, lately <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>s/everything/every software project <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)") <bavier`>I've heard "source available" be used <ng0>ACTION is curious about the Java classes and the language used there <ng0>lost in translation ;D <bavier`>ng0: I do like "Arbeitsspeicher" better than "memory" <ng0>English as the implied lingua franca has its problems, but some German words and description are real akward^^ <ng0>It speichers your Arbeit :) <ng0>what is it in French? Been a while since I've used computers set to French. <ng0>like 10+ years a while <catonano_>in Italian we have "disco fisso" but it' s considered awfully uncool <ng0>I've seen a very rare number of job offers still using the term "EDV" or "Elektronische Datenverarbeitung" here. It used to be a thing in the late 90s I think. That's considered not cool here now <dustyweb>out of curiosity, has anyone tried running Guix's package manager on Windows using the WSL? <dustyweb>cehteh: I don't but I know people who do <dustyweb>it would be amusing if guix as package manager would become the mac ports of windows <dustyweb>might be good incentive for people to become exposed and transition to guixsd <cehteh>i doubt thats the intention behind the guix project <dustyweb>though free software generally has supported the idea of running free software on nonfree systems as a way to encourage people to become acclimated to FOSS enough to transition <cehteh>dunno, some gnu people may be upset by that :D ... <ng0>it's not the primary intention, but it can enable this, which is cool <ng0>you are free to do it if you happen to figure out how imo <dustyweb>which is it could help "guix environment" become the de-facto way to set up a dev environment <ng0>being able to run GNU software on Windowds? <cehteh>otherwise, it may work, dunno about guix-daemon, namespaces and such tricks for the store, but iitc it can on crippled systems as well <cehteh>but i suspect that windows users dont want the ful blown "free software only package manager" but some more batteries included stuff including some non free things <cehteh>you have already some options for that <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>someone has to do it, it wont happen magically <dustyweb>I know... I was asking if someone tried :P <cehteh>i cant remember anyone (on the ml) <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_>cehteh: I think your negativity about Guix and GuixSD is misplaced. <rekado_>there are specific problems with a particular version of Guile that give us some headache <Apteryx>sneek: later tell alezost: I got my emacs-guix flow working much better now, thanks! Is there a way to keep a failed build artifact after running 'C-c . b'? <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 <Apteryx>sneek: later tell alezost: seems one way is to recall the last call at the REPL and add the argument needed, like so: (guix-command "build" "-K" "eudev"). <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)" <cehteh>there is some way to high entry barrier <rekado_>davexunit: at that point I do wonder about what makes GNU a *project*. <cehteh>esp if one just wants to have a easy usable system to do some work <janneke>cehteh: i see some barrier...and guix pull is slow, other than that guixsd is identical in speed to other GNU/Linux distros? <davexunit>I kind of dislike GNU as it stands right now. I like some GNU projects (Guix and Guile are fantastic!) but as a whole GNU needs to get it's shit together. <davexunit>Guile 2.2 compiles way too slowly, that is true. <davexunit>but I think that will get worked out eventually. guix is a good use-case for improvements to guile like that. <janneke>rekado_: i don't think opennssh works with guix offload? <cehteh>rekado_: its not about 'we have' ... sure we have a lot, and meanwhile it is as easy to use openssh as lsh, but the initial documentaiton was in favor of lsh <davexunit>cehteh: that was done because ludo wanted to use a GNU tool over a non-GNU tool. but I think it's clear to everyoen at this point that openssh is the way to go. <elc79>there is any order on packages installation, now is installing llvm :-\\ <rekado_>elc79: I think the first system demo was released in September 2013. <cehteh>yes i meant the mindset, not the lsh/openssh case specifically, guix is strange/foreign on too much ends for a 'causual user' <rekado_>elc79: what do you mean by “there is any order”? <cehteh>and i dont think that lsh is bad, actually it has some nice features, but it just works way different than one is acustomed from openssh <janneke>davexunit: yes, that's pretty weird though: having a GNU tool that sucks <elc79>i see guix system init installing package after package, but i don't know how long this is :-\\ <rekado_>janneke: we’re using openssh on berlin.guixsd.org and its 11 build hosts. <elc79>rekado_: i see guix system init installing package after package, but i don't know how long this is :-\\ <janneke>rekado_: good, i'll have to try again <Apteryx>elc79: It's good to guix pull/update overnight ;) <cehteh>yes recently ofloading works with openssh (i mean prolly it always worked, but its so hard to figure out how to set that up in a way that it works) <rekado_>janneke: feel free to take inspiration from the hydra configuration in the guix-maintenance repo. <dustyweb>janneke: I'm not sure that it "sucks" as much as it's not actively worked on <dustyweb>and we should probably trust our ssh'ing to a project with more careful review :) <elc79>damn, i want to see this thing working <cehteh>well my new server is broken i am waiting for a replacement cpu so i havent done any guix things in the last weeks <Apteryx>it seems lsh is more paranoid about security than openssh, based on my limited use of it. <davexunit>janneke: it worked well enough to seem good initially, but then you notice oddities and missing features. <elc79>no, now no more compilings, it's installing binaries :-D <davexunit>when lsh works it works well, but it doesn't get attention like openssh does. <janneke>dustyweb, davexunit: yes i think i heard civodul say he had hoped lsh would show more progress or so <Apteryx>It lacks some of the convenient tools such as scp, ssh-copy-id, ~/.ssh/config, etc., but other than that looks good? <rekado_>the primary goal with GuixSD was to build the GNU system. <janneke>i have looked at openssh codebase and patched bits of it... <elc79>rekado_: i see this installer and i see is a chaos of packages <rekado_>the GNU project has made this harder than expected :) <cehteh>hey i explicitly leave the discussion about which one is better out here, the main point is what are most (potential) users are common with <rekado_>elc79: I don’t know what this sentence means. Do you have a question? <janneke>i didn't look at lsh...but any alternative to openssh codebase seemed great. maybe i should have a look <cehteh>you cant lower then entry barrier by adding more steps to different ends <rekado_>cehteh: I understand what you are saying, but the goal was to build the GNU system, so that’s where things started. <elc79>rekado_: yes, how to know how much longer will take the installation? <rekado_>cehteh: easy of adoption only became a concern later. <rekado_>elc79: I can’t say this without knowing what you are installing. <janneke>rekado_: where does guix-maintenance repo live? (not in: git clone gnu:guix/guix-maintenance) <cehteh>yeah thats what makes it hard, i'd feel better if started with rather 'usual' things and then work towards a gnu system <elc79>rekado_: how can i give you this info? <elc79>rekado_: tevent, util-linux, wayland, eudev, fuse, elogind... what is the order of package installation? <elc79>rekado_: i see packages but i don't see number of packages, something like 58 of 1037 <elc79>now installing mesa! In other distro when i see this i can be a little bit happy :-p <ng0><Apteryx> What's the way to do a proper shebang for e.g. bash in GuixSD? #!/bin/bash doesn't exist. <- or create special-file /usr/bin/env and use #!/usr/bin/env shebangs <ng0>I found that to be way more portable for my needs <ng0>just #!/bin/sh for bash though <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 <Apteryx>ng0: that's a nice suggestion, thanks. <ng0>ACTION will give mrustc an initial package from git a try soon <Apteryx>ng0: On my 4 GB ram machine I still need to be careful when 'guix pulling' as I often have a fat IceCat running taking 1 GB or so of ram. <Apteryx>But this is only when using multiple core to run 'make'. Using one core seems OK. <ng0>this is on a server where the only big process is nginx <Apteryx>Depends what you run. By itself I think 'guix pull' only ever goes to 1.5 GiB or so. <ng0>never did with my experiments <ng0>never was enough I meant <ng0>for myself 3GB was the limit. <ng0>basically guix pull --max-jobs=1 right <ng0>I'll try to do that when I have money to update the RAM <cehteh>i just brought a new computer with a buggy ryzen, then amd support suggested to increase VCORE which gave it the rest :D <cehteh>anyway i have some old ram leftover soon, if anyone wants <ng0>I have to rent the RAM :) (@ in-berlin vserver) <cehteh>have to try 8GB on the other atom box here, when that works, then either 4GB or 8GB are left over <cehteh>well years ago someone send me ram when i needed it, i would be happy to contribute hardware back i dont need anymore <rekado_>guix pull eats more memory the more cores you have <bavier`>rekado_: I've noticed it usually does fine on my single-core 2GB-RAM netbook <rekado_>it doesn’t do well on my machines; it crashes on a 192 core machine with 1.5T RAM and it crashes on my i686 netbook with 1GB RAM ¯\\_(ツ)_/¯ <bavier`>ng0: 'guix pull' ignore --cores (and probably --max-jobs, too) <ng0>shouldn't we remove that from the switches then? <ng0>or is it technically supported but practically has temporary issues? <elc79>rekado_: i do "guix pull" succesfully in my third attempt, i almost cried lol <rekado_>elc79: didn’t you just install packages? Why run “guix pull” again? <elc79>no no, my mistake, i did, i did haha <elc79>rekado_: i did "guix pull" many times and the vm ran out of memory <elc79>rekado_: then i give 1.5g to the vm and ther worked, but i needed one whole day haha <elc79>rekado_: i'm installing and now it's compiling udisk :)