<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.
<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>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?
<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.
<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)
<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
<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!
<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