<Krafter_>So I tried booting the installation USB drive. The installer wont load. The startup program is stuck. <Krafter_>Also is there a signature file to the .iso file and not just the .iso.xz? <lfam>Krafter_: The xz archive is signed, not the ISO file in the archive <lfam>Krafter_: What do you mean by the startup program is stuck? What do you see? <Krafter_>lfam: the first line is a gnu libre picture, below there is what I assume is a loading results. It ends with a timestamp and "kvm: disabled by bios". <lfam>Krafter_: What kind of computer are you booting it on? <lfam>Do you know what CPU architecture it is? <Krafter_>Yeah, its the latest amd cpu ryzen 2700x. <Krafter_>The only odd things in it are a m.2 drive and two different gpus. <lfam>Are you able to switch to another TTY? CTRL+ALT+F2 <lfam>Maybe someone else has some ideas, or you can send a bug report to <bug-guix@gnu.org> <Krafter_>Ok, I can at least try t remove one gpu and see if it starts. <Krafter_>Ok, it does work if I remove one gpu. Though is it possible to make it work when all is installed? <nckx>Krafter_: I doubt any of the Guix developers have a dual-GPU Ryzen ;-) <nckx>You're more or less own your own in that brave new world of crappy hardware, I'm afraid. <nckx>AMD ♥ blobs and I've enough of their stuff (gifted, not bought) over the years to have a pretty negative opinion of them generally, but I've never touched a Ryzen. <nckx>But otherwise it's like they saw Intel's already pretty low bar and thought: ‘bet we could limbo right under that sucker’. <Krafter_>And here I thought "Get AMD. It has a higher chance of working". <reepca>Krafter_: the rule of thumb for me is "as the age approaches 15 years, the probability of it not having compatibility or freedom issues approaches 1." <reepca>though with signed microcode in all modern CPUs and GPUs, that number of years is just going to keep increasing. <reepca>it's not really an architectural thing, more that "certain very low-level programs require permission from the designer of the CPU to run" is fundamentally opposed to free software. <nckx>Krafter_: I didn't mean to imply it's your fault or your wrong choice; x86 is just, forgive me, fucked. *nckx Sent from my x86 laptop. <Krafter_>I am just curious on how many secrets I am missing out on vs Windows. <nckx>Well… ‘booting’, apparently ☹ <nckx>Krafter_: How's it going now? <Krafter_>Its going alright. I am trying to figure out what "network services" I should use. <Krafter_>I have not tried running windows on it so it might not have anything to do with GNU/ Linux / guix. <nckx>Krafter_: I really hope installing Guix works, but if not, it would be interesting to see how another GNU distribution like Trisquel handles your hardware. <Krafter_>How so? I have never heard of Trisquel before. <nckx>Krafter_: It's based on Debian, I think. <nckx>…without the non-free stuff. If it works, we'll know that Guix can be made to work. <nckx>So Debian plus stuff minus stuff. <nckx>Probably good that they didn't call it that. <Krafter_>I might as well. I have now run through the installer but now it says "error: lstat: no such file or directory: "ftp://sourceware.org........blablabla"". <nckx>Of all the things I'd expect to work in 2019, on desktops at least X-( <nckx>Downloading libffi from that FTP site works here, so it's not an upstream problem. <nckx>The ‘no such file or directory’ message is a bit weird for a network error, but that might just be how that error is reported to Guix. ***jonsger1 is now known as jonsger
<Krafter_>This is odd "lstat --version" -> "-bash: lstat: command not found". <nckx>Krafter_: Maybe, but it's not that. lstat is a library call. <nckx>It should return 0x6zz3wkbzyfiihgqaaqwwnvjka59d70acijvvxs6cld35srlb2w. <nckx>The installer is entirely too fragile, but then writing non-fragile installers is very hard. <nckx>Krafter_: Happy to hear that. TBH it's what I personally prefer & recommend. <nckx>Krafter_: I've tried it a few times in a VM just to see what it looks like & hoping to help people here… I've never got it to even reach the installation phase without crashing. <nckx>All my Guix Systems were installed artisanally. <nckx>The first one without even knowing what ( or ) did in Scheme. <Krafter_>Good to know I am not the only one. I have heard that arch-linux dont provide a graphical installer as it was too much work. <Krafter_>I have some experience with a few lisps. <vagrantc>but i manage to write and fix package definitions all the same :) <nckx>You'll be fine. Read (don't skim) the relevant manual sections and think and you'll be fine. <vagrantc>nckx: understanding all things does seem like a somewhat high bar <nckx>All lisps are mystical indeed. <Krafter_>At least the installer partitioned my harddrive. I am grateful for that at least. <nckx>Krafter_: That's where boot loaders are stored. <nckx>Krafter_: If you're thinking ‘why's it so huge tho’: I agree. <Krafter_>"overlayfs: filesystem on '/mnt/tmp/guix-inst' not supported as upperdir <nckx>Krafter_: Which file system? <Krafter_>...herd: exception caught while executing 'start' on service 'cow-store': In procedure mount: mount "none" on "/.rw-store": invalid argument" <Krafter_>vagrantc: Maybe, I am following the instructions in the manual line by line. <nckx>vagrantc: I don't see how & think it's best to stick to the manual when helping folks install. <vagrantc>yeah, my memory is probably more fallable than the manual <nckx>vagrantc: Didn't mean to snap, just trying to shut down confusion quickly. <nckx>Also just dropped my Thinkpad 😒 <Krafter_>according to lsblk nothing has any mountpoints. <nckx>Krafter_: So /mnt isn't mounted? I guess that could explain it. Does ‘mount | grep /mnt’ agree? <nckx>Then I'm afraid I have to ask the obvious: did you mount /mnt? <vagrantc>i should really try this installer sometime :) <Krafter_>I assume that it was that herd was supposed to do. <nckx>Krafter_: Hm, no, mounting the partitions is done in the section just before that. <Krafter_>I skipped that part as it was labeled "disk partitioning". <nckx>Now, that section is called ‘Keyboard Layout, Networking, and Partitioning’, so I can kind of understand it if you thought ‘eh, I've already partitioned’ and skipped the whole thing. <nckx>On the one hand, we already have ridiculously section numbers like 3.6.1.3, on the other, this is probably a mini-bug and ‘mounting’ should be separate. <nckx>Krafter_: It's understandable. Things like these are why new eyes like yours are so important. <nckx>Krafter_: Hum. I… guess? <nckx>Nobody's ever asked me that. <nckx>This is GNU, we're all devs here. <Krafter_>Is it just me that has never contributed? <vagrantc>seems like you're troublshooting the installer and/or documentation! <Krafter_>I am considering writing about my experiences and sending it to the guix mailing list. <nckx>Krafter_: You're installing Guix on some very new and untested hardware. And you didn't say ‘omfg Guix sucks bye’ but switched to a command line. That's pretty cool. <nckx>I'm going to go ahead and file bug about the ‘Partitioning’ section just so I don't forget. <nckx>Krafter_: Are you back on track? <Krafter_>I think so. I am looking through the configuration file now. It bothers me that I don't have access to vim. <nckx>I hesitate to suggest ‘guix install vim’ since I don't know what else it will pull in, but there's always ^C… *nckx is not a vi'er and doesn't even know the difference but yay. <Krafter_>How up to date are the samples in '/etc/configuration/' ? <nckx>Krafter_: They are supposed to be current… why? <Krafter_>I am noticing some minor differences between them and the autogenerated config that failed. <nckx>Such as? I'm looking at the files, but it's unlikely I'll spot a big ol' deprecated thing lurking in clear sight. <nckx>(There's a bug in the current installer where %base-packages is accidentally omitted but that's not modern, just wrong 😛) <nckx>Every 1.0 needs an embarrassing bug. <Krafter_>I notice that the samples have a top level use-package-modules function unlike the generated one. <nckx>Krafter_: The use-foo-modules forms are just more compact ways of saying the same thing, but it would be user-friendlier to use them in the generated files for familiarity. Good catch. I look forward to reading your notes. <Guest85934>Is there a Guix equivalent of Debian's "build-essential" meta package that includes all the common tools for building C programs? <reepca>Guest85934: not that I know of, the closest thing I'm aware of would be gcc-toolchain, but of course that doesn't include make or the autotools. <calher>Does xz decompress files inside the current directory, or does it to to /tmp? <reepca>I'd assume that unless otherwise specified it would extract to a file of the same name as the file being extracted from minus the ".xz" <boogerlad>regarding inputs in a package, why does it take a tuple like (native-inputs (list (list "pkg-config" pkg-config))) <reepca>boogerlad: often it's necessary for the builder to be able to look up where a certain input is in the store. It can't do that using the package name, because it's possible to have multiple input packages with the same name (for example, suppose you had a gcc toolchain for x86-64 and a cross-compiler toolchain for aarch64 both used in the same package). So some sort of identifier is necessary. <calher>Hm. It's not installing over Wi-Fi. <reepca>calher: what sort of wifi chip have you got? <rekado_>Guest85934: instead of build-essential we usually recommend the use of “guix environment some-package” to enter an environment that has all the things you need to build “some-package”. <boogerlad>reepca: could you provide a concrete example with gcc? would it be something like (native-inputs (list (list "gcc-x86_64" ???) (list "gcc-aarch64 ??))) <reepca>boogerlad: something like that, yes, though the way I've seen it done in guix it'd usually be generealized to (native-inputs (list (list "gcc" ???) (list "gcc-cross" ???))) <boogerlad>reepca: the documentation says "a package, origin, or derivation as its second element". since I'm not familiar with the terminology, a package refers to a scheme variable, origin is some url, and derivation is something in /gnu/store? <calher>reepca no matter, i switched to ethernet <reepca>boogerlad: a package is a structure usually referred to via a scheme variable. An origin is another structure that generally describes a way of fetching something from some other place into the store (url-fetch for ftp, http, https, git-fetch for git repositories, etc). The value of the "source" field of a package is an origin, for example. A derivation is another structure that describes how to construct an output from certain <reepca>inputs. It's serialized as a file in the store with a .drv suffix. <reepca>The common idea is that they are objects that end up representing stuff in the store - in the case of a package, it represents the outputs from building that package. In the case of an origin, it ends up representing some file fetched into the store. In the case of a derivation, it represents the serialized file version of the derivation (I think, I could be wrong and it represents the outputs of the derivation in a similar manner to <emacsite>Installing with GNOME and full disk enc. <emacsite>Wow, lots of packages to download! Hope it dings on me when it's done; I can't see what's happening in the other console. <Guest85934>thanks rekado and reepca: only issue with `guix environment some-package` is that I'm needing the build tools in an environment that's for a non-packaged Python web app that needs to build a bunch of stuff from PyPi <reepca>Guest85934: well, I guess you could get all the implicit inputs for the python build system by just running "guix environment some-python-package". Everything else would have to be specified manually anyway. <MissingNoIOI>Hi, how can I include a package from a channel in config.scm? I can't find an explanation in the docs <g_bor[m]>MissingNoIOI: hello! You can reference it after including the module where it is defined using a use-module, but only atfer you guix pulled with a channel.scm mentioning the channel. <roptat>it builds kotlin-compiler.jar, but fails to build kotlin-runtime.jar (that contains the stdlib) <g_bor[m]>Do you have a build log, or anything else I could help with? <roptat>but now the error is not very explicit (NullpointerException) <roptat>it happens after a big backtrace of library calls <roptat>seems that the recent versions of intellij libraries have different assumptions than the version that was used back then in 2013 <roptat>so I think I'm going to package an older version of these libraries and try again, because the errors I get when I try to compile stuff are all weird <g_bor[m]>do you think that moving the deps to the verison that was used might help? <roptat>like EXCEPTION: /tmp/guix-build-kotlin-0.drv-0/kotlin-0-checkout/libraries/stdlib/src/kotlin/Integers.kt: (3, 1) org.jetbrains.jet.codegen.CompilationException: Back-end (JVM) Internal error: Failed to generate function times <roptat>and other similar things with other files <roptat>I think so, but I don't know what version was used... <roptat>there are not so many commits in 2013 though, so any of them might work <g_bor[m]>roptat: maybe you could try with the last in 2013? <roptat>so it might be possible to build that old version of kotlin and find a path from there after all :) <roptat>I just hope they don't use too many features of their compiler in its source code <g_bor[m]>I believe that from that point on we have the history, so if you can do that, then there is a path. What is more interesting, how long that path would be :) <roptat>g_bor[m], not necessarily, there is no path for coffeescript for instance (without heavily patching) <roptat>there is a version written entirely in ruby, which cannot compile the version written in coffeescript in the next commit... <g_bor[m]>roptat: yes, I remeber you told me that once. There were uncommited changes. That is very unfortunate. <roptat>so I hope kotlin devs didn't do the same mistake <g_bor[m]>It would be nice to do something like have a test, so that the latest 'target version' can always build the latest 'dev version'. This could avoid a lot of mistakes. Moreover, the 'target versions' become apparent. But that might sound like an utopia :) <g_bor[m]>ok, maybe I did not express myself clearly. What I believe would be good development practice for projects is something like: pin a release, that is clamined to be able to build the latest dev version, and then have a ci job to test that assumption, and do not allow a commit to be integrated to master if that ci job fails. Wdyt? <g_bor[m]>or substitute whatever branch naming scheme fits you :) <g_bor[m]>When it becomes inconvinient , then create a new release, based on one of the dev versions... <roptat>isn't that what rust tries to do? <calher>IDK. Last time I was using Guix, I was told to do some weird manual stuff with root and git pull. <g_bor[m]>On a foreign distro you still have to update service files on daemon-changes, but everything else works fine, without further manual intervention. <calher>Can Libreboot's default boot options boot encrypted systems generated by the graphical installer? <g_bor[m]>calher: I don't know, but these are the same that are generated by the manual install process. Unfortunately I am not into Libreboot. <roptat>no idea, but I think some guix users have a libreboot computer, so they might be able to answer <roptat>if you have no answer here, try the mailing list <calher>I guess I'll find out in a few minutes. <Jackneill>i have an existing ubuntu boot usb. can i just dd into it? <Jackneill>and be bootable? the iso contains the fat32 table etc? <g_bor[m]>I have some problems with one of my vm-s. It becomes unresponsive, and the last lines of log I see before restarting it through the hypervisor tells me that elogind-daemon suspended the system. Any idea? <roptat>manzerbredes, have you looked at inferiors? <roptat>you can use them with the --manifest option of guix package too <roptat>"guix package -s abrowser" doesn't return anything, so I don't think so <g_bor[m]>Jackneill: yes, you should unmount it first. <calher>roptat how can i get a vanilla mozilla <roptat>you'll have to package it yourself, or use icecat <calher>is icecat still using the old, crappy version of librejs <roptat>nothing prevents you from downloading a more recent version of the plugin though <g_bor[m]>It seems that currently no os config can be specified without a bootloader-configuration. I believe that we could relax that requirement in the view of system containers. I guess that currently it needs to be specified even then. <rekado_>g_bor[m]: I thought so too. It would be good for VMs. <rekado_>jjjjjjhit.itnjy.nxntghgyuhjghndighdihuxydnhc <rekado_>so… this is what happens when I touch the Yubikey. Huh. *rekado_ just got one for work <str1ngs>nice, I've been thinking of getting one myself *vagrantc has a package for guile-gcrypt and guile-sqlite3 for Debian and working through the guix build-dependencies... <yurb>Hi everyone. I'm currently using nix on fedora to install audio software, but I'm also curious about guix. I have question - currently in nix OpenGL on non-nixos seems quite tricky. How does guix handle OpenGL on non-guix distributions? <yurb>brendyyn: shared library paths <brendyyn>yurb: i dont know much about your specific case, but guix's store has the same structure as nix, so most likely they are comparable <yurb>brendyyn: I think nix makes an exception for OpenGL and doesn't relocate it into the store as it would normally do with shared libraries <str1ngs>yurb: namely, access to X 11 video dirvers <str1ngs>also opengl libraries need to match x11 opengl libraries. not easy to do <yurb>str1ngs: did you run OpenGL programs installed through guix on another distribuiton? <str1ngs>they will not work on foreign hosted distro <str1ngs>but I did not try sample programs such as glxgears. my use case was qtwebengine which uses opengll <brendyyn>but ive run cool-retro-term and godot. they are opengl?? <str1ngs>yurb: yeah, it's dependant on your hosted distro's opengl libraries <yurb>str1ngs: my use case is also qtwebengine which is a dependancy of supercollider 3.10 <brendyyn>oh, i think its just running on the cpu perhaps <str1ngs>yurb: oh, mine is for a web browser I wrote in guile using qtwebengine <str1ngs>glgears might work, so this could be a qtwebengine issue <yurb>brendyyn, str1ngs: for me, with nix on fedora, neither works <str1ngs>yurb: btw there is no package for qtwebengine in guix. but I have started work on one. if you switch to guix <yurb>str1ngs: how can I quickly look up the package definition for supercollider in guix online? <yurb>brendyyn: what is vsync? <brendyyn>vsync locks framerate to ones monitor refresh rate <str1ngs>yurb: that link is for qtwebengine encase you need it in the future <brendyyn>interesting..... Arch's glxgears gives me 5000 fps, but guix's gives me 3500 <str1ngs>yurb: what did you need to know about the supercollider package? <yurb>str1ngs: I'm curious what version it is currently in guix and if it uses qtwebkit or something else <yurb>str1ngs: very interesting - so that must have qtwebengine already <yurb>brendyyn: that is good to know, perhaps I should try it <str1ngs>yurb: dependencies: alsa-lib@1.1.8 avahi@0.7 boost-sync@1.55-1.c72891d boost@1.69.0 eudev@3.2.7 fftw@3.3.8 <str1ngs>+ icu4c@63.1 jack@0.125.0 libsndfile@1.0.28 libxt@1.1.5 pkg-config@0.29.2 readline@7.0.5 yaml-cpp@0.6.2 <brendyyn>yurb: I certainly welcome you to use guix and praise it, but to be fair im sure there is some way of fixing your issue on nix. <str1ngs>yurb: no gui from what I'm seeing. and it can't use qtwebengine guix does not have that package <yurb>str1ngs: ah, so someone just stripped gui off it:( <str1ngs>it might be a feature, headless or something <str1ngs>yurb: I am working on getting qtwebengine upstreamed to guix. will take time. the builds are quite long <yurb>That is not very useful unless for headless mode <str1ngs>either way, does not resolve your current issue <yurb>brendyyn: the way of fixing it is very inelegant unfortunately <brendyyn>Then I'm wondering why things are working for me then <brendyyn>is it because you are trying to use proprietary drivers? *yurb is on a bus, so connection might go away at anytime <yurb>brendyyn: no, I don't have any proprietary drivers <str1ngs>I'm curious how glgears works with arch as well <str1ngs>could be the mesa packages are the same? <str1ngs>can you cross reference arch mesa version with guix mesa version <brendyyn>i had one bug with mesa where there were conflicts in the mesa cache and i had to delete it <str1ngs>I got problems with mesa and nouveau . but nouveau is garbage so... <str1ngs>could be just my video card, as well <str1ngs>I'm thinking about getting an AMD just so life on GuixSD is better <brendyyn>i havent yet tried a full Guix System yet <str1ngs>it's good. the issue I have is nouveau everthing else is great <yurb>This is what it does in case of intel drivers - it seems it adds the mesa package's lib/dri to LD_LIBRARY_PATH <yurb>and then runs the program <brendyyn>many guix programs have wrappers, let me have a loog <brendyyn>i suppose it all could just be accidently working <yurb>str1ngs: is opengl a hard dependency of qtwebkit? <brendyyn>i think we need to get the license issue with ungoogled-chromium sorted out. other libre distros dont include it, and yet we are using the same FSDG label <ArneBab>brendyyn: why don’t they include it? <str1ngs>yurb: I might be able to create a wrapper for guix now <yurb>str1ngs: oh, so now everything will depend on chromium to render basic html:( <devilishtype>I thought google has a roadmap to make it basically impossible to remove their spyware <str1ngs>yurb: nothing is basica about html anymore :P <str1ngs>blame firefox, they dont have a sane reusable browser component <yurb>str1ngs: well, in case of supercollider it only uses it to render its help pages which are html and some trivial JS, certainly no WebGL or things like that <brendyyn>ArneBab: because it is a monster 3-4GiB source code repository with code that was copy-pasted from all over the place apparently, so its dubious whether to call it libre or not. some of us feel that sufficient effort has already been put into librefying it, so it can be included, but others disagree. <devilishtype>Firefox is talking about doing the same stuff with injecting ads in the browser. <str1ngs>yurb: still you need opengl to provide hardware acceleration. <str1ngs>yurb: other wise, page scrolling and videos are garbage <str1ngs>devilishtype: firefox still uses xul <yurb>str1ngs: well, my file manager (pcmanfm) has page scrolling and it seems to be okay <str1ngs>yurb: of course but that's native code anways <yurb>web pages nowadays are very heavy <devilishtype>Google says xulrunner is deprecated and no longer used in qunatum <str1ngs>well it was experimental last I checked <str1ngs>either way firefox is still using xul <str1ngs>I am writing a webbrowser in guile and qtwebengine <str1ngs>also webkit is bad for security updates, ets <devilishtype>arshin, the issue is google and chromium are taking deliberate steps to sabotage people who want to use the code to make "librefied" versions <ArneBab>brendyyn: then it sounds like a decision that can be taken in any direction <str1ngs>well they have no component its either xulrunner or fork firefox <brendyyn>ArneBab: yeah its just some people are quite salty about it and expect unity between FSGD distros <str1ngs>so basically there is no firefox engine <devilishtype>whole issue is it's nice to have their support and updates.. <devilishtype>then you're basically just in the same situation you have with webkit <str1ngs>my alternative was to use guile, and qtwebengine <str1ngs>devilishtype: this is in guile and is more like emacs <devilishtype>I'm not sure if there is any good alternative, one nice thing about webkit is you have a nice base and lots of projects like qtwebengine <yurb>well, with the insane complexity of web today, I couldn't imagine how one could write another web browser (not using chroimum or firefox's codebase) <str1ngs>there is gtk webkit and qtwebengine. that's about it <yurb>browsers now are more like operating systems <ArneBab>brendyyn: :-/ — real unity (not forced) needs a consensus, which needs good reasoning. If that’s not there, there can’t be real unity. <devilishtype>and I don't think Mozilla has done anything yet, or what degree they'd take steps, but .. uh.. I'll have to look for the press conference. They were talking about making it harder to remove tracking, and adding an ad system. <ArneBab>I for one am glad that there’s the ungoogled chromium, because some things don’t work with either my local firefox-workaround or icecat. <brendyyn>id like to package electron programs eventually <str1ngs>until someone writes a freedom html engine , nothing will be free <devilishtype>I can't remember if it was Beard or someone else, but it was someone high up at Mozilla talking about their "monetization" strategy. <str1ngs>so all the bitching in the world won't make a difference <ArneBab>str1ngs: Both Gecko and Chromium are free — Chromium is what became of KHTML, Gecko is just free <brendyyn>can't really blame them for talking about money wheen they are being drip-fed by google to survive <arshin>str1ngs: webkit is free (LGPL + BSD licenses) <ArneBab>The problem is not that they aren’t free, the problem is that they are so big that you can’t easily hack it in your free time <str1ngs>right but even with thos licenses, people still complain <str1ngs>I know for a fact when I release nomad, people will complain it uses qtwebengine <g_bor[m]>on a fresh guix pulled vm after reboot dbus-system did not come up, failing a bunch of services. Have anyone seen something like this before? <ArneBab>you can be sure of that, yes. You can tell them, that the alternative would be uzbl which would not work for the websites they use https://www.uzbl.org/ <ArneBab>str1ngs: I’d love to see more browsers use firefox tech, but that’s hard, too <str1ngs>ArneBab: I know I would use it for nomad, if it was logical to do so <jonsger>ArneBab: at least on Android they are going to this direction with GeckoView :) <devilishtype>I've screwed around with some of those things, and half the web is broken in my experience. <str1ngs>devilishtype: that's why I'm qtwebengine <devilishtype>arshin: did someone pick it up or is it the same developer? <str1ngs>it works for most things and hardware accelerated youtube etc <brendyyn>Is it acceptable to GNU for a GNU software maintainer to offer to sell the right to use GNU software in proprietary applications if they are the copyright holder? <ArneBab>though basically Mozilla did develop a new browser engine — that’s servo: https://servo.org/ — it is now being integrated step by step into gecko <str1ngs>brendyyn: maybe with optional lincense <devilishtype>I've seen some stuff on servo but heard it crashes constantly. <ArneBab>brendyyn: you get back all your rights, so it’s at least legal <str1ngs>devilishtype: ahh servo is what I thought you meant by quantum <ArneBab>devilishtype: I tried servo some time ago, but it wasn’t really ready <str1ngs>maybe with servo life will be better :P <ArneBab>I then understood why Mozilla does not just switch to servo, but rather takes the parts which are ready into Gecko <devilishtype>it'll probably end up bein an abomination of sphaghetti code and never get switched out ;) <str1ngs>right, and rust is really good at that <str1ngs>you can just rewrite subsets in rust and drop in place <str1ngs>it's the whole reason the designed rust after all. <ArneBab>devilishtype: they already switched out quite a few things, and it works really well in real-life deployment <devilishtype>other than I hate building it, uses 1 core and takes forever. <ArneBab>less memory requirement than Chromium, gets much closer in speed. <brendyyn>goes to show how having a well definined challenging goal can provoke good design <str1ngs>devilishtype: strong type, memory safe. no garbage collection. <str1ngs>must sport a hipster beard to program in rust though. :P <devilishtype>All the webkit based stuff I've tried the experience has not been good. <ArneBab>Rust is the only new language (which spread) which actually managed to get the speed to C or C++ levels. <civodul>rekado_: it looks like the lights are green for 1.0.1, WDYT? <rekado_>civodul: should I squeeze in a patch to unhide gfortran at least? <civodul>you can push to master and i'll branch from there <ArneBab>Rust in contrast is as fast as C, and hugs closer to fastest <rekado_>I guess I’ll just do it in custom-gcc <ArneBab>*but* there isn’t yet a rust backend in GCC, so you’d depend on LLVM (which I don’t like). <rekado_>can someone here confirm that magit no longer works properly? <rekado_>I get this error “Symbol’s function definition is void: -reductions-from” <rekado_>I also can’t use “c” for commits any more. <civodul>well, magit-version shows a blank instead of an actual version number <rekado_>the error sounds like something’s mismatched with emacs-dash. <civodul>i have: /gnu/store/f81xrlsyrgmwhnf1rnkgx176rharakvx-emacs-magit-2.90.1-1.b4aec01 <rekado_>I have /gnu/store/3cx4zq6y6m0kyf4yh6z4yh0f01hpjk5k-emacs-magit-2.90.1-1.b4aec01 <rekado_>civodul: the unhide thing is in master now: fbeb92d760 <maav>I have the as rekado_, but the same behaviour as civodul, where do you see it? <rekado_>It’s my problem. M-x find-library dash RET shows me that it points to /home/rekado/.emacs.d/elpa/dash-20160619.611, which is clearly wrong. <maav>Maybe something in your init.el? It seems you have melpa, because elpa shows 2.12.0 version rn <maav>It's quite old, nonetheless <rekado_>well, I don’t need the old stuff there; all packages should come from Guix, so I’ll just delete the directory. <maav>The best option, I did that too long ago:-) <rekado_>mouldysammich: this is from within the environment of the guix-daemon. <rekado_>mouldysammich: there are three possibilities: 1) you don’t have GUIX_LOCPATH set to a valid location (e.g. in the systemd unit file), or 2) you don’t have glibc-locales installed where GUIX_LOCPATH points to, or 3) the version of glibc-locales is for a different glibc version than the one used by the guix-daemon. <mouldysammich>ok, its installed on top of another distro, shoudld a sysctl restart guixdaemon do the trick? or should i set the variable in the .service file? <mouldysammich>ok, thanks ill set it in the unit file and report back, thanks <brendyyn>Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale <brendyyn>maybe thats not the most correct way im not sure <rekado_>mouldysammich: you installed that systemd unit a while ago, right? <rekado_>the Environment declaration used to point to the root user’s profile, but I think this has changed some time ago. <rekado_>yes, now it’s: Environment=GUIX_LOCPATH='@localstatedir@/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <rekado_>IIUC they run a pretty printer over the generated HTML. <rekado_>I’d love to have a richer Info format. It’s a bit sad that we can’t have pretty colours in the Info reader. <civodul>rekado_: BTW, the above syntax for .service is correct, right? <civodul>i still haven't been able to test it with an actual systemd install <civodul>and i'd rather not fail because of a missing semicolon or something :-) <civodul>i guess we could parse the HTML and pass that to guile-syntax-highlighting <civodul>but we don't have a good HTML parser, do we? <vagrantc>ok, i've managed to make debian packages for the missing guile-* guix build dependencies... <vagrantc>and now i see that the guix tarballs for 1.0.0 contain different content than the v1.0.0 git tag! :( <vagrantc>jonsger: i have no idea if they work, mind you! <jonsger>vagrantc: the opensuse ones do work, so if not. I can help checking your debian ones :) <rekado_>vagrantc: note that we’re still using guile-json 1, not the latest version 3. <g_bor[m]>I am studying the operating system reference, and I was wondering why pam-services are separated for services. <vagrantc>ok, so i upgrade the debian packaging for guile-json to 1.2.0 ... <rekado_>g_bor[m]: pam-services are a little weird. I’d like them to be closer to regular old services. <vagrantc>it's still an upgrade as far as debian is concerned. <jonsger>vagrantc: where do you work on your packages? <rekado_>guile-json had two major API breaks, one for 1->2, another for 2->3. <vagrantc>jonsger: haven't pushed to a git repository yet, but was about to <rekado_>the internal representation changed twice; we’re still using the hash representation. <g_bor[m]>rekado_: is there any reason why they are so weird, or it's just someone has to come up with a similar interface? I feel it would make sense to move them into services on the long run. <vagrantc>i wonder if it would be plausible to have guile-json 1.x co-installable with a more recent version on Debian... <rekado_>g_bor[m]: some services existed well before we got used to the system service framework. <rekado_>g_bor[m]: the PAM stuff is pretty old <g_bor[m]>rekado_: ok, so it's for historical reason. Thanks for clarification. <rekado_>civodul: maybe htmlprag of guile-lib would be sufficient? <vagrantc>jonsger: i really prefer to get things "upstream" but yeah, that's a plausible fallback plan <vagrantc>this is all just yak-shaving to try to test guix as part of reproducible builds infrastructure :) <jonsger>vagrantc: I thought more, because bringing stuff to debian could take some time... <sirmacik>does anyone else has problem with missing jsonschema while running docker-compose? <vagrantc>are the .go files guile produces similar in concept to the .pyc files that python produces? <maav>I'm not sure in python, they are the bytecode for the guile vm already compiled <civodul>rekado_: could you check whether 141.80.167.143 has qemu-binfmt up and running? <civodul>there are aarch64 builds offloaded there that fail <civodul>vagrantc: yes, ".go" is for "Guile Object", and these are ELF files <civodul>containing bytecode and debugging info <civodul>ENOENT while executing /gnu/store/jxx6v3ng1mvbhdlqbbr8xahs5rgadd02-guile-2.2.4/bin/guile, which is typically of missing binfmt support <vagrantc>civodul: they seem to be resistant to having strip and dwz called on them... <vagrantc>jonsger: thanks, that spells out most of the issues i've run into :) <jonsger>vagrantc: feel free to have a look around in devel:languages:misc, there are all dependencies of guix written in Guile :) <vagrantc>now i need to figure out how to reasonably handle the discrepancies between git and the tarball... <vagrantc>jonsger: the tarball release has different files than the git tagged release <civodul>vagrantc: i think strip bails out with exit code 1, but yeah, you should just skip them <vagrantc>civodul: yeah, that's what i've been doing <vagrantc>and then silencing all the warnings, just like jonsger <vagrantc>i skipped sleeping and packaged guile-gcrypt, guile-ssh, updated guile-json (twice), and re-added the guile-gnutls bindings to a local build of the debian package ... i've finally reached the "i can try to build guix" part of this <vagrantc>my only way to really tell if i've packaged them correctly is to try and build guix. <jonsger>I wonder if there is a way to run "make check" to install the packaged guix version? I would be really interessted in this <vagrantc>the other thing i started on was just packaging guix-install.sh ... but that seemed kind of silly. <vagrantc>so, i guess i should just make a tarball from git and ignore the released tarball ... it mostly just contains changes to po/* and autogenerated build files ... and the packaging with run autoreconf anyways, so those are silly. <vagrantc>civodul: yes, rekado_ tipped me off to that <vagrantc>civodul: hence packaging guile-json twice :) <vagrantc>automake: error: cannot open < ./doc/guix.es.texi: No such file or directory :( <civodul>vagrantc: the ./bootstrap scripts takes care of that now <civodul>it creates stubs for these files so you can, well, bootstrap <vagrantc>ok, i'll have to tell autoreconf to call ./bootstrap <M4R10zM0113R>How do I go around making gdm work? Seems as if the video card I'm using requires nonfree formate <M4R10zM0113R>Have to use nomodeset because it won't even continue displaying otherwise <civodul>apparently it's tricky with these graphics cards :-/ <civodul>some work out-of-the-box, some don't <M4R10zM0113R>Isn't there some fb I can use in place of amdgpu | radeon? <civodul>looks like samplet has a nice fix here <civodul>hmm js-mathjax sometimes fails to build with EMFILE <Luke|Skywalker>just installed guix system. But when I log in I cant run any command <civodul>that's an unfortunate bug on our side, with a workaround described above <civodul>it'll be fixed in the upcoming 1.0.1 release <brendyyn>Luke|Skywalker: can you use guix environment to save yourself? <brendyyn>Luke|Skywalker: i mean can you use it to make an environment that finds ls <Luke|Skywalker>but i really dont understand tha distro, its really weird, i've been using gnu for quite a time now, more than 10 years <M4R10zM0113R>Isn't there a package for all those base utilities? (binutils?) <sjh223>the guix white paper is very good <Luke|Skywalker>i dont know how to use guix brendyyn, can you put me in that direction <roptat>Luke|Skywalker, the workaround is described in the manual that civodul linked above <brendyyn>Luke|Skywalker: civodul already have you the answer <roptat>you can run "guix install coreutils" for the basic stuff like ls <roptat>then see the workaround, it installs them system-wide <roptat>somehow we forgot to add %base-packages (that contain these basic utilities) to the generated config file <roptat>if you follow the workaround, you will be able to add them back and reconfigure to a system that has these utilities <roptat>M4R10zM0113R, they are respectively in the grep, kmod and less packages <rekado_>on hydra-guix-14 (.145) qemu-binfmt is running <Luke|Skywalker>i will proceed with this workaround... should it be run as root? <samplet>Luke|Skywalker: The “guix system reconfigure ...” part needs to be run as root, at least. <roptat>the configuration file is owned by root, so yes <rekado_>Luke|Skywalker: do you mean editing a configuration file for configuring the system seems not simple? <rekado_>the workaround shouldn’t be necessary, but that’s what needs to be done due to a bug in the release. <samplet>Luke|Skywalker: It’s important not to confuse simple and familiar. For me, learning Guix was hard because it is different, but now that I “get” it I wouldn’t hesitate to call it simple. <rekado_>(I gotta say: this goes both ways… After having used Guix for so long I find myself being frustrated with the other systems I have to maintain.) <rekado_>Luke|Skywalker: on Guix systems we try to avoid having a global namespace for software. <rekado_>that’s why there’s no lib or lib64 or bin or usr/share <rekado_> /gnu/store is an implementation detail. <M4R10zM0113R>Is there some replacement I can use for the missing amdgpu? Doesn't seem to work without amdgpu/stoney_{ce,me,mec,pfp,rlc,sdma,uvd,vce}.bin <rekado_>it ensures that you can “install” different variants of libraries and applications all at the same time. <rekado_>Luke|Skywalker: you don’t have to touch /gnu/store, nor should you ever run a program directly from there. <Luke|Skywalker>i dont see a point for doing so, but will keep digging, love gnu, and thanks for the attention <M4R10zM0113R>I assume it's because it's missing the firmware for this particular card to work <samplet>Luke|Skywalker: The store looks weird, sure, but that’s because it is working hard to make sure that software is properly separated and not just put in a big soup under “/usr”. <rekado_>avoiding global environments for software is much like avoiding global variables when programming. <brendyyn>Luke|Skywalker: having my binarys manualy built on some random hackers laptop and uploaded to a repository is creepy ;) <pkill9>Luke|Skywalker: the packages themselves have /bin, /share etc <pkill9>and a profile is a union of those packages, so you'll find those directories in ~/.guix-profile and /run/current-system/profile <samplet>Also, if you want to *use* Guix, you should conserve your reading attention for our manual, which is generally very good. <roptat>help, biber is not happy: ERROR - Error: Found biblatex control file version 3.4, expected version 3.5. <roptat>I tried to install biber and texlive in the same profile <rekado_>roptat: you installed the big “texlive” package? <roptat>I can't find what I need en the smaller packages <civodul>rekado_: re qemu-binfmt, something's wrong: is guix-daemon passed all the --directory options to add qemu to the build env? <sjh223>which package(s) would I need to display asian language fonts, I installed font-adobe-source-han-sans but asian languages still don't render in icecat/chromium <sjh223>ah, I installed it with the 'out' output in emacs-guix, I'll try the specific outputs <maav>Smalltalk seems to be unavailable for substitutions. I'm getting errors during tests when I guix build it, but when I do the make check manually it works... where should I look to get the error from Hydra? <civodul>as returned by "guix build smalltalk --log-file --no-grafts" <maav>civodul: the exact same error I'm getting locally... :-( <maav>But it works with source ../environment-variables && make check... weird <civodul>it could be because it relies on /bin/sh, which is not in the build env <maav>civodul: I'll check that, thanks <boogerlad>in the context of building packages, does anyone know the difference between %output and outputs? when should I use one over the other? <rekado_>civodul: I’ll try to update the nodes tonight. <rekado_>boogerlad: “outputs” is a variable captured by build phases <rekado_>it’s best to use “outputs” because it’s obvious where it comes from. <rekado_>the % variables are a little special and are injected with magic <rekado_>sometimes they are unavoidable (e.g. outside of build phases) <boogerlad>I usually see something like (out (assoc-ref outputs "out") (utils (assoc-ref outputs "utils") for packages with multiple outputs <civodul>rekado_: no rush though, as long as we have a few build nodes, it's ok <rekado_>boogerlad: %output used to be used in the past <pkill9>specified by "lambda*" of the build phase <rekado_>boogerlad: newer package definitions all use the (assoc-ref outputs "out") idiom. <M4R10zM0113R>Okay I made radeon load instead of amdgpu, still getting that spam of gdm failing to init <maav>rekado_: even though they are not available in some places as %build-inputs, isn't it? <M4R10zM0113R>Does it even work as a display module is what I wonder now <M4R10zM0113R>Am I missing something because my videocard still seems to be using amdgpu instead <pkill9>i see now some packages getting a progress bar when being built, why are they able to report progress and others aren't? <rekado_>pkill9: CMake-generated makefiles print progress information by default. <rekado_>pkill9: autotools-generated makefiles don’t do that, so it’s hard to estimate progress. <rekado_>maav: %build-inputs is used outside of build phases. <maav>rekado_: yes, my bad, I was meaning package recipe <maav>rekado_: as in the configure flags <pkill9>you would create your own package definition that builds akernel with the firmware you want, then put that in your system configuration <pkill9>i dunno about compiling the kernel let alone compiling custom one on guix <maav>civodul: the Smalltalk problems seem to be unrelated with /bin/sh, even though I'm not sure if we should patch scripts/Package.st... I'm getting different errors with guix environment --container smalltalk, all related with networking, but I have to look at the code <civodul>maav: ah, networking is the other possible issue <rekado_>Luke|Skywalker: it will be wherever Guix puts the generated configuration files. You should configure SSH with the openssh-service-type. <rekado_>see the manual for openssh-configuration <maav>civodul: I'm checking the tests and only use localhost, shouldn't that be ok? I mean, networking code needs testing too <maav>civodul: and only some of them fail, other seem to work properly <maav>maav: the failing cases are SpSocketBasics>>##testSimpleEchoingServer, SpSocketBasicsTests>>##test51IO, 5 more of Swazoo.SwazooSocketTest and 11 from Swazoo.SwazooStreamTest <rekado_>Luke|Skywalker: it comes with Guix: run “info guix” on the command line or access it in Emacs. <rekado_>Luke|Skywalker: there’s also a copy on the website, but it may not necessarily match your version of Guix, of course. <Luke|Skywalker>so all the systems config goes in the scheme? this is werdly awesome <rekado_>yes, we’re trying to make it possible to configure the whole system via Scheme. <maav>(awesome) is a better one:P <brendyyn>guile is the only general purporse language that makes every program in a system available to its module system. <Luke|Skywalker>and everytime i change a config (in this case, ssh), i must run guix system reconfigure? <maav>Luke|Skywalker: yes, you have to reconfigure your system. OTOH, it gives you snapshots of the configuration <roptat>and it creates a generation of the system everytime, so you can always roll-back a generation if you make a mistake <maav>civodul: but I cannot reproduce the guix build failures (ANSI compliancy tests) <civodul>maav: these tests are network-related, given their name, so there's probably something that has to do with host name lookups or connecting to remote machines <civodul>perhaps you could strace the failing tests to see what's going on <vagrantc>hrm. so i've got all the dependency packages built, but guix doesn't seem to find guile-git <maav>civodul: it seems something weirder. abort is called 366 times through the code, some of them must reveal the problem (as the tests inside the daemon exit with 134, sigabrt), but my machine's memory is almost full... <vagrantc>looks to have the same files as guile-git in guix has... <rekado_>vagrantc: are the files on GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH? <maav>I'm building gettext-0.20.1 from gettext-boot0 to gettext-runtime and gettext-tools (with java and mono) from core-updates + master, so my machine has already died twice <civodul>that's a lot of work for a lonely machine :-) <vagrantc>rekado_: i'm not sure those are set to anything other than whatever the default might be <maav>civodul: it's a laptop on top of an industrial fan rn, or it reaches 80 degrees <jonsger>vagrantc: I think I can remember a (git) could not been found error <maav>civodul: hmmm, the abort call comes after a failed call to _gst_mem_protect, with either ENOMEM, EFAULT, EACCES or EINVAL in the test 047 <maav>are there any limits imposed through memory protection or something else in the daemon that don't apply to guix environment --container? <vagrantc>jonsger: added a depends for libgit2-dev (similar to your requires) and that seems to be moving along <maav>civodul: thanks for the confirmation, now I'm completely lost:-( <civodul>maav: it could be that it started failing with the glibc 2.28 upgrade <civodul>it's perhaps worth asking upstream if the issue rings a bell <vagrantc>all these guile projects sure have had clearer licensing than other projects, and for the most part ./configure && make && etc. work ... so that's been nice. <civodul>vagrantc: glad you end on a positive note despite all the pain you've endured ;-) <vagrantc>civodul: i now have concrete steps to move forward with getting guix into Debian ... presuming this build finishes ok. <civodul>beware of test failures right when the build is about to complete :-) <vagrantc>at least when setting up for ./pre-inst-env ... i rarely see it pass all tests <jonsger>having now a Debian, an AUR, a Fedora and an openSUSE package. Not bad :) <vagrantc>speaking a bit soon on having a Debian package... but it's coming along finally <civodul>vagrantc: guile-charting is an optional dependency, so you can ignore these messages <civodul>it can be used by 'guix size' to generate nice graphs <civodul>"make" is failing though, so there might be a real error elsewhere, no? <g_bor[m]>civodul: is the load-linux-module/fd unbound at the end is also harmless? <civodul>hmm what to do with "texi2dvi: pdftex exited with bad status, quitting." <civodul>i've seen that before but i forgot the trick <civodul>hmm i did an EFI install in QEMU but the thing won't boot <maav>civodul: what are you seeing? <maav>Do you see the grub? Or it fails later? <civodul>but i think i got it: it's because the EFI variables are not saved <civodul>so when i start QEMU it starts with an "empty" EFI firmware again <maav>civodul: do you mean the efibootmngr thingy? <civodul>but it's just that i'd need to do "something" to have the EFI variables saved across QEMU invocations <mbakke>civodul: I think you can copy the firmware executable somewhere and make it writable, then GRUB will be able to update it. <civodul>mbakke: so you mean the ovmf_x64.bin file, right? <civodul>i have to go now but i'll give it a try <civodul>rekado_: could you have version-1.0.1 built on berlin, if you have time? <Luke|Skywalker>almost giving up, for numerous reasons. guix: the burocracy system <tune>can someone take a look at an issue with the minetest package? the contentdb is not accessible. I get an error about untrust ssl in my debug.txt <devilishtype>Luke|Skywalker, I'm just learning about Guix myself, but did you come here to complain or do you have a question you need help with? <Luke|Skywalker>so, i've been trying for hours to set up mail server, following the manual <nckx>Luke|Skywalker: Please calm down and be respectful. <nckx>Luke|Skywalker: I run several mail servers on Guix System. I understand that learning new things can be a challenge, but this is not the way to ask for help. <devilishtype>Well, if you don't give any information about what's going on you're not going to get help. <devilishtype>Have a pastebin with your file? Have an error message? have a specific question? <Luke|Skywalker>there it indicate to set a config-file, but if I do it complains it doenst exist (abviously) then I took it out and that happen <devilishtype>did you set it to your config file or what was shown in the manual? <devilishtype>I haven't set exim up in guile, but to me it sounds like you just copied what's there and it doesn't have the file? <Luke|Skywalker>i`m setting it to the config.scm and trying to run the guix system reconfigure <devilishtype>I'm talking about the "./my-exim.conf" example in the doc. <samplet>tune: Do you have to set an environment variable so that “minitest” can find SSL certificates? Many programs need “SSL_CERT_DIR” and “SSL_CERT_FILE” set. <nckx>Honestly? I do. I'm just here to keep an eye on things now. <nckx>We're humans here. Except sneek. Botsnack. <devilishtype>So I'm confused if you don't have a website where does this owl come from nckx <samplet>Luke|Skywalker: I just built a VM with the example from the manual, so I can confirm that it works. <Luke|Skywalker>i've yet not included dovecot nor figure how to use it with vmail under sql <nckx>devilishtype: I've wondered that myself. <samplet>Luke|Skywalker: No. I more-or-less copied our “bare bones” configuration file and added the mail services. I just wanted you to know that it is possible and you are probably even close! :) Pasting your config might be the easiest way for us to help you: <https://paste.debian.net/>. <maav>Hmmm, that form is exported by (gnu) module <maav>Luke|Skywalker: how are you instantiating the configuration? <maav>Luke|Skywalker: you mean guix system reconfigure g.scm or are they unrelated files? <nckx>I have an explicit (use-modules (gnu)) before my (use-foo-modules …) forms. Never tried removing it. Might be needed. <maav>nckx: it's mandatory, this module exports that form <nckx>My configuration is such a mess… <devilishtype>Luke|Skywalker: so you need (use-modules (gnu) (gnu services mail)) *kmicu thought that nothing can be more confusing than Clojure’s imports but Guile is close enough. <nckx>devilishtype: Once (gnu) is loaded, (use-service-modules mail) should work, but that's a matter of style. <rekado_>kmicu: I’d like to understand this confusion. What makes it confusing? <devilishtype>nckx, I was looking at some other people's config.scm and most I've seen are declared like that for every module. <kmicu>Then why not ‘(use-modules (gnu services mail))’ only? [Asking from the point of view of folks not familiar with lisp]. <nckx>kmicu: Because that only gives you mail services, and you're presumably using something from gnu. <Luke|Skywalker>guix system: error: /etc/config.scm:45:12: no value specified for service of type 'exim' <samplet>Luke|Skywalker: You will need the “(exim-configuration ...)” part from the manual, too. <kmicu>nckx: we know that; newcomers don’t. For them ‘(use-modules (gnu) (gnu services mail))’ can translate to ‘import gnu.gnu-services-mail’. <nckx>kmicu: No, that was from the point of someone who's never seen a Lisp programme before. <nckx>I.e. me, when I first installed Guix. <kmicu>Guix is your first lisp experience? <nckx>By the way, just tested: (service exim-service-type (exim-configuration)) works fine, no need for a configuration file. The fact that exim-configuration is needed at all is a cosmetic bug, though, IMO. <nckx>You will need a non-empty mail-aliases-service-type. <nckx>It all seems very complicated… *nckx is an OpenSMTPd kindi of person. <nckx>Guix got me into Scheme. *nckx is now one of those people who is slightly too into Scheme. <_rad>so it seems that grub hangs on my dual head setup - disconnecting a monitor allows it to continue <nckx>_rad: There was someone with a 2-GPU Ryzen here yesterday who unplugged(?) their second card to be able to boot. They made it to Linux, though. Still, a strange coincidence. <_rad>nckx: well whats more strange is the the install USB gets past grub just fine <kmicu>(Some folks prefer ‘Configure-By-Example’ style and Guix is currently better for folks prefering ‘Configure-By-Reading-Manual-Top-2-Bottom’ style. Today there are not many real world examples on GitHub/GitLab/etc to make first style not frustrating or futile.) <_rad>and I think they use the same grub version... will compare the cfg files to see if theres something that catches my eye <_rad>now getting kms working is still in progress :) <_rad>I noticed the manual has a fix for no ls :) <_rad>because it couldnt find my NIC for some reason, although it was there in ifconfig *nckx has unfortunately been conditioned to avoid responding to the cargo-cult-config folks for they know not what they wrote. Shame. <_rad>but i used the EZ config.scm <kmicu>Friendly reminder: GuixSD is now Guix System. Nix’s OS is called NixOS. 😺 <kmicu>(And yes we can mix them. Use Nix on Guix System and use Guix on NixOS.) <nckx>devilishtype: Guix System, you furious researcher. <nckx>I used NixOS for several years. *kmicu forgot to start with ‘I’d just like to interject for a moment’. <rekado_>kmicu: I think I’m not the only one who suggested to write a cookbook-style document for tutorials and in depth examples, and include it alongside the manual. <nckx>Or as I've recently taken to calling it: Guix plus nix. <devilishtype>MY main machine is gentoo right now. I was a fedora user for a long time, I had a debian monstrosity with a bunch of pinned packages from testing and sid to get what I need. <rekado_>nckx: Guix + “nothing at all”? (Some Germans pronounce “nichts” as “nix”.) <kmicu>Yes, a cookbook book will be a great help for the Configure-By-Example folks. <devilishtype>Maybe I'll switch to guix once I figure it out more, Fedora has hosed my machine's kernel over like 4 times, just a conicidence they were bought by IBM? <nckx>rekado_: Yup, niks = nothing, but we don't have to be creative with pronunciation to make it work. <_rad>How about a max-case fully commented config.scm :) <devilishtype>I think providing that kind of stuff is asking for trouble. <rekado_>devilishtype: heh, I’m still using Fedora on the workstation at work, just because of active directory account integration. <devilishtype>The people that are going to use it, are going to complain when things are so different than most other distributions. <nckx>devilishtype: I went Gentoo → Exherbo → Nix → The One True OS, it seems an above <_rad>like spit out a config.scm with all the defaults? would that be too unwieldy? <rekado_>_rad: there’s no maximum configuration, really. After all this is a configuration language embedded in a general purpose programming language. It can get as complicated as you want. <nckx>Dunno what happened there. <_rad>devilishtype: difference is so large that more difference doesn't make a difference <rekado_>_rad: we’ve got some example os configurations in the manual. <kmicu>_rad: very bad idea. XMonad had such thing with ‘DO NOT USE THIS CONFIG, THAT’s ONLY a REFERENCE’. That approach generated countless lost souls on #xmonad. <rekado_>for bare-bones, light-weight desktop, heavy-weight workstation. <_rad>rekado_: by max-case i mean use each of the most useful objects (is this what they are called in scheme?) for operating system <_rad>kmicu: right, but there are many lost soles now... :) <rekado_>do we use “cons” or “cons*” or “append”…? <nckx>_rad: Like use cons here, cons* there, list somewhere else, just to exhibit the options? <nckx>What rekado_ just said basically. <devilishtype>Maybe you need a devil popup that's like clippy warning people. <rekado_>M4R10zM0113R: use flags are on the horizon <kmicu>A cookbook with real world scenarios: setup a mail server, setup XMonad, setup automatic gc, and so on is what Configure-By-Example folks need 😺 <M4R10zM0113R>If that was the case I'd get rid of most poetterware if not all <nckx>Including my ‘…wait… whut’ reply. <_rad>nckx: unfortunately I don't understand any of that... need to learn Scheme :) <M4R10zM0113R>*parameterized packages* ... Didn't think there'd be a more formal naming convention <M4R10zM0113R>Somewhere along the logs of this chat, unless I was fooled <nckx>M4R10zM0113R: You weren't. *nckx prefers any name over word-spaghetti ‘use flags’. <_rad>hmmm, i updated guix to the core-updates branch and reconfiguring... takes quite a while! <_rad>compiling multiple versions of guile ... argh! <kmicu>‘Quite a while’ is nothing 😺 you barely started compiling. <nckx>_rad: Oh, you have no idea 😃 <kmicu>Hope you don’t have rust in deps. <_rad>never compiled rust... is it self-hosting with funky bootstrapping? <nckx>Borg sneaks this in a patch release: <nckx>bundle latest supported msgpack-python release (0.5.6), remove msgpack-python from setup.py install_requires - by default we use the bundled code now. optionally, we still support using an external msgpack (see hints in setup.py), but this requires solid requirements management within distributions and is not recommended. <kmicu>As a Borg user I’m dissapointed. <nckx>_rad: Well, you're about to compile it several times. I think it bootstraps from C now, then it's a chain of rust compilers. <rekado_>_rad: core-updates is not guaranteed to be usable at this point. <_rad>rekado_: it's ok because 1.0.0 isnt either for me :) <_rad>so if i'm going to play around i might as well do it on that branch <nckx>_rad: It's true, though, there might be very fundamental breakage. <_rad>np... like i said, playing with it to gain familiarity <kmicu>You didn’t hear this from me, but Tardis runs on Guix System. 🤫 <_rad>rekado_: but isnt the point that i can just switch to gen -1 ? :) <rekado_>(I learned this the hard way when learning to play musical instruments. Everything is frustrating when the instruments make it difficult.) <_rad>guix is supposed to make this easy ;) <rekado_>yes, but if builds fail because nobody has taken the time to fix compilation problems you’re not going to get far. <_rad>rekado_: well then ill play fixing the issue :) *nckx isn't going to discourage someone who's idea of play is fixing core-updates 👌 *arshin is getting the impression you need a supercomputer to update guix <devilishtype>Nah it's fine I started updating it last year on my ATOM machine, and it's still running right now. <nckx>Shovel another libreoffice update onto master, it's getting chilly. <devilishtype>When you think you know somebody and assume they use Emacs, then you learn they use libreoffice. <nckx>devilishtype: Just my go-to ‘huge thing that seemingly depends on everything’ example. Probably shows my age (the cool things that take days to rebuild are Web browsers now). <nckx>devilishtype: Don't worry, I do, and I don't. *nckx not sure if ‘you look like an emacs user’ is the compliment his mother says it is. 😒 <devilishtype>I'd post the picture of the chad emacs user, but it's NSFW. <nckx>devilishtype: I thought I found it, but it's not that NSFW, so now I'm furiously looking for one that is. <nckx>So much browser history that's going to be hard to explain. <Luke|Skywalker>wheres does exim put the mails? it seens to be receveing on the logs <nckx>Hey, let's keep it on topic. <nckx>(It's an old meme, it still makes me uneasy though.) <nckx>I don't know. I printed it out and hung it over my bed and it just creeps me out sometimes. <nckx>Like, it doesn't talk-talk, but… *rekado_ wrote an HTML syntax highlighting post-processor <str1ngs>hello, I have a foreign distro hosted publish server. but --cache does not work. on the client end I get 404 error on first hit. which is normal. but then the guix-publish server does not baked the nar. <str1ngs>could someone confirm that --cache even works? <devilishtype>davexunit: syntax highlighting in the docs for guix I think. <davexunit>it would be cool(tm) if the highlighter could be incorporated into this library :) <rekado_>davexunit: I’m just using your library to highlight the Scheme code in pre.lisp blocks in the HTML version of the Guix manual. <rekado_>the scheme-highlighter is actually called lex-scheme <davexunit>it's always a struggle to keep those project pages in sync with the api on all these experimental projects <nckx>vagrantc: The grand total for all (visible) package sources (both original and patched) is ~54G. <nckx>Do with this information what you will. <vagrantc>so it seems very plausible to keep things under 500GiB if i only rebuild releases and such <bavier>there are a few packages that probably make up a large portion of that <bavier>e.g., iirc, the google fonts source is huge <nckx>I knew the ‘terabyte’ claim was bogus but I wasn't expecting it to be so little (note that this test omits private packages, but I doubt that they'll significantly affect the ballpark size). *rekado_ should add some more genomes <nckx>Luke|Skywalker: I'm not familiar with exim, but I think ~/Maildir is the default. <jdormit[m]>Anyone here using guix as a package manager on arch and running X installed with guix? I'm having trouble running startx, since the X server is meant to be installed globally but guix only installs packages per-user <nckx>Note that the list above is a naive ‘find /gnu/store …’: it includes some old sources, but I didn't count those as part of the 54G. <jdormit[m]>yes, x-server doesn't like being run as a non-root user afaik <nckx>Another caveat: it also doesn't include git checkouts because I'm still waiting for du to complete 😛 <vagrantc>so, when you apply patches or substitutions on an upstream tarball, guix then generates a new tarball with those applied? <vagrantc>i've been wondering about this when i see multiple identically versioned upstream tarballs <nckx>(‘It’ being, again, the list, not the total.) <nckx>vagrantc: Yep. It's not super-efficient but the unpatched sources can be garbage-collected once the patched ones have been generated, so maybe it's not so bad. <vagrantc>i thought the switch to KMS in recent years/decade allowed X to not run as root <devilishtype>most distros don't run as root anymore, some smaller ones still do I think. <bavier>and the upstream source will only be downloaded if the patched source isn't available for substitution <devilishtype>I'd be surprised it the default in guix was root only default. <nckx>bavier: Right, but I ran the test assuming vagrantc would build everything themselves. No substitutes were used. <vagrantc>nckx: yeah, i basically want to build everything and run guix challenge on, well... everything. <nckx>Not that anyone cares but now it didn't run for nothing ☺ <vagrantc>can guix-daemon work without guix? e.g. from a remote guix or something <vagrantc>oh dear. now i remember why i didn't put much effort into packaging guix ... the guile-gnutls bindings are not built in debian due to a history of intermittant test suite failures ... and is likely reluctant to support it again <Luke|Skywalker>luke skywalker sucks, the whole day passed and couldnt set this mail server to work properly <M4R10zM0113R>Turns out it's not enough to include the firmware in the kernel