IRC channel logs


back to list of logs

***benny is now known as Guest49727
<ray__>Hi there: I have an issue where adding binutils to the list of inputs causes a RUNPATH validation failure
<ray__>Specifically, I'm trying to compile xmonad, and just adding binutils to the list of inputs, with no other changes results in
<ray__>/gnu/store/v6k307nzmfwnim9bg08m9c2jb2lgbmch-xmonad-0.13/bin/xmonad: error: depends on '', which cannot be found in RUNPATH ("/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib" "/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib")
<ray__>among other errors
<ray__>Binutils is already in inputs!!
<ray__>How can I use package-name inside a package phase?
<ray__>If I just naively try (use-modules (guix profiles)), I get
<ray__>"no code found for module guix profiles"
<ray__>or something
<cbaines>ray__, I think during the actual build, you don't have package records to work with
<cbaines>what are you trying to use the name for?
<cbaines>Also, regarding your earlier point about xmonad, I see in the libxscrnsaver package
<ray__>Oh yeah I eventually figured that out
<ray__>when I put binutils in the inputs, it overwrote the correct binutils with a cocked up one
<ray__>which couldn't find the libraries
<ray__>anyway, for this issue, I need to construct a path of the form /lib/ghc-8.0.2/xmonad-0.13.conf.d
<ray__>and I want "ghc", "8.0.2", "xmonad", and "0.13" to be automatically generated
<ray__>So I'd like (package-name ghc), (package-version ghc) and so on
<ray__>I want those strings to be available in the package phase environment
<ray__>Is there a way to just pass arbitrary values into that environment?
<cbaines>ray__, you could try this approach initially: (string-drop (which "xmonad") 44)
<cbaines>where 44 is the length of the /gnu/store/....- prefix
<cbaines>e.g. (string-drop "/gnu/store/bihfrh609gkxb9dp7n96wlpigiv3krfy-hello-2.10" 44) => hello-2.10
<cbaines>Ah, actually, ignore the which
<ray__>Wow that seems really hacky. Will that work if it's a different package which might not be in the store?
<cbaines>You'd probably want to do (string-drop (assoc-ref inputs "xmonad") 44)
<ray__>ok yeah it seems like that will work
<ray__>Is there really not a better way?
<cbaines>ray__, at build time, the information about the packages is what's in the "inputs"
<cbaines>which is a list of the input names, and input store paths
<cbaines>I think there is a plan to rework the package build setup to use G-expressions, which would make the whole process much more flexible, and I think that might allow passing in extra data more easily
<ray__>Ok, I have another idea, tell me if it can work. The path /lib/ghc-8.0.2/xmonad-0.13.conf.d is created when xmonad is compiled, so can I just look for a path of that form?
<ray__>I don't know any scheme, but it seems like it should be possible to look for a directory of the appropriate form, then get the true path as a string
<cbaines>The scandir function in the File Tree Walk module comes to mind
<cbaines>Out of interest, what are you trying to do with the xmonad package?
<ray__>When I insalled xmonad, and tried to run xmonad --recompile
<ray__>It complained about all kinds of things going wrong
<ray__>I'm wring to wrap-package the xmonad binary so that it has everything it needs in order to recompile
<ray__>So putting xmonad into the GHC_PACKAGE_PATH, ghc into the PATH, libc into the LIBRARY_PATH
<ray__>I think those are the three things
<cbaines>Ah, ok
<ray__>While I have you here to ask, the next step is going to be to make it possible to get xmonad-contrib into the path if the user wants it, but it should be an optional dependency (so to speak). What's the best way to do this? Does guix have something similar to use flags? Or maybe I can do it like NixOS and have it in the system configuration?
<ray__>The other idea I had was to make a second package like xmonad-with-contrib, which just has a shell script to set the GHC_PACKAGE_PATH and call xmonad
<cbaines>When you wrap xmonad, you can choose for each environment variable whether to include the value from the environment
<cbaines>e,g, PATH="/gnu/store/...-foo/bin" vs PATH="/gnu/store/...-foo/bin:$PATH"
<ray__>mmhm, but xmonad-contrib isn't going to be in the path unless I put it there
<cbaines>Well, someone wanting to use it could just install it right (guix package -i xmonad-contrib)
<cbaines>would that be sufficient?
<ray__>Unfortunately not, since installing ghc-xmonad-contrib doesn't set GHC_PACKAGE_PATH unless you have ghc installed
<ray__>which is, I suppose, a solution
<ray__>but it's kind of nasty to make the user install ghc when it's not really necessary
<cbaines>one approach other than wrapping is propagated-inputs
<cbaines>do you know about those?
<ray__>Kind of like normal dependencies in other package managers?
<ray__>It just installs into the user's profile
<cbaines>ray__, yeah, that's one way of thinking about it
<cbaines>so you could declare things like ghc as propagated inputs
<cbaines>meaning that xmonad relies on having that package available in the profile where it's being used
<ray__>I bet that would work
<ray__>Thanks for your help. I'm slowly getting the hang of guix.
<cbaines>You're welcome :)
<rekado_>Hi Guix!
<Rukako>hi rekado_
<rekado_>I’m moving from my custom installation of hpcguix-web to the Guix service, and after changing the configuration a bit I found that the service does not like to start.
<rekado_>Output in the logs is very sparse.
<rekado_>Can anyone share some shepherd debugging tricks?
<Rukako>my personal method is to put (display)s everywhere I think that might be relevant to the issue
<rekado_>I don’t want to change shepherd itself. I’m only really interested in the output that would be produced when starting the service by hand.
<rekado_>that output appears to be lost
<rekado_>(or maybe it goes to the console, which I cannot see when I’m connected over SSH.)
<Rukako>rekado_: try running shepherd with --logfile=...
<Rukako>you can run it as a local user too
<rekado_>how can I supply this argument for PID 1?
<Rukako>*meant non-root user instead of local user
<snape>rekado_: the easiest way, I believe, is to spawn the command by hand
<snape>but you need to know the exact command the Shepherd would have spawned, which isn't easy if it's dead quickly
<rekado_>that’s not nice, though.
<snape>it's a reported bug
<rekado_>yeah, I remember it’s been around for some time ;)
<snape>you can also know the command by analysing the service or/and 'pk' stuff there
<snape>around the make-forkexec-constructor
<jlicht>hi guix!
<snape>rekado_: (I just set it to important, I definitely agree with you)
<jonsger1>could someone on a guixsd system can run "guix lint hello"?
<jonsger1>snape: with installed nss-certs and export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
<snape>nss-certs installed globally, and SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs:/etc/ssl/certs
<jonsger1>but those error should not be there, because the potential bug triggers only when those succeed
<snape>life is full of things that shouldn't happen, but they happen ;)
<jonsger1>I try to figure out if this is a bug in guix or just in the opensuse package of it...
<rekado_>on GuixSD “guix lint hello” works just fine.
<rekado_>it says the synopsis should not start with the package name.
<jonsger1>I get
<snape>funny, the three of us have different behaviours
<civodul>"guix lint hello" works for me too!
<snape>would that have to do with nss-certs being, or not, installed globally?
<civodul>jonsger1: you're on guile 2.0, right?
<jonsger1>civodul: yes
<civodul>looks like something's wrong with call-with-networking-fail-safe but i can't see what
<snape>SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs causes my SSL errors
<snape>if I set it to SSL_CERT_DIR=/etc/ssl/certs, it works fine
<jonsger1>civodul: gcc, glibc, hello fail all. they use "mirror:" as uri. vim, 0xffff, 0ad etc doesnt fail
<thomassgn>ehrm, suddenly guix fails to reconfigure because it needs some usb storage modules for initrd. Is there a way to silence/continue? I didn't need them yesterday evening. I tried adding what it asks for but hit the bug where usb-storage us misnamed as usb_storage. It was fixed 30 days ago, but it still happens here.
<thomassgn>bug is
<thomassgn>I also just ran guix pull on this system
<civodul>thomassgn: if you're confident about what you're doing, you can use --skip-checks
<civodul>ah no sorry, i misunderstood
<civodul>well yes, you can write (initrd-modules '("usb-storage" ...)) and then use --skip-checks
<civodul>but it would be nice to understand what's going on
<civodul>thomassgn: could you reopen the bug and send details?
<thomassgn>civodul: Yes, I can. Do I just send a mail to the bug address with new info? or do I need something special to reopen?
<jonsger1>when running "guix weather" I get stuff like "error: perl-text-markdown-discount-unbundle.patch: patch not found". They are missing in gnu/ and gnu/packages/patches
<jonsger1>What is the best way to handle this? Just make a patch for all of them?
<thomassgn>I see the first couple sentences in the bug is howto reopen.
<civodul>thomassgn: right, just follow the instructions :-)
<civodul>jonsger1: it looks like you have a mixture of different Guix versions
<jonsger1>it's missing in the release tarball
<civodul>that's because that patch was removed long ago, i think
<rekado>how can I let the hpcguix-web service run in an environment where GUIX_PACKAGE_PATH is set?
<snape>rekado: it's the service's job to provide a way to set it, through its configuration
<jonsger1>civodul: "git grep racket-fix-xform-issue.patch" on master as well as tag/v0.15.0 gives me only the use in gnu/packages/scheme.scm, but not in and gnu/packages/patches
<civodul>rekado: maybe you can't, we need to add an option to do this
<snape>rekado: with the #:environment-variables parameter of make-forkexec-constructor it should be staightforward
<civodul>jonsger1: again i think there are two different versions of Guix at play; how are you running it?
<civodul>roptat: yay for the opam importer!
<pkill9>feature request: a flag for `guix system init` to not copy any files over, so if grub fails to install due to a misconfiguration, you can try again without copying over all the files that the previous run of `guix system init` copied over
<thomassgn>what is it in the store you have to delete to clear old generations? it's some kind of symbolic link right?
<thomassgn>for guix gc I mean
<thomassgn>oh, it says the name in guix system list-generations ofc.
<pkill9>thomassgn: to delete old user profile generations, run `guix package --delete-generations`
<pkill9>for system generations, you currently have to manually delete the symlinks in /var/guix/profiles/system-n-link\\
<snape>pkill9: for feature requests, there is :-)
<thomassgn>mm, I remembered it was something along those lines, the list-generations command helpfully shows full path both to the /var/guix/profiles and the store item. Waiting for GC to finish now
<jonsger1>civodul: I run the guix installed on opensuse. guix-daemon (restarted) from systemd
<jonsger1>adding perl-text-markdown-discount-unbundle.patch and racket-fix-xform-issue.patch to gnu/packages/patches, to gnu/ and running "./bootstrap" resolves the issues with guix weather/challenge
<rekado>FWIW “guix weather” and “guix challenge” work fine here (using a git checkout on this Fedora machine).
<rekado>92.6% substitutes available (7,574 out of 8,183)
<roptat>hi guix!
<efraim>I guess I should test building the newest rust on aarch64
<efraim>be back in a few days :/
<jonsger1>comparing "git checkout tags/v0.15.0" with "guix-0.15.0.tar.gz", the first one has gnu/packages/patches/perl-text-markdown-discount-unbundle.patch, the second one _not_
<roptat>my computer supposedly supports exporting hardware to libvirt, but it doesn't work
<roptat>"Connection does not support host device enumeration"
<roptat>any idea?
<rekado>jonsger1: hmm, the patch is not listed in the Makefile (or gnu/ and is thus not distributed.
<rekado>it *is* in gnu/packages/patches and referenced in gnu/packages/markup.scm
<roptat>also libvirtlogd-configuration is not exported in virtualization.scm
<civodul>rekado: oh!
<civodul>rekado: it hasn't been touched since Nov. 2017 though, so 0.14.0 already had the problem?
<jonsger1>rekado: as well as racket-fix-xform-issue.patch, they got forgotten to be included in gnu/ <-- my guess
<jonsger1>civodul: yes guix 0.14.0 had the same problem, but I didn't really test the opensuse package back then...
<jonsger1>I think I noticed the problem, but didn't investigate :(
<civodul>well, that it went unnoticed for this long also suggests that it's not a showstopper ;-)
<jonsger1>I think it's more a sign, that no one uses the source tarball: ArchLinux, Opensuse and?
<jonsger1>but it's not a real problem for me anymore. I just patched it in the package and hopefully we can get rid of it in 0.16 :P
<civodul>jonsger1: woohoo! good catch
<civodul>i'll patch it in master if no one beats me at it
<rekado>I have an nslcd service, which looks up accounts, groups, and hosts over LDAP.
<rekado>There are two minor problems:
<rekado>when the configuration file contains a bind password (bindpw) the service refuses to start unless the file is chmod 400 – (how )can I do this when the file is created with an etc-service-type extension?
<rekado>the second problem is that this service only works when LD_PRELOAD=/path/to/nslcd/lib/ is set.
<civodul>LD_PRELOAD or LD_LIBRARY_PATH? prolly the latter is enough, no?
<rekado>I always considered LD_PRELOAD to be more precise
<rekado>is LD_LIBRARY_PATH preferred?
<civodul>LD_PRELOAD tells to preload a library, meaning that it can override anything else
<civodul>whereas LD_LIBRARY_PATH tells it where to look for libraries
<rekado>oh, okay.
<civodul>LD_PRELOAD is usually for funny hacks :-)
<rekado>I always picked LD_PRELOAD when I knew that I only need a single library and not the whole directory.
<civodul>regarding the first issue, there's currently no way to specify modes for /etc files
<civodul>perhaps we should fix that
<civodul>in the meantime, you can perhaps add an activation snippet that calls chmod
<civodul>but you cannot be sure it'll be called after the file has been created, which isn't great
<rekado>I have changed the nscd-configuration by adding (name-services (list nss-pam-ldapd)), which should set LD_LIBRARY_PATH for nscd, but I guess I also need to extend the service that provides /etc/environment to set LD_LIBRARY_PATH there.
<civodul>as long as nscd can find your NSS module, everything's fine
<rekado>because “id foo” seems to ignore the ldap module.
<rekado>it magically works when I set LD_LIBRARY_PATH.
<rekado>(not only “id” is affected but also things like ssh.)
<rekado>I have addded (name-service (name "ldap")) to the list of name services in the name-service-switch field.
<rekado>the /proc/PID/environ file for nscd shows me that LD_LIBRARY_PATH is in fact set to the right directory.
<civodul>rekado: indeed "id foo" accesses /etc/groups directly, in addition to talking to the nscd
<civodul>i'm not sure where that comes from
<civodul>that's a bit of a bug IMO
<rekado>oof, maybe this mislead me into thinking that it’s the same problem for SSH.
<rekado>but I think it’s actually because the PAM file for SSH does not include the ldap security module.
<rekado>I really like the service framework for Guix
<rekado>ah, and here’s the old problem I last encountered: “guix system reconfigure” now tries to delete all undeclared users from LDAP one by one :)
<janneke>is there something `plain-file' for binary files (eg, a tarball); i suspect that using plain-file corrupts my tarball?
<janneke>*something like
<civodul>rekado: oops :-)
<civodul>janneke: it's unlikely that 'plain-file' corrupts things
<civodul>it just sends them over to the daemon
<joshuaBPMan>odd question, does anyone know how to modify the icecat package to compile it with wayland support?
<civodul>what issue did you experience?
<snape>joshuaBPMan: doesn't Wayland support come with Firefox 59?
<davexunit>rekado: do you have experience setting up ldap auth with pam?
<snape>Our Icecat package is version 52 if I remember well
<davexunit>I'm currently looking this at $dayjob and it's... kind of brutal, honestly.
<joshuaBPMan>snape: so I'll have to compile firefox if I want wayland support?
<joshuaBPMan>That's a little sad...
<davexunit>I'm trying to use SSSD to help, which I'm not sure we have in guix.
<davexunit>oh hey we do have it!
<snape>joshuaBPMan: well, there was a discussion about packaging Firefox, which I think is the solution :-)
<snape>but it still has to be done
<davexunit>new firefox releases are hard to build
<joshuaBPMan>snape: yeah I heard about that. What build system does firefox use? And why are they hard to build?
<davexunit>I tried and was up to my elbows in rust and gave up
<snape>davexunit: because of Rust, yes, but it has to be done at some point
<joshuaBPMan>davexunit: ahhh. May I ask what makes compiling rust so hard? Are you trying to bootstrap rust and that is what you found hard?
<snape>joshuaBPMan: it's hard to build because it uses Rust, and Guix has almost 0 rust packages yet
<joshuaBPMan>snape: ahhh.
<davexunit>yeah, it's the dependencies
<davexunit>there's a very large rust dependency tree that needs to get figured out
<joshuaBPMan>davexunit: May I ask how large this dependency tree is?
<davexunit>but firefox wants you to use cargo, the rust-specific package manager
<davexunit>I don't remember
<davexunit>it's been many months now
<joshuaBPMan>ok. Ahh. So not only do we have to package a lot of rust stuff, but we have to override firefox's wanting to use cargo...
<davexunit>right when firefox "quantum" was released I tried to build it
<joshuaBPMan>ok thanks for the info bro
<snape>I tried to build it when it was version 53 :-)
<davexunit>we'll get it one of these days...
<snape>joshuaBPMan: but if you have some time.... Feel free to package some Rust stuff :D
<davexunit>if you someone could list the full dep tree for firefox that would be a good start
<rekado>so… ldap auth when connecting via ssh now triggers the right behaviour (but it still fails).
<janneke>civodul: tar says tar: Skipping to next header
<janneke>tar: A lone zero block at 14601
<rekado>davexunit: we don’t have SSSD yet
<joshuaBPMan>snape: I actually wouldn't mind trying to chip in. I'm just not sure how to get started. And I'm not entirely certain how much time I'm willing to invest in packaging things. Maybe I should sit down one morning and try packaging some things.
<davexunit>rekado: we don't? I just ran 'guix package -A sssd' and got a hit
<rekado>davexunit: but once I’m done with this nslcd stuff I want to make it obsolete with sssd.
<rekado>well, yes, we have the package, but we don’t have a service.
<snape>joshuaBPMan: if you want to package some stuff, you should try with some easier packages before getting into Rust
<davexunit>got it
<davexunit>yeah I figured we didn't have a service
<davexunit>but at least the tool is there
<rekado>LDAP auth against Active Directory is pretty confusing.
<janneke>creating plain-file using git archive and pipe read:
<davexunit>I'm trying to configure a central point of authentication for a globally distributed system of servers
<davexunit>many different networks
<rekado>there are many moving parts and kerberos itself is already brittle enough
<davexunit>our current setup uses kerberos and we hate it
<janneke>hmm, maybe i just want to learn git to read from file://
<davexunit>you have to make the AD server the primary DNS provider
<davexunit>and it has caused us serious production issues.
<rekado>davexunit: if you have an AD server, then you should be able to authenticate users with the upcoming nslcd service + the kerberos service.
<rekado>we also should get realmd to keep kerberos tickets fresh
<rekado>otherwise they might expire, sending you on a frustrating trip to debug this whole mess
<davexunit>does this avoid having to make the domain controller the primary dns provider?
<rekado>I don’t think so.
<rekado>Luckily I haven’t ever had to configure AD myself; I’m just a user.
<davexunit>I don't know of a way to do this with AD without the DNS thing
<davexunit>right now I'm researching LDAP integration into a SaaS (*gasp*) called Okta, but it's early access and thus far seems to be missing something
<civodul>janneke: could you try sending the output of 'git archive' to a bytevector instead of a string, and without trimming anything?
<civodul>then we need to adjust plain-file to accept bytevectors too
<janneke>civodul: thanks, i'll try that
<rekado>davexunit: do you *need* to use AD at all?
<davexunit>no, I can use something else that provides an LDAP interface
<rekado>if all you want is user authentication you can use 389ds
<davexunit>specifically I want ssh public key auth, where I can also specify that some users can sudo and others can't
<davexunit>which SSSD provides
<davexunit>hmm, neat.
<davexunit>haven't seen this before.
<davexunit>in order for this to work it would need to be able to pull user data from another directory
<davexunit>or I would need to be able to import data from this into another service
<davexunit>since it's LDAP I think I could do the latter
<rekado>it supports multi master replication.
<davexunit>that's nice
<rekado>don’t know if that’s a standard that’s implemented by other LDAP directory servers, though.
<davexunit>I think I would like to have just a single instance in our main data center
<davexunit>right now we use AWS SimpleAD which I believe is just Samba
<davexunit>but there's no replication
<davexunit>and we have to use one instance per data center per AWS account
<davexunit>so there's all this duplication and it's just not going to work going forward
<rekado>yeah, this sounds like a nightmare.
<davexunit>it got us through a time when we had an even less sophisticated solution, but now it's time has come, too
<davexunit>but anyway, thanks for suggesting this.
<davexunit>I want to get something sane figured out soon because it's a constant source of headache for me
<janneke>civodul: hmm, changing plain-file won't that rebuild world? looking at text-file*, i'm afraid it may need a (set-port-encoding! port "ISO-8859-1"); something like:
<jonsger>civodul: every patch has to be added to gnu/ or?
<civodul>jonsger: yes
<civodul>janneke: 'text-file*' is for text, so i don't think we should force ISO-8859-1
<civodul>'plain-file' translates directly to an add-text-to-store RPC, not to a derivation
<civodul>so adjusting it won't trigger a rebuild
<civodul>well depends on how we adjust it :-)
<civodul>but if we just have it accept bytevectors, that's fine
<dustyweb>guix: system: command not found
<vagrantc>dustyweb: try guix pull again
<civodul>it sounds like a joke but it's a good piece of advice :-)
<civodul>that'll never happen again™
<davexunit>omg someone added recursive gem importing...
<davexunit>could I build entire ruby on rails applications with guix now...?
<dustyweb>did another guix pull
<dustyweb>still getting "guix system: command not found"
<dustyweb>guess I'll run from my git checkout
<brendyn>dustyweb: you should check that you are really running the guix in ~/.config/guix/current/bin/guix
<dustyweb>not sure what that means
<dustyweb>how do I check that?
<brendyn>dustyweb: `which guix`
<dustyweb>cwebber@jasmine:~$ which guix
<dustyweb> /run/current-system/profile/bin/guix
<dustyweb>I thought that guix did something smart to defer to the right guix binary from that one
<dustyweb>but I don't remember for sure
<vagrantc>it's switch to where guix is now managed as a profile, and needs to be added to your path
<vagrantc>er, PATH
<vagrantc>e.g. export PATH=~/.config/guix/current/bin:$PATH ... i think
<dustyweb>vagrantc: oh... I guess I should add that to my bashrc?
<dustyweb>admittedly I didn't use guix pull previously but I figured I'd try to start doing so with the recent changes :)
<vagrantc>i'm forgetting where i added it ... or if just logging out and back in again fixed it
<dustyweb>(also because I got confused with the thread about how to run things from git reliably since it seemed things changed)
<janneke>dustyweb: same for me, I switched to guix pull just before 0.15
<janneke>i figured that i can use ./pre-inst-env on my git checkouts if needed
<tidux[m]>Is Guix hardcoded to install to /gnu or can it be pointed elsewhere, like pkgsrc?
<davexunit>tidux[m]: it can be changed at compile time, but /gnu is what you must use in order to download binaries from guix servers
<snape>tidux[m]: but Guix can produce relocatable binaries, see
<janneke>civodul: adding bytevector to plain-file worked -- just sent patch to guix-paches
<civodul>thanks janneke!
<janneke>if you need to make some tweaks, please feel free to do so
<janneke>oops, seems i created 3 bug reports instead of 1 -- and i tried to fix the documentation of that :-(
<civodul>you can always merge them from emacs-debbugs
<ng0>what's the use for store paths with a leading dot?
<ng0>I wanted to comment via email, but maybe it has been discussed besides the patch
<janneke>civodul: oh no...i'm afraid i did something terrible
<ng0>janneke: interesting how far you've come with the bootstrap. 2 years already :)
<janneke>phew, it seems my erroneous `merge all bugs' control message failed...
<janneke>ng0: thanks :)
<janneke>yes, i'm pretty happy about our progress
<cbaines>davexunit, regarding Rails, I've been working on it recently, there is just a lot of gems
<cbaines>I've got a branch here
<cbaines>I've also successfully managed to write a Rails application, using Guix for the packaging (still using Rubygems locally, but not using Bundler)
<davexunit>cbaines: I have been using guix to install ruby and bundler and then letting bundler do the rest
<davexunit>but it would be nice instead to convert a Gemfile.lock into guix code
<davexunit>and use that
<cbaines>davexunit, I've actually had problems installing bundler from Guix, as it uses a specific version of Ruby, that doesn't always match the version of Ruby I've installed from Guix
<davexunit>yes that can be an issue
<cbaines>If I'm using bundler, I just "gem install bundler" occasionally
<davexunit>also no one seems to be updating ruby in guix lately
<davexunit>2.5.0 has been out for 7 months and we still don't have it
<cbaines>I've been busy writing stuff using Guix recently, but I'm hoping to get back to pushing patches forward now, I'm doing Gitolite at the moment
<cbaines>Also, for the govuk-guix stuff, I do use the Gemfile.lock with Guix in a roundabout way
<cbaines>I wrote some stuff so that I could at least get Bundler to download separately, and then install to the store
<cbaines>From the package perspective, it looks like this
<cbaines>You just have another hash that represents what bundler will download based on the Gemfile.lock
<rekado>janneke: had you merged all the bugs we’d be very motivated to fix them all ;)
<janneke>rekado: *lol*, thanks for the headsup -- it really made me sweat for a couple of minutes
<janneke>only 1 bug left to fix before Guix 1.0 :-D
<pkill9>what does 1.0 mean?
<pkill9>does that mean it's out of beta?
<janneke>pkill, that was a joke
<pkill9>oh lol
<janneke>i accidentally, *almost* merged all open bugs into 1
<pkill9>oh haha
<janneke>there's still some work to do before 1.0
<pkill9>i got guix running on my new second-hand thinkpad
<janneke>pkill9: nice! what model?
<pkill9>x220 tablet
<janneke>ACTION just installed GuixSD on their X60 this weekend
<pkill9>nice :)
<brendyn>I installed slib and tried to load it but get
<brendyn>In procedure primitive-load-path: Unable to find file "slib/guile.init" in load path
<nixd>Hello, does anyone know why mkfs.ext4 is not found when installing GuixSD? other mkfs are fine. mkfs.fat for example is found by bash.
<rekado>nixd: I cannot reproduce this. mkfs.ext4 is part of the e2fsprogs package.
<nixd>Weird. I used a GuixSD Image downloaded around 2 hours ago. I also tried mkfs -t ext4 but it doesn't seem to exist either
<nixd>mkfs gives me "failed to execute mkfs.ext4: No such file or directory" as an error message
<ng0>can you tell us the exactr command you used?
<nixd>"mkfs.ext4 -L guixsdroot /dev/sda1" and after that I tried "mkfs -t ext4 /dev/sda1"
<ng0>does /dev/sda1 exist?
<nixd>When I search the files in the 0.15 image for mkfs files I can find plenty, including fat and ext2, but no ext4. It seems like there are no mkfs.ext4 file on my 0.15 image.
<nixd>Yes it does. I will look for mkfs.ext4 files on the 0.14 image just to see if its any different
<ng0>weird. I'm just running an x86_64 GuixSD installation from this image
<ng0>did you literally write command with the quotes?
<nixd>No, of course not
<ng0>okay, then I'm out of questions for now :/
<nixd>That was just to show what exactly I wrote here
<nixd>The 0.14 image doesn't seem to have any mkfs files for ext4 either. I really don't understand this at all
<ng0>where are you looking for them?
<ng0>as user root, what is the output of: readlink $(which mkfs.ext4)
<nixd>I actually just looked into the ISO's files. Not sure if they are even meant to be there as files. The output of this is: "which: no mkfs.ext4 in (/run/setuid-programs:/root/.config/guix/current/bin:/root/.guix-profile.bin:/run/current-system/profile/bin:/run/current-system/profile/sbin)"
<ng0>I mean.. I don't get it
<ng0>I'm on the iso right now
<nixd>Are you sure its the exact same iso?
<nixd>I guess I have to try using mke2fs to create my fs, I have no clue why mkfs.ext4 doesn't exist here
<ng0>when in doubt, try guix package -i e2fsprogs?
<ng0>should give you mkfs
<nixd>I'll try
<lfam>nixd: Can you clarify which ISO file you downloaded? I just downloaded and booted from the ISO in QEMU and it does have `mkfs.ext4`
<nixd>I downloaded this ISO:
<lfam>Okay, that's the same file, assuming the signature verification was successful.
<nixd>mkfs.ext4 does not exist even after installing e2fsprogs, And yes, the verification was successful
<lfam>Does it exist in the directory returned by this command? `echo /gnu/store/*-e2fsprogs-*/sbin`
<cehteh>nixd: fyi i installed 0.15 2 days ago, used mke2fs -t ext4
<lfam>mke2fs should come from the same place, the e2fsprogs package
<cehteh>well i just saying that, since i had no problems that way i didnt even notice if there was one
<lfam>Understood, I was just trying to provide some more context
<nixd>Iflam, yes it does exist in this directory.
<lfam>nixd: Okay, at least it is available. Strange that it does not end in your PATH...
<lfam>I meant to say, "end up in your PATH"
<nixd>Any idea how to fix this?
<cehteh>you just want to install/workaround or investigate the cause?
<nixd>Mainly just workaround this issue for now. I can have another look at it later
<nixd>Im guessing I have to go with mke2fs?
<nixd>Never mind. I now just ran mkfs.ext4 by going to the e2fsprogs directory and running it manually
<pkill9>that's odd, i recently instealled GuixSd and had mkfs.ext4
<ng0>I mean okay. it's not odd that it's not there, it's a valid problem and concern. it just should not happen this way
<ng0>all ISOs are supposed to be the same
<ng0>they are created from within guix
<nixd>Yeah, but has anyone had this issue before? I couldn't find anything. The workaround for me has been installing e2fsprogs, going to its directory and running mkfs.ext4 manually. Should I do anything regarding this, like opening a bug, or just leave it be for now? Thanks to all for the help.
<ng0>a way to reproduce it would be good
<ng0>like describe what you did, the shasum of your ISO file, etc…
<lfam>nixd: I expect that you already had an e2fsprogs package in /gnu/store and it could have been found with the command I showed you
<lfam>A bug report would be welcome although I think it's going to be hard to reproduce, I think :/
<nixd>Ifam shouldn't guix -i e2fsprogs have behaved differently if it already was installed? Versions should be the same, shouldn't they? The SHA1 of the ISO I used is F2B28A0FC9551900EAFDA27BEB7A834F2C861355 . I'll see and may open a bug report. I burned it onto a DVD. Other than that I just followed the installation manual, no special steps. Should be
<nixd>easy to reproduce, unless my ISO is somehow faulty
<ng0>so what happened with rust? my rust update hang midway, right before the actual new version and now I'm on 1.23.0 compiling?
<ng0>(or.. again. I'll give it a 4th try)