IRC channel logs
2014-12-06.log
back to list of logs
*tadni` should be studying ... but just checked the Guix irc log. <tadni`>davexunit: Is the newer Libreboot laptop information posted anywhere? <tadni`>Like any general work and/or plans? <tadni`>I would love to get a Libreboot as my main box ... but I won't throw out my relatively powered laptop, for something as spec'd as the x60. :^P <tadni`>th3kent: Yeah, I run GNU Distro on this laptop. <tadni`>Too lazy to set up wireless networking, but sans that ... no complaints. StumpWM is really the only missing package I use on my day-to-day box and I hope to work on that a bit over winter break -- strarting a week or-so. <tadni`>Just looked at the specs. What a tremendous improvement, if that Gluglug started selling these. I'd gladly pay a premium for such a thing. <davexunit>tadni`: I don't know where it is, I just heard it through the grape vine. insider info. <tadni`>Really, the display resoulution would be my only complaint ... 1366x768, which is what this lowerend, 5 year old laptop I'm using for GNU Distro currently has. :^P <tadni`>Which isn't horrible ... just not ideal. <tadni`>Mre than 5 hour battery is amazing though. <tadni`>davexunit: Insider trading! Heresy! Heresy! Nerd Alert! Nerd Alert! <tadni`>Do the x230s have a HDMI port? I don't see it listed on the specs for it. <davexunit>tadni`: that's the resolution of my x220, wish it were higher. <davexunit>why is apple the *only* company willing to make high dpi laptops? <tadni`>davexunit: They are the only ones that can charge enough money to allot such a thing and people willl buy in mass. <tadni`>How many college kids, and soccer moms will buy a 1500+$ Dell Laptop? How many of those same people have the newest or close to newest Macbook? <tadni`>That being said, I'd much rather have a laptop with this resolution with this "up to 9.9 hours" of battery life of the X230 than a super high-res laptop that lasts like 2 (Like I have now). <tadni`>All being said, when it comes to hardware products that too happen to be foss supportable via drivers ... it's often and sadly, an attempt to pick to the least worst option. There's very, very rarely hardware that beats their proprietary competition, when it comes to performance. <tadni`>Which is sad, but I'm hoping things like RISC-V and other FOSH (Free/Open Sourced Hardware) products will improve this to some large degree someday... <davexunit>yeah, there aren't any major hardware manufacturers that care about freedom at all. <davexunit>so naturally we're stuck with out of date hardware. <tadni`>davexunit: I'm hoping lowRISC will be a start a positive tred. Making an ALL FOSS board, even just as aprox powerful as the RPi -- would be amazing. <tadni`>davexunit: That's not all FOSS though, right? <tadni`>Librem was a HUGE disappointment. <davexunit>tadni`: I'm pretty sure it can run without blobs. <davexunit>which currently requires nonfree software to build for. <tadni`>Is there even a point of running a fpga with Linux/Linux-Libre? Aren't you just emulating a arch of processor anyways? <davexunit>it's good for parallel processing and things <davexunit>but you could do cool things like mine bitcoins *tadni` has thought of getting a dev board to play with, but it seems like all of them do need proprietary tools to build stuff on it. <tadni`>Ah, yeah, I meant a FPGA dev board -- sorry. <davexunit>though you meant a generic microcontroller dev board. <tadni`>Which is, at least partially based on Arduino -- it seems. <tadni`>Really, I kinda just wish that someone would invest into a small hobby company for a Lisp based FPGA market. Verilog is not a pretty lang. It'd be very nice if we could do actual logic gate programming in some variant of Lisp. <davexunit>what does verilog get compiled into to run on the FPGA <tadni`>davexunit: This is where I get confused and maybe it's because I have only really read a bit into this -- and not actually had direct acess with such things yet, but I think it's different per board. I think verilog (and whatever that other really popular lang was called again) is used as a universal language between most boards, but there appears to be no universal compulation method? I think this is why every company seems to have a <tadni`>Ah yeah, the other big FPGA lang is VHDL. <tadni`>Anyways, shouldn't have even popped in tonight. Definintely won't be on till Wed now; study, study, study, fun, fun, fun. Peace peeps, see ya in about a week or so. o/ <zacts>I'm currently also interested in Dragora Gnu/Linux <zacts>but guix seems more heavy duty <iyzsong>yeh, me too for 1.0, and for Guix we have lots to do.. <zacts>other than mark_weaver and civodul does anyone else use Guix as their primary distro yet? <zacts>I'm stuck with Slackware until I patch Dragora or Guix to allow for full disk encryption <mark_weaver>zacts: I don't know, we don't have a registry of guix users :) <zacts>I guess my intent with that question was to see if any non-core guix dev nerds have been known to use guix <iyzsong>I have installed Guix on my laptop, for primary use :) <zacts>that answers my question actually <zacts>well, I'll try the distro aspect of guix in a vm for now. Perhaps I can contribute from there until it suits my needs for a primary distro. <zacts>I don't want to use guix as a package manager on Slackware yet though. <zacts>I like Dragora and Guix for different use cases. <zacts>Dragora 3 will use the Musl C Library, so it's nice for lightweight installations. <zacts>but guix is good for a primary distro <mark_weaver>Boehm GC doesn't work on Musl, which means no Guile 2. <zacts>mark_weaver: yeah, I looked into that actually after chatting with you a while back. <zacts>the Sabotage Linux guys have patches to fix that <zacts>but they still need to test them more <zacts>mark_weaver: I'm sure they will once they test them. I'll ask them.. <zacts>I'm going to make it a point to try to add mksh as a package before 1.0 <zacts>unless someone gets to it before me <zacts>mark_weaver: I'm seriously considering forking gnu coreutils, for the sole purpose of changing the C indent style, and possibly getting a tiny hackathon to audit and improve the code. <zacts>I'm considering becoming a Gnu hacker of some sort.. I'm also looking at Linux Kernel stuff in the long term. <zacts>but I've also spent a bit of time in the FreeBSD / OpenBSD / Minix3 world. <mark_weaver>wow, forking a major project just to change the indent style? sounds like a collosal waste of time. <zacts>mark_weaver: hopefully it would be a temporary fork. if bugfixing happens, then perhaps upstream may merge it. Perhaps you are totally correct though. <zacts>I didn't mean that as an insult to coreutils, perhaps my current knowledge of this type of thing is too naive. <mark_weaver>GNU has a set of coding standards, including indentation style. I can guarantee that they aren't going to merge some huge patch that changes the coding style to something else. <zacts>my main point with that was the latter part. <zacts>namely, "possibly getting a tiny hackathon to audit and improve the code." <zacts>but I was thinking a run through gnu indent, might encourage more people to contribute <mark_weaver>well, that could be useful, but probably only if the goal is to improve GNU coreutils, not some fork that's unlikely to be used. <zacts>Ok, yeah that does make sense <zacts>note: I've been overloaded with studying today for my finals next week <zacts>my current skill set would mainly be with helping out with distros like Guix and Dragora. <zacts>I plan to do that while I learn how to actually code <zacts>then once I can code, I want to contribute some programming to a few projects <zacts>namely, Gnu and possibly Linux Kernelish projects (Linux for more long-term stuff) <zacts>maybe HURD, but we'll have to see <zacts>I like braunr's x15 microkernel <zacts>much more than what I've seen of gnumach, not that gnumach can't be improved too. <zacts>I'll try to help with that when I can <zacts>mark_weaver: what is your honest opinion, from a purely technical perspective, of the HURD and GnuMach? Both the implementations and the design philosophies? <mark_weaver>well, it's a difficult job. I'd start by packaging mksh :) <mark_weaver>zacts: my knowledge of the Hurd and GnuMach is too superficial to answer your question, although I can say that I'm very impressed with the fundamental design of the Hurd. <mark_weaver>it seems to me that the main problem for them has always been: not enough developers. <zacts>mark_weaver: well I live in the city and attend the University where Thomas invented the HURD ideas. <zacts>so perhaps I should try to contribute back. ;-) <zacts>again, first with GUIX + HURD as a distro, until I gain coding knowledge <zacts>as you can see I'm far behind currently with my coding knowledge <zacts>my main problem has been not enough time from my core basic classes, and my lack of focus on specific projects. <zacts>iyzsong: have you read the Little Schemer book? <iyzsong>I'm afraid to read any teaching book, can not hold to the end XD <iyzsong>zacts: yes, just feel like notepad for me <iyzsong>I use emacs with little customizations <zacts>I'm currently using vim / neovim / emacs evil-mode <iyzsong>Be attracted to scheme for a long time, I find Guix a real chance to get my feet wet. <tadni>zacts: I just checked the chat ... I said I wouldn't respond until my finals were over, but I just did 4 weeks of homework catchup in 2 hours... so I'm making an exception before I pass out. :^P <tadni>zacts: I run GNU Distro on my secondary box. <tadni>If *.iso generation get figured out by 1.0 of Guix and too, my wonky UEFI bios allot it ... I'll be running GNU Distro on my main box. <tadni>I really just need to get Stumpwm going, but I've considered forking it -- due to them unbundling the core from the extra modules. <zacts>tadni: does guile-wm work yet? <tadni>It's "worked" since last year. <zacts>is it a suitable replacement for stumpwm <tadni>It also has barely been touched ... since last year. <tadni>Stumpwm is very mature; Guile-wm is more of a toy/expirement right now. <zacts>so is the issue with packaging the quicklisp libraries in guix? <zacts>you can build from github right? <tadni>zacts: We don't have any build system for CL at all right now. But too, yeah, we preferably should figure out an interface for quicklisp. <tadni>If not, just working off asdf should be "good enough" for the most part. <tadni>Stumpwm requires clx and cl-ppcre, that's it, CL wise. <zacts>which distro is your current primary distro? <tadni>zacts: Fedora, with Linux-Libre. <nully>i havnt had an issue with the way they re-did modules VS core <nully>tadni: the mailing list has become fairly active in the past months <nully>I feel like things are starting to pick up :) (hopefully) <nully>I'm glad to see fellow StumpWM users about ;) <tadni>nully: I just think it would be awkward, guix package wise, for such things to be seperated. Don't know -- I might just say it's good enough. :^P <tadni>But yeah, I'm glad that we have at least one relatively active Lisp-based WM kicking about. <nully>tadni: just manage it downstream? much like debian developers do? <tadni>nully: Does GNU/Guix have the infastructure to do that? <nully>tadni: honestly, i dont know. I have not done my first guix package yet. <nully>If it did not, i would probably want to add that x.x <tadni>I mean "CLumpWM" or whatever would literally /just/ be the pull of the latest release -- with modules thrown back in. <nully>i'm a very minimilst gui user <nully>tbh, there is not much i do with it except the bare min configs <tadni>That's my very poor, unorganized config. <tadni>I really need to update it a bit. <tadni>The module loading is horrid... <nully>much more advanced than anything i'm doing <tadni>Because I've found no combination that works, so I just thew it all together. <nully>probably should set the mode-line better <nully>looking at your config makes me want to fix mine to not suck <tadni>Really, I think the only thing that would get me to transistion of Stumpwm in the next 3 years ... is if we get a Guile based Wayland compositor that acts very much like Stumpwm as-is and too, also happens to be able to implement a custom graphics toolkit ... as been discussed with Guile-wm. <tadni>I know, my mode-line is horrid. <tadni>I really need to sit down and write a formal volume and weather module. <nully>i spent like 5 seconds on it :/ <nully>i used to try to config things a bunch, but these days i'm very *eh* about it. <tadni>I'm pretty obsessive about usability to be relatively similar to that of Emacs ... so I've put a decent amount of time in approximating the best system I could to get it to mesh well with such a thing. *tadni still doesn't know the meaning behind the name StumpWM. <tadni>I could find no rationale anywhere. <tadni>At least with most oddly named Lisp programs I've ran into *cough* guix *cough* :^) there's some sort of clear explination. :^P <tadni>Well, I'm not going to say that I will not be here till mid-to-late next week ... because I've already broken that 2-3 times; BUT, I will say I may pop in here once or twice before Monday. Sans that, I'll be gone from Monday till at least Wed. <tadni>But on that note, I need to get some sleep -- to catch up on some online quizzes later today. <rekado>disk names like /dev/sda are not guaranteed to be the same after reboot. I see that the docs recommend identifying disks by label. Is it possible to use UUIDs as well? <amirouche>rekado: what's the difference between a label and uuid in terms of use? <taylanub>UUIDs are automatically assigned, I think during manufacturing of the HDD, or creation of a partition. labels are assigned by users. <Tsutsukakushi>it's not predictable if you need to dmesg on every computer instead of using eth0 <taylanub>Tsutsukakushi: I think the enXYZ naming is actually consistent across boots of the same hardware, whereas ethX can change when you plug in new devices or so. (probably applies more to wlanX) <jmd>Isn't this an issue with the kernel rather than with Guix? <taylanub>I seem to remember it was related to udev <Tsutsukakushi>as i don't remember the enp51231ยง23s1233412 names of all my computers <Tsutsukakushi>it should be either be disabled in the GNU distro or the documentation should be adapted <Tsutsukakushi>so if i tell guix to install grub on /dev/sdb it'll go in a bootloop <jmd>Tsutsukakushi: Remove this rule from your databank: something-unfamiliar-to-me == shit <jmd>Map all the 1 bits to 0 on your hard drive. That way everything will be consistent. <Sleep_Walker>does guix offer some mechanism for "overlays"? you may know dwm and it has compile time configuration so I need to do some derivation of the original package and store it somewhere so guix will find it and use it... <iyzsong>yeh, we should just pass net.ifnames=0 to kernel, iirc Guix have not made boot options configurable right? <iyzsong>Sleep_Walker: I think you can write a package with patches and (inherit dwm) <Sleep_Walker>iyzsong: thanks, that was expected part, I'll search for 'inherit', second - it makes sense to keep it separately from the Guix's package specifigations - can I tell guix to take packages also from another directory? <taylanub>Tsutsukakushi: I'm guessing you're coming from a different Internet culture where calling something "shit" can be used in a light way, and any dissent is expressed through ridicule, but in other places that behavior can make you look like the jackass. <iyzsong>Sleep_Walker: yes, it is GUIX_PACKAGE_PATH, see info 6.5. <taylanub>Tsutsukakushi: maybe there's a way to disable it; I don't know. I'd recommend you to just get used to the new scheme though, since it solves more use-cases and is thus likely to get more widespread adoption in the long run. <iyzsong>Sleep_Walker: um, info guix. I have it to $HOME/.local/share/guix, so a dwm.scm file start with `(define-module (dwm) ...)' will do the trick. <taylanub>Tsutsukakushi: BTW as a general rule of some IRC channels, please type more stuff in a single line, rather than typing several short lines. it fills up people's screens and makes it more difficult to read :) (thinking more before hitting enter is also good general advice) <iyzsong>I have to agree the naming is annoying, but nowadays with NetworkManager like software, who care? <Tsutsukakushi>general rule on some irc channels doesn't really mean anything <taylanub>Tsutsukakushi: the problem it solves is a technical one: scripts that reference an "ethX" device can break on mere additions (not changes) to the hardware. the problem it creates is making it harder for humans to memorize a name, but that inconvenience should be acceptable for making potentially critical scripts not break. <DusXMT>Tsutsukakushi: Not really, anyone can write a script that depends on an ethernet defice to have a set, unchanging name <Sleep_Walker>Tsutsukakushi: what is so wrong in passing net.ifnames=0 to kernel? <jmd>Tsutsukakushi: I do. <DusXMT>Tsutsukakushi: An inconvenience is less severe than a problem, imho. <jmd>However, Tsutsukakushi is right. The manual needs to be updated, where it says "Configure the network, by running @command{dhclient eth0}". <taylanub>Tsutsukakushi: if you have a well-thought-out proposal for improving things in this regard, feel free to mention it. the issue might be more complicated than one would wish though, and you might be unaware of all the different ways different people use their computers. dissing things when you're not certain that they are a mistake is foolish to be honest. <Tsutsukakushi>i know they aren't a mistake, they are inconvenience for the general user <Tsutsukakushi>no GNU+Linux distro will ever become the general desktop os like this <DusXMT>If you already have to write a config file to even install the OS, I think adding a single line to the kernel config isn't that terrible. <Tsutsukakushi>and as i said, other option is to adapt the documentation to reflect that the nic isn't in fact named eth+ <DusXMT>s/kernel config/boot loader config/ <DusXMT>Updating the manual is indeed neccessary <taylanub>Tsutsukakushi: I think a general desktop OS for lay users would not have them mess with hardware device names at all :) <Tsutsukakushi>yet many regular users using GNU+Linux are often given strings of shellscripts as solutions to their problems <DusXMT>Tsutsukakushi: Nor will apt-get and yum shell strings work with Guix :P <Tsutsukakushi>because that'll be inconsistent between the person giving the advice and the person who needs it <DusXMT>And those shell strings will also fail if they expect programs installed in conventional lications (eg. /usr). I don't think it's a big issue <Tsutsukakushi>but this makes the scripts not work even on different installations of the same distro <Tsutsukakushi>apt and other breakages happen when moving between distros and that's understandable as they have different set of programs installed <taylanub>Tsutsukakushi: it does. the names are consistent across boots on the same hardware, regardless of the distro. you could switch between Debian, Fedora, Gentoo, and Guix, and if they all use the consistent scheme then a script would work across all these. (someone correct me if I'm wrong) <DusXMT>Simple solution: read the name of the interface from the command line, optionally creating a hidden file in the user's home directory where they store the last given nic name <taylanub>perhaps an extension could be made to this scheme where ethX appear as non-consistent aliases to the consistent names. I don't know enough hardware/kernel/udev stuff to be able to say whether that'd make sense though. <DusXMT>taylanub: He's talking about moving a script between two computers, the change makes the nic names computer specific <taylanub>ah, "different installations of the same distro" but on different hardware. then yes. <taylanub>ethX is more "consistent" in the sense that you always have some eth0 if the hardware has some ethernet interface. probably, systems will have a way to programmatically query the available ethernet interfaces so your script can pick one at random, but I imagine that convenience aliases would be neat indeed <taylanub>BTW does someone have a recommendation on how to patch the documentation? maybe "Configure the network, by running @command{dhclient enXYZ} where @code{enXYZ} is replaced by your ethernet device name [...]"? <Tsutsukakushi>the names aren't consistent between different computers and different people <jmd>Tsutsukakushi: Your logic reminds me of a monty python sketch: "... mind if we call you Bruce to keep things simple?" <DusXMT>P. a: First, tell me what $ ifconfig -a shows you. P. b: <link to pastebin. P. a: Okay, run this command: # ifconfig ens7p62 up <taylanub>Tsutsukakushi: yes, the aliases would solve that. if you're motivated enough, you might want to talk with the udev developers and ask them if such convenience aliasing could be implemented for people who want to pick any ethernet device without caring which exact one it is... <DusXMT>I'd tell him to run ifconfig -a, and have him read everything it would show, stopping him when he would say the interface name, telling him to write it down and then to continue on. You're right, it's an extra step, but I think you're making a mountain from moe hill. <Tsutsukakushi>every time one of them is brushed off with "it's not a big deal just add an extra step x" you'll end up with gentoo <jmd>Tsutsukakushi: Nobody is claiming the system is perfect. In fact, the manual explicitly states that there are limitations and is in alpha status. <taylanub>Tsutsukakushi: you do have a point, which is also well-represented in the page I linked above. I think we all agree on that. the documentation needs to be fixed (I'm on it...) and maybe one day udev can add aliases for convenience, but so far the problems this scheme solves seem more significant than the inconveniences it brings, so it should probably be the default. <Sleep_Walker>damn, it seems that `guix package -L <path>' is respected, but environment variable GUIX_PACKAGE_PATH is not <nkar>Sleep_Walker: what's the problem? <jmd>We need a GUIX_FLAGS variable <Sleep_Walker>you can see that when -L is not used, it won't notice new files in different path <Sleep_Walker>(I'm not saying that package is correctly made, but the difference is obvious) <nkar>but the first command shows the same package, no? <nkar>so the envvar seems to be respected, no? <sneek>civodul, you have 2 messages. <sneek>civodul, nkar says: ./pre-inst-env guix system reconfigure /etc/config.scm failed with "unexpected EOF reading a line". when I tried to run it again, I got "/bin/sh: bad interpreter". and 'ls', for instance, returns "/gnu/store/.../bin/ls: No such file or directory". what should I do? <sneek>civodul, nkar says: I found a single warning in the build log: setlocale: LC_ALL: cannot change locale (en_US.UTF-8). that's the old (and incorrect) value I used. <civodul>nkar: did you configure your git checkout with the same --localstatedir as the already-installed Guix? <nkar>civodul: I think so (I didn't specify any flags (except the one for libgcrypt)) <civodul>this should have been --localstatedir=/var <civodul>this is what is used on the standalone system <nkar>so what do I need to do now? <civodul>reconfigure the checkout with --localstatedir=/var, run "make clean && make" <nkar>I cannot do anything since every command returns a "not found" error <civodul>does /run/current-system/profile/bin still contains something useful? <nkar>if I boot from a usb and delete the last profile, will it help/ <civodul>basically set PATH to whatever binaries are usable <nkar>I'll check later. the machine is not working at the moment <civodul>if the current-system was actually switched to the new profile, it may help to reboot to the previous profile indeed <civodul>that depends on where exactly 'reconfigure' stopped <civodul>we need to at least document this pitfall better, but i'm not sure how/where <nkar>redirecting guix-profile to the previous generation didn't help <nkar>civodul: I could reinstall if it's faster <jmd>Ahh bummer. Why does guix insist on guile threads? <jmd>I won't be using that. Can I disable it? <civodul>nkar: we were talking about the system profile, not the user's profiel <civodul>nkar: presumably coreutils & co. are in the system profile, not in your user's profile <nkar>I wasn't aware of the difference. where's the system profile? <civodul>Sleep_Walker: that's because you should give your module a different name, not (gnu packages dwm) <civodul>that's why i wrote you could reboot into the previous profile (from the GRUB menu) <nkar>unfortunately, none of them boots. I'll just reinstall when I have time. <jmd>OMG guix requires a C++ compiler <nkar>I guess it's because it uses nix-daemon which is a c++ program <civodul>then i don't see why they would fail to boot <civodul>i mean, the files are still there, right? (kernel, initrd, etc.) <jmd>The configure script does not check for a C++ compiler <nkar>civodul: one of them doesn't boot because it can't find the initrd, the other one just panics, iirc <jmd>civodul: Err: Which line do you see that? <jmd>Well anyway, absence of a c++ compiler seems not to prevent configure from passing. <civodul>jmd: could you send config.log and a summary to bug-guix@gnu.org? <civodul>the bug tracker is filling up very quickly these days <jmd>Need to rewrite the daemon in C <civodul>sure, but probably not this week-end <jmd>Does the nix daemon require the stdc++ library or just a c++ compiler ? <DusXMT>Sleep_Walker: In the source tree, it is a tool used for launching guix from the source tree <davexunit>yeah, useful for when you haven't installed guix <davexunit>pre-inst-env never gets installed, it's purely for development. <Sleep_Walker>davexunit: I'm still trying to make my own version of dwm package <Sleep_Walker>If the package is unknown to the guix command, it may be that the source file contains a syntax error, or lacks a define-public clause to export the package variable. To figure it out, you may load the module from Guile to get more information about the actual error: <Sleep_Walker>./pre-inst-env guile -c '(use-modules (gnu packages gnew))' <DusXMT>Sleep_Walker: The manual is expecting you to be writing the package in Guix's source tree, so that's why there's the command <davexunit>it's just a wrapper script that sets some env vars and then calls the program specified. <DusXMT>Although nowadays, it's probably better to use the GUIX_PACKAGE_PATH (Or is it called differently?) for the development of custom packages <davexunit>that's what I do, I have started a git repo with a couple of custom packages. <Sleep_Walker>DusXMT: I had problem with this environment variable today <DusXMT>Sleep_Walker: The way it works is that you have to create subdirectories in the specified directory by the path, ie. $GUIX_PACKAGE_PATH/gnu/packages/ <DusXMT>and place the packages into that <bavier>ugh, llvm takes almost 11G of disk to build <jxself>All the more reason to use binary substitutes? <bavier>jxself: for sure. Installed its only about 277M <mark_weaver>Tsutsukakushi: fwiw, the unusual naming of network devices is being done by 'eudev', gentoo's fork of 'udev'. the reason we're using it is because 'udev' has been merged into systemd, and we don't use systemd. <mark_weaver>there's probably a way to configure eudev to change the names to what you like, but I don't know off hand how to do it. <Tsutsukakushi>wouldn't eudev need to be forked by gnu project to make the os completely gnu? <mark_weaver>our distribution is not going to be 100% gnu packages, although we generally aim to use gnu packages whenever we can. <mark_weaver`>Sleep_Walker: Intel wireless requires a non-free firmware blob. <davexunit>I use a mini-pcie wifi chip from thinkpenguin <davexunit>the catch is that I had to flash a hacked (but still proprietary) BIOS on my thinkpad to get it to work. <mark_weaver`>if your laptop has a mini PCI express card slot, you could also put an atheros AR9285 in (assuming that your BIOS doesn't have a whitelist for "approved" cards, grr). that's what my gluglug X60 uses. <mark_weaver`>gluglug replaces the intel wireless card in thinkpad x60 with the AR9285, which works great. however, that only works if you switch to libreboot (or coreboot), because the default BIOS refuses to use the AR9285. *davexunit wishes libreboot was available for the x220 <mark_weaver`>but in short summary: libreboot is coreboot with the non-free blobs removed, and also libreboot has regular *releases*, whereas coreboot doesn't do releases: you just use whatever is current git. <DusXMT>Interesting that there are blobs in coreboot <mark_weaver`>unfortunately, modern intel/amd hardware requires a large amount of proprietary blobs to be included in the bios. <DusXMT>I guess it's one of the conditions of getting the documentation from the chip manufacturers <Sleep_Walker>I hope that reverse engineering will gain the speed as coreboot did <jmd>Is nix packaged in guix ? <Sleep_Walker>how can I specify my own X session in Guix distribution? I'm afraid that auto-generated scheme script doesn't give me a clue... <mark_weaver`>Sleep_Walker: put your script in ~/.xsession and make sure it is executable. <mark_weaver`>the script normally ends by running your desired window manager in the foreground <mark_weaver>grr, since switching to comcast business (against my will, it's a monopoly in this town), my IRC connections are getting dropped very frequently, despite my use of a 30-second keepalive. <mark_weaver>lost them when moving from somerville to cambridge (massachusetts) <davexunit>ah yeah, I heard cambridge is all comcast. :( <jmd>So much for free enterprise <davexunit>telecommunications companies have monopolies on different areas. the situation isn't very good anywhere you go. <jmd>How do I define a propagated native input? <mark_weaver>a propagated-input means that when you install the package in your profile, the propagated-input is automatically included in your profile as well. that's all run-time stuff. but 'native' means during build time. <jmd>Actually, I'm not sure. It's late here. <mark_weaver>Sleep_Walker: the relevant bit is: "gnu/packages/mp3.scm:135:2: In procedure module-lookup: Unbound variable: license:mpl1" <jmd>I wonder if nix's deamon will work with guix? <mark_weaver>we don't have a binding for mpl1. only mpl1.1 and mpl2.0 <Sleep_Walker>my local guix git repository is currently unreachable to tell you which commit caused that <mark_weaver>Sleep_Walker: have you ever done any work on mp3.scm ? <mark_weaver>what exact command did you type, and what are the values of any GUILE_* and GUIX_* environment variables where you ran the command? <Sleep_Walker>GUIX_PACKAGE_PATH=/home/tcech/.local/share/guix:/run/current-system/profile/share/guile/site/2.0 <mark_weaver>we added GUIX_PACKAGE_PATH due to popular demand, but fwiw I always work out of a git checkout. <mark_weaver>I've never used "guix pull", not even once, nor any GUIX_* environment variables. <Sleep_Walker>I'm re-doing all my environment configuration and it's crazy <davexunit>yeah, I use GUIX_PACKAGE_PATH to point at my separate repo for experimental things <davexunit>things that aren't ready to be included upstream like unreleased software builds <Sleep_Walker>ugh, I'm afraid that I will admire the effort of linux-libre from comfort of vanilla linux, no wifi, no sound and I just began to look <Sleep_Walker>the best thing is that I believed that ARM CPUs could be better at providing blob-free drivers <mark_weaver>I don't think I've ever heard of sound drivers requiring non-free blobs (I don't doubt that such may exist, but it's probably rare) <mark_weaver>Sleep_Walker: I hoped so at one point, and in fact my primary machine for many tasks is still a YeeLoong, but I've lost confidence in them. they haven't produced a machine that runs on a free system in several years. *davexunit is eagerly awaiting his novena <phant0mas>hey guys, did anyone had any issue guix system init recently? it fails with "guix/monads.scm:239:6: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct)" <mark_wea`>phant0mas: have you tried "make clean-go; make" ? <mark_weaver>if that's not sufficient, maybe delete ~/.cache/guile/ccache <mark_weaver>anyway, it sounds like you have some stale .go file around. <Sleep_Walker>I'm trying to verify my package, using (load "/path/to/file") in REPL <Sleep_Walker>when I run `guile -c '(use-modules (gnu packages dwm-sw))'' I got similar error, this time for dwm-sw <civodul>Sleep_Walker: sounds like the Guix modules are not in Guile's search path <civodul>so you can either use 'guile -L /path/to/guix/share/guile/site/2.0', or set GUILE_LOAD_PATH <Sleep_Walker>guile -L /run/current-system/profile/share/guile/site/2.0 -c '(use-modules (gnu package dwm-sw))' <civodul>could you first try with '(use-modules (guix))'? <civodul>also, you need to make sure your (gnu packages dwm-sw) is stored under gnu/packages/dwm-sw.scm, relative to the load path items <civodul>but then guile itself does not honor GUIX_PACKAGE_PATH <civodul>so you need a -L for that directory itself, when using guile <civodul>ah yes, you need to change the 'name' field <civodul>looks like you're on the right track anyway ;-) <Sleep_Walker>and now package for msmtp, efl, elementary, terminology, maybe enlightenment <civodul>enlightenment reminds me of my first steps in free software hacking :-) <civodul>that was one of the fashionable things, back then <Sleep_Walker>well, if you have e17 in mind, things almost haven't changed <Sleep_Walker>I used that long time before I noticed I don't use it anymore and it is more distractive than usefull (and dwm is simple and not bothering) <civodul>well apparently a lot of work has gone in enlightenment and related projects lately