<oriansj>is there any reason why dracut isn't packaged in guix yet? <nckx>Utility. I started a good while back (for lsinitrd) but it just wasn't worth my trouble, and I stopped. <oriansj>nckx: well it is also used in gentoo and available in other distros <oriansj>but fair as you didn't feel it was worth the effort and I guess I'll have to wait for someone who feels it is <the_tubular>Man, how I lost interest for gentoo since I discovered nix/guix <oriansj>as I've managed to have guixsd setups down to a science (until I once again change my mind about some details in my eternal tweaking process) <oriansj>and yes, I do probably have one of the most explicit guix configurations here <oriansj>and if I figure out a way of doing something better, I share it with the whole world so that they too can have a clean, simple and easy to understand system (with less crap if possible) <oriansj>and I find I learn things from different systems that allow me to improve *all* of them <oriansj>so if red hat or ubuntu or void or knoppix has a really good idea, it is best to say cool and learn from it <dirtcastle>guys I'm trying to hack on guix through geiser. I have a config file. I tried to run geiser-edit-symbol-at-point. I cloned guix repo and set the loadpath. it throws error. I can see documentation for guile symbols. but I can't do the same for guix symbols. <apteryx>mbakke: got mozjs@91 building on master! I just needed to shuffle phases a bit <Luk6655>hi, so I managed to use modify-services to modify elogind configuration. However, after I boot the resulting configuration I see elogind is still running with the old config. I suspect this is because I just modified an instance of elogind while some other service (gdm?) creates its own instance of elogind with the default config. Is this possible? <jpoiret>Luk6655: did you reconfigure after modifying your config.scm? <Luk6655>yes, I did, then to check for running config I run "where loginctl" to find the current /gnu/store location for elogind <Luk6655>in that folder is /etc subfolder where logind.conf lives <Luk6655>I assume that logind.conf should be updated to reflect my changes <Luk6655>I've looked in / (root fs) for logind.conf and there are only two, both in /gnu/store, both have the variable I set as default <jpoiret>can you paste the relevant part of your config.scm at paste.debian.net? <Luk6655>however, If I run the modify-service snippet in guix repl, I do get an elogind instance configured as expected <jpoiret>if you load the your config.scm in the repl and access the services field of your os, is the elogind service alone and with the proper config file? <Luk6655>that's exactly what I'm doing now ;-) <nckx><I assume that logind.conf should be updated to reflect my changes> That assumption is wrong. <jpoiret>it's possible also that the logind.conf file you're looking at is the sample one from the elogind package, not the one actually loaded by elogind through the config line <nckx>sudo grep -0a ELOGIND_CONF_FILE /proc/$(pgrep elogind)/environ <nckx>oriansj: I know. I was talking about the code, not the availability. <Luk6655>nckx: ..... then, it is working as expected <Luk6655>it shows a location in /gnu/store/igc8hsry2r1r7761d50wqcmsc63c41nb-logind.conf <Luk6655>that has my setting set to yes, problem solved :-) <jpoiret>you should be able to query elogind's parameters through the CLI interface iirc <nckx>jpoiret: Yeah, but when one owns a hammer… :) <jpoiret>generally, don't try to guess which file in the store is being used, unless you know from runtime information the exact path to the file <Luk6655>I did try loginctl -a which I thought was supposed to show all, but it only printed a small table showing user sessions <Luk6655>for future I'll try running the conf file in guix repl <Luk6655>btw, does anyone know a way to pretty-print the output? <Luk6655>there is guile pretty-print, but it is not recursive <Luk6655>well, lets say I copy/paste my system config file into guix repl, it returns the operating system object as a wall of text <Luk6655>this wall of text contains all the services and their config, but it has no line breaks, no whitespace, it isn't very readable <jpoiret>you can query its fields manually :) <nckx>I don't think that exists, what you see *is* considered ‘pretty’-printed. <jpoiret>i think you can make the (ice-9 pretty-print) do some recursive pretty-printing <Luk6655>well, I did make it go one level deep by doing (map pretty-print output) <Luk6655>however, I'm interested in this querying by its fields manually <Luk6655>jpoiret: could you show an example syntax, please? <jpoiret>(operating-system-services os) for example <jpoiret>i suggest doing (define os (load "config.scm")) <jpoiret>then inspecting that object using guile <jpoiret>you'll need to look at the definition of operating-system and whatever other records you're querying to find out which field accessors are needed <jpoiret>it's mostly [record-name]-[field] though <Luk6655>ok, this seems straightforward, how do I go into a subobject, lets say operating-system-services -> gdm-service (I'm makingn up the names here) -> configuration <jpoiret>services is just a list of services, so you can filter it using the list procedures <jpoiret>you can filter using (eq? (service-kind service) gdm-service-type) i think <Luk6655>ok, I'll look into it, thanks for pointing me in the right direction <Luk6655>coming back to the pretty-printing, I think if there was some auto-indent for lisp/scheme it would work with guile too. However I spent some time searching for one yesterday and I couldn't find any for some reason (many other languages seems to have lots of tools like that) <nckx>I used aggressive-indent-mode for a while, but, and I cannot help but suspect this was user error, it was too aggressive. <Luk6655>I don't mind using other tools to achieve it, I'm just starting with emacs too <nckx>The default scheme-mode's indentation is good enough for me. <nckx>There's also ‘guix style’ for a different ‘off-line’ approach. <nckx><good enough for me> …with Guix's dir-locals applied, of course. <Luk6655>sorry, actually this is not os object, just %desktop-services <Luk6655>it does add some line breaks between list items, but that's about it <nckx>That is not ‘Guile’ though. <nckx>As I said, this is what Guile actually considers formatted output already, and pats itself on the back for a job well done. <nckx>If and how you were able to meaningfully run ‘pretty-print’ on this confuses me greatly. Unless it just managed to grab the embedded sexps. <nckx>But both things are almost unrelated. <Luk6655>I though one can simply paste this into repl and get the same object back <nckx>To give an inaccurate analogy, the first is like parsing the output of *running* lscpu [OPTIONS], the second is like parsing the *string* "lscpu [OPTIONS]". <nckx>I hope that makes sense and you don't think too hard about it. <Luk6655>yes, it does, this is just a text representation <nckx>Meh. I'm still going to retract the analogy because it was too inaccurate. <nckx>I suggest (also) asking this in #guile. Maybe there is some way to do what you want, I just wouldn't count on it. <Luk6655>I'll be testing a new config so I'll probably drop off, thanks for the help again <nckx>Luk6655: Oh, and if you would find a way to pretty-print that to a level you like (what that is isn't clear to me either), please let me know! Learning you were wrong is fun. <pkill9>is there a GUI packaged in guix for managing bluetooth devices? <pkill9>has anyone had an issue with bluetooth headset not showing in pulseaudio? <pkill9>I can conect my headset via bluetooth , but it doesn't show <pkill9>it works now, just copied default.pa <ekaitz>hi all, anyone managed to install a desktop in an ARM device, say pinebook pro? <ekaitz>it's like generating an image it's using libtirpc and that's not available for arm <ekaitz>which package/service is trying to use that? <ekaitz>oh forget it... i'm trying to generate images but gnu-build-system does not cross compile so anything using that fails <Luk6655>What is a guix way to set up a shutdown /reboot script? (a script that gets called before reboot/shutdown) ***Noisytoot_ is now known as Noisytoot
***Dynom_ is now known as Guest4686
<Kabouik>Has any of you managed to get dead keys working in urxvt? I cannot seem to get them to work in Guix/Wayland/urxvt, yet they work in every other program. Since this may be related to locale, I am not sure if this is a urxvt or a system issue (I asked in urxvt channels too, but they do not seem to have any trouble with dead keys). <Kabouik>My config looks similar to yours oriansj, I can't understand what breaks dead keys in urxvt. <Kabouik>Wait, it could be that the locale files are not located in the usual place in Guix. My .XCompose file, inherited from another machine, reads "include "/usr/share/X11/locale/en_US.UTF-8/Compose"" <oriansj>you probably would want to replace that with something you have actually on your guix system <Kabouik>Totally, I'm reading the Guix manual about locales now. It's not very clear to me though, it looks made for advanced used, while I'd want to keep it as minimal as possible. <Kabouik> /run/current-system/locale/x.y/en_US.UTF-8 doesn't seem to include a Compose file on Guix <Kabouik>It seems to me that urxvt needs a .XCompose file to produce composed characters (which dead keys make). For instance, if I add `<dead_acute> <c> : "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA` in my ~/.XCompose key, then urxvt is capable of producing ç when I press ' followed by c. I don't know if urxvt is the only program to require such a file, but clearly it fixes the issue with dead keys in it. Now, since I can't find any locale that <Kabouik>contains the Compose file that normally comes with them in other distributions, I am not sure how to fix all other keys in Guix except by writing all rules directly in ~/.Xcompose instead of sourcing them from an existing file. <oriansj>on debian it is: /usr/share/X11/locale/en_US.UTF-8/Compose <oriansj>copy into a file foo; do base64 -d < foo >| .XCompose.xz; unxz .XCompose.xz <nckx>Yeah, package is a bit weird. <nckx>One would expect it to come from xkeyboard-config or so. <Kabouik>How come you have a Compose nckx? I knew that main Guix contributors had privileges. <Kabouik>Let's see if I get it when installing xkeyboard-config. <nckx>Apart from you all have to buy us free as in beers at FOSDEM, I don't see any privilege here. <nckx>This is me sourcing the upstream Compose file in my ~/.XCompose. <Kabouik>Yes but I did try looking in my ~/.guix-profile/ and there was no Compose in there <nckx>That's why I included the realpath hint :) <Kabouik>What I mean is I should have found the "fakepath" one <Kabouik>Oh, thanks. Let's try with this package. <nckx><How come you…> That said, it *is* a scandal that Guix doesn't come with that quoted example out of the box :o) <Kabouik>Installing libx11 and including the Compose key in my ~/.XCompose file does seem to fix it. I find it a bit weird that default locale coming with Guix out of libx11 wouldn't include the Compose file, but what do I know <Kabouik>Fortunately I had an pre-existing .XCompose file that I took from my previous distro and realized when reading it that I need the Compose file for dead keys (at least in urxvt and perhaps some other applications, but definitely not all). <nckx>I can't parse what comes after ‘weird’ here so I can't say, sorry. <Kabouik>Sorry if what I said could not be parsed, what I meant is Guix does come with some locale files out of the box, before installing libx11, and I don't understand why they're devoid of a Compose file. I don't think that was the case in other distros, but then maybe they had libx11 installed out of the box. <trevdev>Hey Guix. Has anyone got any tips for how to get the default keyring to unlock with gdm login? <Luk6655>let's say I'm writing a package definition and I define a module for it with (define-module. Do all such files have to be in a channel, or can I build/install (test) such package definition file in separation? <Luk6655>I know one can install a package from a local file using this kind of syntax: "(use-modules (guix)" <Luk6655>however, in channels there are module definitions that use slightly different syntax for use module statements: #:use-module (guix) <Luk6655>so my question is in relation to the latter only <mbakke>apteryx: can it wait for 'staging' to reduce merge conflicts? :-) it should be ready any day now :P <mbakke>rekado: I don't really have a strong opinion, but would prefer not to introduce rebuilds on 'staging' so it can be merged ASAP <rekado>mbakke: okay, I’ll keep it on a separate branch. ***Xenguy_ is now known as Xenguy
<Cairn>sneek: later tell unmatched-paren: When you have time, I sent just two quick questions about your suggestions on my Hydroxide patch. Once you get back to me, I'll send a v2. =) <Luk6655>Does anyone know if patch-source-shebangs in gnu-build-system patches /bin/bash too (if bash is present) or not? <unmatched-paren>Cairn: I'll have a look on my phone, my laptop is currently unable to access the internet <sneek>unmatched-paren, you have 1 message! <sneek>unmatched-paren, Cairn says: When you have time, I sent just two quick questions about your suggestions on my Hydroxide patch. Once you get back to me, I'll send a v2. =) <unmatched-paren>Luk6655: It'd make sense if it could change any /bin/... to a gnu store path, since iirc it does that with /usr/bin/... <Luk6655>yes, it would. I'll find out for sure soon :-) <nckx>It just replaces whatever's in $PATH, which /bin/bash will be. <Luk6655>nckx: yes, I'm just asking if it replaces strings #!/bin/sh and #!/bin/bash in source files <Luk6655>so it will not replace #!/bin/whatever to /gnu/store/somepath/bin/whatever <Cairn>It doesn't need to though, right? It provides the right path for necessary shells in the build environment <nckx>Luk6655: Only if it's the actual shebang of that file. It will not replace shebang-looking strings in the entire file. <Luk6655>well, the source folder has autogen.sh script that has #!/bin/bash on top. Unless I replace that /bin/bash with a path to working bash it will fail <Luk6655>I mean the actual shebangs, just not neccesarily sh (bash inn this case, but may be perl in future or anything else really) <nckx>OK, != ‘replaces strings #!/bin/sh and #!/bin/bash in source files’ though. <nckx>Yes, it replaces shebangs. <Luk6655>ok, good I don;t have to worry about that /bin/bash <nckx>It's even clever enough to handle ‘#!/usr/bin/env bash’ → ‘#!/gnu/store/…/bin/bash’ — if not much more. <nckx>Well, yeah, that's it job. <nckx>I should just give up typing and go work the land. <Luk6655>will gnu-build-system run autogen.sh before configure, or does it have to be run differently? <Luk6655>looking at packages like gimp it seems it should be run automatically, but there is no mention of it in the guide (that I can see) <Luk6655>(the package is not gimp, its gimp-resynthetizer) <nckx>No, I don't think much of this is documented (to-do, etc.). It will run autogen.sh if it exists and ./configure doesn't, and you need to provide the necessary auto{conf,make}/libtool/gettext-minimal packages. <nckx>Missing ’/…’ — those are just the most common suspects. <Luk6655>I've got a list of required packages because I managed to build the app using guix shell (here a long list of stuff including autoconf gcc-toolchain etc) <nckx>But note that packages like ‘gcc’ are implicit (and ‘gcc-toolchain’ should probably never be an input at all). <Luk6655>yes, in a package file, however in guix shell one has to specify gcc-toolchain. That's how I built it for the first time to check if it even builds <Luk6655>now I'm changing my package to define-module syntax and I plan to run build with passing a folder it is in with -L. Could I have used the guix build command with my package like this: https://paste.debian.net/1252653/ <nckx>Yes, with ‘guix build -f FILE’. <nckx>(hint: Did you forget `(use-modules (guix git-download))'?, but that aside.) <nckx>That was Guix's wording, but you're welcome :) <Luk6655>hmm, it complains about my license definition <Luk6655>I'm including use-module (guix license) where license:gpl3 is defined <Luk6655>yes, I just scrolled to see that in another file... *unmatched-paren laments that it's ((...) #:prefix ...) and not (... #:prefix ...) <nckx>If you're wondering: the convention to almost universally use a prefix for license: and not for almost any other file is 99% zlib's fault. It is both a package and a licence. <Luk6655>nckx: hah, I never knew there was zlib license <vivien>Also be careful if you want to have the make or gettext package :) <nckx>I must apologise to zlib. <Luk6655>wow, It "almost" worked ;-) "./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory" <unmatched-paren>Apparently we decided to use perl-license for the perl license, though. <Luk6655>it seems it hasn't replaced the shebang, or perhaps I need to add bash to native inputs <nckx>H4sIAAAAAAAAA8ssUS9W8PfmAgBDJdY+CAAAAA== <unmatched-paren>Oh, yes, there's --license:naïvely-written-crayon-license-- license:nmap. <Luk6655>there is a file in guix/gnu/packages/gimp.scm that I use as a sort of example. Around line 531 it has this comment: ";; avoid ./autogen.sh: ./configure: /bin/sh: bad interpreter:", but I'm not sure how exactly is it avoiding this error? Its not doing anything special? <nckx>Luk6655: Look at autoconf. <nckx>However, even then we get ‘configure: error: cannot run /bin/sh build-aux/config.sub’. Hmph. <Luk6655>sorry, I don't see it, the manual mentions this is "legacy" method of specifying inputs wih (input, "somestring"), but I'm not sure what does it mean when it is written like this ("autoconf", autoconf-wrapper) <nckx>Just write ‘autoconf-wrapper’. <Luk6655>btw, the shebang is overwritten correctly <nckx>It is, but another /bin/sh sneaks in later. <unmatched-paren>("foo" ,foo) is the disgraced legacy way to write inputs, where the label is explicitly specified <nckx>Smol note: It's ("foo" ,bar) and not ("foo", bar). Note the space. This isn't C. <nckx>The , modifies the symbol after it, and is syntactic sugar for (quote bar). <nckx>*and is syntactic sugar for (unquote bar). <Luk6655>indeed there is a /bin/sh later. I assume I have to replace it by inserting a phase into the build that takes care of it by doing search/replace onn the file. <Luk6655>Doesn't it only work if the shebang to patch is on the very first line of the file? <nckx>It's probably a stupid autogen.sh trying to run something too early. <nckx>Try (replace 'bootstrap (lambda _ (invoke "autoreconf" "-fiv"))). <Luk6655>(I haven't looked at the file yet so I'm guessing why it failed - I had to walk away for a bit) <nckx>Might need to run the gtkdocize then, too, dunno. <nckx>There is no way to patch your way out of this with (substitute* … "/bin/sh" …), there's no inbetween-time. <nckx>Luk6655: The error is not related to gtkdocize. <nckx>It is related to the line I linked to. <nckx>If you were fixing this through patching, which I don't recommend, you'd patch it not to run config.sub too early, before Guix's default patch-shebangs phase has had the chance to work its magicks. <nckx>(Or configure, I didn't check which branch is true.) <Luk6655>If I understand correctly why it fails I might have to patch it and add a delay in there. <nckx>Please try my suggestion first. <Luk6655>The one with bootstrap replace, yes I will <nckx>Even if you have to add a manual (invoke "gtkdocize") to it. <Luk6655>ok, I'm back, what does bootstrap phase do in gnu-build-system? <antipode>And if not, run the autoreconf -vif thing. <antipode>(Actually, that only happens if ./configure does not exist yet) <nckx>It will run autogen.sh if it exists and ./configure doesn't, and you need to provide the necessary auto{conf,make}/libtool/gettext-minimal packages. <nckx>(Not to be pedantic, but it was easier just to copy & paste that again.) <nckx>(Plus a little pedantry never hurt anyone.) <nckx>And that's all I have time for. <Luk6655>indeed it works through configure et al, then it fails because gtkdocize wasn't run <Luk6655>I should be able to figure it out from here hopefully <nckx>antipode: Aksually, you should know it impossible to prove a negative, jeeeez. <nckx>successfully built /gnu/store/vvxvqrihk010iwg7c3gmwh54lqhx9f7q-libldm-0.2.5.drv <nckx>I was promised a mystery. <Luk6655>nckx: if you're still here, how did you sucesfully built libldm? I did add running gtkdocize after configure, but for some reason it doesn't/ <nckx>Luk6655: I am, but on phone now. I added docbook-xsl libxml2 libxslt to native-inputs. Running gtkdocize makes no difference to the build. Also, I think you had some superfluous inputs like m4 and which that should be removed. I think that was all... ***Xenguy_ is now known as Xenguy
<rekado>that license: prefix situation has made me wish for some kind of type-aware scope <efraim>do some of the gnome packages specifically depend on the newer librsvg or would librsvg-for-system be fine for them? <florhizome[m]>is anyone else experiencing a freeze on gnome right after login?