IRC channel logs

<mark_weaver>Xiaoman: as I recall, coreboot can run on the X200, but only with a lot of proprietary blobs included, notably for the ME/AMT.

<Xiaoman>x220 mark_weaver

<mark_weaver>the X200 is the best we can currently runs without blobs.

<Xiaoman>oh

<Xiaoman>I thought I read that both x200 and x220 could run libre now

<mark_weaver>and in order to do that, you need to replace its wireless card, since the one it comes with requires a blob.

<mark_weaver>Xiaoman: I think you are probably mistaken about the x220, but you could ask on #libreboot.

<Xiaoman>yeah, I'm actually buying an Atheros AR5B95 right now - also trying to find a proper IPS panel, but I cannot seem to find out what the name is of it

<davexunit>Xiaoman: the x220 is currently not supported by libreboot

<Xiaoman>:/

<davexunit>otherwise I'd be running libreboot right now :)

*davexunit is also an x220 owner

<mark_weaver>also, I should mention that replacing the wireless card in the X200, while fairly straightforward, requires that you switch to Libreboot.

<Xiaoman>davexunit, you happen to know the name of the IPS panel?

<mark_weaver>because the BIOS it comes with has a "whitelist". it will refuse to use any miniPCIe card that's not in it's whitelist of "approved" cards.

<mark_weaver>s/it's/its/

<Xiaoman>mark_weaver, you mean the X200 or X220, or does it apply for both?

<mark_weaver>Xiaoman: I'm only talking about the X200. I'm pretty sure that X220 has a whitelist of approved cards also.

<davexunit>Xiaoman: my x220 doesn't have an IPS panel

<davexunit>also, I use a hacked proprietary BIOS that removes the whitelist mark_weaver mentioned

<davexunit>it's the best I can do for now.

<mark_weaver>so, in order to replace the wireless on the X220, your choices are: (1) use an external USB wireless adapter, or (2) switch to coreboot (with the blobs, unfortunately) and then replace the miniPCIe card.

<mark_weaver>or (3) what davexunit did

<Xiaoman>Hmm, yeah... Seems like I will have to do (2) unless there are some significant downsides to that

<davexunit>I should probably coreboot it, I don't think that was an option when I got this thing.

<mark_weaver>Xiaoman: yeah, (2) would be my recommendation

<Xiaoman>Still, I could do that fairly quickly if I could just find the name of the IPS panel ;_;

<mark_weaver>Xiaoman: I should mention that in order to reflash your BIOS for the first time, I guess that you'll probably need to take it apart, attach a clip to its internal flash chip, and program it with an external programmer.

<mark_weaver>or at least that is required on the X200. consult coreboot docs for details on the X220.

<mark_weaver>(or maybe davexunit knows)

<mark_weaver>after you've flashed coreboot to it, you'll probably be able to reflash without an external programmer.

<mark_weaver>(everything I write is based on the X200, and the guess that the X220 will be similar, but these are guesses)

<Xiaoman>yup, it is the same with X220 http://www.coreboot.org/Board:lenovo/x220

<mark_weaver><mark_weaver> Xiaoman: as I recall, coreboot can run on the X200, but only with a lot of proprietary blobs included [...]

<mark_weaver>of course I meant to write X220 there.

<Xiaoman>Yeah, you are right

<Xiaoman>davexunit, what wifi card are you using?

<mark_weaver>a_e, bavier: btw, Gnus (Emacs news/mail reader) also looks for a 'gpg' command by default, and fails to find 'gpg2'. I've been installing gnupg-1 (alongside gnupg-2.0) for that purpose.

<mark_weaver>it might be that it would work fine with gpg2, but that would have to be tested.

<davexunit>Xiaoman: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-half-height-mini-pcie-card

<a_e>mark_weaver: Okay. As said above, I am hesitant to what we should do.

<mark_weaver>I think we should keep gnupg-1 in Guix for now, because some programs (and users) may still be using it.

<a_e>Right now, I tend towards keeping gnupg-1.

<mark_weaver>that said, I'm all for encouraging users and programs to support newer versions.

<a_e>Somehow, it is the responsability of tthe authors of these programs to update their dependencies, and not ours as packagers.

<mark_weaver>"I'm all for" == "I think we should"

<mark_weaver>a_e: yes, I agree

<a_e>mark_weaver: Are you kay with my new calibre patch?

<a_e>"okay"

<mark_weaver>a_e: I'd like to ask someone more knowledgeable about license issues about the remaining bits that debian removed.

<mark_weaver>I'll get on it.

*mark_weaver goes afk

<a_e>Okay. But as I said, one of the removed bits is part of debian.

<a_e>Just removed as an additional bundled copy.

<a_e>Time to go, good day/night!

<davexunit>grafting sure takes a loooong time

<davexunit>qt is taking forever...

<davexunit>woop, got a pump.io client packaged.

<davexunit>I often wonder if we should write some syntax for the (lambda* (#:key ... #:allow-other-keys) ...) pattern

<davexunit>I'm certainly sick of typing it

<davexunit>something like: (keys-lambda (inputs outputs ...) ...)

<rekado->mark_weaver: thanks for the fix! guix pull works now.

<zacts> http://www.s3.eurecom.fr/docs/acsac13_zaddach.pdf

<zacts>I'm going to try to get an fsf endorsed laptop

<zacts>and I'll put guix on it

<ewemoa>ryf ftw!

*taylanub wonders how many 'phases' procedures return an unspecified value when they're expected to return non-false for success...

<taylanub>I probably wrote many of those myself

<rekado->gave up on trying to package a2jmidid; 1) the waf script fails for reasons I cannot understand and 2) the feature is available in jack 0.124.x, which we already have.

<rekado->--> jackd -X alsa_midi -d alsa

<davexunit>I have a growing pile of things that I couldn't quite package

<taylanub>davexunit: re. shortening lambda*, you could use some Emacs command to insert that. in terms of number of characters, the only thing one can shave off is the #:allow-other-keys part, which is simple to insert via #:al M-/

<taylanub>M-/ is a surprisingly very useful auto-completion mechanism

<davexunit>taylanub: it's not about less typing, really, it's about expressing the code better.

<davexunit>I think a macro would be appropriate.

<taylanub>hm, in that case one might go a step further and alleviate the boilerplate required for accessing specific inputs and outputs. http://sprunge.us/ZPIR

<taylanub>at least in my limited experience, that seems quite useful

<taylanub>that wasn't even hard to implement! http://sprunge.us/BSKE

IRC channel logs

2015-02-21.log