<vagrantc>axd-v: set up NAT and port forwarding as appropriate <vagrantc>axd-v: which networking method is virtualbox using? it's almost certainly possible to configure the network in a similar manner. <vagrantc>axd-v: but yes, most wireless access points will drop traffic from unassociated mac addresses <axd-v>vagrantc: from what I could tell setting up a network bridge is the way to get networking for guest OSs, couldn't see another option, but admittedly haven't read the manuals. <axd-v>vagrantc: would you be able to suggest any good guides for "setting up NAT and port forwardsing as appropriate"? A lot of info comes up during a search and I'm afraid I don't have hours upon hours to waste on reading this mostly unrelated to me material and trying to find the stuff that's applicable. <nckx>ACTION pokes hydra.gnu.org repeatedly with a stick <nckx>mbakke: Has staging begun yet? <brendyn>I discovered that in guile, top level defines aren't optimised fully, but can be if they are wrapped in let. Does guix incur any performance loss by not doing this? ***dmc is now known as cd
***cd is now known as cmd
***cmd is now known as cd
<nckx>brendyn: My entirely unscientific opinion is that any (probably slight) performance gains through such cleverness wouldn't be worth the (even slight) increase in code complexity. <nckx>More generally, we'd probably be better off if we managed to make Guile optimise *less* rather than more. ‘guix pull’ (i.e. compilation) is horribly slow ATM, while the actual execution speed is... fine. <brendyn>nckx: I find guix quite slow for a package manager. 'guix package -s' is slower than any other package manager I've seen. It's even slower than searching the raw git repo with ag to find a package. <brendyn>'guix package -s blender' takes 2.7 seconds. 'ag blender ~/guix' takes 0.09 seconds, and searches a lot more files it doesn't need to. <vagrantc>ACTION has been known to use 'git grep PACKAGE' <brendyn>If I was a more experienced programmer, I'd try to figure out how to make it faster. <OriansJ>I'm honestly surprised that guix pull doesn't update a local sqlite database with the currently available packages to enable faster searching <g_bor>Recently it shows up in my git working tree sometimes as an untracked file <slyfox>guix-register -- register a closure as valid in a store <g_bor>I have a feeling that guix-register should be gitignored WDYT? <efraim>g_bor: it can be deleted, it was recently depreciated <g_bor>I've packaged prometheus-node-exporter. I'm pulling the sources from git, and the latest tag is 0.16.0, so no stable release yet. I decided to use the current tip of master instead of the tag. Is it ok to do this. If I get it right we usually package released software only. What is the policy in this case? <brendyn>How come I run guix environment autoconf, non of the autotools are in my path? <g_bor>How do I know if a branch is frozen? <g_bor>How do I know if a branch is frozen? <civodul>we don't currently maintain a status page or anything like that <civodul>if you have ideas on how to improve on this, they're welcome! <g_bor>ok, then I will ask :) Is staging still open? <g_bor>civodul: I guess if we have a workflow for freezing branches we might integrate this functionality to cuirass. WDYT? <g_bor>Also, when do we close bugs? If the fix lands on staging or core-updates is that enough, or we close them when the fix lands on master? <g_bor>If the latter, how do we keep track of this? <civodul>g_bor: i think staging is open, but please email guix-devel to be sure :-) <civodul>re closing bugs, it depends: sometimes it's better to wait until the fix is in master (it it's a serious bug, or if it's bound to show up again), sometimes it's ok to close it right away <g_bor>ok, I've sent a patch to a bug,and added STAGING to the subject. I would like to have it reviewed, but I'm pretty sure it's ok :) <snape>is there a way to avoid *.fr.texi being modified? <snape>it's a very tiny bit annoying :-p <snape>because when they are modified, git pull doesn't work anymore, one has to 'git checkout -- .' manually, etc <g_bor>snape: I've already talked about this to roptat. I guess that we need a more streamlined workflow to handle this correctly. The current situation is that the files are checked in, and gets modified whenever the po files or the manual is updated. <snape>g_bor: so why don't we update them when we update those po files? <g_bor>a possible working solution would be to update them whenever the manual or the po files get updated. <brendyn>guix environment doesn't seem to be working for me. 'guix environment autoconf -- autoreconf' fails to run. It doesn't seem to actually put any of the binaries into my path variable <g_bor>However this would result in partially translated fr manuals. <g_bor>Better would be: keep a manual that is the copy of the manual when the po files were last updated, and depend on that. This also has it drawbacks... <g_bor>I'm currently not sure about the correct way to handle this. <g_bor>Another easy solution would be to simply gitignore these files... <snape>brendyn: guix environment will provide only autoconf's dependencies to you. If you want autoconf in the environment, you need to type 'guix environment --ad-hoc autoconf' <g_bor>However, then it might be possible to not have these in a fresh git checkout. <snape>yes... is there a bug opened about it? <snape>I think I saw one discussion on the ml about it <brendyn>Hmm ok but that doesn't work for the inputs of said package. How can I create an environment with everything required to build a certain package? <snape>if you want everything required to build hello: 'guix environment hello' <snape>if you want everything requires to build hello plus guile: guix environment hello --ad-hoc guile <brendyn>That doesn't work. I made a package that has autoconf as a native input, but guix environment PACKAGE doesn't put autoconf in the path <g_bor>snape: I don't think so, but maybe there should be. The situation is much better than it initially was, when make clean removed these files, thus breaking bootstrap. <snape>I don't think so. At least ./bootstrap could be automatically rerun. <snape>This is not the case anymore: a manual step is required. <g_bor>snape: I also see guix-register reborn from time to time as an untracked file. <g_bor>snape: originally bootstrap failed with error after make clean. <snape>yes, but if your workflow is: make || (./bootstrap && make), it's not a problem <snape>I never experienced ./bootstrap failing though <snape>I thought you were saying that 'make' was failing <snape>brendyn: do you modify the PATH in your .bashrc? <snape>brendyn: can you try 'guix environment motion' and tell me if autoconf is in the PATH? <snape>brendyn: what about 'guix environment -C motion'? <roptat>re guix.fr.texi, I think I forgot to push the modifications when I last pushed the po file <roptat>I think an easy fix is to push whatever guix.fr.texi is now <snape>what about not updating it with 'make'? <roptat>for make, *.fr.texi depend on the po file only, so a modification to the English manual shouldn't modify it <g_bor>roptat: I also think that pushing the current content will work. <roptat>ok, I can't do that right now though <snape>brendyn: -C means --container. It <snape>'s in a container, so it is not bothered by your .bashrc and co <snape>If my understanding is correct <snape>brendyn: there may be an issue with how you setup your environment though (.bashrc, .bash_profile) <roptat>if we remove the rule to make *.fr.texi, it will be difficult to regenerate it I think <snape>brendyn: do you source .bash_profile in your .bashrc?.. <roptat>but the current situation is also quite error-prone... <snape>roptat: I imagine a 'make texi' rule that would not be called upon 'make' <brendyn>If I run guix environment --pure motion, it doesnt work either. Should --pure provide autoreconf? <snape>brendyn: --pure isn't in a container, so it should behave more or less like normal environments <brendyn>.bash_profile is only loaded on login though so it should polute the environment produced by guix should it? <snape>you don't log on guix environment <snape>so .bashrc shouldn't source /etc/profile IMHO <roptat>we need to make sure *.fr.texi are regenerated by guix pull and before every release <roptat>I think it's better to have a partially translated up-to-date manual than a fully translated manual that doesn't apply anymore :) <snape>(except in particular cases like ssh) <g_bor>Is shepherd automatically restarting a process if it dies? <roptat>g_bor: not if it dies repeatedly I think <snape>roptat: try to mess up with your Slim conf, you'll end up in an endless slim-trying-to-start loop <snape>which prevents to modify the conf :p <roptat>is that because it doesn't die quick enough? <roptat>I've had situations where herd status told me the service is dead and it would be restarted <snape>yeah I'm not sure maybe there are situations where services are not restarted <g_bor>Ok, thanks! And how do you test when you have written a new service definition? (This is my first service) <snape>g_bor: make sure the service is stopped + guix system reconfigure <g_bor>fine, just what I thought... <snape>g_bor: guix-register is different because it's untracked. So it doesn't prevent 'git pull' to work <brendarn>snape: yeah I've fixed it thanks, I hadn't realised it'd edited my .bashrc like that <rekado_>Is it possible to replace the “r-minimal” package used for building *all* R packages programmatically? <rekado_>i.e. replace the r-minimal used by the build system for a manifest. <rekado_>I remember that there was a patch draft for allowing to override build system packages, but I think it was never applied. <rekado_>I suppose one could fold over the packages and substitute the #:r argument. <rekado_>but how would I do this for all dependencies as well? <rekado_>oh, r-build-system does not pass #:r down to the “lower” procedure. <efraim>Couldn't you use --with-input=r=r-minimal <efraim>Its been a while since I tried but I thought doing that with bash would rebootstrap the system <civodul>--with-input won't work because R is an implicit input <civodul>package-mapping with a different #:r would do, rekado_ <rekado_>changing the r-build-system to support the #:r-gument would result in rebuilding about 590 packages. <rekado_>according to contributing it would be more appropriate for staging. <rekado_>I guess I could just push a new branch and have it built on berlin. <g_bor>rekado_: I guess I would do it on staging. <g_bor>rekado_,civodul: I'm not sure about GSoC rules, but I guess our interns know by now the results of the first eval. I that correct? <rekado_>maybe no rebuilding needs to happen at all. It’s just a change to private-keywords on the host side. <civodul>g_bor: we'd need to check the GSoC timeline on the web site <civodul>rekado_: these are small packages though? maybe ok for master, or maybe another incentive to get staging merged :-) <rekado_>looks like it does not cause a rebuild. <rekado_>but yeah, most of them are simple packages that don’t take a long time to build at all. <rekado_>I saw that Mr Rescue has been removed because it is not compatible with the current version of Love. Can it be made compatible? <sneek>jlicht, snape says: mu4e-conversation looks good! It's not yet in Guix though :-) <civodul>rekado_: i wondered what that meant, too! <Rukako>things are going well, I am currently toying with fibers <civodul>the idea i had was to make an incremental move towards Fibers <civodul>step 1 would be to use signalfd(2) instead of actual signal handlers, and have a big select(2) loop at the top level <Rukako>to move shepherd into a more event-drived approach? <civodul>so this step 1 involves writing bindings to signalfd(2), using (system foreign) <Rukako>never tried the foreign interface before :p <civodul>there's already a couple of bindings in modules/shepherd/system.scm.in <civodul>hopefully they can serve as an example <Rukako>does it use libffi or something? I used it in the past for my own mini-language thing <civodul>(system foreign) uses libffi under the hood, yes <civodul>signalfd(2) is probably a bit more involved than the other bindings in system.scm.in, but i can help <civodul>or probably other people on #guile could help as well ;-) <civodul>step 2 will be switching to Fibers instead of the select(2) loop <civodul>but let's focus on step 1 for now ;-) <Rukako>I have come to like shepherd, it feels quite elegant <civodul>heh, it's very simple, if not simplistic ;-) <jlicht>hey all, just read online irc log: I have some signalfd bindings already <jlicht>they are kind of rough (and possibly incorrect), but I could put them online somewhere if someone could use them as a starting point for a good shepherd hacking session <jlicht>apologies for the state of the code, the semi-relevant stuff should be in signalfd/utils.scm <Rukako>thank you, I will take a look at it! <jlicht> A problem I ran into is that guile has an... interesting way of handling signals currently, so there was some problem with signalfd-based handler not being called consistently (and different behaviour on repl vs non-repl) <roptat>Copenhagen_Bram: yesterday someone had this issue. it was fixed by running guix pull once more <jlicht>Copenhagen_Bram: another `guix pull' might fix your issue. Guix now depends on the guile-sqlite bindings being available, and you might still be running an older version. <g_bor>I'm trying to create a service definition. I guess I got it right, but it seems that I'm missign something. <g_bor>Do we haev to register a new service-type somewhere, like we do it for patches? <snape>once the service-type is defined in a module, people can use it in their config.scm <snape>as long as they 'use' that module <snape>(there is this 'use-service-modules' macro) <g_bor>actually, I've included it in my config, reconfigure worked without problem, but herd status does not show the service <snape>and the program isn't running? <snape>what does 'reconfigure' says about it? It should say 'service foo has started' <snape>or 'service foo could not be started' <snape>:-) it's useful to run 'ps auxww | grep program' sometimes <g_bor>no, actually it's not running. <snape>yeah, and what does 'guix system reconfigure' say? <g_bor>I will try to havee a look at the reconfigure output. <snape>if it says 'it could not be started', it means there was an error <g_bor>actually the service is not metioned in the guix system reconfigure output... <civodul>jlicht: ooh nice, thanks for the signalfd bindings! <snape>he :-) that means the Shepherd didn't even try to run it <snape>g_bor: it would be helpful that you provide your config.scm and your service definition <civodul>"interestingly", commit 32eb44240db23b2320a68a3ab17370531945587f (adding #:r) causes a rebuild of a large subset of the 'guix pull' derivations <rekado_>it doesn’t cause a rebuild of R packages, though. <rekado_>does this mean that the guix pull derivations accidentally depend on too much of Guix? <civodul>no no, everything works according to the plan :-) <civodul>i'm just trying to see whether that's the case <civodul>i mean, often enough we don't get substitutes for 'guix pull' and we end up rebuilding the world <civodul>(the world of guix pull, i.e., "guix-core", "guix-extra", "guix-packages", etc.) <civodul>so i'm trying to run it regularly to see whether all that rebuilding is justified <g_bor>hi, I've pasted it to paste.debian.net, as service and config. I've got to go now, but it would be nice if you could leave me a message about what is rong with that. <jlicht>snape: a patch for inclusion of mu4e-conversation in Guix seems to be in the pipeline :) <snape>yes, it arrived recently, I saw it too! <snape>g_bor: your service-type should extend 'shepherd-root-service-type' with the shepherd-service that you defined (but did not use) <snape>otherwise it's just a Guix service, but not a Shepherd service yet :-) <snape>civodul: is there an hydra guix-modular jobset? I can find only one on the web interface and it seems disabled for months. <mbakke>g_bor: Your staging patch LGTM. If you're around, feel free to push it. <sneek>Welcome back mbakke, you have 1 message. <sneek>mbakke, efraim says: the ldb patch should include mips64el in 64-bit targets <mbakke>g_bor: It lacks a proper commit message, though :-) <mbakke>I wonder if Hydra can manage two evaluations at the same time. <civodul>snape: the guix-modular jobset doesn't work on Hydra because (IIRC) Hydra systematically adds "." to the load path, meaning that build-aux/hydra/guix-modular.scm ends up using the checked out Guix modules instead of the ready-to-use Guix modules <civodul>maybe we could around it by explicitly removing "." from %load-path <snape>civodul: is there a way to see the hydra configuration somewhere? Specifically the argument list that is sent to the "nix expression" for evaluation. <pkill9_>what's the most linux-friendly tablet PC available? <pkill9_>other than the thinkpad tablet version <civodul>snape: in this case it's a "Guile expression" :-) <civodul>you can see the "Inputs" tab on the web UI <civodul>that is passed as an alist to the 'hydra-jobs' procedure <civodul>inputs can be checkouts, strings, or byproducts of other jobsets <snape>civodul: I was looking for some other inputs like 'subset (in gnu-system.scm) <snape>the only input that I can see on hydra.gnu.org is named 'guixSrc' and doesn't seem to be used within the evaluation <snape>I understand that it's used indirectly because the nix expression is taken from the input, but I was looking for examples of how other inputs could be used <snape>civodul: oh great, thanks :-) <civodul>and for "systems" you'd just specify a list of strings IIRC <g_bor>mbakke: I will push it in a few minutes. <mbakke>g_bor: Excellent, I'll (try to) start Hydra shortly after. <g_bor>Ok, I've pushed it. rekado_ said to expect minor breakage on java, because tests were effectively ignored, so we will see how it goes... <g_bor>Do you know where is the current shepherd log? And what is logged by shepherd? <g_bor>Thanks to savannah-hackers our git repos now show correctly on the guix group page! The cuirass repostiory would need a description update. <civodul>g_bor: woohoo, thanks for reporting the issue! <civodul>shepherd now logs to syslogd, which writes to /var/log/messages by default <civodul>maybe that's what prompted lfam to raise the issue on guix-devel <g_bor>civodul: I can't see in the log what shepherd is trying to execute. I think it would be a useful addition WDYT? <snape>g_bor, you talk about the programs's output while civodul talks about the Shepherd's output <lfam>civodul: I'd been meaning to start the Python 2 discussion for a while, but that article did remind me to go ahead and do it :) <snape>g_bor: according to the bug report, it should be in tty1. I never tried though, I usually start the program manually to see it's output. <lfam>I figure it will be a gradual and informal process, but it's good to get some feedback from everyone about what they are using <civodul>well i certainly use applications that use Python, but i don't use Python directly <civodul>the bioinfo use case may be much trickier :-) <lfam>pkill9_: I believe it's part of LLVM <pkill9_>doesn't appear to be lfam, thanks anyway <snape>pkill9_: isn't it libstdc++? <snape>description is "GNU C++ standard library" <pkill9_>i'm looking for a libc++.so which isn't in libstdc++ <snape>Copenhagen_Bram: you package it :-p <nckx>Copenhagen_Bram: If you really don't feel like packaging it for Guix: ~, /usr/local, /opt, … wherever you want, really. <nckx>ACTION prefers ~ since it's ‘me-generated’, even if I just typed ‘make’. <nckx>~/.local/bin seems to be conventional. <roptat>so my system boots and tell me to run fsck manually before dropping me in a guile shell <nckx>roptat: e2fsck -y /dev/foo <nckx>Sure you're not in bournish? <nckx>Otherwise (system or (system*, I forget which. <nckx>ACTION has long since patched Guix to just run ‘e2fsck -y’ unconditionally because they don't like such theatre. <nckx>Is anyone else's mu4e complaining that html2text is deprecated? <nckx>And is this my problem, or upstream's? <snape>nckx, Copenhagen_Bram: Yes of course. I didn't mean packaging them so to release them to the community, it could be a personnal package too. <snape>but I guess it depends of your use case <mbakke>I wonder if gnu-pw-mgr can be moved to (gnu packages password-utils). <bavier>mbakke: have we been moving away from putting GNU programs in their own modules? <nckx>bavier: Oh? When & why were own modules preferred? <bavier>nckx: afaik, "since the beginning", or at least that's the impression I received from civodul quite a while ago. <nckx>bavier: Ohkidoke. Why only GNU packages though? <bavier>as far as "why?", I assume to give the GNU packages a place of honor, or such <lfam>I don't think we need to rush to move packages around, but there are lots of GNU packages consolidated with other related packages in bigger modules <nckx>bavier: OK, thanks for the explanation. <roptat>that was expected, but fsck removed every instance of the guix binry <roptat>I think I can't recover from that ^^' <nckx>I wonder how Guix copes with entries in /var/guix missing from /gnu/store, although I guess that's rather moot if Guix is missing... <roptat>and the iso I generated from a recent commit kernel panics :/ <nckx>...crikey. So no backups, I hesitate to ask? <roptat>I'd like to say complete backups, but you never know :p <nckx>I'm about to be kicked out of the library. Good luck, roptat! o/ <rekado_>ACTION is annoyed by some messages on guix-devel <rekado_>I guess I need a long vacation without computers. <mbakke>nckx: By the way, the Zathura plugindir patch was accepted upstream. Now I just have to fix up the meson stuff and we can remove all the hacks with the next releases. <nckx>Copenhagen_Bram: There's section 4.1 (Defining Packages) in the manual. <nckx>sneek: computers are our friends. <vagrantc>so i've got an aarch64 system, and "guix pull" is reasonably current ... but my user has no profile, and so i have to manually add .config/guix/current/bin to PATH every time i login <sneek>Its been said that computers is our friends <nckx>Damn it sneek you had one job. <sneek>staging is none of your business <mbakke>sneek: The staging branch is live on Hydra! <nckx>That went about as well as expected. <mbakke>sneek: How is your unicode support? <nckx>Mainly used as a message bot for bouncerless peasants, to be honest. <nckx>vagrantc: I'm probably missing the point, but... isn't that the desired behaviour if your user doesn't have a profile? <vagrantc>nckx: i'm not sure what expected behavior. my expectation is that "guix pull" would bring in new versions of guix <vagrantc>it did up until the new change to create a profile for guix itself <vagrantc>though, admittedly, users without any profiles seems like a bit of a corner case <nckx>I'm afraid I'm not at all familiar with those changes (I don't ever use ‘guix pull’) or how they interact with [the lack of] your other profile[s]. <mbakke>I too wonder what the "best" approach for dealing with the new `guix pull` on a foreign distro. <mbakke>For now I added `export PATH="~/.config/guix/current/bin:$PATH"` to /etc/profile (or equivalent). <vagrantc>overall, the new guix pull is really great ... it's so much easier to revert in case of a broken guix. <vagrantc>hrm. elfutils failing to build on aarch64 <vagrantc>which blocks linux-libre from building... <vagrantc>fails in the testsuite: FAIL: run-backtrace-native-core.sh <mbakke>vagrantc: That's odd, I have /gnu/store/7bwiq4h7y5dgm2ybiwvwsxaa6lj3f6h3-elfutils-0.170 on aarch64. Perhaps it's an indeterministic error? <mbakke>vagrantc: I tried rebuilding elfutils on a rk3399 firefly, which still worked. Can you file a bug report? <vagrantc>mbakke: will dig a little deeper first, but sure, can follow up with a bug <rekado_>vagrantc: adding ~/.config/guix/current/bin as the first item on PATH is the recommended way of using the new “guix pull”. <rekado_>there’s no more confusion with some old Guix executable loading another set of modules from ~/.config/guix/latest. <vagrantc>on another machine, that somehow gets added to PATH automagically <vagrantc>both running guixsd, but one has nothing in ~/.guix-profile <thorwil>hmm, looks like garbage collection removes stuff that `guix environment guix` has to restore, then <thorwil>wonder if i should add all those dependencies to my manifest <rekado_>nckx: yeah, no people would be even better; my computer is mostly used as a gateway to people, though. <rekado_>thorwil: if you want the result of “guix environment” to be persistent you can register a so-called garbage collector root with “-r”. <rekado_>“guix gc” removes everything that cannot be reached by following links from garbage collector roots. <civodul>so, under which circumstances can the kernel decide not to dump core? <thorwil>rekado_: yes, it behaves as expected. registering such a root looks like a clean solution, thanks! <civodul>i know of: the rlimit too low, or not enough disk space <civodul>but there seems to be something else preventing the kernel from dumping core in my case <civodul>it dumps core for a trivial program but not for a full-blown guile <thorwil>so i just created a new gc root in current dir, which is kinda unfortunate <thorwil>can i just mv it to /var/guix/gcroots? <cbaines>I'm fighting to get lollypop working on Debian, the package seems to work ok on GuixSD... I've manually installed glib, gsettings-desktop-schemas, dconf and gstreamer, which helped, but I'm still getting an error <cbaines>Are there any tricks for debugging Glib GIO things (<- whatever that is)? <cbaines>Wahoo, I needed to manually install gst-plugins-base as well <cbaines>I have broken icons, but at least it starts! <cbaines>I installed some more packages, and I even have icons now <civodul>i just realized we were potentially no longer getting substitutes for 'guix pull' due to a buglet in (guix self) <wigust>I wonder should we get substitutes for package objects? <wigust>Yes. (I couldn't find such a question several days ago.) <civodul>so yes, berlin.guixsd.org builds the same thing as 'guix pull' <civodul>except that lately it was potentially not building the exact same thing, so you would possibly not get substittues <civodul>basically code that builds guix/config.scm was leaking variables from the current (guix config), which could differ <vagrantc>is it possible to get the log file from a failed build? I tried: guix build --keep-failed --log-file elfutils <vagrantc>but it doesn't make it obvious where to find it <mbakke>vagrantc: I think --log-file only works for successful builds. <mbakke>For debugging I typically just use shell redirection. <civodul>mbakke: it works for both failed and successful builds <civodul>vagrantc: do you get a URL or an error from 'guix build --log-file'? <vagrantc>ACTION tries "guix build --keep-failed --log-file elfutils | tee elfutils.log" <civodul>vagrantc: note that --log-file works only for completed builds, though <civodul>so you could do "guix build -K elfutils", and *then* "guix build --log-file elfutils" <civodul>that's a hint that we should clarify the doc :-) <vagrantc>civodul: not sure the difference between failed but completed, and failed but incomplete ... or the other various permutations <vagrantc>what redirections do i need to capture this? <civodul>what i mean is that "guix build --log-file foo" won't work if no attempt was made to build 'foo' (either locally or by a substitute server) <civodul>does "guix build --log-file elfutils" return something useful now? <vagrantc>civodul: it just starts the build over again <vagrantc>civodul: and doesn't give me any URL to the log <civodul>and "guix build --log-file elfutils --no-grafts"? <vagrantc>i would be lying if i said i saw and understood. heh. :) <mbakke>civodul: Oh, thanks for the clarification :-) <vagrantc>but i now have a log file i can attach to a bug report. :) <civodul>the "--no-grafts" option disable grafts since grafting would require to build the ungrafted version first <civodul>in your case you know the ungrafted version fails to build in the first place <civodul>rekado_: not much success regarding introductory videos :-) <vagrantc>my understanding of grafts is admittedly limited <vagrantc>wow. .guix-profile/bin is just a symlink when there's only one package in it <civodul>yep, that happens if you profile contains only one package providing bin/ ***apteryx is now known as Guest12551
<Copenhagen_Bram>Which process do I kill to shut down my locked up graphical session so that it goes back to the login where I can pick another window manager? <Copenhagen_Bram>The desktop environment is xfce4 and it's frozen at some time during a really hillarious scene from Dragon Ball Z Abridged playing in mpv <Copenhagen_Bram>Also I tried changing my shell to "screen" but "screen" doesn't exist so I couldn't log in as my user. Whoever said it's not a good idea to change the root shell, I can definitely see your point now. I've changed my shell to "/run/current-system/profile/bin/screen" in my config.scm, but guix system reconfigure is now very, very slowly downloading a 2GiB texlive package, which won't finish until midnight. I've <Copenhagen_Bram>fixed the shell problem temporarily by editing /etc/passwd, now I just need to kill my locked up graphical session