IRC channel logs

2018-04-11.log

back to list of logs

<PotentialUser-74>so im trying to reconfigure and im having an error
<PotentialUser-74>I just added kenrnel and firmware parts to my config
<PotentialUser-74>and im getting error: extraneous field initializers (kernel-arguements)
<PotentialUser-74>alright so i fixed that
<PotentialUser-74>so i added (use modules (gnu packages linux-nonfree))and im getting an error "no code for module (gnu packages
<caffe`>so i can see that i have the b43-open firmware package installed, but still the driver fails to load firmware
<caffe`>b43-phy0 ERROR: Firmware file "b43-open//*(DEBLOBBED)*/.fw" request failed (err=-22)
<zybell_>Is the firmware at this place?
<caffe`>yes, i've verified that it's in the path, and the firmware files are indeed there
<caffe`>according to /sys/module/fimware_class/parameters/path
<zybell_>what is before b43-open?
<caffe`>/gnu/store/pklc850lisy25r45zg96s52q9xc0d93n-firmware
<caffe`>/gnu/store/pklc850lisy25r45zg96s52q9xc0d93n-firmware/lib, actually
<caffe`>ugh. no. /gnu/store/pklc850lisy25r45zg96s52q9xc0d93n-firmware/lib/firmware/ (then b43-open)
<zybell_>and cat /sys/module ... path gives you that?
<caffe`>yes
<zybell_>including the last slash?
<caffe`>no
<zybell_>could be a simple strcat in kernel
<zybell_>then the slash would be needed
<caffe`>so should i try adding a slash and rebooting?
<zybell_>Is the WiFi card fixed?
<zybell_>Or PnP
<caffe`>fixed as in internal, then yes.
<zybell_>Ok, you need to find the .scm-file that sets the path (or possibly a shell script)
<zybell_>Because on reboot the path is set again
<caffe`>yeah, i noticed
<caffe`>and don't know where to begin looking
<zybell_>gnu/store/*-firmware
<zybell_>./*bin
<zybell_>I like the theory that the firmware-package contains these files too.
<caffe`>there is no .scm file there
<caffe`>a few scripts, but nothing specific to guix
<zybell_>check if one script contains /sys/mod...
<caffe`>nope
<zybell_>How many binary executables are there?
<caffe`>one
<caffe`>i got the driver to 'load' when i echoed $(guix build openfwwf-firmware) > /sys/mod.../path, but no good result. "Dual-core devices are not supported."
<zybell_>run strings name |grep module/firmware on the binary and if you did grep on the scripts try with that string too. Remembered some sw reads /sys from fstab.
<zybell_>what does guix build put into path, meaning what is shown without redirect?
<caffe`>that's a hell of a lot to retype
<caffe`>also, no results on that binary for that string
<zybell_>slash at end?
<zybell_>from guix build
<caffe`>no slash
<zybell_>possibly a udev issue
<zybell_>no slash to path& firmware found=>no simple strcat=>other error
<zybell_>firmware load:either directly by kernel or... by UDEV
<caffe`>well, seeing as i got it to load only to see "Dual-core devices are not supported.", I don't think b43-open is really going to help me regardless of whether the firmware loads or not
<caffe`>so i'm just going to stop here and move onto building a new kernel that allows me to load the firmwares needed to use the card at all.
<zybell_>Dual core wifi card or Dual core CPU
<caffe`>Neither, actually.
<caffe`>I'm guessing the error message means dual-core wifi card, but then again it's the same revision that's supposed to work according to the HCL
<zybell_>The driver was tried/loaded second time Possibly a counter was set and checked and a second load ascribed to a second core
<caffe`>It's a far cry from 'out of the box' support as claimed, in any case.
<caffe`>i had to install a duplicate of the driver and intervene manually to get the firmware to load at all.
<zybell_>when it is in /lib/firmware as god decried out of box
<zybell_>But you must run a crazy dist
<zybell_>;-)
<caffe`>just guixsd
<zybell_>where nothing is where it should be;-)
<zybell_>A little configuration is needed. Normally the guix command does that.
<zybell_>Now there is a bug.
<zybell_>In the configuration of the guix command.
<caffe`>oh, there's plenty of bugs. i was expecting that
<zybell_>But if that bug is found,the config is more stable for other linux as well.
<caffe`>well, what i'm referring to has existed at least since 2016, judging by mailing list archives
<zybell_>do you have a usb-wifi or another usb-device that needs fw?
<caffe`>i don't have my hopes up that it's going to be fixed anytime soon.
<caffe`>no, and i bought this card because it was claimed to be supported
<zybell_>The idea is to debug fw load in the general case.
<zybell_>Then your card may work by windfall
<caffe`>Yeah, I'll just build a non-free kernel and run that until the day comes.
<zybell_>?
<caffe`>And try to buy hardware that doesn't run into as many jams with linux-libre in the future
<caffe`>but unfortunately, a laptop is pretty much a paperweight without a working network connection.
<zybell_>What has non-free kernel to do with that? Btw is the fw in initrd?
<caffe`>because it will allow me to load firmwares that actually work when they're loaded.
<zybell_>not if they aren't there when they are needed. in initrd.
<caffe`>and save me the trouble of trying to hunt for .scm files that don't actually exist, or being sent on any other wild goose chases that come up with no results.
<caffe`>sorry, just... i've wasted enough time on this today and it's going nowhere
<zybell_>maybe a simple rebuild of initrd is enough
<caffe`>i'll humor you, but... i don't think that's going to help
<caffe`>it has the correct path
<zybell_>And a reboot ofc;-)
<caffe`>okay, nevermind, i don't know how to rebuild the initrd on this system
<buenouanq>on guix system init, am I supposed to mount the boot partition to /boot/efi or /mnt/boot/efi ?
<caffe`>buenouanq: /mnt/boot/efi
<buenouanq>caffe`: I did just normal /boot/efi and it worked.
<buenouanq>┐( '~')┌
<Sleep_Walker>can I define environment in similar way how I can define package?
<Sleep_Walker>or it's actually the same object but how it is handled is in different way (no record about being part of system profile, no build system just exec of shell)
***Gamayun_ is now known as Gamayun
<ajjlmau>how should I configure my system if I would want to login with getty and use startx to start window manager?
<rekado_>ajjlmau: have you searched the GuixSD manual for getty yet?
<ajjlmau>rekado_: yes, but I'm not still sure what I should do
<ajjlmau>I don't know maybe I should just use slim or sddm
<allana>Hi, I am getting a few errors when trying to import a nix package. The first one is "In execvp of nix-instantiate: No such file or directory". I have cloned the nixpkgs repo to my local machine, under ~/projects. Following the guix documentation, I have set NIX_REMOTE=daemon and ran the example: "guix import nix ~/projects/nixpkgs/ libreoffice". Can anyone help me by letting me know what I am doing incorrectly? Assuming user error here.
<allana>guix documentation that I am referring to: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html
<ajjlmau>I want to use adblock via hosts file but the file would be too large to be in the configuration file
<ajjlmau>how should I do this?
<ajjlmau> https://github.com/StevenBlack/hosts
<rekado_> https://www.biorxiv.org/content/early/2018/04/11/298653
<jlicht>hey guix!
<allana>Has anyone had experience using "guix import" on nix packages? I have been unable to replicate the example provided in the guix documentation for libreoffice.
<Apteryx>Anyone else having issues with webkitgtk? It seems its source don't even build fine: http://paste.debian.net/1019713/
<zybell_>Neat. There seems to have been an env where JSChar and UChar amounted to the same underlying type. So that bug wasn't found because it was masked. Your env uncovered it.
<snape>sneek: later tell ajjlmau: you can do something like: (host-file (local-file "/path/to/my/hosts/file")). I'd love this to be packaged though, I'll think about it.
<sneek>Got it.
<snape>I think it would be better if sneek gave messages to people when they connect instead of giving them when they talk.
<roptat>but people like me stay connected even if away, so they don't get the message when they actually connect
<snape>How can you not get the message if your IRC client is connected? It should at least display something in a special color to indicate that someone talked to you...
<snape>that's something to deal with on the client side
<zybell_>By having a limited scrollback
<roptat>exactly
<roptat>or simply by not thinking to scroll back
<snape>Come on, we are in 2018, a week of Guix messages doesn't take lots of memory :)
<snape>if someone says your name, then your client should beep and display all sort of different colors so that you think about scrolling back
<siraben>If I install a package such as VLC from Guix, how do I make it appear in my launcher on Debian?
<snape>anyway ajjlmau when you'll talk you'll get my message -_-'
<zybell_>my scrollback is 23 hours on #guix atm and hexchat doesnt save changes to prefs
<snape>(<troll> then switch to Emacs </troll>)
<ajjlmau>hello
<sneek>Welcome back ajjlmau, you have 1 message.
<sneek>ajjlmau, snape says: you can do something like: (host-file (local-file "/path/to/my/hosts/file")). I'd love this to be packaged though, I'll think about it.
<g_bor>Hello guix!
<jsierles>Why does the guix command write to stderr?
<jlicht>jsierles: afaik, the only stdout output of most guix commands is the (produced) store path
<jlicht>this allows you to do cool things such as `cd /tmp; tar xf $(guix build --source <pkg>)' or other simple things
<jlicht>jsierles: https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/ has a {nice,extremely hacky} example for setting LD_LIBRARY_PATH as well, for a more serious example
<jsierles>Alright. I get it , though it's surprising behavior to see non-errors on stderr
<jsierles>Seems like a flag for only outputting the produced store path makes more sense
<rekado_>this is part of the Outreachy project.
<jsierles>'guix package' doesn't seem to have any stdout
<jlicht>rekado_: The paper was a nice read! Very encouraging to see the numbers and tables regarding reproducible builds
<rekado_>jlicht: thanks :)
<thomassgn>mmmm, hadn't realized there was a new guix pull, and it receives "fatal: early EOF" and some other warnings... Is this a known problem? My network connection is not bad, but does have dips in connection...
<rekado_>thomassgn: are these errors reproducible?
<thomassgn>don't know. But have been trying for maybe half an hour-ish bnow.
<thomassgn>I'm getting a warning about "error: Server does not allow request for unadvertised object 486de7377f25438b0f44fd93f97e9ef822d558b8" (I say warning cause it continues working...)
<rekado_>thomassgn: I saw that too. This might be a change in github.
<rekado_>thomassgn: what package did you build?
<thomassgn>none, guix pull
<thomassgn>ah, it went through now, it just came to the regular loading %%% compiling %%% and so on..
<jlicht>thomassgn: I saw that one as well some time ago, and I just tried to build guix from git when I encountered that error message
<thomassgn>hmm, looking back at what it did, it checked out the entire git repo of guix from savannah. Is that what guix pull is supposed to do?
<jlicht>*warning message
<thomassgn>mm. It seems to be fine now though.
<bavier`>rekado_: nice paper
<jsierles>Link?
<bavier`>jsierles: https://www.biorxiv.org/content/early/2018/04/11/298653
<efraim>looks like elfutils only fails on aarch64
<efraim>strace update failed hard, tried to pass -m32 to gcc on aarch64
<efraim>if I understand the previous run-backtrace-native.sh test failures, it looks like our glibc is too new on aarch64 for that test to pass
<efraim>new elf.h updates to elfutils from glibc are mostly related to s390 and riscv, so probably not that
<rekado_>thomassgn: yes, “guix pull” downloads the git repository from savannah. It keeps a copy in ~/.cache/guix, so subsequent pulls should be faster.
<rekado_>bavier`: thanks :)
<caffe``>has anyone here ever gotten b43-open to work? if it matters, my card is the same revision 5 as noted in "Hardware Considerations": " those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the b43-open Linux-libre driver. Free firmware exists for both and is available out-of-the-box on GuixSD, as part of %base-firmware (see firmware)."
<bavier`>caffe``: AFAIK we've had at least one other user use b43-open successfully
<caffe``>as-is with the minimal template, the firmware fails to load, citing "Missing Free Firmware"
<caffe``>though the correct location is found in /sys/module/firmware_class/parameters/path
<caffe``>and the firmwares are in the location it points to
<caffe``>if i manually run 'rmmod' then 'modprobe', the firmware loads, but still fails with "Dual-core devices are not supported"
<efraim>i assumed it wouldn't load on my machine because it connects to the same interface as the proprietary b43 driver
<thomassgn>rekado_: didn't know, is this new behaviour or am I just noticing it for the first time?
<rekado_>thomassgn: it’s been like this for a while.
<rekado_>thomassgn: in the past “guix pull” would download the complete repository snapshot
<rekado_>now it uses git to download just the difference.
<thomassgn>ah, I see.
<thomassgn>Thanks!
<caffe``>efraim: you never got it to work, either?
<bavier`>any foreseeable issues with /gnu being a symlink to another directory?
<efraim>caffe``: nope
<caffe``>someone filed a bug report on it last year, but that never got resolved..
<caffe``>i don't really want to submit a duplicate
<bavier`>caffe``: if you're seeing the same problem, feel free to comment/send a response to the existing bug
<efraim>i tried building edi with bear and it recognized it but didn't add it to 'guix gc --references'
<caffe``>should i do that for the year-old emacs bug on i686 that hasn't been resolved, too?
<bavier`>caffe``: yes :)
<caffe``>that was also, already reported...
<caffe``>sorry i'm sounding sour here today/yesterday.. guixsd is a very nice system, and i'd like to stick with it and possibly contribute. it's just frustrating to find that it's almost useless on any of my laptops, as well as with hardware claimed to be supported 'out of the box' that i specifically tracked down so i could use at least one laptop with guixsd.
<caffe``>and it's also frustrating to see that most of the bugs i run into were reported long ago, and still left unresolved
<caffe``>it works great on my desktop...
<Sleep_Walker>I'm building curl against MIT Kerberos5 instead of GNU GSS - do you think it would be acceptable change or I should keep it for myself? I have difficulties using GNU GSS and MIT kerberos might be more common
<jonsger[m]>rekado_: nice paper, at least the parts which I could understand :) is there no table about the "not reproducable" packages?
<rekado_>jonsger[m]: no, there’s no table for the packages that are not reproducible. I see that this might be interesting, though.
<rekado_>I guess I can add it to the supplementary materials.
<pkill9>Sleep_Walker: what's the difference?
<Sleep_Walker>pkill9: I'm unable authenticate, store tokens and I'm not sure GNU GSS even support it
<Sleep_Walker>it has the right license but not the right features
<pkill9>caffe``: sorry to hear of your issues using hardware with guixsd
<pkill9>which hardware in particular did you get for it?
<caffe``>b43 wireless card, revision 5
<Sleep_Walker>b43 is cursed :)
<pkill9>where does it say that card is supported?
<zybell_>GNU GSS should do that --- with the right plugins^WProviders;-)
<caffe``>pkill9: right here: https://www.gnu.org/software/guix/manual/html_node/Hardware-Considerations.html
<Sleep_Walker>last time I had this card (probably different revision) was the cheapest solution to buy something else
<Sleep_Walker>zybell_: so you're saying that the GSS as we packaged it is wrong?
<caffe``>"WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the ath9k Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the b43-open Linux-libre driver. Free firmware exists for both and is available out-of-the-box on GuixSD, as part of %base-firmware (see firmware). "
<caffe``>if b43 is indeed 'cursed', whoever wrote that didn't get the memo... and i bought the card based on that info.\\
<pkill9>you put that card in your laptop?
<caffe``>yes
<pkill9>i didn't know you could put different wireless cards in the laptop
<pkill9>haven't relaly looked though
<caffe``>yeah, it's called Mini PCI
<pkill9>really*
<zybell_>No it is an interface, to many ways to prove ident. Every way needs a "Driver"
<pkill9>caffe``: what does dmesg say?
<pkill9>does it mention the wireless card anywhere/
<caffe``>yes, it does. give me a minute to retype the relevant bits
<caffe``>since i can't just paste them
<pkill9>put them ina pastebin
<caffe``>that machine has no network connectivity...
<pkill9>if they're too long
<pkill9>ah ok
<zybell_>Some of them may be included. But all? impossible!
<caffe``>b43 ssb0:0 Direct firmware load for /*(DEBLOBBED*/ failed with error -2
<pkill9>interesting
<bavier`>caffe``: like I said earlier, the b43 firmware was confirmed working by at least one user before we added the documentation and put the b43 firmware in %base-firmware
<caffe``>ssb0:0 Missing Free Firmware (non-free firmware loading disabled) (I've verified the firmware is indeed in the right location, and is correctly referred to by /sys/module/firmware_class/parameters/path)
<caffe``>when i rmmod b43 and modprobe b43, the firmware then loads, only to give me this: Dual-core devices are not supported (despite this being a model listed as known to work)
<zybell_>Did you (caffe)rebuild initrd?
<caffe``>No, I didn't. I don't know how to on guixsd, and documentation is still a bit lacking. Unfortunately, this leaves me dependent on IRC. :/
<caffe``>and i, as well as others, can confirm that b43 does not work 'out of the box' as described, nor has it for quite some time, judging from the old bug reports that seemed to go nowhere.
<caffe``>and, my bad, i said it was a year old... it's actually two:
<caffe``> https://lists.gnu.org/archive/html/bug-guix/2016-05/msg00074.html
<bavier`>caffe``: could you try the experiment in https://lists.gnu.org/archive/html/bug-guix/2016-05/msg00058.html ?
<caffe``>already have.
<bavier`>ah, got it
<caffe``>i can type the results a third time if that helps
<caffe``>or, in a nutshell: the same thing happens. $(guix build firmware) > /sys/module/fimware_class/parameters/path results in the same contents as before in /sys/module/firmware_class/parameters/path
<caffe``>and you get the same dmesg results as before, unless you rmmod before modprobe... in which case, the firmware appears to load, but results in the error claiming Dual-core devices are not supported.
<bavier`>caffe``: what's your chip id?
<caffe``>BCM4306, Revision 5
<caffe``>or, rather, bcm4306 rev. 3, core rev. 5
<caffe``>or do you mean this? b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 2, Version 0
<bavier`>caffe``: I'm not sure I can help much more
<caffe``>well, for what it's worth, i appreciate your trying
<bavier`>np. iirc these wireless devices apparently work with Trisquel; it would be nice if someone could figure out what is different in our setup
<caffe``>well, if that's the case, i'll try installing Trisquel on the other partition and see if i can find anything.
<caffe``>again, sorry about being frustrated with this... just not being able to get on a network is a severe showstopper.
<bavier`>that's understandable; we appreciate your testing