<ride>Since lvm2 support is new I am having trouble figuring out how to use it in the config.scm file. I found how to do mapped-device so I assume it is something similar.
<ride>There are also no mentions of crypttab in the manual, so I assume it is determined by the config file.
<rekado_>dissoc: specifying record types for configurations gets old really fast when you have lots of fields
<rekado_>the define-configuration macro takes care of a whole lot more: it also lets you weave in documentation and provide generic serialization procedures that turn any concrete configuration value into a file
<rekado_>define-configuration provides a unified method to, well, define configurations, something that is otherwise done in an ad-hoc fashion with alists and custom record types.
<rekado_>so “because scheme” is actually a pretty good answer
<dissoc>rekado_: thank you. that completely answers my question
<dissoc>only problem with that is im not that good at scheme yet
<rekado_>define-configuration lacks documentation, but there are a number of services that use it
<dissoc>getting there. and definitely loving guix thus far
<rekado_>sometimes you don’t need to be good at Scheme, you just need to know where to copy from.
<dissoc>i can do a reasonable job reading scheme. i only lack the experience to write good scheme when there's not an existing example of something similar as to what i need to do
<rekado_>(gnu services ldap) shows that you don’t need much to use define-configuration
<rekado_>that’s because in that configuration all fields accept primitive values
<kagevf>btw, I'm trying to install guix as a package manager on top of Ubuntu 18, not stand-alone guix
<kagevf>ok ... I clearly didn't enable substitutes .... did that step and am re-doing guix pull ... seems to have done the trick ... thank you for the idea, guix-vits
<clone11>Under what conditions can the repos contain two versions of a package? I was trying to use rails with only guix packages, and the version of ruby-sqlite3 doesn't work with ruby-rails. You don't *need* sqlite3 for rails, so I don't know if the older ruby-sqlite3 could be added
<ryanprior>clone11: you can add another version of ruby-sqlite3 for compatibility. Is that the only reasonable solution? Would an updated version of Rails be compatible with the new package?
<ryanprior>Or if it's a trivial incompatibility, would a small patch to the new ruby-sqlite3 be sufficient to add legacy support?
<sneek>dannym?, pretty sure was seen in #guix 4 days ago, saying: Anyway, just wanted to know what it is for in the first place (personally, my channels always worked without that file--maybe Heads' engineers are doing something unexpected...).
<dftxbs3e>janneke, they wanted to handle installation of GNU Guix on the OSUOSL ppc64le CI machine we were donated and since they're the only ones with access AFAICT them being absent means we are stuck not being able to add powerpc64le-linux-gnu to official GNU Guix CI
<jgart[m]>Would someone be able to help me track down unpackbootimg in guix?
<dftxbs3e>abcdw, I'm sorry I can't be of much help here, wish I was better at GNU Guile and Scheme :-)
<dftxbs3e>also your videos come off as great ones, will take a look some day :-)
<abcdw>dftxbs3e, Thank you anyway (: Hope I'll figure out, how to fix it.
<dftxbs3e>janneke, I could setup the machine myself but they insisted on doing it themselves to learn, I'm all for that but they went away aaah
<dftxbs3e>hopefully they come back soon so we can have official powerpc64le-linux-gnu CI :-)
<xelxebar>Found a quirk/bug in `guix system rollback`. When running with --dry-run, it "rolls back" from the system pointed to by /run/current-system; however, without --dry-run, it rolls back from /var/guix/profiles/system. This means that if you `rollback` while booted into an older generation, --dry-run gives misleading information.
<PurpleSym>jonsger: I’ve had the same issue before. See ↑
<leoprikler>Is there a way to convert all source files in a package to UTF-8?
***samis is now known as CompanionCube
<jcf>Hello everyone! I'm on the cusp of a failed drive and will have to rebuild my OS as a result. I've been thinking about moving to Guix for a while now and this could be the time to do it, but I have a couple of concerns/questions. Firstly, I'd like to move away from btrfs and over to ZFS (inspite of the disappointing license) and I need to encrypt data as I deal with personal data at work.
<jcf>I see a ZFS package is available but wonder if I can use a "zfs" type of file system with Guix…?
<jcf>I also have two Nvidia GPUs that I use for work that'll need some support (from proprietary blobs no doubt). I'm lead to believe I can download binaries for Nvidia if necessary to get that stuff working too. :fingers-crossed:
<dftxbs3e>jcf, ZFS is not supported at all currently as a root file system on GNU Guix, but you can try programming that on your own, I am not sure it will be accepted upstream though, but it doesnt need to. About NVIDIA, same story, no support at all from GNU Guix upstream but you can hack your GNU Guix System configuration for that. You'll have to learn some GNU Guile's Scheme.
<dftxbs3e>jcf, for encryption, LUKS works well and is supported by GNU Guix
<jcf>I'm using LUKS and btrfs now, and I'm pretty happy with it. I have a FreeBSD box with ZFS that I'd love to be able to `zfs send` to though. :)
<dftxbs3e>Can it use configured offload systems as well?
<apteryx>Anyone mastering the Guix state monads? :-) I'd like to further my current (fairly limited) understanding of it. Regarding the example in 'info "(guix) The Store Monad"', that defines a 'square' (monadic?) procedure; when ran with 'run-with-state', it needs to be wrapped in something like 'sequence' (from the same example) from (guix monads), else it fails. Why can't I simply (run-with-state
<mbakke>dftxbs3e: I have a working GCC 10 for 'core-updates', cross-compiler and all. Do you think it would make sense to use that to generate the ppc64 bootstrap tarballs?
*mbakke attempts TeX Live upgrade for 'core-updates' for GCC 10 compatibility
<leoprikler>Quick opinion poll: esoteric programming languages in Guix, yay or nay?
<cbaines>dftxbs3e, as for the differences between the Guix Build Coordinator and Cuirass, it's hard to put succinctly. With the Guix Build Coordinator, you give it derivations and it'll handle building them, potentially across many machines. With Cuirass, you give it a specification, and it'll evaluate it, producing derivations, which it'll then build (and with offloading that can happen on other machines)
<dftxbs3e>cbaines, I have hardware and non-upstream GNU Guix support
<dftxbs3e>mbakke, awesome! yes we can definitely try!
<dftxbs3e>mbakke, I read your message earlier about missing leading / - glad it's just that
<dftxbs3e>cbaines, so Guix Build Coordinator does not support using offloading?
<mbakke>dftxbs3e: sounds great :-) I'm still working my way up to the native 'guix' package, but hope to push it in a few days
<cbaines>dftxbs3e, as for offloading. there's no reason I can see why that wouldn't work. But you'd probably be better off just running the Guix Build Coordinator agent on each machine you want to perform builds
<dftxbs3e>mbakke, if you can give me dirty patches I can apply them on top of existing core-updates and try
<dftxbs3e>cbaines, GNU Guix System isnt supported yet on powerpc64le-linux-gnu, just on top of another distro for now
<mbakke>dftxbs3e: awesome, will send in a few minutes
<dftxbs3e>mbakke, I could also give access to a powerpc64le-linux-gnu VM directly if you wanted
<mbakke>dftxbs3e: interesting, might take you up on that if there are problems at least ;-)
<cbaines>dftxbs3e, you can run the agent on a foreign distro, that should work fine (and I want to do this for testing builds on foreign distros)
<dftxbs3e>cbaines, let me try installing it there then
<dftxbs3e>cbaines, what would the command line be like?
<guix-vits>leoprikler: > esoteric languages saruman_so_u_have_chose_death.jpg
<cbaines>dftxbs3e, if you're going to run it from systemd or something similar, I'd perhaps use the Guix package, but if you're going to run it something like a regular user through screen, then I'd clone the Git repository and run it from there
<mbakke>lfam: I have not! I suppose the Rusts are mostly taken care of by the "ungrafting" branch, if that is still going.
<cbaines>lfam, maybe someone can expidite that by just asking the guix-daemon on berlin to build the rust at the end of the chain. I have access so I can do that
<lfam>cbaines: Yes, that would be helpful, assuming berlin can handle it
<cbaines>leoprikler, I think the serious answer is yes, esoteric programming languages are fine. The normal packaging standards apply, like building from source (which is sometimes hard with languages)
<lfam>Speaking of esoteric programming languages, yesterday I added an esolang module on behalf of someone
<leoprikler>Welp, gotta handle some merge conflicts once I pull then
<guix-vits>leoprikler: ah, i thought you compiling the Rust lang. :|
<leoprikler>Well, Rust is esoteric to some, but I'm talking about a different kind of esoteric.
<lfam>cbaines: I've been using the "broken" comparison tool that you showed me. I'm curious about the base and target datetimes. Are they the dates of when a Cuirass evaluation was started? Or when a particular build was started? Or completed?
<lfam>Ohhh, that's why the first page is called "compare-by-datetime"
<cbaines>lfam, yeah, I was going to make a compare branches page, but then I realised I could just use the datetime comparision (which I'd originally written for comparing master with master 1 week ago, for the automated weekly news thing)
<lfam>The compare-by-datetime interface has some other nice selectors, like System and "Build change"
<dftxbs3e>cbaines, setup is done for a VM on the AMD Epyc machine, btw it has 64GB SSD (RAID1 on 3 SATA SSDs with ZFS and the disk image is a block device from ZFS), 32 cores and 32GB of RAM (with memory ballooning, min 2GB, max 32GB)
<lfam>It's the HEAD of staging and a master commit from last night
<cbaines>dftxbs3e, I hadn't actually seen that bit in the manual, but yes, if by some means reviewing patches can be more rigerous, less time consuming, and people without commit access can be empowered and supported, then I think quite a few things will improve.
<dftxbs3e>leoprikler, oh I mean everyone would still be able to, just that there would be identified people who are doing the work there more often than not
<lfam>In practice, I was the package-specific maintainer. But ultimately, I stopped doing the work
<lfam>I don't really see the difference from if I was designated officially
<dftxbs3e>lfam, still good to know you are the original person, I could've checked git honestly for it.
<dftxbs3e>I use syncthing so it's very useful for me
<lfam>I simply ran out of energy to do that work for free
<leoprikler>I think people gather enough clout on IRC without being designated maintainers :)
<cbaines>One of the less important one is maybe having commit access becomes less relevant, and that's good because it would be good to scale up the number of engaged voluenteers without having more attack surface by having more committers.
<leoprikler>cbaines: on the flip side, you add an attack vector in the CI that does automatic builds and pushes
<dftxbs3e>lfam, I understand, I run out too. It would be nice somehow warning users a package is unmaintained or lagging behind
<lfam>I think my expectations are a little different. In traditional distros, Syncthing would not be considered out of date
<dftxbs3e>I would think of a middle ground, not removing but warning
<lfam>The expectation of continuous updates is not really universal yet
<cbaines>leoprikler, indeed. Even though the manual says that, I don't believe there's an actual plan anywhere for having some automated way of pushing to master. There's plenty of good stuff that can happen before that at least.
<lfam>I've warned about issues with Go support several times
<dftxbs3e>leoprikler, guix refresh doesnt cover Go things yet, heh
<lfam>Go (and Rust) doesn't fit the paradigm of a "distro" as we understand it
<dftxbs3e>lfam, Ah well.. sorry, my email provider flagged GNU mailing list subscriptions as spam so I don't read as attentively anymore..
<lfam>Simply put, we merely get in the way from the point of view of Go programmers and users
<lfam>Those languages handle distribution and deployment on their own
<dftxbs3e>lfam, also npm? Isnt GNU Guix intended to help tackle those?
<lfam>Now, there's nothing wrong with Syncthing 1.5.0, afaict. The software has been rock solid for years
<leoprikler>lfam: I'd disagree and say, that languages with a built-in package manager get in the way of actual package management in any distro ;)
<dftxbs3e>lfam, it is linked to empowerment and software freedom I think
<dftxbs3e>That's what I like about them, ultimately.
<lfam>It is empowering. I could never figure out how to make my own Debian packages, or really control my Debian system in a meaningful way. Systemd made it possible to control and create services, but packages were still totally opaque
<dftxbs3e>lfam, I need to get better at GNU Guile so I can understand GNU Guix's core aha, the packages are easy enough but the rest..
<lfam>A clear example of the trap of "local maxima"
<terpri>apteryx, i'm not sure there's a GNU getopt executable. glibc has getopt and related functions, bash has "getopts" to use them in shell scripts, and as you mention util-linux has its own getopt program
<terpri>i don't think a getopt program is specified in posix (just getopts) but not 100% sure about that
<dftxbs3e>cbaines, you can run miredo to get it instantly, it's packaged in GNU Guix :-)
<slimjim>mbakke: so I tried that, duplicating the python-3.5 recipe from the old guix commit. I also had to resurrect the python-3.5 patches that that old package worked, so it looked like I had everything the same as the python-3.5 package definition as used in the old guix commit
<dftxbs3e>run it as root and it will get you a teredo 4to6 address for free from a public pool
<slimjim>but then I still couldn't get the build working bc/ a bunch of tests in the check phase were hanging indefinitely
<slimjim>or do I need to manually create packages for python-3.5, 3.6, and whatever other old versions I want to test on, including other dependeinces like python-pip etc for each version
<mbakke>slimjim: for now that's the best approach, if transformation options like 'with-source' and 'with-input' does not cut it. You can submit your packages to the 'guix-past' project so they won't vanish: https://gitlab.inria.fr/guix-hpc/guix-past :-)
<slimjim>oo I didn't know about that project, thanks!
<slimjim>would it be possible for me to check out a separate copy of the guix repo from that old commit, and compile it locally (outside of the guix build system), and somehow use that guix to try to build the old python-3.5 pacakge?
<mbakke>slimjim: yes, you can check out any revision of guix using git, and build packages with './pre-inst-env guix build foo'.
<mbakke>and the preceding "building from git" section
<slimjim>ooo ok, that might be even easier. Because all the packages I want are already in that old ~2017-era guix
<slimjim>so if time-machine from newer guix can't travel back that far, maybe I can manually build the old guix
<mbakke>slimjim: should work, but you may still run into problems with the Python (and other) test suites due to your new kernel, or "time bombs" like expired test certificates
<slimjim>mbakke: one thing that might be nice is if (guix build-system python) could export package-with-explicit-python ; it's a utility function which is used to define the exported package-with-python2 function. I think if i had my own python-3.5 package definition, I could use that function to transform some of the other packages
<mbakke>slimjim: sounds reasonable, can you submit a patch? :-)
<slimjim>I'm a guile newbie, is there any way to call functions defined in a module that are not exported by it?
<mbakke>slimjim: you can access it with (@@ (guix build-system python) python-with-explicit-python)