IRC channel logs


back to list of logs

<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
<civodul>not sure what happens in qemu
<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!
<efraim>cve2015-7575: time to update openssl to 1.0.1f and probably gnutls also
<mark_weaver>efraim: I looked into it and it seemed that our versions of openssl and gnutls were not affected. are you sure?
<lfam>It looks like gnutls was fixed in 3.4.1:
<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>lfam +1 regarding gnutls, and for openssl: states that 1.0.2e is not vulnerable
<mark_weaver>I came to the conclusion that nss was the only thing to update, and did so 31 hours ago.
<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.
<lfam>Ah, 1.0.2
<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 and the debian security-announce mailing list
<efraim>mark_weaver: ah, i missed the 2 part of 1.0.2e
<mark_weaver>but the oss-sec mailing list is also a good thing to monitor. or on gmane.
<mark_weaver>and yeah, the linter is surely helpful as well
<zacts>can I configure wifi off of the liveusb?
<zacts>(of the latest pre-release)
<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>oh nice
<zacts>let me try this now
<zacts>which kernel does the latest pre-release of GuixSD use?
<zacts>v0.9.0 I guess
<mark_weaver>where a typical config file would contain:
<mark_weaver> ssid="Home"
<mark_weaver> key_mgmt=WPA-PSK
<mark_weaver> psk="your passphrase here"
<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>it's 4.2.5
<zacts>it's supported then
<mark_weaver>zacts: after running wpa_supplicant, you'll also need to run "dhclient <net-device>"
<mark_weaver>(assuming DHCP)
<zacts>ah ok
<zacts>indeed DHCP
<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
<mark_weaver>I don't know, sorry
<lfam>With X it works fine
<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
<mark_weaver>it's often added to linux-libre
<mark_weaver>the bathing signifies the removal of non-free blobs
<lfam>Yup :)
<zacts>mark_weaver: I keep on getting 'server is somewhat slow' messages
<zacts>my network just got disconnected
<zacts>it's working now
<taylan>wow, hydra is a thousand times faster today than yesterday
***jubalh is now known as Guest12494
***Guest12494 is now known as jubalh_
<alezost>jubalh_: hello
<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_>nice efraim
<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
<karhunguixi>Very exciting!
<karhunguixi>Hopefully 1.5.2 will be added after that :)
***luke-jr_ is now known as Luke-Jr
***iElectric is now known as domenkozar
<cehteh>mhm ..
<cehteh>found an old USB flash .. thought i could use it as guixsd install stick
<cehteh>Model: USB Flash Disk (scsi)
<cehteh>Disk /dev/sdc: 65,3MB
<cehteh>.. no :)
<cehteh>0.46mb/sec writes \\o/
<rekado>finally fixed the cross-compiler problem. Had to enable multilib.
<rekado>now the firmware actually works.
<efraim>awesome rekado
<mark_weaver>rekado: woohoo!
<rekado>now I don't really now how to best submit these patches...
<rekado>the compiler toolchain uses sources from
<rekado>they offer a tarball containing tarballs.
<rekado>it's one distribution.
<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?
<civodul>in that big tarball
<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>a new module "embedded.scm"?
<rekado>so I'll use the individual upstream sources and add comments somewhere to remind people to update them together.
<civodul>rekado: maybe embedded.scm, yes
<civodul>so that won't work with the pristine Binutils?
<civodul>this is terrrible
<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>I can do this again.
<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>rekado: i wonder too!
<civodul>sometimes people seem to use all-caps for software package names or something
<civodul>very weird
<civodul>(not complete yet)
<mark_weaver>I suspect it's because UNIX is usually written in all caps
<civodul>IS IT?
<mark_weaver>heh :)
<civodul>but yeah, that could be the reason
<civodul>yet, we also see people write "Gnu"
<mark_weaver>boost-1.60 fails to build on mips64el :-(
<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
<mark_weaver>I could ask RMS
<mark_weaver>he would probably know who to ask anyway
<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.