<unmatched-paren>i'm doing #:modules ((guix utils)) so i can use %current-target-system in #:phases <nckx>alMalsamo: I agree it would be. I don't know a way to do it off-hand (but that means little). <nckx>unmatched-paren: Why do you need to call it at build time (spoiler: I think you don't)? It's not a build-time deal. ,(%current-target-system). As a general rule, importing Guix modules outside of (guix build …) won't end well. <unmatched-paren>hmm, and adding #$ in front of the (%current-target-system) doesn't work <nckx>Or #$(current-target-system) if you're using gexps. <unmatched-paren>yeah, i had to replace ungexp with unquote to get it to work (also my (arguments) was quoted, not quasiquoted, which i think caused the problem in the first place) <unmatched-paren>interesting... installing gdc apparently doesn't install the gdmd wrapper ***lukedashjr is now known as luke-jr
<batalie>what's the easiest way to just download the source of a package with guix? say, if i wanted to look at tbe source code for bash, but not build it? <batalie>pretty basic, i know, but i can't figure it out.. ***Xenguy_ is now known as Xenguy
<AwesomeAdam54321>For the Shepherd's default service actions, can a reload action that sends SIGHUP to the service be added? <AwesomeAdam54321>For example, `herd reload service` would send the SIGHUP signal to "service" if the reload action wasn't overridden in it's service definition <bdju>anyone know why that article "Guix: A most advanced operating system" seems to have disappeared? I had to use archive.org to get to it again recently <apteryx>has anyone ever debugging pulseaudio <-> alsa mapping problems? <apteryx>I have this 'Mic Boost' toggle in ALSA(mixer) that is not picked up by PulseAudio, and I don't get it. <apteryx>by picked up I really mean "exposed" <jackhill>bdju: where was that article? On the Guix website? <jackhill>hmmm, `guix gc --verify=repair,contents` doesn't seem to be sucessfully reparing files (it tries to repair the same store items on a second run). Is this likely to be a hardware problem? https://paste.debian.net/1232259/ <bdju>well, there was one on someone's blog, but I think the same article was also on the guix blog <nckx>jackhill: I'd say it's very unlikely without any (non-Guix) evidence. <jackhill>nckx: I don't think I have any non-guix evidence. I believe that I got rid of the random non-recoverable freezes when I got rid a bad/underpowered USB hub. <jackhill>I do have sway and gdm problems that I don't have on any other host, but I think that might be that I'm stetching the limits of the GPU/display driver. <jackhill>if it's not a hardwared problem, what might cause --verify=repair,contents to repeatedly try to repair the same items? I figure that once they are repaied they should stay that way, no? And what else might cause them to become damaged? <nckx>One exception would be if you've turned off checksumming for /gnu/store, but otherwise I trust btrfs more than I trust Guix to infallibly repair (not detect!) mismatches. Maybe the repairs don't even happen for some reason, who can say… <jackhill>I guess I should report it. Any additional information that you think I should gather. <nckx>I think this is worth reporting if you have time; even if someone does end up saying ‘this is actually expected’ it should be presented better. <nckx>I guess I'd be interested in comparing the contents of your ‘bad’ files to those on berlin that Guix should be downloading. <jackhill>nope, checksumming is on. I suppose memory problems could cause the bits to get flipped before the initial checksum is calculated. <nckx>Deffo don't delete them, maybe attach them if they are reasonable in size. <nckx>jackhill: The chance of that happening between btrfs saying ‘yep, everything checks out’ and Guix verifying the checksum is, ehm, ‘astronomical’ doesn't come close. <nckx>This would happen *multiple times*. <nckx>If you're being attacked by aliens with very accurate cosmic ray guns (the galactic equivalent of ‘zomg nation state’) all bets are off. <nckx>But thanks for reporting a bug! /me → 😴💤 <jackhill>goodnight. I might do that too and report tomorrow <PotentialUser-74>how do i select packages that come from a specific channel from the guix cli? for example with guix refresh -l pkg, i only want to list packages from main guix <lilyp>PotentialUser-74: you can use -e to evaluate a arbitrary expression, but other than that you're limited to version-matching <AIM[m]>Why isn't there a search bar in packages page of guix.gnu.org ? <Michal_Atlas[m]>Hello, I'm just wondering if it's just me with a niche usecase, or if some other people would benefit from the ability, to ask, for example cuirass, what package provides a certain file? <futurile>Michal_Atlas[m]: nice idea, would definitely be useful - I've used similar commands in dpkg etc - I guess there's no way to list a packages files in Guix? <Michal_Atlas[m]>It's simple if it's on your system, since every package has it's own directory, but nobody wants to download all packages to just find that one library file <unmatched-paren>where does guix install manpages relative to (assoc-ref outputs "out")? <reza[m]>Where do I find the configuration file og nginx after a guix deploy? <unmatched-paren>how can i splice outside of a quasiquote? like in janet you can do (print ;list-of-strings) to splice list-of-strings into the print <cbaines>unmatched-paren, in what language, are you asking about #guile? <unmatched-paren>i need to splice a `make-flags` variable into an `invoke "cmake"` call <cbaines>I'd suggest using the apply procedure <phf-1>sneek later tell lfaim https and firewall configurations are still missing, I will add them shortly. <phf-1>Please let me know if you find any error... it might be a bit raw : I've just published it. If it's of any use, it would be nice to integrate it to the Cookbook I guess. <opsimath>hi, I just installed guix from scratch, and I'm following the cookbook to install StumpWM, but following those steps doesn't seem to work, it says that sbcl is an unbound variable. Is there a missing step that I'm not following? <viivien>Dear guix, I take the liberty to remind you that my set of python packages still needs review and approval: 53402 <Guest67>Why is the code of conduct so inefficient? <Guest67>"In the interest of fostering an open and welcoming environment, we as <Guest67>contributors and maintainers pledge to making participation in our project and <Guest67>our community a harassment-free experience for everyone, regardless of age, body <Guest67>size, disability, ethnicity, gender identity and expression, level of experience, <Guest67>education, socio-economic status, nationality, personal appearance, race, <Guest67>religion, or sexual identity and orientation." <Guest67>should be: "In the interest of fostering an open and welcoming environment, we as <Guest67>contributors and maintainers pledge to making participation in our project and <Guest67>our community a harassment-free experience for everyone." <cbaines>Guest67, please don't paste large blocks of text <viivien>That’s the core of the paragraph though <Guest67>No, it's drivel attached to the end of the core statement. <Michal_Atlas[m]>There will once hopefully be a day, when that can be removed, but for now, it's an important part of the statement. <oriansj>Guest67: could you produce a more efficient statement while expressing the same concept? <viivien>I don’t know. To me, your short version is not very useful without defining what "everyone" means. <Guest67>why would you need to define everyone? That's utterly ridiculous. <oriansj>Guest67: why would you assume that everyone agrees on what you think the meaning of everyone is? <Guest67>because language conveys meaning, if you choose to interpret that the word everyone doesn't mean everyone then you've got bigger problems <ekaitz>Guest67: I proposed the same thing some days ago in the mailing list to avoid a discussion it was happening and they gave me a really good reason to keep this <ekaitz>Guest67: it makes people feel their problems are specifically understood by people at Guix <ekaitz>also, there's no reason to propose this in that aggressive way <Guest67>these code of conducts are a dime a dozen, seem to have crept in over the last 5 odd years <ekaitz>opinions are like asses: everyone has one <ekaitz>you have one too, that's alright, but being agressive about it is not going to make all of us change ours <viivien>As for functionality, it’s true that maintainers banned people before and continue banning people, for the same reasons, but I think it’s better to be explicit about it. <Guest67>who's being aggressive? Have you redefined that word too? <ekaitz>Guest67: that message is aggressive, the one about redefining words is too <lilyp>unmatched-paren: not really, but I can try <lilyp>Guest67: what you count as pointless blathering actually has meaning, because it is hard to qualify harassment without a few pointers <lilyp>For example, you could claim that me pinging you at all while you were doing something else counts as harassment. That'd be silly, of course, but it'd be hard to counter without getting more specific about what the project considers harassment. <unmatched-paren>this cmake'd package's build phase is failing because of some `sh -c` call having invalid shell syntax, but i've looked everywhere i can think of and i can't find any calls to sh in any cmake files <unmatched-paren>i'm looking in: $build/build/CMakeFiles/*, $build/source/cmake/*, $build/source/CMakeLists.txt <Guest67>You latch on to it because you feel like you need to, not because you actually need to. It's a strange phenomenon, I hope it goes away again. <unmatched-paren>even `rg "sh -c" /tmp/guix-build-ldc-1.28.1.drv-0` doesn't find anything <lilyp>I think you want to do a grep over the entire build directory. <lilyp>hmm, do you have a paste of the build? <unmatched-paren>so i guess cmake invokes it internally? or maybe guix is invoking it? <lilyp>if guix invokes sh, the command ought to be well-formed <unmatched-paren>i would consider the latter unlikely; this package replaces 'build with a simple call to cmake <lilyp>note that grepping "sh -c" is not enough, because it could also be written like ${SHELL} etc. in a Makefile <unmatched-paren>`gunzip -c <logfile> | wl-copy` -> goes to paste.debian.net -> pastes the build output -> 413 Request Entity Too Large <cage>Hi! Which package contains sha256sum? Coreutils? <unmatched-paren>all the shell scripts i can see are part of the test suite, which isn't the problem... <lilyp>unmatched-paren: whatever it is, it appears to be injected into the build rules <lilyp>I'm not sure whether gcc calls sh under the hood, but I would super hope not <lilyp>Other than that I suppose it'd be good to start with CMakeFiles/LDCShared.dir/gen/aa.cpp.o adn work from there <unmatched-paren>lilyp: $build/build/CMakeFiles/LDCShared.dir/gen/aa.cpp.o does not exist <lilyp>Oh, sure, but there ought to be a recipe for it, as well as CMakeFiles/LDCShared.dir/gen/aa.cpp.o.d <lilyp>I do think that GCC and Clang would be working the same way in this regard, but I'm more afraid it has to do with filtering its output or simply invoking it. <lilyp>Also try generating makefiles rather than ninjafiles and see whether it makes a difference <unmatched-paren>there's now a problem with my gdmd recipe, which should be trivial to fix <Michal_Atlas[m]>Hello, in xorg-configuration, in extra-config, I tried passing local-file to it, but it doesn't accept that, the docs say "object" so what kind of object does it accept? <lilyp>I'm fairly certain extra-config ought to be a raw string of code to inject. <Michal_Atlas[m]>It says string or object, but having a string in the config directly seems ugly <Michal_Atlas[m]>So, how do I... Is there something that's supposed to read the file and act as a string? <Michal_Atlas[m]>I'm dumb sorry, I forgot I could check the source code for what it does ***Guest8046 is now known as roptat
<lilyp>Hmm, I wonder if you could pass a gexp that returns a string. If not, then the docsting might in fact be lying. <unmatched-paren>lilyp: apparently there's a bug in cmake's ninja backend, since make works... thanks :) <unmatched-paren>i cannot be bothered to report it because i do not use cmake and probably never will <lilyp>haha, neither will I out of my own will <Michal_Atlas[m]><lilyp> "Hmm, I wonder if you could..." <- There's a comment in the config record declaration that literally calls it an "array of strings" <lilyp>hmm, so you could perhaps pass more than one stringß <unmatched-paren>"command "cmake" "--build" "." "-j" "8" "--target" "all" "ldc2-unittest" "all-test-runners" failed with status 2 <Michal_Atlas[m]>But I don't like things that don't fail at compile time 😅, was debugging something else and found this to be the issue, I know it's bad of me to presume I can substitute a string for local-file every time, but it's the case with many other places <unmatched-paren>... according to the interblag, exit code 2 means invalid usage of a built-in shell command... not again :) <lilyp>exit 2 on make could also mean recursive error <unmatched-paren>"haha, neither will i out of my own will" <- but meson has no gui!!! think of the windows users!!! <nckx>grep 'Ported build system to CMake' NEWS <Christoph[m]>OS, and ghc installed via guix can compile some programs and not others. <Christoph[m]>To be more precise, the linker complains with some imports, e. g. Control.Comonad. <gnoo>tests for package gnu pspp are failing <nckx>From what I've been told of Perl, valid Perl is a strict superset of the known universe. <Christoph[m]>It says: Linking Main: /usr/bin/ld: cannot find -lHScomonad-5.0.8-KDPzf2....QH6d <Christoph[m]>My first question is: Why does it try to use the foreign distro's ld and not one from Guix? <Christoph[m]>And of course, how can I fix the error? Are there environment variables missing? Is the file realy missing? Where is it supposed to be? <nckx>Most likely insufficient patching of our GHC package, Christoph[m]. E.g., it's execvp'ing ‘ld’ when it should invoke ‘/gnu/store/guixs-gcc/bin/ld’, not rely on $PATH. <nckx>Christoph[m]: What's you $PATH? Just in case. <unmatched-paren>aaaaaa Makefile2 has loads of lines like this: $(MAKE) $(MAKESILENT) -f CMakeFiles/LDCShared.dir/build.make CMakeFiles/LDCShared.dir/depend <unmatched-paren>and several recursive lines, as expected: $(MAKE) $(MAKESILENT) -f CMakeFiles/Makefile2 CMakeFiles/LDCShared.dir/all <Christoph[m]>nckx: Its first entries are $HOME/.guix-profile/bin and $HOME/.guix-profile/sbin. <nckx>I tried building Android again last night I'm pretty much unshockable when it comes to build systems. <nckx>Christoph[m]: I wonder what happens when you ‘guix install gcc-toolchain’ and try again. <nckx>unmatched-paren: I think I might've! Fatal flaw was trusting The Internet that a 250G virtual disc suffices to build phoneos. It doesn't, so now I have to do an infernal dance. <nckx>But it got to ~98% or so where previous attempts got to ~0%, so I'm hopeful. <nckx>Next step will be trying to build as much as possible with Julien's android patches. 🤞 <unmatched-paren>hopefully once postmarketos-on-the-pinephone-pro becomes viable as a daily driver we can all abandon that abhorrent mess <nckx>I don't know enough about GHC to know if this is the culprit, but: libraries/Cabal/Cabal/Distribution/Simple/Program/Builtin.hs:ldProgram = simpleProgram "ld" <Christoph[m]>nckx: Now ghc tries guix's ld, but the error message remains the same. <nckx>Is GHC_PACKAGE_PATH set? <Christoph[m]>Yes. And it contains $HOME/.guix-profile/lib/ghc-8.10.7/ghc-comonad-5.0.8.conf.d <nckx>I'm not of much help with that. <Christoph[m]>Well, that's a directory and contains some files, in particular one named comonad-5.0.8-KDPzf2k.....QH6d.conf. <Christoph[m]>Which is a text file containing some license info and the key and id, which are comonad-5.0.8-KDPzf2k.....QH6d <unmatched-paren>i've found the solution to my problem: add `(delete-recursively (getcwd))` to the 'build phase :) *nckx doesn't Haskell, sorry. <nckx>unmatched-paren: Not even sure if joke or. <Christoph[m]>But a file named like that itself is missing. I'm not sure how it's supposed to be. I assume there should be something containing the comonad functions in compiled form, so a binary file? <unmatched-paren>although i wouldn't be surprised at this point if it actually worked <nckx>If nobody here can help you, there's also the help-guix at gnu.org mailing list. *nckx now has A-team theme stuck in head, who they are definitely not ♪ <nckx>gnoo: Missed your message. Thanks for the report. <cage> I am trying to package a C program that uses, in the testing rule of its makefile, a local script that, in turn, call sha256sum. I have listed coreutils as native dependency but the testing phase fails anyway because sha256sum can not be found, any idea? <nckx>PATH must not be used or set correctly whilst testing. I'd patch the Makefile to echo $PATH before invoking sha256sum first, to see what's going on. <nckx>Make sure it's not trying to run /usr/bin/sha256sum or something silly like that. <cage>nckx: thanks, i'am going to try! <nckx>If you're stumped, paste the full package expression (with module imports if possible) to the -bin in the channel topic. <unmatched-paren>... i just realized that there's a comment in the ldc recipe explaining that using make fails :) <lilyp>you get a build fail, you get a build fail, everyone gets a build fail <lilyp>I do think the ninja fail might be guix-specific tho, so if you can get an MWE working someone smart enough to patch cmake can do the rest <unmatched-paren>digging through a single ninjafile is better than digging through a pile of recursive makefiles tho <lilyp>well, in this case "minimum breaking example", but yeah <unmatched-paren>btw, i think you should 's/smart enough/brave enough/' on that message :) <lilyp>Well, I am smart enough to avoid cmake like the plague, but I have the vague feeling CMake elitists would rather be associated with wisdom than cryptocoins. <nckx>CMake being part of an elaborate proof-of-work scheme is believable. <singpolyma>If I use `guix system vm` and then run `guix archive -r /gnu/store/.../vmscript.sh` am I likely to get everything needed to run the VM on another system? <unmatched-paren>building with llvm11 doesn't work, i'll try rolling back the version to 1.27 <gnoo>nckx: thanks! i'll try it tommorow <nckx>CMake / CMake run / keep watching / any day now / it's almost done. <unmatched-paren>i guess i could live with ldc 1.27.1, because what i'm _trying_ to do is remove the bootstrap chain by using GDC instead of a really old version of LDC. <lilyp>which is not a shell built-in <nckx>(Add it to native-inputs.) <nckx>You can also remove the ‘#t’, its use is obsolete. <cage>nckx: yes, this would be the next phase :) <unmatched-paren>apparently, the version is not the problem. the same thing happens when i try 1.27.1... <cage>also seems i need "ps" :-) <lilyp>with makefiles or with ninja files? <unmatched-paren>which is really weird, because the version of ldc that already exists in guix is 1.27.1 <cage>check phase passed! Thanks to you all! <ekaitz>lilyp: wow! surprisingly similar timings! <pkill9>my sqlitebrowser bug report was closed just 1 day out from being 3 years exactly <lilyp>admittedly, those numbers are somewhat old, but still <Dynom>Hi Guix, I'm building my first configs and I'm wondering if there is a place where I can find package specific configuration? Like Alacritty has configuration which can be set from Guix, but I cannot find any documentation about this. <sneek>Dynom, GNUtoo says: Hi, you worked on packaging rpi-open-firmware, and days ago a GPLv2 license was added to the new design (https://github.com/librerpi/lk-overlay) which has a much better status (composite video works on most devices for instance). <lilyp>Dynom: in general, guix home is the place to look at if you're asking for stuff that you'd normally put into $HOME/.something <lilyp>At the moment, it might appear a little bare-bones and will not have a configuration for every application out there <Dynom>lilyp: Yeah, I was wondering where that came from. <lilyp>The alacritty thing was a peak into the future by Andrew Tropin during FOSDEM , who is the main contributor of guix home features to Guix. It is not yet in Guix and I don't know whether it's in his own channel. <lilyp>nckx: fuzzy matching, I suppose <Dynom>Sorry, meant to reply to nckx, my bad. <Dynom>But thank you lilyp for the clarification <nckx>That match is fuzzier than your grandmother's undies. <lilyp>That went from 0 to dark quickly. <nckx>If they're dark, you need to buy the fancy detergent. <nckx>But, uh, yeah, I don't know where that came from, I write things sometimes. <nckx>‘I write things sometimes.’ — nckx, 2022 <lilyp>Writing things is barbaric, we should limit ourselves to words 😜️ <nckx>+1 Internet point for the emojo. <PotentialUser-50>How does guix decide to look in ~/.config for files? I'm trying to package keyd which normally looks for config files in /etc/keyd. I cant specify CONFIG_DIR=$(HOME)/.config in the package definition because that sends it to the homeless shelter <lilyp>PotentialUser-50: you don't. You put the necessary files somewhere into the build container <PotentialUser-50>Ok, stupid question maybe but the build container is what goes in the store? <nckx>PotentialUser-50: Only the part unders #$output (and any other #$output:ones), which even in the build container is /gnu/store/xxx-foo-1, not / <nckx>If you try to create /etc in the container I'm pretty sure that will fail, but you can create (string-append #$output "/etc"). <nckx>That raises other questions, like ‘but do you *actually* want foo to look for its configuration file in the store at run time?’ but the above is a start. <PotentialUser-50>it's a keyremapping daemon where you define the configs. I'm not sure they need to be in the store which is why I was trying to put them in ~/.config or somewhere user accessible? <nckx>~/.config is the most reasonable, but that's normally something upstream configures, not you when building. You can't --sysconfdir=/home/bob/.config, you need code to construct it. <nckx>Otherwise the built package will look for /home/bob on *any* machine. <nckx>If the package doesn't support resolving $HOME/.config already, CONFIG_DIR=/etc (or omitting it if that's the default) is the most reasonable. <nckx>Problem is many packages use CONFIG_DIR, --sysconfdir=, and similar options to configure *two* only tangentially related things: (1) where to look for the configuration at run time, (2) where to install the example/template file during the build. For (1) you might want /etc, but you don't want that for (2) because it will break. <nckx>Perhaps it's possible to configure/build with the default CONFIG_DIR=/etc/keyd and run ‘make install CONFIG_DIR=$output/etc/keyd’ to get both. <nckx>But this is getting into specifics ☺ <Kolev>Do I do 'guix pull' if my newly-installed Guix does not have Guix Home or Guix Shell?