<seepel>Hi there, I've been trying to get into Guile on a Surface Book 2 with Windows Subsystem for Linux, and having a heck of a time. I'd like to explore dual booting with a guix package manager and I'm wondering how hard it would be to dual boot into guixSD with a custom kernel (someone has put together a kernel that supports pretty much all of the hardware on Surface devices).
<malaclyps>seepel, the default guix is set up to use a linux kernel with no proprietary firmware -- you can definitely find definitions that work with the mainline kernel, and maybe that would be better stepping off point, but I suspect you should play around with getting that working first, before you experiment with a more exotic kernel!
<seepel>Good suggestion! Maybe I should actually just start with a VM and/or docker image? Two follow up questions then, 1) Do you know of any existing images to quick start such a thing, and 2) Do you know of any (preferably simple) definitions for guixSD with a mainline kernel that I could use as a starting point?
<bdju>Discussion of mainline kernels here (or other things related to needing a blob for hardware) is a mess because talking about non-free stuff is discouraged.
<seepel>Ok, sorry about that. Thanks for the suggestions
<seepel>Do folks have favorite hardware to run guixSD on?
<atw>I have had good luck with a desktop (though don't ask me about graphics cards!) and with a Librem, barring one tweak around the keyboard
<seepel>I have been eyeing the puri.sm stuff, looks very cool, though I suppose I need to convince myself that I'm going to stick with this before plunking down more money
<atw>fair enough. Though hardware that's good for free software would be good for more than just Guix
***apteryx_ is now known as apteryx
<seepel>Yeah, less about the hardware itself and more about moneys :D
<seepel>Hi there, just wanted to pop back in and apologize if it seemed like I was ungrateful. Was thinking about it and I asked for hardware recommendations, and it seemed like I complained that they were too expensive. It was not my intention at all! Thanks for the guidance!
<nixo_>Hi guix! After a recent update (probably 215a45) my emacs loads an older org-mode, anybody else has the same problem?
<nixo_>this works as a workaround : EMACSLOADPATH=/run/current-system/profile/share/emacs/site-lisp/guix.d/org-9.2.6:$EMACSLOADPATH emacs
<jyscao>At this point, when I run `$ guix build --file=love-nuklear.scm -K`, the build always fails with the following error:
<jyscao>builder for `/gnu/store/pb1c62pg48c0xy6yy3yfq3c0v99xh71q-love-nuklear-v2.6-0.0cca218.drv' failed to produce output path `/gnu/store/j2ldf7vxpvj1pg41h7kb30pz5kmw25yn-love-nuklear-v2.6-0.0cca218'
<ScaredySquirrel>another question, how do I include all of the gnu/packages/fonts.scm in my packages automatically?
<snape>ScaredySquirrel: the goal is to pass them to 'guix package -m'?
<nckx>ScaredySquirrel: You can't ask for ‘all the fonts please’ (maybe some day, we could tag things like fonst, cups drivers, etc.) but I ran ‘guix package -A ^font- | cut -f1’ and curated that list. You'll have to, because at least one of them isn't a font at all and another (mathjax) slows down guix profile operations immensely.
<ScaredySquirrel>well is there any reason why (kernel-arguments "quiet i8042.nomux=1 i8042.reset") says: "ERROR: procedure append: Wrong type argument in position 1 (expecting empty list): "quiet i8042.nomux=1 i8042.reset""
<snape>ScaredySquirrel: because "quite something" isn't a list
<anon987321>you might also have luck searching for "(device) drivers gnu linux"
<nckx>shrzen: …and since you dare say ‘linux’ here… 😉 I'll explicitly point out that reading ‘works with Linux!’ on a random site doesn't mean it will work with GNU Guix. ‘Linux’ ships proprietary firmware blobs, we (and other GNU distributions) don't.
<atw>wireless cards can be a common sticking point; I had to do a bunch of reading about if ones I was planning to buy would be supported.
<shrzen>Thanks guys, the seller gave me the wrong laptop(x280 instead of x260) so that kinda caught me of guard. I'll check for hardware compability now, but i'm quite sure the wifi doesn't work on this one.
<shrzen>nckx: yea, my bad hehe. Still gotta get the habit of putting GNU first
<nckx>shrzen: No bad. Could've been indicative of a culture shock is all.
<ScaredySquirrel>guys the X server uses a /gnu/store/bd51fdgpjsp87irjg3sr726m2xgci6pc-xserver.conf file
<Mrtn[m]1>If I understand it correctly, I need to run "guix pull && guix package -u" for each of my users, for it to be upgraded. However, "guix pull" is failing for some of my uses with a "502 bad gateway" or something like that. However, for other users, it seems to run just fine?
<nckx>Mrtn[m]1: Could it simply be arbitrary? Savannah (the GNU hosting service that guix pull uses) was having problems recently. I ran it in a loop & the 10th time it worked.
<Mrtn[m]1>Oh .. I guess we can't see netsplits on the Matrix side.
<Mrtn[m]1>nckx: On this machine, I guess it is 3--4 potentially 5 or 6 - plus root of course. .. On my other machine, I am guessing 3 plus root.
<Mrtn[m]1>nckx: Yeah, I guess it actually boils down to "number of users running guix, plus number of machines (to include root)"
<sputny>Hello together, I'm trying to install guix system on my machine. I prepared an USB according to the manual. The USB is found by my BIOS and Grub Menu shows up. But then ther are some warings and error:
<sputny>GC Waring: pthread_getattr_np or pthread_attr_getstack failed for main thread
<nckx>Mrtn[m]1: I really wouldn't worry about ‘your’ load on Savannah: it's only used when guix (or git) pulling, for the usual git ‘hey, got updates? sure, here they are’ dance. What can kill a server is the potentially thousands of pipelined requests for substitutes, but those are sent to ci.guix, which is not Savannah.
<nckx>Mrtn[m]1: …now, ci.guix has its own troubles, but they're not related to what you're seeing tonight.
<nckx>sneek: later tell sputny: Those errors & warnings are scary, but ‘normal’ (we all get them) and don't affect the boot. If your installer works there's nothing to worry about, if it doesn't it's unrelated to those messages and we'll need more info to find out why.
<Mrtn[m]1>nckx: Well, what I was thinking about "my load", was that other L-users probably does the same thing ... which might add up in the end .. From a personal point of view .. it is also a slow process to run "guix pull" for all my users and machines... I wonder why it is necessesary, when all it really does in the end, is changing some symbolic links ... so why does it have to download it all again for each user?
<nckx>Mrtn[m]1: It does quite a bit more than that. It Guile-compiles all of Guix. And Guix being Guix, it does that from scratch. Guile's compiler is also slower than everyone would like, that's being worked on.
<leoprikler>I don't think guix pull should compile things twice if you have the same git commit.
<Mrtn[m]1>leoprikler: Exactly .. it is not just redundant, it is potentially evil ...
<nckx>Mrtn[m]1: Does it? I don't run (real) multi-user sites, but that surprises me. It does the same as any other package: build derivations to the store, which should be re-used for ‘free’ when nothing has changed between pulls.
<leoprikler>Then again, I never guix pull'ed without the top commit having changed in-between so I might be wrong.
<leoprikler>That said, master is somewhat lively, so if you want to be 100% sure that nothing changes in the time you make your observations, you should provide --commit
<nckx>Yes, that will be question one: are you sure nothing changed upstream? It is true that Guix will then rebuild all of Guix. We don't really handle incremental builds well by design, and that's the drawback of using the same mechanism for pulling Guix as for building all the rest.
<lfam>So I wonder what it would take to add some "try to respawn" code to starting services
<Mrtn[m]1>nckx: So it would make sense to split pull in a "clone" and a "build" command, so that the "clone" would check if the repository has changed, and _only_ clones changed/new pacakges, and then marks new/changed packages for build, and then "build" only builds the new packages.
<lfam>First, we aren't using hydra anymore so make sure you are using a working substitute server (ci.guix.gnu.org) and all that
<lfam>Either the package is broken, its dependency graph changed and it hasn't been rebuilt yet, or the CI server is broken
<dftxbs3e>Hello Guix, I'm sorry I was busy this week-end.
<lfam>You can visit the ci.guix.gnu.org web site, and then search for znc
<lfam>Then, select the build for the 'guix-master' "specification" for your architecture
<lfam>I'm guessing it's x86_64 since that is indeed failing to build on the server
<atw>thanks for teaching me to fish, lfam :) much appreciated
<lfam>But I don't know how to investigate more with the Cuirass-based CI interface
<lfam>On Hydra you could really dig in. For example, this build is failing because one of its dependencies failed. Hydra would have told you which one and offered the full build log
<dftxbs3e>nckx, I see, so GNU Guix's CI currently requires proprietary firmware to run, that's bad. Hopefully the POWER9 hardware can replace x86 entirely, with cross compiling it could. However, for testing..
<lfam>atw: So unfortunately you will probably have to build locally and investigate like that
<atw>lfam: I've built znc locally successfully but on my server which has less memory it does not build. Admittedly the derivations are not equal so it's not a perfect test but my hunch is that znc requires a hefty amount of memory while building.
<lfam>You'd think that wouldn't be a problem on the build farm
<lfam>Remember, on the build farm, we did not even try to build znc, because one of its dependencies failed
<ScaredySquirrel>and I know that my xorg server is broken without its /gnu/store/bd51fdgpjsp87irjg3sr726m2xgci6pc-xserver.conf file being used by telling xorg about it via its options by xinit and/or startx