<ilmu>Hey, so I installed guix on my fedora 26 workstation using a copr (https://copr.fedorainfracloud.org/coprs/lantw44/guix/), started the daemon and then did a "guix package -i clojure" (just wanted to give it a challenge, building the jvm etc.) it ran for like 15 hours before it started hanging on "PASS: test-verify.sh" the other "test" steps were also taking a while so I let it go on for 7 more hours but I just stopped it. Now I just started the command <ilmu>ooh it just jumped past it like nothing now it's doing something useful again. Is there some logfile or something where I can investigate why it hung the previous time? <ilmu>ahh there is a test-verify for every step ok I guess this wasn't a very informative question. Sorry for the spam <ilmu>okay I love looking at this thing recursively build the whole world haha ***Gamayun_ is now known as Gamayun
<apteryx`>efraim: was it you who were trying to get guix copy working? <apteryx`>lfam: OK! Did you manage to get it working? I'm still struggling with 'guix offload', I understand the setup is similar? <lfam>apteryx`: I was tired so I just built the package on both computers :/ <apteryx`>not everybody is as stubborn as I, good ;) <lfam>I did glance at the manual section Daemon Offload Setup, which should help <apteryx`>yep, I've been through this many times. I get to the 'guix offload test' part. At which point it fails with some unhelpful error: "guix offload: error: build failed: program `guix-authenticate' failed with exit code 1." <apteryx`>Well, unhelpful because I'm not sure what that exit code is about. <apteryx`>and my GDB fu seems to not be strong enough. I get it stepping in guix-daemon but can't seem to break in the forked process where I want to (rbreak .*exportPath.*). <apteryx`>anyway... sorry for bothering you with this novel. <lfam>It's a wild guess, but were the signing keys set up properly? <apteryx`>I think so, but let me double check just to make sure. <apteryx`>also, found a bug: 'sudo guix archive --authorize < the-key.pub' adds it again even if it is already present. <apteryx`>I think the program 'guix-authenticate' is either not found in PATH, or its getting passed wrong arguments. <apteryx`>but without GDB cooperating it's hard to validate this. <janneke>rekado: i updated our wip-bootstrap branch @ savannah, whenever you can create the time to help and look at integrating/merging, let me know -- much appreciated <reepca-laptop>quick question before I send something to the CUPS mailing list - is there any guix-specific reason updating the defaults for a printer through the CUPS web interface at localhost:631 would silently fail (not be saved, despite saying they were successfully saved)? I'm having a heck of a time trying to get this custom page size to stick... <rekado>reepca-laptop: where does CUPS try to save changes? <rekado>reepca-laptop: the default location in the store is not writable and /etc would be cleared on reboot. <reepca-laptop>I *think* in /etc/cups. But I'm not too familiar with how guix services work. <rekado>we may need to configure it to write state to some directory that is writable and persistent. <efraim>i had a hard time getting mine set up with the cups server on my laptop pointing to the cups server on my RPi <reepca-laptop>you'd think if it had issues with being able to write under /etc/cups for whatever reason it wouldn't say "successfully updated defaults", etc <efraim>sneek: later tell mbakke the ldb patch should include mips64el in 64-bit targets <Copenhagen_Bram>How do I download (and build if necessary) the necessary files for a package without installing it? <reepca-laptop>guix pull just updates guix and it's package definitions and stuff. The actual update-the-installed-stuff is guix package -u <Copenhagen_Bram>Hmm. So, what would be the equivalent of 'pacman -Syuw --noconfirm' in guix? <Copenhagen_Bram>Hey thank you for helping me boot into my single encrypted partition <snape>haha! Okay let me know then, I'd be interested in knowing whether it's faster this way or not <Copenhagen_Bram>Alright. I'm sure it'll be faster. I'll probably only have to type the password once. Either that or whoever said guix didn't work with a separate /boot partition was right and it'll be misery once more. <snape>anyway you won't need to reinstall if you want to switch to full-encryption again <snape>you'll just end up with an extra unused space <reepca-laptop>Copenhagen_Bram: well, -y looks a bit like guix pull, and -S looks like guix package -u, and -w looks like guix build. I'd say the full command ("update the list of available packages, then download all new updates but don't install them") would look something like: guix pull && guix build <somehow get all installed packages>. It occurs to me that for that use case it would be nice if guix build could take a manifest object. <snape>Copenhagen_Bram: the equivalent would be 'guix build package' I think <reepca-laptop>(note: this is my first time looking at the pacman man page...) <Copenhagen_Bram>I might have to reinstall or something if it doesn't boot. If I can't boot, I can't just go in and do a `guix system reconfigure` <snape>Copenhagen_Bram: you don't need to reconfigure <snape>you just need to copy /boot's content from the extra partition to /boot in your original partition <Copenhagen_Bram>reepca-laptop: I looked at the info page for guix build, and I think the command I'm looking for would be: <efraim>'guix package -I | cut -f1 | sort -u | xargs guix build' <Copenhagen_Bram>then again, guix probably doesn't have the same chance of not being able to boot, or things crashing, after an update like arch/parabola does, so maybe I'll just do a guix package -u <snape>Copenhagen_Bram: actually, each time you reconfigure, a new entry is created in /boot/grub/grub.cfg. So if you use the one that used to work with the fully-encrypted disk, it should be fine <Copenhagen_Bram>because of the whole each-package-runs-in-its-own-environment-with-the-exact-versions-of-dependencies magic that I installed GuixSD for <Copenhagen_Bram>snape: well, actually I changed the partitions, made a whole new luks partition and am now running guix system init so that's not an option <snape>oh yeah I had forgotten about that <Copenhagen_Bram>if a /boot partition doesn't work then maybe an encrypted /home partition will <snape>it's getting less and less secure <snape>but there is no perfect solution <Copenhagen_Bram>and then i'll run out of space and decide to go fully unencrypted like i always have <snape>I like fully-encrypted /, although only if I don't reboot too often <Copenhagen_Bram>snape: well if an unencrypted /boot works then it was the perfect solution. There's nothing important in /boot <snape>like the grub configuration, that some nasty person could modify so that it log your password <snape>and some other nasty people could put a modified linux in there <snape>and get your grub to point to the modified linux <snape>those things are not easy to do, but it's feasible <Copenhagen_Bram>so if i have to take my computer somewhere where someone might take it... suppose I dd the boot partition to a usb drive, then modify config.scm to point to the usb drive as the /boot partition, then guix system reconfigure <snape>by the way Copenhagen_Bram, I think you will have to type the password twice even with an unencrypted /boot <Copenhagen_Bram>if it's still slow and requires typing the password twice i'll just go back to encrypted boot ***nordstrom_ is now known as nordstrom
<snape>the first time is libreboot unencrypting your root partition, the second time is linux unencrypting your root partition <Copenhagen_Bram>i wish i could guix system init with some packages added to the user's profile <snape>with Archlinux you don't need the first unencryption step because linux is in /boot <snape>but it's not the case with Guix <snape>if my understanding is correct <snape>yes, basically Guix just contains the grub config in /boot <snape>whereas Arch contains the grub config _and_ linux <Copenhagen_Bram>but if i have a separate /boot partition i won't have to manually type the command in libreboot, right? <snape>actually, you never have to manually type the command in libreboot <snape>even if it's fully encrypted <snape>(it's just even slower when I let libreboot automatically detect the encrypted partitions...) <Copenhagen_Bram>it takes what feels like 10 minutes just to autocomplete a list of devices <Copenhagen_Bram>hey how do I get weechat onto the guix installation so i don't have to download it when my internet becomes slow? <Copenhagen_Bram>or, you know. How do I transfer any package to the new guixsd system? <Copenhagen_Bram>and... the answer to that question might be simply `guix package -i weechat` while cow-store is running <snape>Copenhagen_Bram: you can use 'guix archive' <Copenhagen_Bram>speaking of cow-store, how does one install guixSD from a different distro? Would it simply be a matter of somehow simulating what cow-store does and then running guix system init? <reepca-laptop>(note that when using guix archive you wanna make sure you're using the same versions of guix) <snape>I don't know how to install it from another distro <reepca-laptop>snape: because if I understand correctly, it doesn't copy packages, just store items. <snape>yes, but you can use the store items even with another Guix version can't you? <reepca-laptop>yes, but if much of anything changes about the package definition, the derivations are going to change. And so is their hash. <reepca-laptop>so doesn't technically have to be the same version, but it's the only way to guarantee the package definition will correspond to the derivation outputs unless you manually compare hashes <snape>reepca-laptop: yes I understand, so guix package -i <something> will build everything again. But you can use the files from the store directly :p <snape>I do that often, it's convenient <reepca-laptop>it just seems like such a hassle not having all the environment variables set for you <snape>it works for complicated softwares like icecat <snape>try to run /gnu/store/...-icecat/bin/icecat <snape>you can run thousands of them without any installation to do <snape>Copenhagen_Bram: yes I believe <reepca-laptop>my excuse has something to do with "I am a compulsive tab-masher in anything to do with filesystems in emacs, and that completion takes a /long/ time with a store as big as mine" <snape>yeah I don't use emacs features with the store directory <Copenhagen_Bram>so basically if the guix version is off then my --imported weechat won't be found at $PATH/weechat? <snape>Copenhagen_Bram: it's very unlikely because nobody will update weechat while you're doing the migration :p <snape>and even if they do you can still use the store file directly <reepca-laptop>I just remember it was an issue for me when I was trying to get medicine to my crippled laptop <Copenhagen_Bram>btw how big of a change would it be to put the hash somewhere other than in the beginning of the directory name, and have the name begin with the package name so that they can be listed in alphabetic order? <snape>Copenhagen_Bram: guix archive doesn't "install" the package, so you won't find it in your PATH anyway I believe <snape>I think that after the import, you can just do guix package weechat <snape>and it will install it, without the need to build it <snape>because it's already in the store <Copenhagen_Bram>and if someone updates weechat then it'll get the latest version of weechat lol <snape>yes, but you don't need to install it anyway <snape>you can use the store file directly I think <Copenhagen_Bram>guix archive: error: build failed: getting status of `/etc/guix/signing-key.sec': No such file or directory <reepca-laptop>do make sure to bring the source machine's daemon's signing key along, though, so you can authorize imports <Copenhagen_Bram>so basically my source machine's daemon actually doesn't have a signing key <OriansJ``>For those who haven't been following, today's discussion in #guix-COC-discussion is are Codes of Conduct biased against individuals with low EQ thus are a form of discrimination and how to improve the situation. <divansantana_>I think docker isnt available in guixsd. Is there a bug report or thread that discusses that? <snape>divansantana_: you can create one if you want, and add the 'wishlist' tag <jlicht>hey Copenhagen_Bram, everything working out on your Guix adventures? <Copenhagen_Bram>jlicht: yeh, just have to wait a long time to download things now, and may have to run guix system init a few times if it fails to download something <jlicht>I start calling ISPs when my speeds dip below 2000kb/s <Copenhagen_Bram>what do you mean you start calling ISPs, do you look for a new one or do you bug the one you have? <jlicht>There is basically a multi-level-ISP where I live (i buy from ISP A, they get their services from ISP B, etc etc) so when there is a problem I start calling them in A -> B -> C order to find out what the problem is :) <efraim>mmm, new mesa in staging, time to check all the different galium drivers again for aarch64 and armhf <Copenhagen_Bram>Speaking of drivers, how do I get wayland to work for an intel GMA 4500MHD? <jlicht>Copenhagen_Bram: It is mostly the opposite of that, sadly. It's a bit complicated, but tl;dr: it's affordable, quite fast when it works, but I can't really go to any other ISP so if they decide to change either of their qualities I will be very unhappy <jlicht>there some blockchain based meshnet being talked about. Not sure what to think of it, as they made some promises that seem unlikely to be delivered on (e.g. "you can have lower latency on the meshnet compared to normal internet") <Copenhagen_Bram>jlicht: why do you say lower latency is impossible? also how low does latency get on the internet? <roptat>well, if you consider two machine physically closed to one another, it's possible that on the normal internet you have to go through routers all other the continent before you can reach the other machine <roptat>on a mesh network, that won't happen <roptat>but in general, the server is not close to you, so the reverse may happen: with more routers, you add more latency <roptat>so in general, it's more likely that a mesh network will have more latency <roptat>that may be normal if you're far from the servers <roptat>that's about the latency I got between Europe and Japan <roptat>If you're using a sattelite network, it adds a lot of latency because the sattelite is far away <jlicht>Copenhagen_Bram: I was not talking about improving latency times in rural areas for example. SkyCoin is what the thing is called btw, and the FAQ entry was about /gaming/ latency (so think 20ms), which to me seem unreasonable to get faster by adding potentially a lot of routers in between two systems <efraim>Probably just no one packaged it <Copenhagen_Bram>once i get settled into guix, im gonna make packages for these things <pkill9>nice, my ethernet works after waking up from suspend since last `guix reconfigure` <sneek>pkill9, alezost says: if you want to use fonts from another profile, you can just add the needed <dir> to your "~/config/fontconfig/fonts.conf" file <lyr3>well, its working after all, dont know why, though! haha <snape>is there a specific cuirass mailing list? <snape>or should I send patches go guix-patches? <snape>well I'll send it to guix-patches <ngz>v0.0 was released 6 years ago ***Guest70456 is now known as sturm
***sturm is now known as Guest12932
<Guest12932>I'm getting an error "ping: Lacking privilege for raw socket" when I run `ping gnu.org`. Do i need to be in a special group for this? Currently in users kvm netdev audio video wheel. <jlicht>Guest12932: I have users adbusers kvm netdev audio video wheel <snape>Guest12932: can you check in your PATH that /run/setuid-programs is first? <snape>well, first thing to do is 'which ping' to see where it comes from <snape>if it doesn't come from /run/setuid-programs, it won't work <snape>if you are on a foreign distro, you should use the ping of the foreign distro <Guest12932>snape: thanks, issue is indeed setuid-programs, as running `/run/setuid-programs/ping gnu.org` works fine. <Guest12932>snape: I copied 'export PATH="/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin${PATH:+:}$PATH"' from somewhere, so I guess that's not right <roptat>Guest12932: this adds your profile to the existing PATH, so it's correct <snape>well, no it's not, because the setuid programs should come first <snape>actually, I believe there is a bug about it <snape>because the user profiles prepends ~/guix-profile/bin to the PATH, which makes ping unusable <snape>otherwise you wouldn't have /run/setuid-programs <jlicht>it seems there is a typo in the r-factoextra description (cod instead of code). <jlicht>would it maybe make sense if texinfo.scm error are caught (and prominently displayed), but not bring down all of `guix package -s'? ***Flyynn is now known as on
<jlicht>(I have no access to my private key today, so I can't fix the cod -> code thing rn) ***on is now known as Guest68741
<lyr3>there is any tutorial on how to install guix on foreign distro. the manual aint that precise or I am just dumb <jlicht>lyr3: you are probably not dumb at all, guix just does things in its own way, which might be a bit daunting when you are starting out <jlicht>The manual provides a decent step-by-step list of instructions, and you might even be able to use installer, although I have no experience with that <jlicht>rekado: no worries, I think I've done this twice now as well. It just seems a bit unforgiving for such a non-essential piece of information to have such big consequences ***Guest68741 is now known as Flyynn
<rekado>jlicht, lyr3: are they necessary, though? Let’s improve the manual instead. <snape>lyr3: and there is the script at etc/guix-install.sh <g_bor[m]>jlicht: actually these texinfo problems are reported by guix lint, I believe. <jlicht>rekado: fair point, but the manual would e.g. not be the place to explain /why/ you would use certain configuration options (such as explaining the benefits of FDE, which kind of FS is good for your usecase, how large to make your partitions etc). A tutorial cross-linked to the manual would make a bit more sense in that case. <jlicht>full disk encryption, file-systems <snape>but those things have nothing to do with Guix, so I don't see why they would fit in a Guix tutorial <jlicht>basically, stuff that is most definitely relevant to an aspiring GuixSD user, but would not make sense to explain properly in the Guix manual <jlicht>snape: If I hand my good friend $RandomUbuntuUser the guix manual, they will run into quite some issues where their current knowledge is lacking, and the manual does not really provide a helping hand on how to remedy this. A tutorial fits this as it is meant to solve a specific problem without assuming too much about the reader's existing knowledge <snape>I mean, for example, you can't explain stuff about full-disk encryption or about partition schemes in a Guix tutorial <snape>it would be low quality information <snape>there are very good documentation somewhere else about it <jlicht>I totally agree, but an interlinked network of high-quality and correct information is usually not what people want to deal with when they just want to get a 'sneak-preview', so to say <jlicht>snape: I totally agree, but an interlinked network of <jlicht> high-quality and correct information is usually not <jlicht> what people want to deal with when they just want <jlicht> to get a 'sneak-preview', so to say <jlicht>ACTION is unhappy with rcirc's pasting behaviour <snape>(sorry for leaving, I just pressed C-x C-c intentionnally) <g_bor>we are already having problems with information provided so far. <jlicht>I have that effect on people sometimes :-) <g_bor>Please see information related to uefi. I consider getting that sorted and backed by system tests after fixing java bugs. <jlicht>I do think the documentation is very nice if you have specific question on how to achieve a specific action, or just want to know about some topic. It just falls short if you have no clue and just want to sit back and be informed. <jlicht>g_bor: I tried working with uefi, but in the end just disabled it on my main laptop. <snape>but people should be able to install Guix without needing other blog content about Guix. If they need information on, say, how 'ls' works, then they should find documention elsewhere <snape>so redirecting people to unofficial blogs doesn't help improving our official documentation <jlicht>the manual properly answers: "How do I install Guix(SD), given that I already kind of know what kind of configuration and programs I am going to need on my eventual system". <jlicht>snape: what would you propose then? Because maybe even having a list of prerequisite knowledge and/or decisions might already make it easier to follow for a total newcomer <jlicht>I agree with your explanation of the issue, it's just that I do not really see how to deal with it. <g_bor>jlicht: What would be the usecase of the documentation you are reqesting? One way to have a quick system to try is to provide a vm image, which is already done. <snape>I don't know that is problem lyr3 had, so it's difficult to answer <jlicht>I do not feel that doing thoughtless things like that should be condoned in any official capacity by a project, but it still is getting closer to the convenience people are expecting <g_bor>I also do not feel comfortable with that. I guess providing a vagrant file could be considered. WDYT? <g_bor>Also the etc/install script should be quite similar. <g_bor>But the install script covers only guix I guess. <g_bor>Ok, I will have a look at that later, I am on mobile now. <jlicht>Unrelated topic: I have some French guix stuff showing up in info. Is this expected? <roptat>unless you configured your system to be in French? <snape>jlicht: it's 2 years out of date <jlicht>roptat: I did not, or at least not on purpose. Everything else is English as well. <roptat>jlicht: actually, even so you "info guix" should be in English <lyr3>jlicht: thanks, I will those too. <roptat>but there's guix.fr which is in French <lyr3>rekado: As I learn how to properly install Guix on Debian I might help the tuto if there are any need room to improve <roptat>jlicht: what parts are in French, and what command did you run to see them? <jlicht>roptat: in Emacs: "M-x info", and there exists a heading "Administration système" with the guix subheadings, with a french description. Trying to read these leads to "no such node or anhor" messages <roptat>lyr3: ludo suggested that we collect tutorials in a separate texinfo source, so guix.texi would be the reference manual and guix-tuto.texi would contain use-case-oriented tutorials <jlicht>lyr3: apologies for the misinformation in that case. <roptat>jlicht: I don't know how emacs finds info manuals :/ <roptat>I don't really know how the manuals work together anyway <jlicht>roptat: If I can reproduce it on my other system, I'll send a bug report. It might just be something silly that I did with my git-checked-out and sometimes mutilated guix ;) <roptat>what we have is guix that is the English version and guix.fr which is the French version <roptat>they are both installed in .config/guix/latest <roptat>if someone knows how to make sure you can only find the manual for your language, that would be great <roptat>otherwise people will find entries in a lot of languages they don't speak, when it gets translated in more languages <roptat>maybe there's a language directory like with man pages? <jlicht>point is, the nodes don't actually point to anything. (I don't actually have a French manual available, just some headings). So it might really just be some transient effect of something I did. <roptat>jlicht: actually with plain info, I have the same issue <roptat>jlicht: I see, it tries to load "(guix) Invoquer guix gc" instead of "(guix.fr) Invoquer guix gc" <roptat>the French manual simply references nodes that don't exist <roptat>I can't fix that right now, but I'll try either this evening or tomorrow <roptat>oh, installing info manuals in multiple languages is listed in "Ideas that will not be implemented" :/ <Copenhagen_Bram>sneek: later tell snape You wanted to know what happens when you have a separate /boot partition? I couldn't get it to boot at all. Even using the libreboot cli. <Copenhagen_Bram>why is guix downloading everything again even though cow-store is enabled and there's a /gnu/store on the target system <rain1>i had that problem too, the only fix I found was to keep running it <Copenhagen_Bram>there's gotta be a way to conserve internet usage/get some relief from the sheer slowness of it <Copenhagen_Bram>with nothing to do but weechat and nethack over ssh and browsing wikipedia with links <rain1>i experimented with installing guix from one local VM to another, I think it's possible <rain1>but the annoying bit has to be done once <Copenhagen_Bram>the annoying bit has been done, this morning when i installed guix with a separate /boot partition and rebooted to find out guixsd isn't compatible with that <rain1>i had to set up bridge networking and then allocate them different ips and use one as the guix publish for the other to install from that local URL <rain1>unfortunately ti still installed SOME packages from the net <Copenhagen_Bram>has anyone tried symlinking the */gnu folder from one drive to /gnu/? <Copenhagen_Bram>how do i change the location of where guix looks for its store, from /gnu/store to something else? <pkill9>Copenhagen_Bram: you can compile guix to look for a store in another location (actually there may be an environment variable aswell) but you won't be able to use substitutes <pkill9>it is however possible to use bind-mounting to put the sstore elsewhere while still being able to use substitutes, however so far i haven't been able to do this on GuixSD, only Guix on a foreign distro, because the guix daemon is started before anything is mounted <pkill9>so even if you put the bind mount in the system configuration (which will write an fstab), the guix-daemon won't 'see' the bind mount because it was started before fstab was read <Copenhagen_Bram>Why can't you use substitutes if guix looks in a different location? <g_bor[m]>Copenhagen_Bram: It's because the store path is hardcoded in several places. <ng0>what happened with the bash completion? <ng0>ever since the last update its gone for all applications <ng0>I don't mind typing, but.. urgh <ng0>it's not that kind of hardcoding. it's like , the store location in the nix daemon, etc <g_bor[m]>ng0: Ludo said it was broken by a commit that disables sourcing one of the bash init files... I don't remember which one. <ng0>nad I think some patches and sunbnstitutes do the /gnu/.. replacemnte <snape>Imperio sneek tell me what's up <sneek>Welcome back snape, you have 1 message. <sneek>snape, Copenhagen_Bram says: You wanted to know what happens when you have a separate /boot partition? I couldn't get it to boot at all. Even using the libreboot cli. <snape>hm :-) so what's your solution now? <snape>Copenhagen_Bram: /gnu/store is hardcoded in the binaries. You can see it with the 'ldd' command. <g_bor[m]>pkill9: When does guix-daemon do the unshare? Could we make the mount in such a way that it is visible? <lyr3>its working. I just followed guix binary install yet again and voila... <lyr3>I just had to restart debian. Dont know, maybe some boring default on systemd by debian team...meh! <lyr3>even info are there, haha... c-h i...cool <ng0_>you need to reload the daemon files, in case you didn't do that <lyr3>ng0_: might be it! it was issuing no socket under /var/guix <ng0_>daemon files as in systemd <lyr3>some way guix generate that file, cant say if it related to systemd, though! <ng0_>lyr3: it is. what I'm trying to tell you is, that systemd has a command to reload its state of system files and let you start the guix-daemon.service then. <ng0_>should've worked like that before, can't remember right now and feeling too bad to not be able to spend energy on thinking about it <ng0_>anyway, you got it working :) <lyr3>ng0_: interesting. time to delve into guix source code to learn about it! h <ng0_>it's more like systemd reload --help or man systemd <lyr3>ng0: yep, as I extracted /var/guix no daemon-socket file are there so its generated, probably by nix-daemon <ng0>that is how socket files usualy work. <ng0>you start the application, socket file appears <lyr3>there are effort to port nix-daemon to guix team vision? <ng0>nix-daemon in guix already isn't the nix-daemon in nix anymore for some time.. sometimes efforts are shared, but we have work going on to implement the daemon in guile <ng0>it (was) part of gsoc 2017 and 2018 <ng0>guix package -i nix, and then write a service file, cause you need to replicate some of what the nix in NixOS does <ng0>idk if the guix package definition is recent, I updated my definition when the last nix release was made <lyr3>ng0: guile, cool! I wish I had scheme instead of C back there on Uni, anyway, I love C, late I will learn scheme <ng0>Copthat's when I noticed you need some manual work, and a service would be rather straight-forward <ng0>but it is out-of-scope for guix <lyr3>I hope that emacs team switch to guile so I wont need to learn elisp! <ng0>I have lots of unpleasant thoughts about Java in university.. and now I learned that the next module generation will use Python instead of Java >.< would've been less annoying. well, if it were just for learning I could do that at home, it's just for the final paper. <axd-v>So here is a use case that I need to work. I <lyr3>ng0: yep, but java boys earns a lot...too bad I hate java <ng0>the funny thing is, java 11 will make javafx obsolete or something? and we got started with some old gfx framework, and now got introduced to the current one, which is being replaced again :D <axd-v>So here is a use case that I need to work. I have a package in user's generation 5 that was removed in generation 6. I'm on generation 45 now and this package fails to compile on the latest guix. How can I add this package from my cache from gen 5? If I manually switch to the generation then I'm able to use the package, so it should be doable, I'd think. <lyr3>axd-v: dont know, but if that it is achiavable would really make me rethink GuixSD as daily driver, even though it still in beta <rekado>ng0: it seems to me that learning Java in university is not meant to be remembered :) <rekado>sneek: later tell axd-v You can do “guix package -i /gnu/store/…-the-package-…” <sneek>Someone once said tomorrow is quite soon <ng0>rekado: it's some kind of entry to C, but actually some do even C as a direct beginners language <ng0>could be that university and university of applied science are different in that regard <axd-v>rekado: thank you for suggestion, I'm gonna try it out momentarily. This type of use is one of the best use cases of guix, partial upgrades etc. Would you know if there's a way to let guix update the system upon `guix package -u` even if some of the packages fail to build, but others don't? Because qutebrowser and owncloud-client don't compile for me, going on for a few weeks now, I don't want to be kept back from other software that <sneek>Welcome back axd-v, you have 1 message. <sneek>axd-v, rekado says: You can do “guix package -i /gnu/store/…-the-package-…” <axd-v>p.s. I read this message already in the log, since I knew that I got disconnected. <ng0>rekado: would've loved to pick Anglistik or Linguistik and Theoretische Informatik instead, but I'm also fine with what I got now.. been a long road and fight. <rekado>axd-v: you can use “--do-not-upgrade=qutebrowser”, for example. <axd-v>lyr3: well you just got your answer. I'm already running GuixSD on the daily, just set up a safety vm that you can power up at any point with a more normal gnu/linux and you're set. <rekado>ng0: yeah, I also didn’t get the courses I really wanted. And now I just stopped to do more fun stuff for a few years. <axd-v>rekado: that's exactly it, I suppose I should have just read the info page, thanks. <rekado>axd-v: you can also try “guix package --help” to get an overview on features that you might want to look up in the manual later. <lyr3>axd-v: good to know! I want to learn scheme, I will first try it under QEMu! <axd-v>rekado: guix is so good, I still don't completely comprehend everything that it enables me to do, but I know I picked the right distro and community to be a part of. This is a future. Somewhat unrelated: do you know if guix aims for feature parity with nix or at least implement some of their interesting stuff that guix doesn't do just yet? How much influence do guix and nix have on each other? <ng0>rekado: hmh. yeah I somehow got the nice opportunities to work on as a flexible part-time job now, and the main reason I got this job was because of all the extra time I was able to spend before university on free software work.. still doing "real" world work is so much more fun. writing large scale crawlers, etc.. <ng0>shifting back and forth, will see how it all works out.. but Germany, you need the papers one way or the other <ng0>lyr3: I run an openSUSE VM for Eclipse <ng0>that was the first time in 3 years I couldn'T solve a problem on my own with just cheating <lyr3>ng0: how is Eclipse nowadays? I miss it, not that much, but still a bit! haha <jonsger>lyr3: you know there is an opensuse package for guix? just in case it could help you... <lyr3>jonsger: too bad, debian boy! haha <ng0>buenouanq: thing is now, I am working on something which has taken more priority, in addition to university. the service will be there eventually, but I've given other topics around it more thought, so the service will just be a proposal to pick up for Guix when it's done. Or maybe I'll send it, since it will probably just be like the module imports which need to be adjusted. <ng0>no idea? I've only started getting used to it.. I don't like these kinds of editors <rekado>axd-v: there is little overlap between Guix and Nix. We sometimes struggle with the same problems when it comes to packages, but the solutions we implement aren’t always the same. <rekado>axd-v: feature-wise I think there’s also some divergence. <ng0>different goals, too <rekado>axd-v: one thing we definitely want but haven’t achieved yet is Guix Ops, something that Nix has had for a while now. <axd-v>rekado: Interesting. Where would you say guix and nix diverge? I got interested in nix at first after reading about it, but after learning about guix when looking for libre distros, the choice was obvious to me. But it does seem like nix has a bit more steam and is further along development than we are here. Not to say that there's anything I don't have that I need on my gsd system, I'm really comfortable and already light years ahead <axd-v>of conventional package/system managers. <ng0>what I wanted to write before the freenode onion dropped: sometimes what's acceptable for Nix, isn't for Guix when it comes to packages. like direct elf patching in package definitions which I've seen in some places. So you spent some more time tinkering about solutions. <ng0>which is not to say with judgdement or anything, it's just a different approach at some problems <rekado>I would not say that “Nix has a bit more steam” — it has been around for much longer than Guix. <rekado>one point of divergence is as ng0 wrote: we have different sensibilities about what is and isn’t acceptable. <rekado>the Nix folks seem to be concerned more with increasing the number of packages that can be installed via Nix, even if that sometimes means ignoring bootstrapping problems. <vagrantc>are there any specific features present in guix or nix not present in the other? <rekado>Another thing that is important to me personally is the quality of R packages. In Nix there are lots of R packages, and a staggering amount of them cannot be built. <ng0>vagrantc: depends on which set of features you mean <rekado>I don’t think Nix can generate Docker or Singularity images. <rekado>(But it’s not too difficult to add, I think.) <vagrantc>ng0: hard to say exactly ... i don't really consider guile a feature, per se, rather an implementation detail <ng0>what are singularity images? has guix reached the point of singulatiry and become self aware? <rekado>I haven’t used Nix myself, so I can’t say much about how they differ feature-wise. <vagrantc>more like the sort of thing rekado just mentioned <rekado>to me Guile is a feature, but not necessarily a feature general users care about. <rekado>it makes extensions to Guix possible and easy. <ng0>(asking, because searching in the source, and also in search engines will be hard) <rekado>Examples are hpcguix-web or the Guix Workflow Language. <vagrantc>i haven't really used nix at all ... the commitment to free software licensing in guix is pretty significant, but not so much a technical thing as a social thing <rekado>ng0: Singularity is yet another “container” system, which targets HPC. <rekado>ng0: their container image format is little more than a SquashFS filesystem. <vagrantc>i guess i was thinking things like "guix environment" "guix container" or the virtual machine support, etc. <nyberg>I have currently ended up with guix unable to boot as even grub won't be detected by my x220 and it is not visible from the boot menu. Is it possible to restore this via grub and if so how should I proceed? I'm currently in a chroot environment without network capabilities. Thanks <niebie>nyberg: I haven't had to recover from that in ages - a thought might be to try and recover GRUB with something like Rescatux <nyberg>I'll have a look. Only "rescue" cd I have currently is an old ubuntu install disk from work