<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>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 <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 <vagrantc>did you also install it in your user profile? <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` <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 <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 <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. <nouun>I'm trying to package qmk and I need to create setup.py with "from setuptools import setup" "setup()". <nouun>I can create a the file with (invoke "touch" "setup.py") but I can't figure out how to insert text to it. <jpoiret>attila_lendvai, Lumine: a lot of things are needed only when reconfiguring, with the system generation not keeping references afterwards <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 <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 <nouun>Does anyone know what causes this error when trying to run the build phase in a python package? <nouun>"running "python setup.py" 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)) <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 <jpoiret>basically, you need a store connection to do this, that's why <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... <jpoiret>(run-with-store (open-connection) (lower-object (lower-object pinentry))) maybe <jpoiret>use mixed-text-file, it uses gexps internally <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 <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 <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]>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]>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]>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! <janneke>after guix pull, upon running guix environement i get: "signature is not a valid s-expression", ring any bells? <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. <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]>but there's something I'm missing w.r.t. how pkg-config should be used... <bost>According to the guix.gnu.org 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. <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>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) <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 <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 <gnucode>sneek later tell joe6512 that sway works really well on guix. <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>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>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 ***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. <jpoiret>Ox151: if you want to use gcc, you need gcc-toolchain <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... <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 *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. <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 <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 <jpoiret>did I really just say "no, yes"... looks like i need a bit more sleep <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 <tschilptschilp23>mpf, I was hoping that the ~#:mapped-devices '()~ could do something useful... <jpoiret>you can see that the pre-mount actions are the mapped-devices opening ones of the dependencies of the root filesystem <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) <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 <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>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 <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>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 works...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 configure.ac and a makefile.am <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... <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>and the configure script generated says it has a syntax error :S <jab>what's the error message that you are getting? <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>configure.ac:17: error: required file 'build-aux/config.rpath' not found <ekaitz>configure.ac:17: error: required file './ABOUT-NLS' not found <ekaitz>jab: got it finally! it was me running this wrong <civodul>ekaitz: you need to run "autoreconf" in the Shepherd repo to generate configure, Makefile.in, and all that <ekaitz>civodul: yeah but it wasn't that simple, also automake --install <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>civodul: OTOH i have not related question for you if you have the time to try to answer it <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