<mange>Yeah, it's actually more annoying because I haven't figured out how to reliably save that to my dotfiles, which means that I have to remember how to configure XFCE whenever I make a new machine.
<eubarbosa>mange: I dont think DE, others than KDE have that export config feature
<mange>Yeah, but I would have assumed they would be in a file somewhere in my home directory. XFCE stores config under ~/.config/xfce4, but I have had issues trying to transplant the (relatively straightforward) XML files from one installation to another.
<mange>It's not a bit enough problem for me to actually work out how to fix it, just a mild annoyance every now and then.
<reepca>also, once again the download works fine with wget
<mange>I'm on 4.15.0-43-generic, which means I can't confirm the kernel. I'm not on GuixSD, so I'm hesitant to try changing my kernel.
<reepca>what's your guix version like? I'm using a recently-rebased development branch with pre-inst-env that shouldn't have any differences on the download parts, will check it with my user's guix now and see if problem persists
<mange>I'm on a custom branch coming off 6df4d8338, but I think I've only changed packages.
<mange>The texlive download just finished. It stalled at 100% for a little while, and took up a lot of a CPU, but it completed.
<reepca>my user's on a773f141c and it's getting stuck. Maybe my kernel is drunk on lack of sleep.
<reepca>I guess I could grab my laptop and try reproducing there, in case it's a network driver thing
<mange>Unfortunately I have to go to a meeting, so I can't test anything else for you, but good luck!
<reepca>mange: thanks, you've given me much to consider
<reepca>hm, download finishes just fine on my laptop - linux 4.18.5-gnu with guix 40c7476af
<reepca>laptop still succeeds at download. Puzzling. Perhaps something specific to 4.19.8?
<reepca>so I was looking through the wget source code trying to figure out why it's working, and came across a comment that says that "the HTTP spec doesn't require the server to actually close the connection when it's done sending data", which is problematic considering our http client implementation tries reading until EOF...
<mange>Then how does the HTTP server say that there's no more content, if it hasn't sent a Content-Length header? That also wouldn't explain issues with FTP (but I have no idea what the FTP protocol is like).
<reepca>I haven't read the spec, but if that comment is correct I'd assume it's left up to the implementation whether to terminate the connection or send a content-length header, but at least one must be done.
<reepca>the FTP spec *does* require that the connection is closed when all data has been transferred, but for some reason my system never gets wind of it happening when a lot of data has been sent.
<reepca>I would guess that in practice most/all http servers do close the connection when all the content has been sent, including the one being used here, and the same issue experienced with ftp (certain connection terminations not being detected on my system for some reason) is causing the issue with http, and wget just happens to work around it.
<reepca>I get the feeling that if I just reconfigured and rebooted the problems would all go away, but then I'd never know what exactly was causing it
<reepca>hm, how can I get sudo to use my guix? guix --version and sudo guix --version both report the same stuff, but "sudo guix ..." gives a warning about being 11 days old on some commands, and I /just/ did a guix pull for my user.
<reepca>ah, I think I see the problem... the warning uses $USER to look up which file's modification time it should use, so it looks at root's modification time. Because apparently sudo -E still changes $USER.
<ArneBab>Is there a package for HTCondor somewhere?
<reepca>anyone else try to do some emacs-guix command, and then it says "Starting Guix REPL ..." in the minibuffer and it all freezes up until you spam C-g, after which you can run commands fine?
<reepca>desktop is now on linux 4.20.3-gnu with what is as far as I know the latest guix version, and still it gets stuck at 100%
<efraim>I've heard there can be problems with the REPL in emacs consuming all the memory
<reepca>and it's not like it's blocking transfers, it's just messing up the connection termination
<reepca>and only in very specific cases, apparently
<reepca>having to do with connections that lots of data pass through
<reepca>I'm at a bit of a loss as to how to debug this. I could try to write a minimal test program, but I already have a good idea of what happens: the connection never gets closed. Whatever mechanism is supposed to do that is probably in the tcp/ip stack in the kernel somewhere, right?
<civodul>did you make sure you have precisely all the bytes of the file when it hangs?
<reepca>hm, no I haven't. I strace'd wget (which succeeded at downloading) and ran it with --debug and it never had to retry anything and just did a bunch of recvfroms, and it got all of the bytes (it stopped once it got the amount corresponding to the content-length header). But in the texlive-over-ftp case it did time out and have to restart for the last 200 or so bytes, so it'd be worth checking out.
<pkill9_>yeah im starting to remember, i think gnome-shell tries to find a cursor icon and just crashes if it doesn't find it, the solution i had at the time was to copy the default cursor to the filename that it looks for
<roptat>now I have a few more things to do: have an sbt-build-system that mirrors the way binaries are cached, rebuild generated scala code with contraband, continue building gradle, bootstrap scala and have a look at kotlin
<lsl88>g_bor: hi! sorry, do you have your IPFS up?
<thomassgn>huh, guix started complaining about 'In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f' from one of my module files encoded as utf-8. most of my scm files are encoded ascii...
***janneke_ is now known as janneke
<rekado>I’m having problems updating the core-updates branch.
<rekado>there are a few conflicts that don’t have obvious resolutions.