IRC channel logs


back to list of logs

<mik_>is it meant to be used with sudo?
<mark_weaver>no, most guix commands are run as your normal user
<mark_weaver>the exceptions are "guix system reconfigure", "guix system init", and guix-daemon itself, which should be run as root.
<mark_weaver>to run those commands directly out of the source tree, you'd do: "sudo ./pre-inst-env guix-daemon ..." or "sudo ./pre-inst-env guix system ..."
<NiAsterisk>GNUdists sounds akwardly close to nudists. not that I judge one or the other, it just sounds too similar
<sprang>any guix-related stuff happening around libreplanet this weekend?
<sprang>I'll be in Cambridge tomorrow morning
<sprang>oh, yeah, I know about the session. I was just wondering if there were any informal gatherings
<mark_weaver>I'm not sure!
<sprang>well, I'll be around tomorrow and Friday if anybody wants to grab a meal and/or a beer
<sprang>flying out soon, I'll be on IRC tomorrow
<kristofer>dumb question, but do I need to be root to reconfigure the system?
<kristofer>any pointers on creating a system configuration with nginx-service?
<lfam>I'm glad to hear the xfce4-power-manager is working for people
<Jookia>Hmm. I have a derivation to build but I get errors when running "(run-with-store %store-monad (base-initrd '()))"
<Jookia>Oh, I have to open a connection. My bad.
<Jookia>Does anyone have an example of using guix build -e ?
<mark_weaver>guix build -e '(@ (gnu packages commencement) gcc-toolchain-5)'
<mark_weaver>to access a private variable (not exported), use @@ instead of @
<mark_weaver>btw, this syntax is not specific to 'guix build', it is guile syntax for accessing a variable in another module without relying on importing it first
<Jookia>it works! Thanks so much.
<mark_weaver>any scheme expression that evaluates to a package object can go there
<lfam>bavier: Did you see this bug regarding python-2.7.10 being unreproducible?
<lfam>So, is anybody fetching substitutes over https? I still can't get that to work
<lfam>This is the error output:
<lfam>That's the same as in
<dvn>new to guix. using it on a foreign os. I installed glibc locales, and set the path but I'm still getting this error: warning: failed to install locale: Invalid argument
<Digit>sat looking at my unupdated gentoo, realising it's only going to get scarier to update the longer i leave it... and gets me thinking of guix again... and how safe one feels when performing system upgrades with the knowledge of clean roll-back.
<jmarciano>dvn: if you as user get the error, you can put this in environment: export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
<jmarciano>if one of guixbuilderXX get the error, you can ignore. I had the same problem.
<dvn>thx jmarciano
<Digit>thnks again for making guix, Ludovic & everyone. ~ also, it's nice how one can simply "mpv" :)
<Jookia>mpv and youtube-dl are pretty fantastic tools
<roelj>Has anyone else run into "error: libgcrypt version mismatch" when trying to run the guix-daemon? I cannot seem to solve this..
<efraim>are you on guixsd or on a foreign distro?
<roelj>A foreign distro, Fedora 23.
<roelj>It has version 1.6.4 of libgcrypt, and Guix has 1.6.5.
<efraim>so it could be referencing the wrong one for the daemon
<roelj>I tried compiling guix with --with-libgcrypt-dir=/gnu/store/...-libgcrypt-1.6.5/ as well as with --with-libgcrypt-dir=/lib64
<efraim>I actually have libgcrypt in my profile to ease some pains I had
<roelj>Both resulted in the same error.
<efraim>from config.status its referencing the libgcrypt in my profile
<roelj>I checked with ldd whether it really linked to the store version or the system version, and that seemed OK.
<roelj>Ok, I will try again
<roelj>Now this is weird.. I don't have a directory /var/guix/ anymore.
<roelj>Is it normal to have it in /usr/local/var/guix/ instead, when compiled from git?
<efraim>it depends if you passed --localstatedir=var to configure
<efraim>good call on the /var and not just var
<roelj>So I've run "./configure --with-libgcrypt-libdir=/gnu/store/4iqlcz069gw3qnx2iry9yifwg9mc5k51-libgcrypt-1.6.5/lib/"
<roelj>Then make and sudo make install
<roelj>config.status says: S["LIBGCRYPT_LIBDIR"]="/gnu/store/4iqlcz069gw3qnx2iry9yifwg9mc5k51-libgcrypt-1.6.5/lib/"
<roelj>Yet, ldd /usr/local/bin/guix-daemon says: => /lib64/
<roelj>What should I configure differently, so that guix-daemon uses the libgcrypt from the store instead?
<alezost>roelj: try "./configure --localstatedir=/var --with-libgcrypt-prefix=/gnu/store/4iqlcz069gw3qnx2iry9yifwg9mc5k51-libgcrypt-1.6.5"
<efraim>vlc has a recursively linked download page
<alezost>although I don't know why you have this problem, I don't specify libgcrypt explicitly
<alezost>efraim: cool :-)
***kelsoo1 is now known as kelsoo
<rekado>ACTION switched to mpv just now
<rekado>roelj: I never run "sudo make install".
<rekado>and I also didn't need to pass "--with-libgcrypt"
<rekado>I'm using it on CentOS 6.x or 7
<efraim>i did the binary install on debian
<efraim>but did ./configure --localstatedir=/var with my git repo
<efraim>vlc fail: configure: error: "You cannot build VLC with Qt-5.5.0. You need to backport I78ef29975181ee22429c9bd4b11d96d9e68b7a9c"
<wingo>i think i might have fixed that gnome suspend-forever bug. fingers crossed
<efraim>2.2.2 will have to wait for us to package qt-5.6
<jmarciano>somebody knows if emacs-guile can be extended with guile?
<wingo>yay, fixed it! anyone using gnome and having the suspend problem, or who are not using gnome because of it, you can pull and things will work.
<wingo>it was an elogind bug.
<janneke>jmarciano: yes, see
<janneke>wingo: yay!
<wingo>also last night i was checking something
<wingo>and while the brightness keys and other media keys don't seem to be working yet
<wingo>you can adjust screen brightness using the control panel
<wingo>which means the pkexec / elogind / pam / sudo dance is all working as it should, it seems
<janneke>wingo: do we have a list/checklist for potential guixsd gnome users?
<wingo>janneke: users or developers? :)
<janneke>ehh...yes :)
<wingo>there are things to do but i don't know of a list
<wingo>adding gnome-backgrounds to the metapackage is an easy one
<janneke>hints like these can help people to switch
<wingo>ah, you mean for users then ;)
<wingo>it's fairly straightforward i think.
<wingo>you just cons (gnome-desktop-service) onto your %desktop-services
<wingo>and then you can log in in gnome
<janneke>yes--well developers could pick stuff that is problematic and fix it
<wingo>and things work as well as they do in xfce, more or less. except that gnome-shell wants to talk to networkmanager instead of wicd
<wingo>i don't know what the right solution is there -- do we make gnome-shell talk to wicd? or do we switch to networkmanager? and if so, how?
<wingo>ACTION dunno
<janneke>if i have networkmanager/wifi and openvpn, i'm good
<wingo>janneke: what do you do now? something wicd-specific?
<janneke>i tried gnome 6weeks ago and reverted to minimal debian+guix
<wingo>ah, so you are not on guixsd yet then
<janneke>not just yet
<janneke>i have migrated all my work to guix; "only" use debian+gnome-shell
<janneke>no emacs/guile/gcc/bison/whatever from debian only network+gnome
<jmarciano>janneke: thanks yes. I tried it, now I know it can be used like elisp. Only it is slow yet.
<janneke>jmarciano: great...i was hoping guile would speed things up...
<rekado>wingo: yay! So, this might mean that the shutdown/reboot bug in Xfce would be fixed too.
<jmarciano>I think it will be, only at this moment is slow.
<janneke>yes, i'm sure
<janneke>wingo: i've resurrected my gnu standard error-messages patch for guile
<janneke>but i cannot get guile master's debugger to ,break or ,break-at?
<janneke>stable-2.0 is fine...
<wingo>rekado: it could be!
<wingo>i don't know if xfce talks to logind by default
<wingo>janneke: that could be a bug, i rarely test the debugger
<wingo>a report for how to reproduce the bug would be welcome :)
<janneke>wingo: will do
<janneke>ACTION is going afk
<jmarciano>may I ask... if developers use Amazon AWS? Or is Amazon rather rejected?
<jmarciano>I mean, if Amazon is rejected due to freedom principles, then packages relating to S3,
<jmarciano>Route53, etc. cannot be included. Like some file systems on S3, and such
<jmarciano>like s3-fuse file system for example. I just wonder.
<wingo>ACTION dunno :)
<jmarciano>openstack is I guess alternative to Amazon tools, when GuixSD starts running, openstack could be good solution.
<jmarciano>I mean when GuixSD starts invading the Internet.
<efraim>we have awscli
<efraim>it also works with amazon-compatable services
<jmarciano>aha yes.
<jmarciano>and is Amazon AWS rejected for some principle of freedom?
<jmarciano>I mean as services
<jmarciano>of course they don't run services on free software
<jmarciano>GuixSD could be new method of quick startup of web services.
<wingo>one day i want to be able to create vm's to run on virtual hosting providers, using guix.
<jmarciano>Something like Docker... can be implemented through GuixSD
<wingo>so to that extent i think libraries that integrate with various hosting provider's facilities are welcome. dunno though, there are many opinions :)
<jmarciano>and something like one-click-apps
<jmarciano>I guess hosting providers shall integrate with GuixSD, not other way around.
<wingo>this discussion is a bit abstract :)
<jmarciano>I try to see the future picture
<efraim>mysql wants boost-1.59
<dptd>Hello there! Anyone have a minute to help newbie with GuixSD installation?
<wingo>i have something to do now and so i can't, but i wish you luck dptd and that you find someone to help you!
<wingo>also, please keep notes as to what is a problem so that we can improve the docs :)
<wingo>and the code of course :)
<dptd>I have downloaded USB installation image. Converted it to the VirtualBox VDI. Mounted and booted. I follow the official instructions (started ethernet, started cow-store, modified sample system config and run guix system init). However tests/store tests keeps failing. I cannot find logs anywhere. :\\
<dptd>wingo: Thanks. Actually when I will be done I will probably post somewhere step-by-step instructions how to install GuixSD in VirtualBox.
<civodul>Hello Guix!
<Jookia>Is it blasphemy to use Guix to build an initramfs that doesn't use Guile?
<civodul>Jookia: of course :-)
<Jookia>civodul: I'm trying to build something that's supposed to fit under 3M, but Guile alone in an initramfs goes waay past that size :(
<civodul>right, 7MiB for /run/current-system/initrd here
<civodul>thing is, i'm not sure you can do much better without Guile
<civodul>because you need klibc, Bash, etc. etc.
<Jookia>well, i could try and get it down to busybox-land
<civodul>yeah, but i suspect we could make the same space savings with Guile
<civodul>you'll tell us! :-)
<dptd>Anyone knows where I can find test logs from guix system init? Store tests failed and I cannot find why...
<Jookia>I could aim for 8MB instead but I'd still have to write a small networking service
<civodul>networking service?
<Jookia>Yes, I want to be able to get ethernet and wi-fi in this initramfs
<civodul>in the current framework, you'd "just" need to add the relevant kernel modules, and give an expression that sets things up
<civodul>unless udev is needed...
<Jookia>Probably not- but won't I need something like wpa_supplicant?
<civodul>yeah possibly
<civodul>rekado: r-dnacopy-1.44.0 has a wrong 'home-page'
<Jookia>civodul: Is there any low hanging fruit that could be shaved off guile-static-stripped?
<civodul>Jookia: no idea, i haven't checked, but i know i haven't really tried to make it small
<civodul>so there's hop
<Jookia>I wonder if replacing glibc could help. Looks like I have some fun things to test
<Jookia>Unless guile hard depends glibc
<civodul>grr hydra is dying and the mirror doesn't have everything in cache
<dptd>Anyone tried to install GuixSD in VirtualBox?
<rekado>dptd: someone did and they kept notes, but I cannot find them right now.
<Jookia>dptd: Have you tried using qemu instead?
<rekado>civodul: oh, you're right about r-dnacopy. Sorry! Slipped by the review.
<dptd>rekado: I found one or two pages and I did exactly what was there. Still no luck though.
<rekado>dptd: which guide did you follow?
<dptd>Jookia: No, I did not. Actually I just went to the project website, never heard about it before.
<Jookia>dptd: It's really good and free
<dptd>And official Guix manual of course.
<dptd>The problem is that after guix system init <blabla> store tests fails. I cannot find any logs anywhere and I am stuck.
<dptd>Jookia: I will check it today. How it compares to VirtualBox? Have you used both?
<rekado>I have used both.
<Jookia>dptd: I mainly just use qemu, it's just as fast :)
<rekado>I no longer use VirtualBox.
<rekado>a graphical frontend for qemu is provided by virt-manager.
<rekado>roelj: I restarted the guix-daemon and now also get "error: libgcrypt version mismatch" :)
<dptd>I see. However my issue is probably not related to VirtualBox itself. No idea why this test fails. I cannot find any logs anywhere. Should it be that way?
<Jookia>should you be running tests? aren't there substitutes?
<dptd>I believe tests are run automatically after system init.
<dptd>After preparing the partitions and config file all I have done was to run guix system init /path/to/config
<Jookia>have you run 'guix pull'
<rekado>roelj: "make clean" and "make" fixed it for me.
<dptd>Jookia: Yeap, before I have run system init.
<dptd>Exactly... :< :P
<mkoenig>substitute download is terribly slow (1% per hour) and "--no-substitutes" also fails (downloading pkg-config) :/
<rekado>hydra doesn't work right now and I don't really want to wait for substitutes to create an environment, but even with "--no-substitutes" it seems to wait for hydra.
<civodul>mkoenig: could you try --substitute-urls=
<rekado>when I switch to it wants to download the bootstrap binaries --- even though I have them already.
<rekado>"guix environment --no-substitutes --pure -l guix.scm"
<rekado>unpacking bootstrap Guile to '/gnu/store/aiz8db2gni401wc9fgidmcggxyb1czis-guile-bootstrap-2.0'...
<mkoenig>civodul: seems to be working, but now download speed is 1% per 5 minutes
<rekado>without --no-substitutes (and using it does this: "Downloading cib4xy...-diffutils-boot0-3.3 (368KiB installed)..." and then fails with 504.
<mkoenig>is that a common problem?
<civodul>rekado: i'm currently tuning to be less tolerant of delays on
<civodul>so i guess it's somewhat in flux
<jmarciano>anyone yet using KDE?
<jmarciano>I just wonder, as I have realized, nobody I know uses KDE...
<mkoenig>jmarciano: not together with guixsd but yes
<jmarciano>mkoenig: aha yes, because of German connection?
<mkoenig>no, just because i like it
<jmarciano>yes, sure. I tried it many times, I was thinking for it to become my default. But that was back in 1999-2001
<jmarciano>After testing the speed and all usabiliy, I stayed with simple window managers.
<jmarciano>but good to know you use it.
<mkoenig>i prefer xmonad but i don't want to use it on multimedia systems
<NiAsterisk>do we even have ruby/rails ? i send an email on the recent CVEs of it as I had 3 results for guix package -s rails
<jmarciano>aha tiling window manager, well I tried it back in time. But if I tile, my windows would get smaller and smaller.
<NiAsterisk>I used kde with kde3 or 2 or somewhere around year 99/2000 and now I use kde plasma 5.5 when I can or awesome-wm..
<jmarciano>will install it and try it
<rekado>NiAsterisk: we have ruby but no rails.
<NiAsterisk>then disregard the CVE email
<jmarciano>awesome-wm looks powerful, I have seen this setup:
<jmarciano>maybe guile-wm could become something like that...
<mkoenig>thats xmonad
<mkoenig>the photo
<mkoenig>NiAsterisk: why exactly 5.5?
<NiAsterisk>idk, I just use gentoo's kde overlay. 5.5.5 is the newest plasma
<Jookia>trinity desktop port when? ;)
<mkoenig>hey, using gentoo too :)
<mkoenig>it's a fork of kde 3
<NiAsterisk>whoever likes that..
<NiAsterisk>what else do I need for gnome-desktop-services to be valid?
<NiAsterisk>"In procedure module-lookup: Unbound variable: gnome-desktop-services"
<mkoenig>i wonder how you can offer gnome without systemd
<rekado>you need to load the module in which it is defined.
<rekado>mkoenig: we have elogind
<NiAsterisk>which is (use-package-modules gnome xfce wicd avahi xorg ratpoison certs emacs tor) where I assumed gnome is the right name
<rekado>it's a part that has been carved out from systemd (mostly through the efforts of wingo)
<NiAsterisk>oh, it did not work because i wrote services and not service
<mkoenig2>i'll give guile-wm a try
<mkoenig2>do you know if it supports tiling?
<janneke>mkoenig2: it has a tiling.scm module...
<janneke>i succeeded in running guile-wm for the first time on guixsd
<mkoenig2>ok thx
<janneke>but it crashes on my and i haven't found a way to make a bug report
<janneke>i have high hopes for guile-wm, it needs some love...
<mkoenig2>what's the best way to install the proprietary nvidia driver
<Jookia>mkoenig2: you'd have to find someone's branch of guix that allows it
<mkoenig2>mhh. maybe i will try nouveau first, but:
<Jookia>yeah, all GPU vendors are unfirnedly to OSS hardware
<efraim>mkoenig2: AFAIK linux-libre actively blocks loading non-free firmware
<NiAsterisk>^ yes.
<NiAsterisk>but, not advocating this, you can rewrite the linux-libre package according to your needs.
<jmarciano>efraim: good, when I found actively blocking, I have installed it.
<jmarciano>mkoenig2: I guess GuixSD is free software distribution. Non-free will never belong to GuixSD neither will be sponsored, or otherwise supported or referenced to.
<redshelled>Hey everyone, I'm getting started with GuixSD, but I can seem to get it to install. libarchive always fails one test. Any ideas?
<redshelled>is anyone else able to build libarchive on amd64?
<efraim>did you already run guix pull?
<redshelled>I did last night, would it be worth trying to pull again?
<redshelled>for the sake of being useful, the test that is failing is test_format_newc
<mkoenig2>efraim: oh, didn't know. this will be a problem..
<mkoenig2>still getting 504 download errors...
<pizzaiolo>mkoenig2: same
***mkoenig2 is now known as mkoenig
<pizzaiolo>something is up with hydra
<dptd>redshelled: I have also some strange problems. I am still trying to install GuixSD on the VirtualBox. After guix system init <blabla> test/store.scm is failing.
<davexunit>dptd: I don't understand. running 'guix system init' doesn't run the Guix test suite.
<davexunit>and even so, a test failure isn't necessarily indicative of a broken installation because the tests are run in isolation from the main system.
<dptd>davexunit: I don't understand either. However after running this command I had some tests output printed out.
<mkoenig>does guix install required nouveau automatically?
<Jookia>unless you want no screen
<davexunit>dptd: sorry, we need more information in order to debug this.
<davexunit>what is your OS config? are you using substitutes?
<davexunit>have you run 'guix pull' before installation?
<dptd>Okay, let me write it step-by-step. :)
<davexunit>you must run 'guix pull' beforehand, otherwise you *will not* receive pre-built binaries
<davexunit>because 0.9.0's binaries have long since been garbage collected.
<davexunit>our next release will make it more clear that you need to run 'guix pull' immediately
<dptd>I have done everything according to the official instructions. I am trying to install GuixSD in VirtualBox. I downloaded newest usb installation image, converted it to the VirtualBox VDI and mounted. I successfuly booted this image. Created partitions (boot and root) and labeled root. Mounted it, started cow-store and copied sample desktop config to /mnt/etc. Edited the sdX in the config. After that I actually have
<dptd>run guix pull and after that guix init /mnt/etc/config.scm /mnt --fallback.
<dptd>And - as I wrote before - it failed. Last prints in buffor were tests run summary (2 skipped, 1 failed).
<mkoenig>look for download errors
<dptd>I will. However it will take a while to go back where I was yesterday. I will let you know when I will be done.
<davexunit>dptd: did you take note of what guix said it was going to download vs. what it was going to build?
<davexunit>dptd: why are you using --fallback?
<davexunit>that's surely the culprit
<davexunit>guix is building guix instead of downloading it
<davexunit>and the test suite fails on a virtual box machine
<dptd>Okay, will check without --fallback. Makes sense what you are writing.
<davexunit>so there's a bug report there if you can run 'guix build -K guix' and capture the test suite log
<davexunit>and we can try to fix that
<dptd>However at the very beginning I was not using this command. During the debugging process I read (or someone told me to) to try with this flag. ;)
<Jookia>dptd: are you using btrfs
<davexunit>note that we do not condone or support virtualbox specfically because it requires nonfree software.
<davexunit>but I suspect the test suite failure may be a bigger issue.
<mkoenig>guix pull always fails, but guix pull --bootstrap seems to work!?
<Jookia>oh, wrong person
<dptd>davexunit: Roger that, thanks for the help.
<davexunit>mkoenig: could you provide some detail?
<dptd>Jookia: No idea. btrfs?
<Jookia>Oh, I knew there was a few btrfs bugs a while ago
<Jookia>On my system at least
<davexunit>wingo: so happy to hear about the infinite suspend loop being fixed! reconfiguring my laptop now.
<mkoenig>still fetching.. but now with a realistic speed
<mkoenig>error is 502: bad gateway
<davexunit>mkoenig: hydra is frequently under heavy load
<davexunit>you can try --substitute-urls= and see if it helps
<mkoenig>this is not a valid option for guix pull
<davexunit>mkoenig: oh sorry, I thought you were doing something else.
<davexunit>then can you explain what URL returned 502?
<mkoenig>know what you mean. it also fails
<ajgrf>how do i get the correct hash for git-fetch?
<dptd>davexunit: Should I also use substitute-urls during system init? Currently I see some logs like "system is somehow slow" related to hydra.
<davexunit>dptd: you could give it a try
<davexunit>and see if it works better
<civodul>so, with my latest nginx changes, will *feel* faster
<davexunit>civodul: what did you change?
<civodul>ACTION becomes a web dev
<civodul>davexunit: the proxy timeout :-)
<davexunit>shorter or longer?
<civodul>that is, and will give up quickly instead of waiting forever
<civodul>so effectively, if is overloaded, you'll get fewer substitutes
<civodul>it turn, that will probably help reduce load on
<davexunit>sounds like a good trade-off
<civodul>yeah, i think it will make the UX less bad
<civodul>while waiting to make it better ;-)
<civodul>assuming it feels better to build things locally than to wait forever
<civodul>which may or may not be true
<davexunit>I'm currently building an awful lot of GNOME
<kristofer>it's difficult to walk away from an installation because of the 502 errors
<davexunit>"I really like Guix's ideas, but I think that project made a very unwise choice when it picked Scheme rather than Common Lisp."
<davexunit>the feud continues
<redshelled>i actually like scheme better xD
<redshelled>its why i came here from nix
<davexunit>so do we :)
<jmarciano>I guess Guile is used because of future, to be very extensible
<redshelled>plus there is an advantage that scheme is taught at a lot of uni's
<jmarciano>There is application on Android FOSDEM Companion, one can many new talks about Guix. Get it on
<jmarciano>but I cannot be there...
<paroneayea>I like both, I prefer scheme
<paroneayea>but if you can use a lisp, that's better than most of the world still :)
<jmarciano>"Your Distro is a Scheme Library"... thanks Ludovic
<davexunit>paroneayea: I'm currently writing "Scheme Considered Unwise" to be published by the ACM
<paroneayea>davexunit: wait huh?
<paroneayea>you're writing an anti-scheme article...?
<paroneayea>I must be misreading :)
<piyo>Countdown to april fools in 3 2 1...
<jmarciano>GuixSD will blur distinction between users and developers. It is teaching users to become developers.
<jmarciano>and vice versa
<davexunit>paroneayea: early april fools for you
<civodul>davexunit: that's because you got an awful lot of 504/502 without noticing :-)
<davexunit>I think it may still be in the grafting phase
<davexunit>because it's just printing 'updating list of substitutes' a million times :)
<civodul>ah, that too
<davexunit>I'm gonna stop it and try with the mirror
<davexunit>oh except I still haven't figured out why 'guix environment' breaks SIGTERM
<davexunit>I need to figure that out... probably something really silly.
<jmarciano> works considerably better than hydra
<jmarciano>I repeat it from Fosdem video, I tried: ,use (gnu): ERROR: no code for module (gnu), and I have guix. What to do?
<davexunit>jmarciano: you are at a guile REPL, right?
<davexunit>you need to make sure that the guix modules are on GUILE_LOAD_PATH
<jmarciano>let me check
<davexunit>I have no idea how you have installed Guix so I can't give specific advice
<davexunit>but that's what that error means.
<jmarciano>explain what you mean above with (and GUILE.. ?
<jmarciano>aha it is just and, not scheme
<jmarciano>yes, I have both but I cannot ,use (gnu)
<davexunit>jmarciano: just because those variables are defined doesn't mean that they are correct
<davexunit>obviously they are not correc
<davexunit>otherwise ,use (gnu) would work fine in your REPL
<paroneayea>davexunit: heh :)
<davexunit>paroneayea: maybe "considered unwise" can be the new "considered harmful"
<jmarciano>I have it, but not finding, can you check the name of gnu file?
<davexunit>I don't understand.
<jmarciano>maybe I can find it and load to path (gnu), but I need some clue
<davexunit>the first thing you should do is identify where the Guile modules are for Guix
<davexunit>how have you installed Guix?
<jmarciano>yes sure
<jmarciano>/home/data1/protected/.guix-profile/share/guile/site/2.0/ that is LOAD PATH
<jmarciano>and inside many sym links
<jmarciano>only not gnu
<davexunit>that wasn't my question
<davexunit>but okay
<davexunit>how do you use guix? where is it installed?
<jmarciano>on Debian
<jmarciano>but that does not matter for the loading
<jmarciano>I see shepherd, I can ,use (shepherd), but I don't see inside gnu
<jmarciano>and I have gnu somewhere in /gnu/store/...guix.../site/gnu.scm like that
<jmarciano>I wonder why that... I could try loading with hadn
<davexunit>it's because you don't have guix installed to your profile
<jmarciano>hmm, it seems like it magically disappeared...
<davexunit>'guix package -i guix' will install a version of guix there, but it won't be the same version you are using.
<jmarciano>yes, I am doing it now for X time...
<davexunit>if you run 'guix pull', you could add $HOME/.config/guix/latest to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH
<davexunit>then you'll have the latest guix modules available
<jmarciano>aha, let me try that too (I did it few times)
<jmarciano>504, "Gateway Time-out" on but OK, let me try that
<civodul>jmarciano: what tool reports 504?
<davexunit>so much missing information today.
<jmarciano>guix package -i guix --substitute-urls= reports 504
<jmarciano>and I have now latest, but no, it does not find it...
<davexunit>jmarciano: how did you get "latest"?
<davexunit>we *really* need details here otherwise we can only guess and keep guessing wrong.
<jmarciano>ok I removed double path definition... now I get better error: ERROR: no code for module (guix config)
<jmarciano>and in latest, I can see: guix.scm guix directory, etc. gnu.scm, so it loads. but maybe "config" is not loading
<davexunit>does /home/data1/protected/.config/guix/latest/guix/config.scm exist?
<jmarciano>my config looks like:
<jmarciano>inside is definition for config package, but why is extension .in ?
<jmarciano>and no config.scm there.
<davexunit>jmarciano: because config.scm is a programmatically generated file
<jmarciano>what to do to programmatically create it...
<davexunit>it's generated as part of the configure phase of the build process
<davexunit>so it *should* be there
<davexunit>civodul: does 'guix pull' do something special such that guix/config.scm isn't generated?
<jmarciano>hmm, I have only .in sadly.
<davexunit>like skipping ./configure?
<jmarciano>I will do now guix pull for X**X time..
<mkoenig>pull was successful this time
<mkoenig>"copying and compiling to /gn"
<davexunit>jmarciano: that's unlikely to change anything
<mkoenig>is that normal "guix-latest" ?
<dptd>davexunit: Okay, I am done. This time it failed on "guix substitute: error: host name look up error Name or service not known". It is the result of running system init with --substitute-urls set to mirror.
<Jookia>dptd: are you having internet issues?
<Jookia>i recall some VMs have internet issues
<dptd>No, I keep pinging google. Solid ~20ms.
<davexunit>dptd: what is the exact command you are running?
<dptd>guix system init /mnt/etc/config.scm /mnt --substitute-urls=
<davexunit>dptd: did this failure happen immediately or did it successfully download some things?
<ajgrf>if i'm packaging something from git instead of a tarball, how do i know which hash to put in the package definition?
<Jookia>ajgrf: usually i just build then get the new hash from the failure
<davexunit>dptd: if it was a spontaneous error, all I can recommend is to try again. our servers are simply overloaded, unfortunately, and it sucks. we're actively working on getting new servers but it's going to us some time.
<davexunit>going to take*
<davexunit>Jookia: please don't recommend this.
<rain1>thats what i do too
<davexunit>ajgrf: the correct way to calculate the hash of a git repo is to create a clone of that repo that you can safely throw away, checkout the commit you are interested in, *delete* the .git directory, and run 'guix hash -r .'
<rain1>is there a reason to do it that harder more complex way?
<dptd>davexunit: Yeah, I can see that. People are writing that here all the time. Not a problem though, thanks for the help. Answering your question - it is spontaneous error. Some staff is being successfully downloaded.
<ajgrf>Jookia, davexunit: thanks!
<jmarciano>after guix pull, no change... ERROR: no code for module (guix config)
<dptd>I will keep trying though. Love lisp and really want to contribute.
<davexunit>dptd: :/ sorry about that. hang tight everyone! this UX really sucks right now, but it *WILL* be fixed.
<rain1>davexunit, why "don't recommend this."?
<davexunit>rain1: security.
<rain1>that doesn't mean anything
<davexunit>take a look at the source.
<davexunit>don't just assume that the thing that was downloaded was correct
<davexunit>it could've been corrupted
<davexunit>or otherwise incorrect
<davexunit>I don't want to recommend "easy" things that lead to bad habits.
<jmarciano>exactly, that is opposed to why guix is there
<davexunit>the proper easy way would be to extend 'guix download' to handle git repos.
<rain1>well don't but you shouldn't tell other people to stop helping people do their task easily
<kristofer>dptd: does it err installing perl?
<jmarciano>rain1: such things oppose proper usage of package manager.. right?
<rain1>I don't know what you mean by thta
<dptd>kristofer: Random packages. Each run stops on different one.
<jmarciano>that is like when you do on Debian apt-get package, the PGP keys are not trusted, so what do you do? Proceed for insecurity?
<rain1>it's not like that
<Jookia>fwiw i didn't know that was how you did it because it wasn't documented in my guix manual, or maybe i missed it
<davexunit>I care about promoting proper packaging practices. I also care about building tools to make that process the easiest possible path.
<rain1>davexunit, your instructions didn't mention auditing the source code
<rain1>there's no difference in security it's just extra work
<davexunit>I don't have time to argue about this now.
<davexunit>but I know that this isn't the first time that this topic has been brought up.
<mkoenig>gateway tome-out; package "pciutils"
<pizzaiolo>pinging here, also getting 505 timeout error when connecting to or
<jmarciano>you mean
<jmarciano>I can ping it.
<civodul>pizzaiolo: when installing substitutes?
<Jookia>Is there a 'smart' way of making a closure of a staticly linked program not drag in glibc when running "populate-store", without just creating a derivation that copies glibc?
<civodul>you need to find out why the statically-linked thing drags glibc
<pizzaiolo>civodul: yes
<civodul>Jookia: it could be because it actually uses it, or because of debugging symbols, etc.
<pizzaiolo>civodul: I'm trying guix package -u and guix reconfigure, both are throwing the 505 error
<civodul>while downloading /gnu/store/foobar, right?
<pizzaiolo>yes, and also on
<civodul>which /gnu/store item exactly?
<civodul>pizzaiolo: could you paste the URL?
<pizzaiolo> seems to be working momentarily
<pizzaiolo>civodul: sure
<Jookia>civodul: Is there a graph command I could use? I'm also finding wrapping my package in "glibc-for-bootstrap" i causing two glibcs to be copied too
<civodul>Jookia: guix gc -R
<civodul>pizzaiolo: thanks; there was a cache misconfigurations so for a while 504s were getting cached for one hour on
<civodul>so i think this particular item will remain 504 on for a few more minutes...
<pizzaiolo>civodul: all righty
<Jookia>civodul: I see. Is there documentation or code on how this is determined?
<civodul>Jookia: references are determined through "conservative scanning", aka. 'grep -r'
<davexunit>civodul: I think we scared off that one person at my talk in January that asked about the conservative scanning on the mailing list.
<davexunit>he proposed that packages should explicitly encode their runtime dependencies.
<davexunit>wingo: I've managed to crash gnome-shell by activating the "hot corner" and attempting to drag a window to a new workspace
<davexunit>aaaaand it's reproducible.
<davexunit>try to move a window once, some weird graphical stuff will happen and it will kick you out of that overlay menu
<davexunit>try a second time and it will crash with the "Oh no! Something has gone wrong." screen and you have to kill X
<wingo>davexunit: i got that too
<davexunit>this is one of those "I have no idea where to even start debugging" things
<wingo>it's not elogind at least ^-^
<Jookia>I wish I wasn't such a newb when it came to object code
<wingo>davexunit: i think a start would be getting a .xsession-errors file going
<wingo>right now we don't have one afaiu
<davexunit>wingo: ooh but maybe this is! ;) asking GNOME to shut down doesn't work.
<davexunit>and there's no option to log out. :)
<davexunit>wingo: are we missing a service that writes that log file?
<wingo>there are a bunch of errors on tty1 it seems
<wingo>i guess logs are going there
<davexunit>the ol' landfill
<wingo>that is a shepherd problem afaiu
<wingo>so i think the first thing to fix is that gnome-session's warning that says WARNING: Using null backend for session tracking
<wingo>probably gnome-session needs to be compiled with logind support
<wingo>needs same s/// over it as polkit, to change some instances of systemd to elogind
<davexunit>good find :)
<Digit>ACTION notices, besides the guix talk schduled at libreplanet, there's also a debian-centric "Beyond reproducible builds"
<wingo>and needs removal of integration with systemd's journal
<wingo>afaiu that is the extent to which systemd has percolated into gnome-session
<davexunit>Digit: that looks interesting
<davexunit>is that a sunday talk? I hope so.
<davexunit>I have to bail early on saturday
<Digit>yup, the 10am session block, on sun. you're in luck
<Digit> jam packed with goodness.
<Jookia>It seems no amount of stripping will stop glibc paths being put in busybox's program
<mkoenig>do u use the original hydra by nix? or a modified version
<davexunit>mkoenig: modified.
<davexunit>civodul: the mirror for /gnu/store/cnhqk5cwyrfaq7py2l1sq2ddcxxjh7x6-gcc-cross-boot0-4.9.3-lib may be corrupt on
<davexunit>I'm getting a consistent failure trying to 'guix environment --ad-hoc gcc-toolchain' using that mirror
<davexunit>going to see what hydra says
<wingo>davexunit: i'm on gnome-session fwiw
<davexunit>wingo: okay!
<wingo>davexunit: just sent gnome-session change to list; look ok to you?
<NiAsterisk>GNOME works pretty okay
<davexunit>wingo: will look!
<NiAsterisk>not related to your comment. but I just launched it. cool
<wingo>haven't had a chance to try it properly yet tho
<wingo>rebuilding :P
<wingo>rebuilding the system, i mean
<davexunit>wingo: looks good!
<davexunit>if it works for you, I say "push"!
<wingo>will push once i give it a go :)
<NiAsterisk>some akward settings like you described, screen brightness needs root pw, etc. and I had to start rxvt-unicode through some other terminal application
<wingo>for me screen brightness does not need root pw NiAsterisk
<wingo>i assume you installed gnome-desktop-service?
<wingo>not just the metapackage?
<NiAsterisk>no, I just added the package. service somehow is not working for me for any desktop.. with this system:
<wingo>i woudl remove gnome and xfce packages from your packages list and instead add (gnome-desktop-service) and (xfce-desktop-service) to your services
<NiAsterisk>doesn't work
<NiAsterisk>errors are thrown this way, I have not logged them
<wingo>hmmm :)
<NiAsterisk>one moment
<NiAsterisk>rephrasing: errors appear when I have them in packages list and add those two to the services.
<NiAsterisk>mkay. I just got spam from a school district in downingtown.
<jmarciano>NiAsterisk: how do you know it is school district?
<davexunit>ACTION found a problem with 'guix environment --container --network' on ubuntu (possibly other distros)
<jmarciano>you can find last "received" IP address, and whois IP to find where to complain
<NiAsterisk>because it goes back to
<NiAsterisk>darrin cummings, social studies
<jmarciano>that is like From:? Or link in the email?
<NiAsterisk>no, in the raw view of the email
<NiAsterisk>and replyto
<jmarciano>if you see domain name, it need not be true, look for the IP before it came to your server
<NiAsterisk>ah, right
<NiAsterisk>definitely the school
<jmarciano>sometimes school servers can be compromised
<NiAsterisk>ip brings me to an office web access
<NiAsterisk>maybe I find an admin / staff email address. not that I care much, but maybe it helps them to fix it.
<wingo>seems gnome-shell needs gdk-pixbuf+svg
<redshelled>is there a reason running guix system init would be trying to build guix and not using the substitute?
<wingo>oh god it's gtk+ that needs gdk-pixbuf+svg :P
<NiAsterisk>wingo: no, with only the gnome package I get popups of Administrator Authentication Dialogues each time I change the brightness, but I can just ESC that
<wingo>NiAsterisk: I am getting that too fwiw
<wingo>i wonder why
<NiAsterisk>I would if I could see past all the svg errors
<civodul>davexunit: indeed, "wget --save-headers -O t" returns 200 with an empty file
<civodul>will look at it later
<redshelled>dptd: did you fix the issue of the test failing on store.scm
<redshelled>mine is doing the same
<NiAsterisk>also: Mar 17 17:49:51 localhost gnome-keyring-daemon[452]: Unsupported or unknown SSH key algorithm: ssh-ed25519
<NiAsterisk>no idea how keyring daemon is build or if this is intended
<redshelled>and mine is on hardware, not in a vm
<wingo>i had some old gnomey packages installed in my profile
<wingo>after having removed those, my backlight works and i can power off from the menu
<rain1>NiAsterisk, im using ed25519 and its good but i don't think ihave keyring daemon
<wingo>first time since i've had this computer that the backlight keys work :-)
<NiAsterisk>it's just something I noticed, that's all.
<NiAsterisk>a .desktop or whatever for xfce, gnome and others to "see" rxvt-unicode would be nice.
<wingo>holy crap everything works
<wingo>even my pulseaudio now
<wingo>and my volume keys
<davexunit>NiAsterisk: icecat also is in need of a .desktop file
<wingo>i guess we need to add an accountservice or something
<wingo>i.e. a service in addition to the package
<davexunit>hmm I guess so
<davexunit>I haven't fully explored what is missing
<davexunit>I know networkmanager of course
<wingo>i seem to have determined though that you shouldn't have "system"-type things in your user profile
<wingo>at least, i believe that was the source of some problems i was having
<wingo>e.g. gnome-settings-daemon
<wingo>davexunit: so when i tried to drag something from the gnome shell activities view just now
<wingo>it did kill gnome-shell but it restarted fine
<wingo>i wonder if having made gnome-session have a non-null backend "fixed" that too
<davexunit>seems so.
<wingo>and the error that causes it to fail is that it can't load close-window.svg
<wingo>it seems
<wingo>not sure tho
<davexunit>wingo: my brightness controls work!
<davexunit>wingo: gnome-shell crashes still if you try to drag the window a second time.
<davexunit>this is some great progress though.
<davexunit>the close button icon is definitely not showing up so perhaps that is part of the issue
<NiAsterisk>this sucks much battery... I wonder if this battery is broken. I can spot nothing in powertop
<efraim>NiAsterisk: Debian has a package called laptop-mode-tools
<efraim>and a couple of others it looks like
<dptd>Strange. I am during the guix system init and after transferring python from hydra it is stuck with such message. "killing process 20719" and the line below "killing process 20719: no such process".
<dptd>I am waiting more than 10 minutes now - nothing changes. Anyone have seen something like that before?
<efraim>I've seen it occasionally in a terminal window where I _wasnt_ building software
<efraim>I ignored it and waited to see if anything broke but it seemed ok
<efraim>so it's likely a bug but not a fatal one
<dptd>But my installation process is stuck now. Not sure if it will progress any further right now.
<raphmaster>I have seen it me too after or during the download of python-2
<raphmaster>rerun guix system init /mnt/etc/config.scm /mnt and it always stop there by killing process
<NiAsterisk>efraim: yes, but with GuixSD there's no such thing (yet)
<raphmaster>dptd: i am using virtual box like you i think
<NiAsterisk>maybe I should just learn how to read powertop.
<davexunit>another triumph for 'guix environment' today
<paroneayea>davexunit: :O
<paroneayea>tell me more!
<davexunit>not a huge deal, but I was able to make a guix environment container on my ubuntu machine at work that can build and run one of our web applications
<davexunit>it's a good interim solution while we don't have all the *hundreds* of gems that this application needs
<davexunit>I just include ruby, bundler, a gcc toolchain, and the C libs I need
<paroneayea>davexunit: :)
<davexunit>I'm quite happy. this would *not* have worked without containers.
<davexunit>because guix libs and ubuntu libs would have mixed and blown up
<davexunit>and for the folks complaining about not having /usr/bin/env: I just run 'mkdir -p /usr/bin && ln -s $(which env) /usr/bin/env' in my container
<davexunit>I have a patch or two that I want to make to 'guix environment' now to improve things further.
<davexunit>here's my crazy command line:
<davexunit> guix environment --container --network --ad-hoc \\
<davexunit> --share=$GEM_HOME --share=$HOME/.ssh --share=/run/mysqld \\
<davexunit> ruby bundler mysql imagemagick libxml2 libxslt gcc-toolchain \\
<davexunit> make git coreutils openssh libffi pkg-config which sed gawk openssl
<efraim>shouldn't it be echo "TAKE THAT DOCKER"
<rain1>very cool :D
<davexunit>guix environment --container -- echo TAKE THAT DOCKER
<rain1>I need to rememeber these commands
<davexunit>I think this is a good example of a middle-ground state with guix. it doesn't *have* to be all-or-nothing.
<NiAsterisk>do we have an example.scm for a system with luks encryption?
<davexunit>there's a good migration path here.
<rain1>NiAsterisk, for encrypted /home only, I think its not perfect for encrypted root yet
<NiAsterisk>ah, okay
<NiAsterisk>so we're getting there
<rain1>it might already be working well on libreboot? I'm not sure
<rain1>there was an issue about secret derivations
<rain1>I would like to understand it better
<NiAsterisk>core/libreboot, yes
<rain1>was the problem that with the current setup initrd would be readable by everyone? and that lets something .. bad happen?
<mark_weaver>on a libreboot machine, you can have GuixSD with a *fully* encrypted disk, including /boot
<mark_weaver>rain1: that's only an issue if you try to put the encryption key in the grub.cfg, to avoid having to type in the password
<rain1>oh right!
<mark_weaver>or maybe it was putting the password in the initrd
<rain1>so putting a key on a separate USB should work well right now
<rain1>maybe I should try that in a VM
<mark_weaver>yeah, I guess that would be doable
<rain1>and if its a keyfile rather that password entry it cant ask you twice :)
<mark_weaver>normally with that setup, you need to type in your disk password twice: once for grub and once for linux
<mark_weaver>hmm, libotr-4.1.1 is consistently failing one of its tests on my yeeloong
<tg>fbut why would anyone put their encryption keys in grubcfg?
<mark_weaver>tg: actually, I think it was probably the initramfs, not the grub.cfg
<mark_weaver>but there is one reason: if the purpose of the encryption is to protect against a compromised HDD firmware
<mark_weaver>but setting that aside: on a Libreboot/GuixSD fully-encrypted disk setup, since the initramfs is stored on the encrypted root partition, in theory it could contain the disk key to avoid typing the password a second time.
<mark_weaver>however, on GuixSD the initramfs is in /gnu/store, and everything there is world-readable
<mark_weaver>Guix does not currently have any provision for secret data within the stuff that it builds.
<jmarciano>secret data could be on the USB, or it should be left to user how and from where to slurp secret data.
<jmarciano>it would be insecure to fix it in GuixSD configurations.
<jmarciano>my password is sha256 password from a plain text password... I like it that way.
<rain1>jmarciano, how do you input it?
<rain1>it must be too hard to type it?
<redshelled>Is there a way to force a package to install with the substitution and not try to compile from source
<redshelled>or maybe a way to delete a previously downloaded source so that I can install guix and not try to compile it during install
<jmarciano>oh nooo
<jmarciano>but maybe I input it on X, that is why is easy for me.
<jmarciano>I do like: echo (with or without -n, you must remember it) PASSWORD | sha256sum
<rain1>ah i see :)
<jmarciano>but all in one line, few commands, then: cryptsetup create protected /dev/sdX
<jmarciano>then fsck...
<jmarciano>I enter password with mouse...
<jmarciano>on the other hand, the backup disk, has password on my mounted encrypted partition, as file. So that is solved.
<jmarciano>there are various ways, look: man cryptsetup
<jmarciano>it can accept from stdin...
<jmarciano>I did not try, but I guess, that something like: echo | something | sha256sum | cryptsetup --key-file=- should work. Maybe gawk is required too.
<jmarciano>if those tools are available in guixSD start
<jmarciano>look --hash option, I guess that makes it more secure, you enter wee, and you get long hash as passwor
<rain1>that doesn't increase keyspace though
<jmarciano>I have no idea what is "keyspace". I have the space, I put key inside. That?
<rain1>if there are 100 small passwords [keyspace=100]
<rain1>if you hash them all, its true you have big complicated hashes
<rain1>but there's still only 100 of them
<jmarciano>the point is: how is somebody going to know how did you hash it yourself?
<jmarciano>not by tool, but yourself, before the tool is invoked.
<rain1>rather than say 2^256, if you chose a random hash instead of basing it on a password
<rain1>yes thats true, if they don't know that... :)
<jmarciano>random hash is for /tmp, I don't need to know it
<rain1>but you told us!
<zacts>hi guix
<jmarciano>ok I give you beer if you decrypt my hard disk
<jmarciano>free beer
<jmarciano>sometimes I use md5, sometimes sha512, 224, etc. I forget it. But I try it multiple times, and I get it.
<jmarciano>or I forget, did I use echo or echo -n, newline or not...
<jmarciano>echo -n new | sha512sum
<jmarciano>I am not sure if keeping a key on USB stick is "secure".
<rain1>it has different positives and negatives
<jmarciano>and yes, what I am doing DID save my life.
<jmarciano>when bank laptop is stolen... international spying agencies open their eyes and ears.
<jmarciano>If I am asked, /home encryption should be by default. Secondary option would be "No encryption".
<jmarciano>sensitive data in /var - should not be there. Databases shall keep data in /home/var or something
<jmarciano>idea: cryptsetup can be easily used with files, to be read. Keep temporary file on memory, if there is such in Guix. Like /run/shm
<NiAsterisk>that's a good idea, however it is highly discussable. if it were in email/bm thread form I would go into detail with my positive/negative opinions on this.
<NiAsterisk>ACTION afk
<NiAsterisk>jmarciano: one option later could be to ask users in a non-specified graphical setup assistant dialogue to set encryption options, like some *buntu do now or whatever distros these days do.. I haven't looked outside of Tails, Gentoo and others the last years on desktop systems. some started including encryption I heard.
<jmarciano>don't they all have encryption?
<jmarciano>I guess extX file system was not made to be slow, but rather fast. Encryption slows things down.
<jmarciano>/tmp, swap, /var, /home - sensitive data should be.
<jmarciano>and encryption shall be set up quickly, even before the X
<Gamayun>They probably all have encryption. But perhaps not as an easy option in a graphical installer.
<jmarciano>aha like that. I know that Debian has it easy, but I never tried it.
<jmarciano>well, I don't trust installers enough.
<jmarciano>GuixSD will give more control to the user. I can create system.scm or something, and always get what I want and nobody else.
<suitsmeveryfine>Hmm, is there a delay before emails are delivered to the devel-list?
<civodul>suitsmeveryfine: the first message can take an hour or two; subsequent messages directly get in
<suitsmeveryfine>Thanks civodul. I'll then just send this warning to any MacBook2,1 users here that might be thinking of building from master: DO NOT try to suspend to ram in Gnome 3. It just corrupted my file system.
<suitsmeveryfine>which is totally fine in my case. I've just been using that system to do testing on behalf of the Guix SD project.
<suitsmeveryfine>But I'll now give up and switch to Parabola on that particular computer :)
<mark_weaver>I've been investigating the libotr test failure on mips, and so far it seems very likely to be a code generation bug in gcc :-(
<mark_weaver>adding print statements to investigate the failed check fixes it
<mark_weaver>suitsmeveryfine: the suspend-to-ram problem with Gnome 3 on GuixSD seems to happen to all of us, but this is the first I've heard of filesystem corruption from it :-(
<mark_weaver>actually, that bug is the reason I switched back to Xfce for now
<suitsmeveryfine>OK. Well, I'm not reinstalling GuixSD at this time also because I can't get the touchpad to work.
<suitsmeveryfine>Gnome 3 was usable without a mouse but Xfce isn't.
<mark_weaver>suitsmeveryfine: that's very surprising. are you sure you didn't end up with an old version again?
<mark_weaver>oh well, sorry it didn't work out for you :-(
<pizzaiolo>suitsmeveryfine: thanks for the heads up
<suitsmeveryfine>It's not your fault!
<pizzaiolo>I'll be sure to not suspend to ram
<mark_weaver>fwiw, suspend-to-ram works on Xfce
<mark_weaver>in fact, it even works from the logout menu now.
<suitsmeveryfine>mark_weaver: no it doesn't
<mark_weaver>it does for me, anyway
<suitsmeveryfine>on the macbook2,1 :)
<mark_weaver>and for some other people here
<mark_weaver>the problem was fixed very recently, maybe you didn't try the version that fixed it
<pizzaiolo>yeah so far I've had no issues in xfce
<suitsmeveryfine>Yes, I wrote that mainly to pizzaiolo so that he would't try it in Xfce.
<suitsmeveryfine>pizzaiolo: resuming from suspend in Xfce used to worked for me but then it stopped
<pizzaiolo>suitsmeveryfine: my only issue with suspend to ram so far has been an unresponsive touchpad
<civodul>hey, lfam
<lfam>Hi civodul!
<suitsmeveryfine>pizzaiolo: yes, but there have been many new changes related to power management in the more recents commits.
<civodul>lfam: great work on the Biber review, once again!
<pizzaiolo>I see
<lfam>civodul: Thanks! And indeed, I am glad you replied as well
<jmarciano>I was suspending like this: sudo sh -c '/bin/echo mem > /sys/power/state' and it worked well with my encrypted partition.
<suitsmeveryfine>jmarciano: OK, I just closed the lid.
<lfam>I'm still having trouble with https substitutes on my "foreign distro" system. I think that I must have done something to root's copy of guix (used by all users) that is preventing it from upgrading
<mark_weaver>closing the lid hasn't worked for me on the Libreboot X60, but choosing "logout" from the Xfce menu and then clicking on "suspend" works for me now
<jmarciano>it is different from ACPI to ACPI
<mark_weaver>that's a very recent fix
<lfam>I see that people are talking about power management on xfce. Is there a consensus that xfce4-power-manager has improve the situation? Or degraded ti?
<civodul>lfam: which problem do you have?
<jmarciano>It is GUI, how it could improve the situation... ;-)
<mark_weaver>so, if closing the lid simply doesn't do anything for you, what I described above may work
<lfam>civodul: I get the backtrace from #22937
<mark_weaver>lfam: at some point recently, things improved dramatically for me with Xfce, but I'm not sure whether it was xfce4-power-manager or wingo's (xfce-desktop-service) or some combination.
<suitsmeveryfine>mark_weaver: closing the lid worked before but not any more (in Xfce on the macbook)
<suitsmeveryfine>unfortunately I can no longer test the above command.
<lfam>In root's profile, I have /gnu/store/...-guix-0.9.0.f888c0b, which is the daemon I'm using
<suitsmeveryfine>mark_weaver: closing the lid also doesn't work on my libreboot+T60 on any GNU/Linux distro. The screen then stops working.
<civodul>lfam: oh so that means guix-daemon calls the "old" 'guix substitute'
<civodul>lfam: maybe /root/.config/guix/latest points to an older Guix?
<lfam>Okay, I did do `guix pull` and `guix package -u .` yesterday
<mark_weaver>suitsmeveryfine: Libreboot on the X60 seems not to provide the usual ACPI events to the OS, or something along those lines.
<lfam>It points to /gnu/store/is65rfjl6iakmif60ybyzii7rxagj5n6-guix-latest
<mark_weaver>suitsmeveryfine: the situation might be similar on other computers of a similar generation, e.g. the T60 and Macbook2,1
<lfam>Which appears to be 47 years old ;)
<civodul>lfam: :-) could you compare substitute.scm in that directory to what we have currently in master?
<lfam>ACTION looking
<suitsmeveryfine>mark_weaver: yes, one might think so but the T60 and MacBook2,1 are quite different
<rain1>mark_weaver, that otr thing is really interesting
<rain1>I wonder what it will take to make reproducible builds
<suitsmeveryfine>mark_weaver: the brightness controls and touchpad work differently also.
<mark_weaver>rain1: another possibility, I suppose, is that the test code depends on undefined behavior in C
<rain1>that makes sense!
<mark_weaver>I need to investigate further
<rain1>I think we need a boringc like djb brought up at some point
<mark_weaver>rain1: well, compiling it with -O0 would probably fix problems like this
<lfam>civodul: The substitute.scm in root's 'latest' is identical to that of current master
<lfam>I bet that, a few months ago, I did `guix package -i guix` as root. I wonder if that could cause this issue?
<civodul>hmm no
<civodul>maybe you could 'strace guix substitute' as root and see which substitute.scm is being used?
<lfam>Good idea
<lfam>I've never run `guix substitute` before :o
<jmarciano>where in which package can I find this background?
<mark_weaver>jmarciano: it should be somewhere in the guix-artwork git repository:
<mark_weaver>jmarciano: for the code that arranges to use it in our slim service, see %default-slim-theme in gnu/services/xorg.scm
<rain1>recently i get this:
<rain1>(midori4:20870): GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy' is not installed
<rain1>so i can't use midori, but it's odd because I do have gsettings-desktop-schemas in the propagated-inputs
<rain1>if i recompile midori (using package -i) it works again
<mark_weaver>jmarciano: it's in here:
<lfam>rain1: If it works after rebuilding midori, perhaps some dependency of midori changed in a way that broke things?
<rain1>it might be from a system reconfigure
<mark_weaver>rain1: iiuc, midori uses an old version of webkit that has large numbers of security flaws
<lfam>Yeah, the "live reconfiguring" feature is not 100% perfect yet :)
<rain1>im getting firefox as we speak
<rain1>i blame gschema to be honest
<NiAsterisk>wild. So I wrote a new package, and it used to work in the first tests, but now pre-inst-env guix build can't even locate it.
<lfam>Perhaps the code in the package definition is malformed
<NiAsterisk>maybe.. but then lint would be able to find it. and it is just unknown
<lfam>No, I've had lint be unable to find package definitions due to malformed code
<NiAsterisk>oh :)
<NiAsterisk>okay, I'll check it once more
<lfam>Good luck. Feel free to share it if you get really stuck
<mark_weaver>I think I found the problem in the libotr test suite
<mark_weaver>I no longer suspect a bug in gcc
<mark_weaver>test_auth_clear in test_auth.c never initializes the context. there's a missing call to otrl_auth_new(&ctx);
<mark_weaver>it works by accident on some platforms, presumably because of the way those static test functions get inlined together into the same parent function
<lfam>civodul: I confirmed with strace that `guix substitute` is using the same code as that of the current master branch. However, I find that when I run the daemon from a root shell, I can fetch over https! It's only when running the daemon with systemd that things go awry. But, the systemd service file executes this file: /root/.guix-profile/bin/guix-daemon, which is what I am running in that root shell.
<lfam>Also, when running the daemon from root's shell, if my regular user does not ask for an https substitutes-url, I fetch from, rather than some https URL. I'm not sure if that is expected or not.