<snape>lukas__: hint: you can ask about building custom kernels (or custom packages) :) It's more generic, and it will probably meet your needs
<lukas__>@snape I see. My script right now is failing with error message invalid field specifier and I was just scratching my head
<snape>lukas__: I don't know. Maybe you could try to remove stuff until it works, and add little by little then. And find inspiration from Guix git repository. Now I *really* must go to sleep... good luck!
<lukas__>After trimming some functions to more elegant forms now the kernel is building :)
<lukas__>I am reading generating initial ram disk section of guix manual but I do not see any intrinsics that might help be sort the order of the kernel modules. Can somebody help me?
<kimin>I am confused with GuixSD as to where I define the system configuration and where I define specific user configurations. When I run guix system reconfigure, is that setting the system configuration?
<kimin>Then how would I set specific user configurations*
<sturm>kimin: Yes, that's the system configuration with `system reconfigure`, which will (probably) include things like Gnome and a basic set of programs to use on the system.
<sturm>You can install programs for a specific user with `guix package --install [package] ...`
<sturm>I prefer to do `guix package --manifest=somefile.scm`, where somefile.scm contains a list of all the programs I want as a user
<sturm>pretty handy to be able to commit that file with version control
<kimin>Yeah, that was something I was unsure about. But on a machine with a single user, I assume just using the system config is ideal
<sturm>I guess they're tools you can use however you prefer, but I've settled into having a mostly stable system config that upgrades reasonably reliably and quickly for security, and the bulk of my day-to-day tools in my user config, which doesn't always upgrade reliably if some package no longer builds.
<reepca>out of curiosity, anyone know why openssh clients can't seem to access lsh servers? They complain about failing to find matching ciphers, but ssh -Q cipher shows that there *are* ones that match... does openssh not try all the ciphers it has available? How do you know/control which ones it does try?
<reepca>On a more on-topic note, what have we got in the way of remote desktop services?
<snape>g_bor[m]: I don't understand, if you don't 'guix pull', you stay at the same Guix version don't you?
<janneke>i tried the jump to gcc-4.7.4 but haven't managed yet and opted for a (temporary?) half-way step to gcc-4.1.0
<g_bor[m]>snape: Actually, yes. But it would simplify provisioning new machines, furthermore would allow to use guix pull with much less breakage. Using such config files would bring the possibility to get to a completely defined state one more step closer :)
<g_bor[m]>snape: Actually, yes, I know that. It is nice that we have this. My point is that guix pull --commit and a manifest, or an operating system file separates configuration to two places... I would not want this as a required filed.
<civodul>that is, a channel will be an entry in the profile that 'guix pull' create
<civodul>then it's just a matter of writing 'guix channel add' and all that
<g_bor[m]>civodul: It would also be nice, if we could create links between manifests, or embed them into one another, or to have a format to bundle them together. WDYT? This is just an idea for now, I don't have any particular thing aside from deployment in mind...
<civodul>at first sight they seem to work at two different levels though
<civodul>so for instance 'guix package -m' alone cannot do anything with the commit info
<civodul>that's why i'm suggesting to have two manifests
<g_bor[m]>civodul: I'm fine with that. Two manifests are no problem, but it would be nice to be able to mark them 'compatible'. So that for example we don't try to reconfigure to a system with a config incompatible with the guix version. For example see the changes around file system config.
<g_bor[m]>civodul: I have a workflow in my mind, which goes something like this: Install guixsd from this installer image (determined by guix manifest, and an os description) to nodeid. Log in the node, guix pull to this manifest. guix system reconfigure to this os description. Add these manifest to these profiles. Maybe add profiles to users... Configure users like this (guix home, for example as roptat mentioned, with a home
<civodul>hopefully we'll work on this for good after 0.15 :-)
<civodul>speaking of which, i am/was hoping to fix one of the guile multithreaded crashes before the Guix release
<civodul>because 'guix pull' is just too crashy currently
<jlicht>g_bor[m]: How would you 'know' if something is compatible with a guix version?
<g_bor[m]>roptat: Currently most of the time provisioning either goes trough an api, so you know already what you need for an installation image, or when provisioning unknown devices, most probably bare-metal, you netboot it using a discovery kernel, an enc classifies the node, and reboots, so that it can provide the image that fits the node. I hope to shortcut this, by guix system reconfiguring the discovery image. I'm actually trying
<g_bor[m]>to design out other configuration management tools from the setup.
<g_bor[m]>jlicht: Oh, that is so nice question. Actually what I know, is that it is compatible with the very version it was used an succeeded :)
<g_bor[m]>roptat: woops:) this is similar to ghc boostrap problem....
<roptat>it's not complete: I bundled generated text files in the recipe for gradle-docs, I have doubts about my gradle-maven package, I somehow had to add java-commons-logging-minimal even though it's not in the upstream binary distribution and gradle-ide eventually requires scala
<roptat>well, it's the same problem with ocaml and rust
<roptat>and we didn't do anything to address those
<roptat>so maybe it's fine to package a binary version for scala?
<g_bor[m]>roptat: I guess it is still good to have a todo item, but it would not make much sense to stop using these. In the last Reproducible Build Summit we mapped this problem space, a graph should be lingering somewhere about that. Rust seemed to be the most problematic, depending on everything including itself.
<g_bor[m]>roptat: I guess we could do that, until we can find out something better, but it would be nice to wait for some other opinions. I guess writing a message to guix-devel, with a shot summary of this conversation would be nice. WDYT?
<ngz>I'm pretty lost when it comes to npm ecosystem.
<g_bor[m]>ngz: It seems that the java-ecosystem is a bit crazy... Once there was an npm exporter, but it very quickly blew up to hundreds of dependent packages... I think it is not maintained any more. The main problem is that versions are locked, and this causes version bloat. The correct way is to have a look at the package.json file. There will be the dependencies listed. Package those first.
<civodul>atw: you mean have a project.clj -> pom.xml converter of sorts?
<atw>civodul: I propose manually writing the translation of the linked build.clj to a pom.xml once, in order to write a leiningen-bootstrap package definition, then using leiningen-bootstrap to build a modern leiningen
<roptat>kimin: I think you should try running guix pull once more
<kimin>roptat: I did, same problem after it finished
<jonsger>oke. then I'll drop it. Non systemd distros are too old for guix 0.15
<tibbe>Hey, since a few days any attempt to execute guix pull fails for me. I am quite new to guix. Is it "normal" that the guix master branch points to non buildable commits or is it a problem with my setup?
<tibbe>compilation works fine but after calculating the derivation it the process crashes with stacktrace and an error message (-> invalid build result (#<derivation /gnu/store/0dqqhqq9fmwjadhrj9wa0kpdp3q74c56-compute-guix-derivation.drv => /gnu/store/r2cvdmf3bbdqz07lw14zvp3j7hgz7w9q-compute-guix-derivation 2b4e280> "") )
<mbakke>tibbe: Is this on a foreign distro or GuixSD?
<tibbe>mbakke: I am running debian right now and can reproduce the problem on another machine running debian
<nckx>That's a known limitation of Guix (and Nix) when running unmodified ‘foreign’ binaries. IIRC, they point to something like /lib/ld-linux.foo as the linker loader which doesn't exist on those systems.
<nckx>You'll have to use patchelf to, well, patch them. Let me see...
<ng0>it's not nice, but you can elfpatch if it's for private use
<ng0>that is.. if this is Guix-on-GuixSD. Otherwise you could simply write a thinwrapper to re-set the path
<nckx>Ugh. It's been years since I've patchelf'd something.
<nckx>How would you even go about protecting such a thing against GC? Any best practices for the worst practice?
<ng0>I would share the code, but I can't because I use it for the obvious cases where you can't get the source of an application. I have a package definition, and as I had to replace the install phase, it was trial and error. the basic recipe is that this has to occur:
<ng0>something along those lines, I mean.. (for-each (lambda (file) (system* "patchelf" "--set-rpath" rpath file)) (cons* bin bin-as bin-as2 (find-files out "\\\\.so$"))) followed by (for-each (lambda (file) (system* "patchelf" "--set-interpreter" ld-so file)) (list bin bin-as bin-as2)))… you get the general idea. there's no one formular that matches all cases though. Our rust package has an example.
<ng0>if you wanted to, you could try and formalize it into a build system for yourself, but so far the 1 application I have did not justify half-automation
<nckx>Copenhagen_Bram: What ng0 wrote is correct. A less elegant but faster way if you just want to play around in the meantime: a manual ‘cp $(patchelf --print-interpreter $(which ls)) /home/bram/...’ and ‘patchelf --set-interpreter /home/bram/.../ld-linux-x86-64.so.2 $your_binary’ should at least get ‘ldd $your_binary’ to work so you can list the required libraries.
<nckx>The reason for making your own copy is that the original ld-linux*.so.2 in /gnu/store will get GC'd eventually.
<nckx>If this all sounds very complicated and ugly that's because it is, unfortunately, quite.
<nckx>I just realized I have (service special-files-service-type ("/lib/ld-linux-x86-64.so.2" ,(file-append (canonical-package glibc) "/lib/ld-linux-x86-64.so.2")))) in my system configuration and absolutely no memory why or when I wrote that.
<Copenhagen_Bram>nckx: wow, it's like the only way to install something in Guix is to write a package for it
<Rukako>g_bor: sorry for not replying to your mail before, I just noticed it
<ng0>I think you could still install to a path in your home directory, or in the root, etc.. options exist, but if you want to maintain control a package is nicer
<ng0>it's what I do for my scripts collection for example
<ng0>tbh, I would really pay more money for renoise if they would do a source release. but that's their business model. a .deb is better than nothing.
<ng0>ah, I forgot: you also need to disable runpath verification for some software.
<nckx>Copenhagen_Bram: Keep in mind that ‘installing’ here is short for ‘installing binaries compiled someone else’. I agree it's (probably unnecessarily) painful, but it's not really what Guix stands for.
<nckx>(File system Hierarchy Standard, I believe.)
<Copenhagen_Bram>hmm... It might be even better to improve the ease of writing guix packages?
<fzer0>Hi guys, newbie here. How do you guys handle package managers? I have seen a lot of youtube videos about this distro and the speakers talk about it, but I am still confused. Do you use package managers, or do you declaratively add the package to the config?
<ng0>I'Ve been think about package manager namespace for things I'm working on.. provide with lots of hacking for portage, etc
<nckx>Copenhagen_Bram: Not that I know of. Guix is very source-focused (understatement of the week) so this is not considered much of a problem AFAICT. I certainly don't think it merits the effort or possible overhead.
<ng0>which might or might not involve some tinkering with chroot-like FHS spaces.. or something. nothing I prioritize, just a curiosity.
<Copenhagen_Bram>fzer0: guix is a package manager, and you don't add every package you install to the config, just the ones you want installed system-wide. You can install guix packages by typing `guix package -i icecat`, and they get installed just for your user. And you could install a different version of icecat for a different user.
<ng0>Copenhagen_Bram: eventually we should have converters. Where you write a limited set of a package definition and it transforms to a guix readable package, but you have to do some manual work, like dealing with gexps which we might or might not get later on in package objects.
<nckx>Copenhagen_Bram: Making packaging easier is always good.
<fzer0>Copenhagen_Bram: Sorry, I am mostly referring to GUIXSD and want to know best practices. For instance, if you use python do you use pip for scikit-learn, or are you creating a guix package?
<ng0>so a friend and myself have been discussing ideas about what essentially is a lexer+parser, taking a range of languages and try not to output to much garbage for something based on guix or guix. I didn't think about packages, but rather about system definitions though
<ng0>pip works.. though I noticed for python development to really work, I need to enter a guix environment, where I then can activate a venv or whatever
<nckx>ng0: I think that's the way to go! Not making packaging ‘easier’ by dumbing down the DSL, but making sure that people have to write as little as possible of it whenever possible.
<ng0>sharing configs is not forbidden though. in my case, idk. it would be on the same git host as the almost-instrucitons but: you just will not be able to use it, since what I do in there and reference in there is currently not in a state that is online. so it mentions a different kernel because I have more kernels, but that's it.
<ng0>Copenhagen_Bram: remember when I said enter a guix environment with python + the required modules?
<ng0>fzer0: what is done in terms of using other kernels and firmware is to use the module where the kernel is and maybe its firmware, and use the firmware in the firmware-related part of the system config and the kernel like (kernel name-you-used)
<rekado>roptat, g_bor I looked into Scala a while ago and it cannot be bootstrapped sanely.
<rekado>The earliest Scala versions (from before the history was cut) depend on Pizza, which (of course) has a bootstrap problem of its own.
<rekado>everything from 2.0.0 onward depends on a working version of scalalib, which is written in Scala.
<mbakke>rekado: Can you remember how to run the "reduced" test suites of scipy and friends? I'm trying to update them, but iteration cycles are sloooooow....
<fzer0>mbakke: I actually ran across this config about a week ago. I like I3 as well, so I just keep those sections as well correct? Why the suplementary groups?
<mbakke>fzer0: That config is years old, though I do like to have access to various device nodes without being root, which is why I am member of all the things.
<fzer0>mbakke: interesting; I have a lot to learn.
<ng0>hm. I think I can link to my config without problems here, I made a split by hosts recently and there's no indication on the one hosts what the other host is, at least not in the old_systems.git repo
<ng0>there's lots of testing and old testing experiments in that file.
<mbakke>Bah, scipy:doc is failing hard and inexplicably. Syntax errors from matplotlib, and "sphinx-build: error: option -b not recognized".
<rekado>mbakke: the Python science packages have very strict version requirements on one another. Make sure that this particular version of matplotlib will work with this particular version of scipy.
<rekado>I once had to revert an upgrade (and the attempts to fix breakage) because it couldn’t be made to work.
<mbakke>rekado: From their CI configuration and docs, it does not look like they depend on an unreleased matplotlib (we have the latest version already, and 1.0.1 works fine with it).
<mbakke>I suspect rather that Sphinx@1.6 is broken. Or that it actually requires 1.7.
<mbakke>Woah, my tmux server crashed. Disconcerting.
<lukas__>Hi. I just installed guix and wanted to reconfigure system (to enable sshd service). I changed /etc/config.scm but guix is not reconfiguring system with error message: guix: system: command not found
<lukas__>This is very strange as both manual page and guix -help both list system as subcommand. Any ideas of what is happening?
<pkill9>lukas__: a lot of people have mentioned that issue lately, can't remember the fix though
<lukas__>pkill9 : google search is not revealing any useful insights and I do not know where guix developers keep their issues. Should I look at the devel mailing list?
<pkill9>someone here will probably be able to tell you when they see your message :)