<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 :-( <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 <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. <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: http://i.hizliresim.com/6PVo5P.png <UNKNOWNBUCKETHEA>I followed installation instructions. My last command is "guix system init /mnt/etc/config.scm /mnt" <civodul>UNKNOWNBUCKETHEA: the screenshot shows that things are built from source, which is annoying but ok <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) <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 ***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: I guess guixsd is out then :( <rekado>I'm using GuixSD on a Thinkpad x200s. <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. <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 :/ <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)" <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>mthl: yeah, so something needs to be fixed :-) <civodul>i don't know what the internet has to say on this topic <civodul>there are 2 distros in the world that have this problem :-) <mthl>modprobe msr fixes the issue for me <civodul>but we should patch that /sbin/modprobe <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 gnunet.org? i'll push the update to gnu.org womb maint and pick up work on the gnunet packages here soon. <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>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 gnu.org womb <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 gnunet.org/about 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 ***piyo` is now known as piyo
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos at https://gnu.org/s/guix/help/#talks | 0.10.0 is out! | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | paste to http://paste.lisp.org | channel logged: https://gnunet.org/bot/log/guix'
<ng0>civodul: bug #14851 regarding linux-libre-3.3.8 tarball disappearance, is this still relevant or can it be just 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>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 <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 (http://www.openssl.org), 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>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 <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") 