IRC channel logs

2018-09-27.log

back to list of logs

<TwistedFate>is guix operating system using systemd init by default?
<ng0>no
<ng0>it is using Shepherd
<TwistedFate>is shepherd anything like systemd?
<ng0>it's an init system.
<ng0>besides, I would suggest watching "The tragedy of systemd" from BSDcan 2018. systemd is not that terrible or unix-unlike like everyone assume
<TwistedFate>sorry, i mean't to ask it like this - is shepherd just init or everything else too like systemd? :D
<ng0>i leave that for others to continue. here's the video of the talk btw: https://www.youtube.com/watch?v=6AeWu1fZ7bY
<civodul>roptat: containers should work reasonably well now, lemme know how it goes :-)
*civodul -> zZz
<emacsomancer>which package should I install on guix to get the 'dig' utility?
<emacsomancer>TwistedFate:: shepherd is much more minimal than systemd
***nonlinear is now known as NB0X-Matt-CA
<Blackbeard>hi
<emacsomancer>alternative question: how do I discover what package an application belongs to in guix?
<emacsomancer>hi Blackbeard, I last saw you on #stumpwm; you're here too!
<buenouanq>how usable is guile-wm at this point?
<efraim>Never tried it, but I've heard the emacs one (exwm?) works fairly well
<wigust>emacsomancer: bind:utils package contains a dig program. However I think that currently there is no way to discover file or program belongs to package unless it's mentioned in a package description.
<emacsomancer>wigust: thanks. it would be nice to have some util that does this (I got used to Void's xlocate - https://wiki.voidlinux.eu/Frequently_Asked_Questions#Which_package_contains_XYZ.3F )
<divansantana>Why does one get these messages when doing a reconfigure? https://paste.debian.net/1044710/
<divansantana>Something along the line of note: source file... newer than compiled... etc
<civodul>Hello Guix!
***rekado_ is now known as rekado
<rekado>hello!
<ng0>emacsomancer: bind
<ng0>guile-wm is usable but seems to have bugs or non-features which can only be fixed with continuing the development in a new codebase.. or something like that
***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs and patches: https://issues.guix.info/ | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | reduced bootstrap seeds: http://joyofsource.com/reduced-binary-seed-bootstrap.html | This channel is logged: https://bayfront.guixsd.org/.well-known/logs/'
<civodul>rekado: i've just pushed to wip-ui code to check the daemon's protocol version and to display "substituting..." messages when the daemon doesn't support extended build traces
<civodul>like you suggested yesterday
<civodul>WDYT?
<rekado>civodul: thanks! I’m going through the rest of the patches now.
<civodul>rekado: cool :-)
***Server sets mode: +cnt
<jlicht>hey guix
<roptat>identify xl9a3PF7
<roptat>arg
<roptat>the test after PASS: tests/basic.sh in the shepherd is taking a very long time
<davexunit>ah icecat, the browser whose default experience makes me feel like it's horribly broken until I change a ton of settings.
<ng0>we have public logs (soon again), I would change that password.
<roptat>already done ;)
<davexunit>nice to finally have firefox 60 on guixsd, though.
<roptat>so, there's a test in the new shepherd that takes forever
<nly>I am getting trace: `stdenv.isArm`+ a bunch of other stuff is deprecated when importing a nix package from a local checkout. Is this a bug?
<nly>Exact command was 'guix import nix /path/to/nixpkgs pass-otp'
<nly>I'll run guix pull, see if it changes
<ng0>nly: it probably won't
<ng0>there's a bug open on import nix
<nly>Oh, I see it.
<rekado>How do people here review large patch sets? Patches that don’t just add packages but that add new features and/or modify existing features?
<rekado>I always decide case by case.
<rekado>sometimes I apply the patches to see more context
<rekado>sometimes I just read the mail containing the diff and look up context separately.
<rekado>I wonder if there’s an Emacs mode to assist this kind of workflow.
<rekado>civodul: one thing about the new (guix status) that I don’t understand is how the communication between the daemon and the client works.
<rekado>civodul: does the client just have a single port to the daemon’s stderr, even if there are multiple things going on at the same time?
<rekado>one problem with the code in “master” is that it has no idea of what came before the current chunk of text, so we couldn’t even properly colourise the multiple lines of hash mismatch errors.
<rekado>this might still be a problem with the new code, but I have yet to test this.
<civodul>rekado: regarding workflow, i do on a case-by-case basis as you describe
<civodul>rekado: fundamentally there's still just a single build log port, meaning that for max-jobs > 1 things might be intermingled (except "@ build-succeeded" and other things written by the daemon itself, which are guaranteed to be "atomic")
<civodul>the problem with the multiple-line hash mismatch error, i don't know
<civodul>i suppose it's not colorized at all?
*civodul checks
<rekado>I’m running guix package -i rust right now on wip-ui (with the new daemon) and I only see the spinner moving; it doesn’t show any download progress.
<rekado>admittedly, that’s from before you pushed the daemon protocol update.
<rekado>i’ll fetch the latest version
<roptat>I tried to change my guix-daemon.service to run guix from /root/.config, but I get /root/.config/guix/current/bin/guix: Permission denied
<rekado>civodul: the multiline hash mismatch error is weird: it’s printed twice; once it is received as a big multiline string with newline characters; another time it’s just build log output received as separate strings.
<roptat>more precisely /gnu/store/sf84mb2y5vcykwq9fv02l2nipp34qng2-guix-daemon-0.15.0-3.3d43017/libexec/guix/download: line 8: /root/.config/guix/current/bin/guix: Permission denied
<rekado>the implementation on “master” has no way to associate the following lines with the first line, so it doesn’t colourise them.
<rekado>this also made filtering difficult.
<rekado>it would be good, I think, to use the protocol bump to simplify that message to keep it terse and on one line
<rekado>let the client handle prettification
<rekado>roptat: this sounds familiar.
<rekado>hasn’t there been a bug report about this? I vaguely remember civodul commenting on this.
<roptat>maybe http://issues.guix.info/issue/32183 but the page is empty :/
<civodul>rekado: re hash mismatches: http://web.fdn.fr/~lcourtes/tmp/hash-mismatch-failure-guix-build.png and http://web.fdn.fr/~lcourtes/tmp/hash-mismatch-failure-guix-package.png
<civodul>roptat: yes it's this one: https://bugs.gnu.org/32183
<civodul> (http://issues.guix.info/issue/32183 returns 500)
<rekado>civodul: the second time the hash mismatch is printed, the first line appears to be missing, no?
<rekado>i.e. after “View build log” we see “ expected…\n actual…”, but not “sha256 hash mismatch”
*nlyy is trying to investigate http://issues.guix.info/issue/32339
<civodul>rekado: indeed, because of the multi-line error, which we should probably revert
<rekado>right
<rekado>I think it’s fine to revert that commit because now the client can style daemon messages freely.
*rekado is still waiting for “guix pull --branch=wip-ui” to finish
<civodul>heh
<civodul>rekado: yes, and we can make it "@ substitute-hash-mismatch" while we're at it
<civodul>though old clients may not see it
<civodul>so we'd need both
<sirgazil>Hi, I just installed guix 0.15.0 on Debian 9 using the guix-install.sh script, but I'm getting this error when I try to install something:
<sirgazil>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<jonsger>sirgazil: did you started the guix-daemon?
<sirgazil>systemctl says it is running
<sirgazil>I wanted to mention also that I had a previous version of guix installed, and deleted /gnu and /var/guix before running the installation script.
<lrochfort>Hi all. I'm modifying my config.scm for the first time. I've read the "Services" section of the Info manual, but still don't fully understand what use-package-modules and use-service-modules do.
<lrochfort>Where can I find more information?
<roptat>lrochfort: since the configuration is a scheme file, they are convenient macros to import scheme modules
<roptat>use-package-modules will import modules from (gnu packages)
<roptat>and use-service-modules from (gnu services)
<roptat>I think the manual should tell you in which file the different services are
<roptat>but in any case, you can try to run guix system reconfigure and guix should tell you what you need to do if there is a missing import
<lrochfort>roptat: That makes sense thanks. The Info page had (use-modules (gnu servicees desktop), then later (use-service-modules desktop), but didn't explain the latter was a macro for the first.
<lrochfort>Where can I find the definitions and/or dev documentation for this stuff, besides the Info pages?
<rekado>civodul: I must be doing something wrong as I can’t get “guix package -i rust” to show me the download progress.
<rekado>“guix build rust” does the right thing, though.
<rekado>I use guix and the daemon from wip-ui.
<civodul>hmm
<roptat>lrochfort: guix system search might help you
<lrochfort>roptat: Thanks, I'll give it a try
<civodul>rekado: note that the progress bar is erased after completion
<civodul>so if it's super fast you don't see it
<rekado>civodul: yes, I’ve been watching it.
<rekado>I’ll try again with something bigger
<rekado>icedtea
<civodul>:-)
<civodul>also are you in shell-mode?
<roptat>sirgazil: maybe there's some log that could be helpful?
<rekado>nothing
<rekado>civodul: no, in screen
<sirgazil>roptat: I don't know where to look for :)
<roptat>journalctl maybe?
<sirgazil>thanks, I'll check
<roptat>otherwise, try to restart the service
<rekado>civodul: same in a plain terminal outside of screen.
<rekado>civodul: I see “substituting …” followed by “substitution…complete”
<roptat>there's some weird code in openjdk... "if (colon + 2 != '\0')" where colon is a pointer...
<roptat>(at least that's what gcc says)
<rekado>sirgazil: does /var/guix/daemon-socket/socket exist? Does “pgrep -fa guix-daemon” show you anything?
<civodul>rekado: you must be running an "old" daemon no? with the protocol version check 'guix package' should not display "substituting..." messages
<rekado>I run guix-daemon from ~/.config/guix/current/bin
<rekado>civodul: it shows “substituting /gnu/store/7p52x3wv3nnsww4p3fq8gkq2mk53qk18-icedtea-3.7.0-doc...”
<rekado>and then the next line “substitution of /gnu/store/7p52x3wv3nnsww4p3fq8gkq2mk53qk18-icedtea-3.7.0-doc complete”
<civodul>rekado: oh but that daemon must be using root's 'guix substitute' or something, as in the bug roptat was mentioning :-)
<rekado>aah!
<civodul>one bug at a time please ;-)
<rekado>sorry!
<civodul>np! :-)
<civodul>when there are too many bugs it's hard to choose which ones to enable ;-)
<rekado>there should be a flag for that
<sirgazil>rekado: "/var/guix/daemon-socket/socket" does not exist. And "pgrep -fa guix-daemon" returns:
<sirgazil>447 /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild
<nand1>the sshuttle package is a python program that tries to use /usr/bin/env, which fails on guixsd
<nand1>should I report this as a bug
<rekado>nand1: yes, please do.
<nand1>thanks, it works if I create a symlink myself
<nand1>will report
<civodul>rekado: how about this: http://web.fdn.fr/~lcourtes/tmp/hash-mismatch-corrected.png ?
<civodul>that's with a new "@ hash-mismatch" trace
<civodul>(also notice the funny build log...)
<rekado>civodul: looks good!
<rekado>the funny build log… hmm. Can we prevent the extended build trace from appearing in the log?
<civodul>nope!
<civodul>the extended build trace remains a hack
<civodul>to the daemon it's just build output
<civodul>when we have the new daemon we can do better, but for now that's all we have
<roptat>\o/ build phase of openjdk9 succeeded
<rekado>roptat: awesome!
<rekado>civodul: okay. Previously we’d get weirder output when downloading things.
<rekado>this is an improvement either way.
<roptat>now building openjdk10
<roptat>if they are usable I'll send a patch later
<civodul>rekado: yeah
<ng0>fwiw, rust-wip is good for me. went through the build in the last 2 days
<ng0>did something "weird" happen with guix system vm in the last days? I am trying to build a server config with nginx and it keeps spitting nonsense at me in terms of error messages.
<nly>What emacs modes do you guys enable to M-. jump and show procedure info with geiser?
<civodul>ng0: nothing special happened AFAIK
<ng0>hm
<ng0>kurios.
<civodul>nly: s/guys/people/ :-)
<civodul>nly: M-. is part of Geiser
<civodul>you need to have the module loaded/compiled through Geiser though
<civodul>you can do that with C-c .
<civodul>or C-c C-k (to compile)
<nly>Oh. People, I meant
<ng0>i can't really push, so i can't share what I have in context. given that %nginx-config exists, I think the following could be a problem as I am moving from nginx where it used to have #:config-file.
<ng0> (service nginx-service-type
<ng0> (nginx-configuration
<ng0> (file (file-append %nginx-config
<ng0> "/nginx.conf"))))
<rekado>civodul: in case my emails to gnu.org are delayed again: the wip-ui things L very GTM!
<civodul>rekado: alright, thank you for taking the time, rekado!
<civodul>much appreciated
<rekado>I’m very grateful for your work on making the output more usable.
<nly>Ty civodul :)
<civodul>well rekado did the ground work
<civodul>i guess there's still room for improvement, but it's a step in the right direction!
<rekado>after upgrading my system I see this error when starting Epiphany:
<rekado>FATAL: Primitive gigacage disabled, but we don't want that in this process.
<rekado>same with eolie
<rekado>so it’s probably a problem with webkitgtk
<rekado>this makes epiphany and eolie useless as they fail to render all web pages.
*rekado looks at the log
<rekado>this is what NEWS says: “Disable Gigacage if mmap fails to allocate in Linux.”
<rekado>oh…
<rekado>this is probably due to some changes I made to the global pam limits.
<rekado>There are some quirks with GNOME.
<rekado>a lot of settings aren’t really working
<rekado>if you go to Settings -> Users and select an image for your user account, for example, nothing happens.
<rekado>Similarly, Settings -> Sharing doesn’t let you input a computer name, nor does flicking the switch do anything.
<rekado>The screen reader (when enabled) doesn’t seem to do anything either.
<rekado>the screen keyboard doesn’t seem to work either. It just doesn’t appear.
<rekado>Privacy –> Location services says “In use”, but the switch is off.
***JaiMari is now known as Guest91683
***mbowcutt_ is now known as mbowcutt
***mbowcutt_ is now known as mbowcutt
<roptat>openjdk@10 fails to build :/