<civodul>lfam: the desktop thing includes Wicd <lfam>Yeah, but it doesn't seem to work properly out-of-the-box <lfam>Of course, I might be invoking qemu improperly. But I do find that the bare-bones template works as expected <civodul>normally wicd detects wired networks and runs dhclient automatically by default <lfam>For both the bare-bones and the desktop, I attempt `guix environment --ad-hoc curl` after first boot. It works without issue in the bare-bones system. In the desktop sytem, it gets to the point where it runs the bootstrap guile. Then, there is a series of warnings about unbound variables in download.scm (make-session etc) and then it fails when it can't find /etc/resolv.conf <lfam>It works after `dhclient eth0`, so I guess that wicd is not running dhclient successfully, or at all <civodul>you should try running wicd-client or similar to see <lfam>How can I pass arguments to the kernel in GuixSD? <mark_weaver>lfam: see the 'kernel-arguments' field of the operating-system configuration. See 'operating-system' Reference in the manual, section 7.2.2 <lfam>Thanks mark_weaver. Hey, did you get a chance to look at the w3m changes? <mark_weaver>lfam: not yet, but if it works for you I don't doubt it will work for me too. thank you! <mark_weaver>efraim: I looked into it and it seemed that our versions of openssl and gnutls were not affected. are you sure? <efraim>it popped up on debian security for openssl so I assume we're affected, haven't looked at it too closely <efraim>we could always toss it into core-updates <lfam>That page says that NSS is vulnerable < 3.21, but the link to the bugzilla is private <mark_weaver>efraim: our openssl package is 1.0.2e, which is the latest release. 1.0.1f would be a downgrade. <lfam>The debian page says that openssl 1.0.1e is not vulnerable, but the mitls page says that it is. <mark_weaver>having said all this, I very much appreciate having more people paying attention to security updates. thank you! <mark_weaver>more eyes make it less likely that things will be missed :) <lfam>guix pull: error: tarball did not produce a single source directory <lfam>How do you keep on top of the CVEs? Is there a mailing list? Or a web page you check? <lfam>Oh, I guess I could just use the linter's built-in CVE checker <efraim>i'm subscribed to the debian-security mailinglist <mark_weaver>I confess that I mainly just watch security announcements on lwn.net and the debian security-announce mailing list <efraim>mark_weaver: ah, i missed the 2 part of 1.0.2e <zacts>can I configure wifi off of the liveusb? <mark_weaver>zacts: you can do so by creating a wpa_supplicant.conf config file and running: wpa_supplicant -i <net-device> -c wpa_supplicant.conf -B <zacts>which kernel does the latest pre-release of GuixSD use? <zacts>I grok how to config wpa_supplicent.conf <mark_weaver>out of curiosity, why do you want to know the kernel version? <zacts>mark_weaver: to see if atheros wifi devices are supported with a recent driver <mark_weaver>zacts: after running wpa_supplicant, you'll also need to run "dhclient <net-device>" <lfam>Any idea how to configure the size of the Linux console in GuixSD? I think it's at 640x480 by default. I've been trying some different values to the "vga=" kernel parameter but they really don't do the right thing <mark_weaver>lfam: on my machines the kernel seems to automatically determine the right resolution <lfam>I guess because this is in qemu it doesn't work as expected <lfam>The weird thing is that the grub menu is larger than the console <lfam>Ah, vga=791 worked. I guess it doesn't like hex numbers <lfam>Not sure about the cartoon at the top, though <lfam>I've never seen the "bathing tux" before <zacts>mark_weaver: I keep on getting 'server is somewhat slow' messages <zacts>my network just got disconnected <taylan>wow, hydra is a thousand times faster today than yesterday ***jubalh is now known as Guest12494
***Guest12494 is now known as jubalh_
<jubalh_>ACTION attempts his desktop install of guixsd today <efraim>I have to put it down for now, but wanted to share: @ build-succeeded /gnu/store/q2xfl4nipmicq08fg9x31jj96mxa34ls-go-1.4.3.drv <jubalh_>i am looking forward to have go on guix <jubalh_>how can i stop the slib service? i would like to use startx for some testing of window managers ***luke-jr_ is now known as Luke-Jr
***iElectric is now known as domenkozar
<cehteh>found an old USB flash .. thought i could use it as guixsd install stick <rekado>finally fixed the cross-compiler problem. Had to enable multilib. <rekado>now the firmware actually works. <rekado>now I don't really now how to best submit these patches... <rekado>they offer a tarball containing tarballs. <rekado>I could download the individual sources from SVN and git, but as they should only be updated together I think it's best to tie them together by using the same source tarball. <rekado>but that makes it impossible to apply patches in the source expression <rekado>(it would have to be done via build phases) <rekado>what is the preferred way to go here? <rekado>big nested tarball for binutils, gcc, c library (newlib) --- or fetching the sources from their respective version control systems at specific revisions/commits? <civodul>rekado: congrats on the achievement! <civodul>rekado: do all of binutils, gcc, and newlib contain patches? <rekado>the big tarball contains the very same sources that I could also get from SVN + git. <rekado>no additional patches as far as I can tell. <rekado>another problem is where to put the package expressions; they need texinfo for building docs (as they are just SVN/git checkouts and do not contain built docs), so I cannot add them to gcc or cross-base, or else there would be a cycle. <rekado>so I'll use the individual upstream sources and add comments somewhere to remind people to update them together. <civodul>so that won't work with the pristine Binutils? <rekado>I haven't tried building this with just the regular binutils, using the configure flags that I have now determined to be required. <rekado>with the exact same version of the toolchain as the upstream project uses I could get the exact same binaries for the board. This was very encouraging. <rekado>ACTION wonders why so many people keep writing "Guix" as "GUIX" <civodul>sometimes people seem to use all-caps for software package names or something <mark_weaver>I suspect it's because UNIX is usually written in all caps <civodul>could it be that -m32 patch that was removed? <mark_weaver>maybe we should just drop that platform. I don't have the energy to keep it up, and it seems that no one else is much interested in it either. <civodul>s/is interested in it/has access to it/, even <mark_weaver>I've run out of patience waiting for Lemote to produce an updated machine that can be used without non-free blobs. <civodul>is there any chance we could talk to someone who has more insight about Lemote's plans? <civodul>that could help make an informed decision <rekado>bleh, the compiled firmware does not work when built with just the stock binutils+gcc+newlib sources. <rekado>next up: changing them one by one to find out which of them needs special sources.