<maximed>Maybe "guix system init /mnt" works like that (not sure)
<maximed>or maybe that messes up /etc/passwd and the like, I dunno
<GNUtoo>In any case if it's easy enough and that I manage to do it I'll probably only work on add-from-tarball and I had --grow-image in mind mostly to show a more general picture of what could be done if we have an abstraction like that
<GNUtoo>We could probably handle things like cryptsetup, lvm and so on there too
<GNUtoo>Though it'd probably need some key and/or passphrase handling to be done in a safe way
<GNUtoo>--password=mypassword is not that safe when most users can do ps | grep password
<dragestil>I just installed guix system on a server. Does the installation generate a file of the current configuration, i.e. guix deploy this file would produce the same result? If so where can I find this file?
<dragestil>Another question is, if I change the openssh config, say adding (x11-forwarding? #t) (permit-root-login 'without-password) to the current config, and do system reconfigure, I have to wait for a long time, compared to editing sshd_config and restart sshd on say debian
<ekaitz>civodul: how are the guix iso images generated? I suppose they use guix system image to be generated but is the description of the images anywhere in the guix repository? (I'm still having issues to find stuff in the code, after all this time *sigh*...)
<rekado>roptat: yes, you can use “time -v” (the application, not the built-in); it shows max resident memory
<roptat>I'll let the profile build, and record the memory for just computing it afterwards
<roptat>right know, the builder is taking 1.5g resident
<roptat>so for instance, one issue I have with grafts is related to texlive. I always build it with --no-grafts, because otherwise the gc will collect the ungrafted version, and next time I need it, it will build the ungrafted version again to find out it already has the grafted version
<roptat>would it help to have reference information in the narinfo?
<wirez>something liek a semver software dep would be best, like you say a package but then also a version, and the version pattern controls the version you get, and even in 2 years the version your pattern says will be installed
<wirez>like python3 to get latest of 3.x, python38 to get latest of 3.8.x, etc
<marusich>If you want something like that, then right now the best solution is either "guix time-machine" or a "guix pull --commit=HASH" (replace HASH of course with the actual commit hash) followed by a "guix package -i PACKAGE"
<marusich>Sometimes, Guix maintains multiple versions of a package for a while in the regular package collection. For example, there are few versions of gcc available to use.
<marusich>There is no feature that specifically will interpret a package version in a spec like email@example.com, find a package in prior version of Guix matching that spec, and then build it.
<marusich>What about its dependencies? What about if I customize the code for "Python 3.8.1" and keep the same version number? These changes are reflected in the commit hash (i.e., version) of Guix and its package collection.
<wirez>ya well that's all the more reason to want as much control as we can get
<wirez>if i can lock something to y.x, i greatly narrow the scope of my problem if a .z is different
<marusich>I agree with you, but I don't see why you can't do that.
<marusich>For example, what stops you from declaring the software you are using, including the version, in a manifest, and then including the Guix channels in use in a channels file, and then later on running "guix pull --channels=FILE" followed by "guix package -m MANIFEST" to install exactly the same stuff as before?
<vagrantc>upgrading guix is basically saying "update all the software to newest versions and rebuild it with the newest versions" ... the way you get reproducibility is you upgrade to the exact same set of package versions.
<marusich>Guix is designed to be a rolling distribution, so if you run "guix pull" you are going to get different software for "python". If "Python 3.8.1" is still included in the distribution after you run "guix pull" (often it is, since it is popular and likely to remain for a while), it is likely that its dependency graph has changed, so it could behave differently, despite the version number being the same.
<wirez>vagrantc so you can set which versions of all programs you want to install?
<marusich>What I'm trying to say is that you CAN exactly specify the software used, and you CAN install it two years from now (assuming sources are available), by using "guix time machine" or "guix pull".
<vagrantc>wirez: for a given generation of guix, you'll get a sepcific set of versions of software
<wirez>the most important thing is i need to be able to totally specify a known good config, and get it byte for byte over time
<marusich>But the way in which you accomplish that is different than simply saying "Python 3.8.1", since that statement is not enough on its own to exactly describe the closure of software used for an exact version of Python.
<marusich>In practice, getting it byte for byte is difficult, since not all builds are actually reproducible in practice.
<vagrantc>wirez: bit-for-bit reproducibility is maybe only 80%, depending on exactly which packages you use
<dstolfa>but sometimes the build gets the current date
<marusich>wirez, the biggest risk to the ability to rebuild software in the future with Guix is that the sources might become unavailable, or they might change. For example, if ten years from now you try to build "glibc-2.33", but the source for that has changed or disappeared from the URL recorded in the package definition, Guix will fail to build it.
<marusich>OK. The path for you to reproduce what you have is this: describe the software you use in a manifest (so you can install it with guix package -m manifest.scm and similar), and make sure you record the exact version of guix and any channels you used to build it (e.g. the output of "guix describe --format=channels", which is suitable for input to "guix pull --channels=FILE"). See...
<marusich>But yeah, 100% bit-for-bit reproducibility is very hard to do when building from source.
<dstolfa>also, note that you can `guix package --export-manifest` to get your current manifest
<wirez>i don't need 100% it's just a goal. better than what i have now is good enough
<marusich>In practice, the only way today to achieve 100% bit-for-bit reproducibility is either through very difficult, tedious debugging and fixing, to make the software build reproducibly. Or, to store an archive of the built result so you can re-use it as-is, without rebuilding it.
<wirez>any place to see the guix system growth? like userbase, installs
<marusich>Yeah, that's the case for a lot of use cases.
<marusich>Hmmm, well, I try to use Guix whenever I can, but it's hard. The ecosystem of free software still often expects a traditional distro environment, to say nothing of the non-free world, so there are always a lot of "gotchas" when using Guix.
<marusich>I think, if you have full control over your own infrastructure and environment, you would be in the best position to adopt Guix for most purposes.
<vagrantc>honestly, guix *should* be able to get more like 95% reproducible with some effort ... as debian does it and intentionally varies more things
<dstolfa>guix works really well in datacenters and on foreign distros on timesharing systems (e.g. if you have RHEL 8 and a bunch of users on it that want their own packages)
<dstolfa>guix system i find works reasonably well as a desktop/laptop, but some things require docker to work
<the_tubular>There's no telemetry in guix, this would be hard to guess
<dstolfa>e.g. if software really doesn't want to work on guix and you don't have time to write a service for it, just use docker
<marusich>But OK, for example, consider something like PyCharm community edition. If you just download it and try it out on Guix System, the installer might complain it doesn't know how to install on this distro type. Even if you get it to work, you might find out that some of the pre-built executables don't work because they were built to expect libraries to be present in specific locations on the system, which is not true on Guix System. Again, this is
<marusich>something that can happen with any GNU/Linux distro, but it's more frequent with Guix System because Guix System specifically avoids the Linux Filesystem Hierarchy Standard in order to avoid accidentally causing installed software to unintentionally use the wrong version of a library.
<marusich>Stuff like that is not insurmountable, but in practice after years of using Guix System myself, I can say it sometimes feels like a death by a thousand cuts.
<marusich>It's like, come on, again? I just want to try this nifty thing. So, sometimes, using Guix on top of a traditional GNU/Linux system may be the path of least resistance, depending on your situation.
<marusich>But yes, none of this is Guix specific. You'd have the same troubles if you tried using Nix, for example.
<the_tubular>I'll be experiencing this soon, marusich, will have to execute a binary on my system.
<dstolfa>a lot of the time you can work around this issue by setting LD_LIBRARY_PATH, LD_PRELOAD and at worst, patchelf
<marusich>Nix has some kind of command that lets you temporarily set up a FHS environment, like "guix environment" but it sets up the FHS environment like a normal distro would be. Guix doesn't have that (the closest thing would be to run Guix on a foreign distro, or use Docker, or use a VM).
<marusich>I don't know though. Every time somebody "solves" a build problem by saying, "here, just use my copy of libcrypto.a and you'll be able to build this fine", I thank my stars for Guix.
<marusich>(True story, by the way. I have seen that happen.)
<dstolfa>marusich: on most systems i often need to bootstrap a bunch of dependencies manually because the ones in the existing system don't work for what i'm trying to do
<dstolfa>if i have enough resources and need to do this for enough machines, i can make my own package repository with these things, but more often than not, that's not the case (:
<wirez>tbh i dunno how anyone used computers before stuff like guix. imagine manually typing out commands to configure a server, or running some stupid config mgmt thing, and never knowing if your system state is out of sync with your desired config? like wtf
<wirez>dstolfa is this a prob with guix or linux or? can ppl use guix to get real work done?
<dstolfa>wirez: this is a problem with every system in existence
<dstolfa>"i need to test a particular piece of software using my libfoo, but my libfoo also depends on libbar and libbaz which it didn't before because new functionality is hard sometimes, but the software itself depends on libbarv0.1, not v0.2 so here we are"
<dstolfa>also regarding managing a fleet of servers that don't use guix... i use ansible and version the system myself with a sentinel file
<marusich>Usually, even people who like systems like pip or cargo seem unconcerned about the fact that they do nothing to manage the dependencies for other languages, in particular the underlying c toolchain
<marusich>There is something to be said for mutability (it's fast, the iteration time is good for experimentation), but I think that in the same way that mutable data structures can theoretically be replaced by persistent data structures, so too can mutable distros be replaced by "persistent" distros like guix.
<dstolfa>that doesn't even matter honestly, the problem is the way it's configured in yaml and the fact that they didn't have nested loops for the longest time because their loop item was always called "item"
<dstolfa>which also means you can't call things "item"
<marusich>I wish you luck on your Guix journey, wirez! Guix is a fantastic system. It has the best design of the current OSes that I've seen, and I hope that its pain points are just temporary on the path to world domination. :)
<dstolfa>the_tubular: yeah, but they aren't as integrated in guix in my experience. in RHEL you can just dnf install the necessary kpatch stuff and dnf will handle it
<the_tubular>Never used it though, I can take a 3 minute downtime
<marusich>wirez, just keep in mind that right now, sometimes another tool may be better depending on the case. If Guix is a hammer, not all problems are nails.
<dstolfa>if they were as integrated as they are in RHEL, you could just run an LTS kernel and rely on kpatch for security issues, upgrade once every 6 months and that's it
<marusich>like, the only downside i have with guix, really, is that sometimes the effort required to get things working with it is just so much higher than "simply using another distro" - in times like that, using the other distro right now is a good choice. But it's also an opportunity to get hacking on an improvement to Guix.
<dstolfa>yup. currently i use guix where it makes sense, i don't try to force things it obviously doesn't do yet, but i do have some "alpha" stuff running in production :)
<wirez>dstolfa ya but i mean, are guix updates force pushed into systems and they reboot on you?
<dstolfa>no, you can reboot whenever you want as a sysadmin, it's just that guix doesn't have a notion of "here's a kpatch for this kernel version to fix this annoying little security issue and you don't need to reboot"
<wirez>can you choose to not receive updates until you want to next?
<lispmacs[work]>luis-felipe: I have not been looking at any Japanese input, but I find I occasionally need to rebuild font database with fc-cache after an upgrade
<PurpleSym>luis-felipe: I remember ibus keeps a registry in ~/.cache somewhere and updating your profile invalidates the paths recorded there.
<luis-felipe>lispmacs[work]: In my case, there is no font problems though. The problem is, when I activate Japanese and type in Emacs, what I type is not converted to Japanese, I can only type latin characters...
<luis-felipe>PurpleSym: Thanks. I removed ~/.cache/ibus, restarted Emacs, and now it works :)
<jas>hi! the manual says 'Note: It is highly recommended to run guix pull once before you run guix system reconfigure for the first time (see Invoking guix pull). Failing to do that you would see an older version of Guix once reconfigure has completed.'
<jas>However, I'm reading about --allow-downgrades and it suggests to me that the default behaviour is that 'guix system reconfigure' would never install an older version. Right? If so the first warning is a bit too strong.
<the_tubular>If you don't guix pull, then guix system reconfigure won't know it's not the latest version
<apteryx_>jas: tricky to see at first, but the guix package collection contains guix itself, used by the likes of the guix-daemon-service-type, which means if you've never 'guix pull'd and repeatedly run 'guix system reconfigure', you'll navigate the guix version history backward.
<apteryx_>(since before the first 'guix pull', the guix refered to is the guix found in the system profile, which is pulled by guix-daemon-service-type)
<bmk>I'm noticing some weird behavior with some files recently, on GuixSD. They're there, I can see them in ls, cat them, but when a program tries to load them it's like they don't exist. Anyone else experience this, or have I goofed up something?
<cbaines>bmk, are these a specific kind of file, or just files in general?
<cbaines>is it a specific kind of file that can't be opened, or just files in general?
<bmk`>Files in general. For example, was attempting to play good 'ol dorf hellhole simulator when first off: Downloaded a premade pack for the game, couldn't load files saying they weren't there when they appeared to be, now installed through a user channel and it says it can't find the music for the game, even though they're there and readable
<bmk`>and it's not a problem with the game, as I accidentally proved
<drakonis>civodul: what does adding early cutoff to guix entail? design wise?
<civodul>drakonis: i should write about it, but essentially, (1) the daemon would store hash-modulo-self-references for each store items, and (2) upon build completion, it'd check whether the result's hash-modulo-self-references is already known, and in that case, go on with grafting instead of building dependents