IRC channel logs


back to list of logs

<tschilptschilp23>I liked the old version too, but with the new one I tend to remember the news better. But I really like to chop things into steps and in the meantime (thanks to the person who told me here about it) also run ~guix weather~ before reconfiguring, as some bigger packages toast my laptop without substitutes being ready...
<tschilptschilp23>0x151: I had some troubles with it too -- where did you install pinentry (home-config, system-config, or ~guix install~)? I have it in the system's package list now, pinentry only though (although running gnome), and it does nicely without any .conf!
<Ox151>tschilptschilp23: i installed with "guix package -i" so i guess guix install
<tschilptschilp23>second, I quickly look my config up
<tschilptschilp23>yes, I ended up removing it from ~guix package -i/guix install~ and home-config places and put both gnupg and pinentry into the package section of config.scm
<Ox151>ill try that out, thanks for info. I wonder why it would make a difference
<tschilptschilp23>neither do I -- hope it can help!
<unmatched-paren>hello guix :)
<unmatched-paren>for some reason swaylock is complaining about not having setuid, even though i declared it as a setuid program in my config.scm
<unmatched-paren> (setuid-programs (cons (setuid-program
<unmatched-paren> (program (file-append swaylock-effects "/bin/swaylock")))
<unmatched-paren> %setuid-programs))
<unmatched-paren>that's what it should look like, right?
<vagrantc>did you also install it in your user profile?
<unmatched-paren>yeah, it's installed in my guix home (~/.config/guix/config.scm)
<unmatched-paren>do i need to install it system-wide for it to work?
<vagrantc>yes, only system-wide things can be marked setuid, otherwise ... everyone can have root access :)
*unmatched-paren once again is reminded that `nvim` segfaults when run with `sudo`
<unmatched-paren>ok, my screen locks now :)
<unmatched-paren>thanks vagrantc
*vagrantc waves
<apteryx>sneek: later tell vagrantc w.r.t. to a .deb guix pack available for install, it'd actually be possible via a postinst script
<sneek>Will do.
<paladhammika>hello guix, there is a patch that seems to have been overlooked does it meet the standards for packages?
<Ox151>anyone know a good default font for odd symbols such has different type bar characters? eg | _ -, but the odd ones out
<Ox151>I guess ill try gnu-unifont, supposedly has good unicode support
***the-porcupirate is now known as porcupirate
<Syboxez[m]>Hey. New to GUIX here and got a couple of questions. 1: Do flatpaks work? Second, do locally compiled applocations have any issues, and how do dependencies for those work? Is there a Bash environment that's sandboxed in a GUIX package, or will I still have access to all my libs?
***sneek_ is now known as sneek
<user_oreloznog>Syboxez(m]: Hi! You can install flaptalk like this : $ guix install flatpak
<user_oreloznog>An exemple to install firefox :
<Syboxez[m]>Any idea about the second question?
<Syboxez[m]>I locally compile a lot of stuff
<user_oreloznog>Maybe you'll need to custom yout own channel
<user_oreloznog>I'm not an expert, so you can refer to the manual
<MysteriousSilver>it would be much easier to compile them with guix than to do it manually
<lilyp>Syboxez[m]: See `guix shell' for clean development environments. It is not recommended to install your usual dev tools (GCC, Python, npm, even Guile libraries most of the time) in the user profile.
<attila_lendvai>i'm doing a repeated `guix system reconfigure` after a `guix gc`, with practically the same config and without pulling, and there are a lot of substitutes being downloaded, including stuff that i think shouldn't be. am i missing something, or did the gc delete stuff over-zeaously?
<attila_lendvai>hrm, my channels.scm is bound to my local checkout, but i did not pull from it.
<nouun>Is there a way to insert text into a file in a build phase? (invoke "echo" "test" ">>" "test") just prints because it isn't being interpreted by a shell.
<Lumine>Yeah it happens that it deletes a whole lot of packages even needed ones if you don't specify the options, I had 80 GB freed with gc on my previous setup and I had basically everything being installed back when I did a reconfigure.
<MysteriousSilver>nouun: what are you trying to do?
<nouun>I'm trying to package qmk and I need to create with "from setuptools import setup" "setup()".
<nouun>I can create a the file with (invoke "touch" "") but I can't figure out how to insert text to it.
<MysteriousSilver>nouun: does this work?
<jpoiret>attila_lendvai, Lumine: a lot of things are needed only when reconfiguring, with the system generation not keeping references afterwards
<jpoiret>think grub-install for example
<attila_lendvai>jpoiret, oh, that makes sense, thanks!
<nouun>MysteriousSilver: That seems to have worked, thanks. Now to work out the other kinks.
<jpoiret>some profile hooks need quite some tools as well, and they're run but often do not leave references behind as well
<jpoiret>that's also why sometimes removing generations will need to download grub again, which is pretty counter intuitive
<Lumine>Oh I see
<tschilptschilp23>lilyp: your hint from above somehow triggered my 'what to put where' thoughts... do I get you right, that you basically suggest not installing these packages anywhere (neither system nor home)?
<lilyp>tschilptschilp23: which packages in particular? Guile always exists on behalf of it being the Guix hacking language, but othre than that using them in your profile is inviting trouble
<tschilptschilp23>lilyp: what comes to my mind would be packages like python, python-beautifulsoup, python-requests
<lilyp>yep, that's guix shell -D guix.scm material
<lilyp>though perhaps that also depends a little on how well organized your personal scripts are
<tschilptschilp23>cool, thank you! I think it's OK at the moment. Cleaning my home right now, and backpropping GUIs of daily usage to the system-config right now ;)
<lilyp>if you have a Makefile defining generic utility procedures that you need to... idk, fetch some manga over the web and read it, a dirty home will be the consequence
<tschilptschilp23>I have to admit, I'm not doing Makefiles!
<tschilptschilp23>I'm thinking more of gnome-utilities like evolution...
<nouun>Does anyone know what causes this error when trying to run the build phase in a python package?
<nouun>"running "python" with command "install" and parameters ("--prefix=/gnu/store/jdq8m2k13n9kn779q8hg9ja3nfghi94n-qmk-1.0.0" "--no-compile" "--single-version-externally-managed" "--root=/") Listing '/gnu/store/jdq8m2k13n9kn779q8hg9ja3nfghi94n-qmk-1.0.0'... Can't list '/gnu/store/jdq8m2k13n9kn779q8hg9ja3nfghi94n-qmk-1.0.0'"
<tschilptschilp23>as I'm requesting the gnome-service-type in the system-config, I think packages that I (maybe falsely) think totally connected to it, might fit there...
<unmatched-paren>how should i get a package's store path from its #<package ...> object?
<unmatched-paren>i'm trying to configure gnupg to use pinentry-curses in my guix home
<unmatched-paren>so i need to get a path to /gnu/store/...-pinentry-.../bin/pinentry-curses
<jpoiret>i'd say (call-with-store (open-connection) (lower-object pkg))
<unmatched-paren>hm, ok
<jpoiret>you need (guix store) and (guix gexp)
<jpoiret>maybe it's open-store-connection i don't remember
<unmatched-paren>seems a little convoluted, but i guess it'll make sense once i read the docs for those procedures
<jpoiret>okay so it's run-with-store and open-connection
<unmatched-paren>ah, thanks
<jpoiret>basically, you need a store connection to do this, that's why
<unmatched-paren>connection to the daemon?
<unmatched-paren>do i need to `close-connection` the connection?
<jpoiret>i don't think so, but then you'd prefer (with-store store (call-with-store store (lower-object pkg)))
<jpoiret>with-store takes care of opening and closing
<jpoiret>by the way, it's still run-with-store :p
<jpoiret>call-with-store is different, it's for plain procedures, whereas (lower-object ...) is a monadic value
<unmatched-paren>hm, guile says that (run-with-store (open-connection) (lower-object pinentry)) doesn't return a string...
<unmatched-paren>it returns an derivation
<jpoiret>ah, right, you could lower it again
<jpoiret>(run-with-store (open-connection) (lower-object (lower-object pinentry))) maybe
<jpoiret>it ain't really good
<unmatched-paren>ok, thanks
<jpoiret>aren't you in a gexp though?
<unmatched-paren>i'm in (plain-file "gpg-agent-dot-conf" (string-append ...))
<unmatched-paren>so i don't think i'm in a gexp
<jpoiret>use mixed-text-file, it uses gexps internally
<unmatched-paren>ah, okay
<jpoiret>so (mixed-text-file "gpg-agent-dot-conf" "whatever\n" "hello=" ncurses-pinentry "/bin/whatever")
<jpoiret>or rather, (mixed-text-file "gpg-agent-dot-conf" "whatever\n" "hello=" (file-append ncurses-pinentry "/bin/whatever")), which is cleaner
<unmatched-paren>thanks, jpoiret!
<unmatched-paren>...and now pinentry-ncurses refuses to work :(
<unmatched-paren>hm, i think i need to log out and log back in first
<paladhammika>hey guix, what prevents this patch ( from being integrated?
<ekaitz>hi guix I need some help with ld-wrapper and that kind of things, I have this package definition for a custom GCC but I'm unable to make a gcc-toolchain that finds glibc.
<guixquestion>Hello, does anyone have a sample configuration (config.scm) that works with gnome and pipewire? Thanks in advance :)
<ekaitz>guixquestion: there's a thread about that recently in the mailing list but I can't really help you further than that
<ekaitz>guixquestion: I can't find it now :(
<nouun>Is there a reason you couldn't just use the gnome service and install pipewire? I don't know gnome so can't confirm.
<guixquestion>pulseaudio server is already running . I desactivate it by removing in desktop-service and configuring alsa-service whith pulseaudio to false
<guixquestion>but it's always running even i kill it (auto restart)
<wehlutyk[m]>Hello guix!
<wehlutyk[m]>I'm cross-compiling a system config from x86_64 to arm64, for a rock64 board (similar problem to something I asked about yesterday)
<wehlutyk[m]>my configuration is
<wehlutyk[m]>Now, the base `gnu/system/images/rock64.scm` config works fine, but building with an added openssh service (as in the config I just pasted) fails by failing to build libfido2-1.9.0
<wehlutyk[m]>The libfido build log is
<wehlutyk[m]>I'm guessing it's similar to what I was asking about yesterday (adding fish to the config, and fish not being adapted to cross-compiling yet)
<wehlutyk[m]>but I can't figure out a way to fix it
<wehlutyk[m]>the main problem seems to be appear with `Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)` while building libfido2
<wehlutyk[m]>if anybody has a hint on how to fix this, it'll be much appreciated!
<yarl>Hello everyone
<janneke>after guix pull, upon running guix environement i get: "signature is not a valid s-expression", ring any bells?
<janneke>a roll-back "fixes" it
<yarl>This is not strictly related to guix but maybe someone had this issue already. In 18.3 The Perfect Setup of the guix manual, geiser is recommended. I managed to have geiser-edit-symbol at point and geiser-pop-symbol-stack working, which is very useful to browse the source. But I can't get geiser-xref-callees/callers to work.
<tschilptschilp23>whelutyk: I followed civodul's and your discussion yesterday and didn't quite get, where to place inputs in your image-build-config -- but maybe this goes in a similar direction? Like putting pkg-config to the inputs. I hope I'm not bloating things here, just saying, because I think pkg-config does not necessarily get autoloaded...
<yarl>janneke I don't know if that's relevant but guix environment is deprecated according to the manual and the help subcommand
<tschilptschilp23>but I do not have experience with cross-compiling, so maybe someone with could jump in...
<yarl>Do someone here uses emacs+geiser+guile and can use geiser-xref-callees or geiser-xref-callers?
<wehlutyk[m]>tschilptschilp23: thanks! Yes, given civodul's answer yesterday, adding pkg-config to inputs was the first thing I tried and it doesn't change the error
<wehlutyk[m]>actually, pkg-config is currently in `native-inputs`, but the version that appears in the `environment-variables` file of the tmp build folder is the aarch64 one (so it makes sense that the pkg-config for the host machine is not found). I just don't see why pkg-config in native-inputs leads to the aarch64 pkg-config appearing in environment-variables.
<wehlutyk[m]>(adding it to inputs doesn't change this)
<tschilptschilp23>mhm, unfortunately this cross-compilation topic is out of my scope, so I just can cross fingers :(
<tschilptschilp23>wehlutyk: but looking at the log -- might it be, that it's actually failing on zlib missing, not even pkg-config?
<wehlutyk[m]>tschilptschilp23: I think zlib is searched for using pkg-config, from looking at CMakeLists.txt in the source
<wehlutyk[m]>so failing because pkg-config isn't found
<wehlutyk[m]>but there's something I'm missing w.r.t. how pkg-config should be used...
<ekaitz>janneke: ping
<bost>According to the the GuixOS proudly claims to be the in version 1.3.0. So, is there any command which returns such a version number? Like e.g. `lsb_release` under Ubuntu? And since we've rolling release, does such a version number have any meaning at all?
<jpoiret>because guix is rolling release, almost all users (all hopefully) run not on 1.3.0 but on the latest master branch
<jpoiret>you could consider point versions as "good snapshots" of Guix
<jpoiret>with many new features, big updates etc.
<gnucode>morning #guix
<joe6512>hi i am trying to compile dwm but when i run make i get error make no such file or directory makefile drw.o 18 error 127
<joe6512>i have installed all the dependencys
<MysteriousSilver>it'd be a lot easier to compile them with guix
<MysteriousSilver>you can inherit the existing dwm definition and replace the (source ...) with your local url of dwm source
<jpoiret>you can even just apply plain patches on top
<jpoiret>but yeah, suckless software may be annoying to use on Guix (the philosophy is to blame though)
<joe6512>ok how do i apply patches?
<jpoiret>well, you'll need to define a package yourself that inherits the guix dwm package
<jpoiret>maybe there's even some helper procedure for that already
<MysteriousSilver>read the first few parts of the cookbook ($ info guix-cookbook)
<MysteriousSilver>here's my dwm configuration for reference:
<MysteriousSilver>s/configuration/package definition
<jpoiret>for packages, it's better to use (package/inherit dwm (name "my-dwm-package") ...)
<jpoiret>the reason is, if dwm gets grafted (ie. its (replacement ...) field is set), then package/inherit will use the replacement instead, so that your modifications actually happen!
<jpoiret>otherwise, the grafted package would be used as-is
<MysteriousSilver>thanks for the information jpoiret
<gnucode>sneek later tell joe6512 that sway works really well on guix.
<sneek>Got it.
<maximed>wehlutyk: it is expected that the aarch64 pkg-config is in environment-variables
<maximed>The point of confusion might be that the aarch64 pkg-config is an x86-64
<maximed>That is, it is a pkg-config that can be _executed_ on x86_64 and it will locate libraries _for_ aarch64
<maximed>In the $PATH, you should find a 'aarch64-linux-gnu-pkg-config'
<maximed>That's the name of the ‘cross-pkg-config’ that the Autotool system expects
<maximed>However, possibly libfido2 looks for 'pkg-config' instead of 'aarch64-linux-gnu-ppkg-config'
<maximed>... nevermind, it looks like it somehow found libcbor but not zlib
<maximed>nevermind the nevermind, given the ‘Could NOT find PkgConfig’
<maximed>bost: Guix has never used the name ‘GuixOS’ -- there is Guix System (previously named GuixSD / Guix System Distribution) though
<maximed>wehlutyk[m]: Perhaps some environment variable PKG_CONFIG could be set to override cmake's logic for finding pkg-config
<barra>Can I have an ssh server in my initrd on guix, for entering my encryption passwords?
<jpoiret>theoretically yes, in practice no
<jpoiret>is it possible to get ssh to connect directly to the kernel console?
<jpoiret>the initrd as it is now is not very modular
<barra>I don't believe so, I think most implementations work with a shell
<barra>It's not a deal killer for me though, encryption is more of a nice to have for me
<jpoiret>what will you be using the encryption for? you could also consider having an additional unlocking key and adding it to the initrd, so that it automatically unlocks
<jpoiret>i know some people using this method to securely erase a disk by simply overwriting the key file
<barra>Mainly protection against casual snooping
<barra>but the device I'd require to unlock remotely won't need the same protection
<jpoiret>snooping as in, it's a server and you want protection against physical access?
<barra>Essentially, but it's more a nice to have
<barra>It's my main desktop, but I use it to preform more intensive work remotely through "Sunshine"
<barra>I had a similar setup to what I'm describing on Artix linux, where you could embed dropbear into your initrd, and unlock encrypted drives through that.
<jpoiret>yes, that's roughly what i was reading. I think it's possible to do for guix, but you'd have to patch things a bit
<jpoiret>the thing is, you'd want to be able to enter the password either via SSH or physically, right?
<barra>Yeah, that'd be ideal
<barra>I don't have the skill to implement it myself at the moment, so I guess I'm going to have to remember to leave my PC on when I need to use it later on in the day
<jpoiret>in any case, I think you'd need to modify luks-mapped-device to add that feature there
<jpoiret>I don't think you'd need to directly modify the initrd code
<jpoiret>having both physical and remote unlocking might be non-trivial though, you'd need some signal-foo for that
<barra>I'll keep that in mind in case I decide to try and hack together something
<barra>thank you for your help
***Xenguy_ is now known as Xenguy
<Ox151>what is the equivlent to build-essential with guix?
<nckx>There is none. Just install the packages you need. What's essential depends entirely on what you're building.
<Ox151>ok thanks
<jpoiret>Ox151: if you want to use gcc, you need gcc-toolchain
<nckx>Good note.
<Ox151>jpoiret: thank you, that is what I was looking for
<nckx>sneek: later tell tex-milan: I'll have to dig through my backups && pray. Fired that client...
<sneek>Will do.
<nckx>Would it not make sense to rename gcc-toolchain to gcc?
<nckx>It's not like it would conflict with anything.
<jpoiret>maybe you can use gcc with eg musl? i'm not sure
<jpoiret>you can install gcc only iirc
<jpoiret>guix install gcc?
<nckx>Try it.
*nckx mobilitated but pretty sure that's not a thing.
<jpoiret>maybe i'm misremembering people having issues with `gcc` when they should've installed `gcc-toolchain`
<nckx>Maybe! It used to be possible to guix install gcc.
<nckx>It was hidden for that very reason.
<jpoiret>ohhh, right
<nckx>IFF we keep that so (I've always been meh on it), I can't see a plausible drawback to (name "gcc") the gcc-toolchain variable.
<nckx>Maybe there's one. I'm in a weird mood.
<jpoiret>at the same time, guix search gcc should be enough
<nckx>Not to be facetious, but 'so should guix install gcc' perhaps? Defence of hiding gcc was 'user friendliness'. Current status quo not *that* user-friendly, regular IRC reports suggest.
<tschilptschilp23>reading about encryption above -- any hints where would I have to start to decrypt my system via usb-stick or sd-card during boot? my system is luks encrypted, and so is my home-directory, which is on an external usb-drive. This results in me having to type passwords 4 times, which is OK as I don't reboot very often, but could need some optimization. I had a usb-stick version a while ago on a debian system, but lost my notes. And I
<tschilptschilp23>suppose it will work a little different here too, so I don't cry after it.
<jpoiret>you'd need to modify the initrd code
<jpoiret>ideally, there would be an initrd rework from the ground-up to allow things like these to be easier
<tschilptschilp23>jpoiret: thanks -- is this something to be done in the system-config?
<jpoiret>unfortunately, no, touching the system config won't be enough
<jpoiret>you'd need to modify things in gnu/build/linux-boot.scm iirc
<tschilptschilp23>OK, I will look there. If I'm offline for the next two weeks, you know what happened ;)
<tschilptschilp23>Argh. This starts way earlier... would I have to do this at pre-install-time? I cannot see any gnu/build directory on my system. Well yes, on my local checkout, but not on the one I'm running right now...
<jpoiret>tschilptschilp23: what I was saying was that you need to modify guix's source code
<jpoiret>no, yes, you'd need a local checkout on which you would make changes, and use that patched guix for your system
<tschilptschilp23>yes, I feared that I kind of understood what you said
<jpoiret>did I really just say "no, yes"... looks like i need a bit more sleep
<tschilptschilp23>haha ;) I just poured some coffee and doubt that this was a good idea, but looks looks like one might tweak initrd from the system-config... but this honestly somehow scares me off!
<tschilptschilp23>(as I like my computer at the moment very much, except of the password-typing)
<jpoiret>the thing is, none of these will help you modify the actual initrd booting sequence
<jpoiret>it's mostly about adding modules and such to the initrd
<jpoiret>base-initrd has a pretty hardcoded behaviour unfortunately
<jpoiret>what happens at boot is defined in boot-system at
<tschilptschilp23>mpf, I was hoping that the ~#:mapped-devices '()~ could do something useful...
<jpoiret>specifically, mounting the root filesystem happens after all of its pre-mount actions are done, which happen to be specified at
<jpoiret>you can see that the pre-mount actions are the mapped-devices opening ones of the dependencies of the root filesystem
<unmatched-paren><greeting appropriate to the time of day>, Guix.
<jpoiret>and these are in turn defined at for luks
<jpoiret>so the behaviour is pretty non-customizable regarding that
<unmatched-paren>tschilptschilp23: pretty sure that if you mess your initrd up you can just roll back in grub to the previous system generation (after making modifications and guix pulling from your local checkout)...?
<jpoiret>that's right, as long as you don't touch bootloader stuff you should be safe
<unmatched-paren>you should be able to set the `guix` channel to a local checkout, right?
<jpoiret>unmatched-paren: yes, but the easiest way to test is to use ./pre-inst-env, since guix pull'ing will be pretty slow
<jpoiret>and it'll create a lot of generations
<jpoiret>you need to use `sudo -E ./pre-inst-env guix system reconfigure` though, since guix's dependencies need to be available in the environment
<tschilptschilp23>well, I'd fear that I never end up seeing grub, as I typically have to type the passwords before seings it...
<unmatched-paren>if your bootloader gets messed up it's pretty easy to fix it with a usb and good ol' chroot anyway, i've had to do so once before...
<jpoiret>oh no, the initrd doesn't start until later on in the boot chain
<jpoiret>i'm afraid you can't unlock grub with a usb key (but I might be 100% wrong)
<unmatched-paren>grub's job is to load initrd and linux-libre into memory, mount initrd at /, and tell linux-libre to take over (start /sbin/init, etc)
<unmatched-paren>at least, that's my understanding of it
<jpoiret>actually, the initrd is "mounted" by the kernel
<jpoiret>grub only loads the initrd and kernel, and passes control over to it
<jpoiret>the initrd is mapped into RAM before handing off
<unmatched-paren>right, ok
<tschilptschilp23>i don't think my grub itself is encrypted -- guix just wants me to enter passwords to decrypt the root filesystem (and also for the external usb), before I get to the grub splash screen. how this all goes into each other is very much opaque to me...
<jpoiret>but, in any case, grub needs to see the store to load the kernel and initrd, and so may need to unlock a LUKS device, and I'm not sure you can use a usb key with a keyfile for that
<jpoiret>tschilptschilp23: well, that's actually GRUB asking you that, to be able to read its configuration files/the kernel and initrd
<jpoiret>if your /boot is encrypted, GRUB still wants to read /boot/grub/grub.cfg for example
<unfroq>tschilptschilp23: Even though, I think it would be aweseome, if you would find a way to solve the problem by patching guix, you could also think about alternative solutions: Depending on your requirements, you could also try to boot an unencrypted system with a ssh-server available. Then you could SSH into it and mount an encrypted home or other encrypted devices. That way, you could also solve the grub password issue.
<tschilptschilp23>jpoiret: right, this makes sense. I was wondering about this behaviour already for a while now...
<tschilptschilp23>i just checked, it's really weird -- ~/boot/efi~ (I *think* I'm booting from that one) is on an unencrypted partition, ~/~ is encrypted, therefore ~/boot/grub~ will be as well
<tschilptschilp23>s/think/at least though/
<unmatched-paren>tschilptschilp23: / != /boot
<unmatched-paren>they are generally different partitions
<tschilptschilp23>probably like the /boot and /root on the raspberry sd that I was willing to sacrifice for that [about half an hour ago ;)]
<jpoiret>pivoting root is pretty complicated to do right
<jpoiret>especially once you leave initrd land
<jpoiret>it's certainly possible though
<blackbeard>nckx: ping
<nckx>By the most bizarre coincidence I just logced on. Yes?
<nckx>Did you ask a question earlier? I can't find one, or I forgot, sorry. Away again for now.
<jpoiret>unmatched-paren, tschilptschilp23: tbh it's common to have /boot on /
<jpoiret>Mine is on my EFI partition, but seeing how many people had the luks2 bug i'd say the former occurs more often
<tschilptschilp23>here I have ~/dev/sda1~ on ~/boot/efi~ and the (encrypted) ~/dev/sda2~ on ~/~, ~/var/lib/docker~, and ~/gnu/store~. I did not really put hand on this, for convenience I use the graphical live installer, and then reconfigure with my home-config and system-config
<tschilptschilp23>well, I have to adapt the uuids to get things right, but I can live with that, as I don't do this often
<tschilptschilp23>might happen quicker than I hope for though ;)
<tschilptschilp23>I could cry though, that we don't have (or I don't get what represents it) an ~/etc/crypttab~ and that mysterious ~/lib/cryptsetup/scripts/passdev~... the mapped-devices section in the system-config /must/ (?) set up something like this, but I cannot find how and where...
<tschilptschilp23>I mean the mapped-device section in combination with the file-systems section...
<old>Anybody has problems with `run-geiser` recently?  After some recent update, I get `geiser-repl-project-root: Symbol’s function definition is void: project-root` and the REPL is never spawned :/
<jab>old: I used run-geiser this morning...but I was using doom-emacs's provided package from github....
<jab>I have had some weird issues, where the geiser process can lock up...and it makes emacs almost unuseable...
<jab>I have to kill the repl...
<jab>I have tried connecting geiser to an external scheme repl....but then the REPL in emacs gets all wharped...
<jab>It's just the prompt is all jumbled.
<ekaitz>civodul: is it normal that the shepherd repo doesn't contain a configure script or am I doing something superwrong
<jab>ekaitz: I believe that configure script is generated.
<jab>It has a and a
<ekaitz>jab: i'm not really a gnu-buildsystem kind of guy so I don't know how to build it
<jab>I think you need to run something like autoreconf...
<jab>just a sec
<ekaitz>what should I do to build it?
<ekaitz>(this is something I need to learn someday... ugh)
<jab>ekaitz: It's super easy.
<jab>I think you just install autotools...
<jab>then run autoreconf in the directory.
<jab>Then you should see a configure script after you do that.
<ekaitz>aiight let me try
<ekaitz>something is broken
<ekaitz>aaaaha! need to automake too
<ekaitz>and the configure script generated says it has a syntax error :S
<jab>what's the error message that you are getting?
<ekaitz>gimme a sec
<ekaitz>./configure: line 3197: syntax error near unexpected token `external'
<ekaitz>./configure: line 3197: `AM_GNU_GETTEXT(external)'
<ekaitz>and then I decided to add gettext to the environment and the autoreconf is failing with a different thing
<ekaitz> error: required file 'build-aux/config.rpath' not found
<ekaitz> error: required file './ABOUT-NLS' not found
<ekaitz>those are the current errors
<ekaitz>jab: got it finally! it was me running this wrong
<ekaitz>thanks for the help!
<civodul>ekaitz: you need to run "autoreconf" in the Shepherd repo to generate configure,, and all that
<civodul>"autoreconf -vfi", even
<ekaitz>civodul: yeah but it wasn't that simple, also automake --install
<ekaitz>finally managed to do it
<civodul>note that "autoreconf" (not "autoconf") does it all
<ekaitz>well i managed to compile everything already
<ekaitz>i need to learn this autotools magic
<ekaitz>normally projects come with the configure script already built and...
<civodul>in tarballs, but usually not in the repo
<ekaitz>i see
<ekaitz>civodul: OTOH i have not related question for you if you have the time to try to answer it
<civodul>sure i can try :-)
<ekaitz> <--- I can't make this gcc toolchain find the -lc
<ekaitz>i can build the gcc, but when i make the whole toolchain it doesn't find the libc
<ekaitz>I tried setting the LIBRARY_PATH by hand and all that... but impossible
<ekaitz>I thought it was because of the ld-wrapper was missing at the beginning but I added the make-gcc-toolchain and it's still failing
***vagrantc_ is now known as vagrantc