IRC channel logs


back to list of logs

<anthk_gnu>quiliro, del norte de EspaƱa
<anonkun>can the guix package manager do some of those things? I'm more interested in a pkg-file or apt-file function
<alezost>anonkun: no, there is no analog of pkgfile :-(
<anonkun>It's fine
<anonkun>I only needed to ever use it once
<civodul>'lo Guix!
<UNKNOWNBUCKETHEA>is guixsd download sources from web and compile by itself or just download binaries and installs it?
<anonkun>You can download the binaries, use dd to make a bootable USB
<anonkun>and then install it
<rekado>sources are cached by hydra. You can choose to download binary substitutes from hydra or build the packages locally from source.
<UNKNOWNBUCKETHEA>I can't boot my computer to GuixSD which ends with kernel panic. Now, I'm in VirtualBox. And I followed installation instructions.
<UNKNOWNBUCKETHEA>As I understand its building from source :/
<UNKNOWNBUCKETHEA>SKIP: tests/ and things like that I saw.
<civodul>UNKNOWNBUCKETHEA: this happens while trying to install from the 0.10.0 USB disk?
<civodul>you mentioned a kernel panic, could you give more details?
<UNKNOWNBUCKETHEA>I rebooted my computer after kernel panic I don't take any notes about that. :/ After, I started to try on VirtualBox. I booted up without kernel panic. It's working normally. But look at this screenshot: This is screenshot:
<UNKNOWNBUCKETHEA>I followed installation instructions. My last command is "guix system init /mnt/etc/config.scm /mnt"
<UNKNOWNBUCKETHEA>About 1 hour ago.
<civodul>UNKNOWNBUCKETHEA: the screenshot shows that things are built from source, which is annoying but ok
<UNKNOWNBUCKETHEA>Hmm, do you know which command helps to install with binaries?
<civodul>it automatically uses binaries if they're available, and falls back to building from source otherwise
<civodul>i would expect binaries to be available, but perhaps they vanished on our side (which we should fix)
<UNKNOWNBUCKETHEA>Hmm, okay. Thank you for help. :-)
<civodul>so for now you just have to let it continue :-)
<UNKNOWNBUCKETHEA>Okay, :-) It's good to see a distribution from GNU itself. I hope it'll be successful. Peace from Turkey. :-)
<alezost>UNKNOWNBUCKETHEA: did you do "guix pull" before "guix system init"?
<civodul>alezost: this shouldn't be necessary
<alezost>civodul: apparently without it UNKNOWNBUCKETHEA builds something from source
<UNKNOWNBUCKETHEA>Hmm, it's not mentioned in instructions. :/
<alezost>ACTION is cowardly quitting
***kelsoo1 is now known as kelsoo
***ringst_ is now known as ringst
<mg_>Is there any resource for looking up whether linux-libre supports your hardware? I have a x230 I'd like to have guixsd on
<mthl>mg_ for a Thinkpad x230 the only issue would likely be the wifi internal card
<rekado>note that replacing the card with another one might not work as expected due to the restrictive Lenovo BIOS.
<mthl>you can fix the issue by getting a RYF certified USB wifi dongle
<mg_>mthl: thanks
<mg_>mthl: I guess guixsd is out then :(
<rekado>I'm using GuixSD on a Thinkpad x200s.
<rekado>(I don't miss WiFi much.)
<mg_>Has anyone tried nixos, and using guix for dependencies?
<mg_>rekado: well, I need wifi
<mg_>I love the idea of nix and guix, but I hate the syntax of nix
<rekado>there are two options: you can use a USB wifi dongle or you can replace the BIOS with coreboot/libreboot.
<rekado>I think there's no libreboot for the x230.
<mthl>mg_: See for usb wifi dongle
<mg_>mthl: I'd prefer to avoid the dongle. I understand the reasoning behind using -libre, but I wish guixsd was available with a kernel with intel drivers :/
<civodul>see also
<mthl>Does someone is using powertop in GuixSD?
<civodul>sneek: later tell mthl powertop fails for me on GuixSD with "Model-specific registers (MSR) not found (try enabling CONFIG_X86_MSR)"
<sneek>Will do.
<janneke>morning guixers!
<mthl>civodul: I have the same error with powertop
<sneek>Welcome back mthl, you have 1 message.
<sneek>mthl, civodul says: powertop fails for me on GuixSD with "Model-specific registers (MSR) not found (try enabling CONFIG_X86_MSR)"
<civodul>hey, janneke!
<civodul>mthl: yeah, so something needs to be fixed :-)
<civodul>i don't know what the internet has to say on this topic
<mthl>civodul: found
<civodul>there are 2 distros in the world that have this problem :-)
<mthl>modprobe msr fixes the issue for me
<civodul>oh, "/sbin/modprobe"
<civodul>right, works for me too
<civodul>but we should patch that /sbin/modprobe
<civodul>not sure what "ms/s" means
<civodul>wakeup frequency?
<mthl>maybe it is a '/' mean or
<mthl>but i would make much sens
<mthl>I think when you have done enough calibration those are replaced by Watts
<civodul>vlc builds & builds reproducibly! \\o/
<mthl>I have seen the commit log
<ng0>hi. anyone could do a minor review of verbosity or repetion on the second paragraph on i'll push the update to womb maint and pick up work on the gnunet packages here soon.
<ng0>*could anyone do
<civodul>for the Womb the description should focus on the software rather than on the "high-level goal" of the project, IMO
<mthl>civodul: is it normal that you have used 'snippet' in commit 4ef2721b52c4929aac15db4f8b39702cd37955a1?
<ng0>well that is the project description i am doing. or did I misunderstand what should go into womb? gnunet has no focus on p2p as it is more like you know.
<civodul>mthl: i think it makes sense to do it here; i guess there's no definite answer on what goes in a snippet and what goes in a phase
<mthl>OK, maybe the manual should be updated. I thought snippet was reserved for FSDG things.
<civodul>that's the main use case, but not the only one IMO
<civodul>i think the idea is that people can build something very similar by starting from "guix build -S foo"
<civodul>it's similar to regular patches
<civodul>the change here could have been written as a patch
<ng0>if the purpose of womb is the description of the software, and the description of the software includes the highlevel goal, is that wrong? Should I just remove the highlevel goal and it's good? The last update to it included even more of a high level goal and was accepted by womb
<mthl>civodul: OK
<civodul>ng0: yeah maybe you're right, dunno; you should just propose it to bug-womb and see what they think
<ng0>see the current womb description of gnunet, mostly done by myself, collab corrections by other people in the project. The current edit on is just to make some minor fixes.
<mthl>civodul: for powertop what would be the preferred way to patch the source files?
<mthl>with absolute directories or by relying on PATH
<civodul>mthl: absolute directory of kmod, i would say
<civodul>iyzsong: on gnome-updates, glib fails on i686:
<civodul>apparently SIGSEGV during a test
***piyo` is now known as piyo
***civodul changes topic to 'GNU Guix | | videos at | 0.10.0 is out! | bugs: | paste to | channel logged:'
<ng0>civodul: bug #14851 regarding linux-libre-3.3.8 tarball disappearance, is this still relevant or can it be just closed?
<civodul>it can probably be closed
<civodul>ACTION is glad to see someone do some triage :-)
<ng0>i just see 20 closed bugs and many many open ones.. which makes me suspicious that there have to be forgotten to be closed bugs.
<bavier>sneek: later tell quiliro try adding "/b43" or "/b43-open" to the "PREFIX" declaration in your openfwwf-firmware package definition. that should install the firmware to the appropriate subdirectory for the firmware activator. your persistence is appreciated :)
<lfam>I'm doing a final review of the patch adding liboauth:
<lfam>It links against openssl, but does that mean we have to add openssl to the list of licenses in the liboauth package definition?
<lfam>Grep doesn't show any bundled openssl code
<bavier>lfam: I don't think so
<bavier>as long as it's not bundled
<lfam>I didn't think so either. There is a LICENSE.OpenSSL file in the tarball, so I think Rene was being appropriately cautious
<lfam>That file begins like this: Certain source files in this program permit linking with the OpenSSL library (, which otherwise wouldn't be allowed under the GPL.
<lfam>I guess I'll reply to the list, because this situation isn't clear to me.
<lfam>The recent "syscalls" commit has broken the build in my repo. I can build from fresh repo but I can't seem to rebuild.
<lfam>I tried `make clean` but that didn't help. Any advice?
<lfam>Here's how it fails:
<lfam>Well, I'm not sure that commit is the problem. Checking now
<lfam>I think it was due to the difference between `guix environment guix` and `./pre-inst-env guix environment guix`
<cbaines>After running reconfigure, is it normal to log out and back in again, or restart the machine?
<civodul>lfam: i think it's a different problem: the syscalls change doesn't touch the C++ code
<lfam>civodul: Okay, I didn't really figure it out. Using `./pre-inst-env guix environment guix` allowed me to keep working so I stopped investigating
<civodul>hmm ok
<lfam>As if the Guix provided by `guix pull` (only a day or two old) could not provide the correct environment to build HEAD
<lfam>Except when starting from a fresh git clone
<ajgrf>i need to get the output path of another package to put in #:configure-flags. anyone know the best way to do this?
<bavier>ajgrf: (assoc-ref %build-inputs "foo")
<ajgrf>bavier: thank you!