<mbkamble>Which package do I need to make "ldd" available on my guix system? <civodul>mbkamble: it's in gcc-toolchain (it's actually part of glibc) <mbkamble>yeah. thanks civodul. I installed glibc and got it <nikola`>What do you all think about rust in the kernel <lhp22>Same powerness of C ? With more memory management guards ? It can't be totally wrong <mekeor[m]>hello guix! i'm trying to build/run a rust project with cargo. i set RUSTC_BOOTSTRAP=1 and added 'cargo-features = ["edition2021"]' to the Cargo.toml. but 'cargo build' still fails with "feature `edition2021` is required". what's wrong? <mekeor[m]>i don't even know what that patch is waiting for... <nckx>nikola`: The language is a good idea, but I hope they eschew Cargo and other Rusty antipatterns. No directly externally-maintained libraries in the kernel, just like they do for C. <mekeor[m]>it's a pity that the packaged rustc does support rust-edition2021 but the packaged rust-cargo does not <vagrantc>mekeor[m]: infinite dependencies and no way to track them sanely? <nckx>Because of Cargo the Rust 'ecosystem' is already an unmaintainable mess in user space today, it would be a nightmare in the kernel today. Good night Guix! <nckx>*tomorrow. Me tired. Wave back & zzz! <mekeor[m]>vagrantc: why is there no way to track deps? they are listed in cargo.toml *mekeor[m] realizes how ugly cargo-build-system is, regarding #:cargo-inputs <GNUtoo>Hi, is it possible to reuse an operating-system declaration for both guix system image and guix deploy? <GNUtoo>I was thinking of spliting it in 2 files with one being a module that export the operating system with something like (define base-server-system (operating-system [...])) and the other that use base-server-system, though for some reasons that doesn't work, do I need some special quoting for that? <vagrantc>mekeor[m]: there are ways to track dependencies, there are too many to track practically <mekeor[m]>GNUtoo: maybe it's with packages where you can use (define-public custom-package (package (inherit another-package))) <GNUtoo>ok, I could also try -e to see if I can evaluate part of the file <GNUtoo>I don't really see where inherit should go though <GNUtoo>The issue is that guix system image expect an operating system while guix deploy expect a machine <mekeor[m]>GNUtoo: i'd try (define foo (operating-system …)) (define bar (operating-system (inherit foo) …)) *mekeor[m] goes bed → zZzZ <GNUtoo>I think I managed to do it with -e, I'll paste a link here when I'll have tested it <whereiseveryone_>Is there a guide that shows the particularities of using erlang with guix for development? <vagrantc>arg. the somewhat arbitrary formatting of Copyright lines in gnu guix ... while orders of magnitude better than many projects ... are tediuous to verify :/ <podiki[m]>the manual says: "The herd rules udev command, as root, returns the name of the directory containing all the active udev rules." <podiki[m]>this doesn't work for me, can anyone else try? <podiki[m]>I get: "herd: service 'udev' does not have an action 'rules'" <acrow>pokiki: Same here regarding herd rules. <podiki[m]>acrow: thanks. guess I'll report it, not sure if it is wrong in the manual or something that was removed/never implemented? <acrow>podiki: yeah, I've fiddled with it and udev just doesn't cooperate with rules. <lilyp>nckx: It's hard to evaluate. I certainly didn't pay any extra on top of the listed price and it was cheaper than the listed price for Windows, but still... <lilyp>It's also about the principle. Had I wanted the Microsoft OS, I'd have specified so. <mlan__>Hello Guix, I am a new person in this guix. <horizoninnovatio>Good afternoon Guix. I noticed wine 7.8 is now current (website) but not with "guix search wine" even after "guix pull" Am I missing something? <acrow>I think so bc ver 7.8 is current. Maybe you've run guix pull but then run the search in a shell that did not have the updated GUIX_PROFILE? <horizoninnovatio><acrow> "I think so bc ver 7.8 is current..." <- Good point. I'll check. <mlan>Dr civodul, other using Guix source, What function? <retropikzel>How can I get "javac" command? I installed openjdk but weirdly that only gives me "java" <maximed>Have a look at the 'outputs' line: 'out', 'jdk' and 'doc' <maximed>By default, you only get the 'out' output. <maximed>But if you do "guix install openjdk:jdk" instead of "guix install openjdk:out', you get the 'jdk' output. <maximed>('jdk': the compiler, 'out': whatever you need to actually run Java things) <maximed>horizoninnovatio: "guix show wine" gives 7.8 here <maximed>vagrantc: What would you like the formatting to be? <mlan>I not idea about guix source, test n errors <mlan>my question, from guix source canit be modified or just to testing system? Sorry guix I am not perfect system part of this program. <abrenon>well as with any open source software, you can tweak the source to modify your version of guix and generate whole systems with that, but you can of course redistribute your changes as patches so that the rest of the community may benefit from your improvements <mlan>thank abrenon about information.. <abrenon>does that help ? I'm not sure I get the meaning of your interrogation perfectly <abrenon>are you perhaps confused by the "source" describing a system to build and the source code of the guix package itself, allowing to alter its behaviour, the list of packages it knows, etc. <mlan_>sometimesthere is a problem, I have no idea how to continue building this OS guix <abrenon>ok, what kind of problem ? could you tell us when it occurs ? what are you concretely trying to achieve when you say "building this OS" ? are you installing from a live CD/USB onto a new machine ? <horizoninnovatio><maximed> "horizoninnovations: "guix show..." <- would there a reason why "guix pull" isn't updating to show 7.8? <maximed>horizontalinnoatio: what does 'type -P guix' say? <maximed>horizontalinnovatio: Did you run "guix pull" or "sudo guix pull"? <maximed>(~/.config/guix/current/bin/guix looks good though) <mlan__>abrenon. I try a lot to use the VM method through windows 10 <maximed>What does '~/.config/guix/current/bin/guix show wine' say? <horizoninnovatio>I was messing in "root", so type -P guix shows: /run/current-system/profile/bin/guix <maximed>horizoninnovatio: Looks like ~/.config/guix/current/bin/guix is an old Guix somehow. <maximed>Also, what's the output of '~/.config/guix/current/bin/guix describe'? <maximed>(in particular, including the guix commit) <maximed>Is ~two month old commit somehow ... <maximed>Did you pin a commit in your list of channels? <maximed>horizontinnovatio: You can copy the file $HOME/.config/guix/channels.scm (to a pasta, e.g. paste.debian.net) <maximed>horizoninnovatio: Reconfigures are orthogonal to pulling. <NaturalNumber>Oh, I finally got Guix up and running. It feels great and what a learning experience. Most of my issues ended up having nothing to do with Guix per se. I wonder if some others might be interested in some tips or if I should let them figure it out on their own. <maximed>NaturalNumber: Please share before you end up with stockholm like many old Guix contributors and don't recognise the issues for issues anymore. <horizoninnovatio><maximed> "Is ~two month old commit somehow..." <- How do I update the commit? <maximed>horizoninnovatio: You are pinning the 'guix' channel there. <maximed>horizoninnovatio: Even if you don't know how you have pinned it, it is pinned anyway. <fps>ok, i installed geiser and paredit from "the perfect setup" <fps>now i'm in my config.scm in emacs and i have started geiser.. if i have the point on "operating-system" and press M-. it tells me operating-system is not found <fps>i guess this is not the way to go about this ;) <fps>and yes, i have a guix clone and setup the paths in .emacs for geiser <fps>hmm, and even when i open gnu/system.scm and have the point on operating-system and press M-. it tells me the same thing <fps>hmm, the repl tells me i'm in the module guile-user while it really should be gnu/system i suppose? <attila_lendvai>fps, you probably need to load stuff into geiser (see the command ,m). and even if that is loaded, then config.scm is not a module, so it may still not work from there. <fps>attila_lendvai: yeah, i went to gnu/system.scm to see if i have better success there. my last comment referred to that. will check out ,m *attila_lendvai is not a geiser expert, though <fps>i'm just checking out this "perfect setup" to see if it can help me at all navigating the guix source ;) *maximed Sent an update to #53163 ‘doc: Document some reason for/agaisnst git tags/commits.’ <fps>C-u C-c C-z does a lot of things and now hangs ;) <fps>oh well, i'll kill it and return to grep for now ;) <maximed>I'd like more opinions on that (it's almost some kind of project-wide quasi-policy) <fps>ok, a different question: the config.scm is a guile-scheme file. but it is not a module. what precisely is it? <gabber>which returns an (operating-system) <rekado>I’m afraid we’ll have to revert 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 and 00056eafaefed0af8535f219760fbbe01dd6f240 <fps>gabber: ok, since the operating-system call is the last thing in the script that's what it returns? <rekado>the former commit adds r-mathjaxr, which is full of non-trivial minified JavaScript <rekado>there’s an ongoing multi-year-long struggle to build it from source <rekado>this is something the R team could have prevented <fps>gabber: and it's executed in a context set up by the guix system command such that it finds the modules it needs.. <fps>ok, wrapping a (display ...) around the operating-system call and running it in guile actually outputs something <maximed>rekado: I'll send a message to 56282@debbugs.gnu <gabber>fps `env | grep GUI` should show all the relevant env vars <civodul>rekado: i guess we'll need to notify whoever applied the patch *civodul is kinda under water <maximed>for r-mathjaxr, to 56282@debbugs.gnu.org. <rekado>I can’t revert the commits because gnu/system/image.scm is currently broken <rekado>error: validate-configuration: unbound variable <civodul>like "rm gnu/system/image.go && make" <civodul>(that has to do with changes i recently pushed in define-configuration) <maximed>Also, WDYT of giving records a (mostly) stable ABI (with some syntactic support in define-record-type*)? <maximed>I had some unimplemented ideas in that direction. <rekado>yes, probably a problem on my end <maximed>(FWIW, such a thing is already done for the <origin> record) <civodul>maximed: stable ABI would mean no inlining, and i'm not sure it's a good idea <maximed>civodul: Maybe not in the general case, but for (gnu system ...)? <civodul>define-record-type* has ABI-incompatibility detection though <maximed>Does (gnu system ...) benefit from inlining in those records? <rekado>maximed: I’m a bit annoyed that I couldn’t find r-mathjaxr with the search on issues.guix.gnu.org <civodul>actually, i think we should rebase define-record-type* on raw records/structs, so we can have inheritance too <rekado>I suppose you found it with a local email search? <maximed>civodul: Maybe: enable by default, disable for <package>, <bag>, ...? *rekado thinks we need a productive mumi hackathon <maximed>civodul: I also sent comment to: ‘doc: Document some reasons for/against git tags/commits.’ <maximed>(I think I understand your point about reference/guideline better now) <maximed>civodul: Inheritance is supported by RnRS records, no raw records needed? <maximed>(Unless RnRS records are non-Guile 2.0)? <maximed>There's a bunch of ruby security fixes on guix-patches <maximed>Someone needs to actually build-test the @2.7 update but otherwise should be fine (diff doesn't look malicious when scrolling through, hashes match with the ruby-lang.org news entry) <maximed>something equivalent to (condition? (make-condition)) -> #false <attila_lendvai_>i wonder if this is due to user code, or due to some change in guile: "gnu/services/mail.scm:431:0: warning: shadows previous definition of `%namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0" <attila_lendvai_>and why it's not showing up at all the other uses of define-configuration ***attila_lendvai_ is now known as attila_lendvai
<attila_lendvai>and i'm still seeing regularly this: "substitute: In procedure write_wait_fd: unimplemented" <fps>btw: the installer produced a config.scm that guix system warns about. like using target instead of targets, etc.. <fps>is there a way to produce a nop-derivation for places where a derivation is expected? <fps>and the same question for a package.. <maximed>I think you have mentioned it previously, but is there a bug report yet? <maximed>(with backtraces, which command is run, etc.) <attila_lendvai>maximed, i haven't created one, because i thought i'm not the only one seeing it. maybe it depends on the network config on my side that occasionally causes the send buffer to get full. e.g. i have QoS set up on my router, because without it the ping goes through the roof (vodafone landline in hungary) *attila_lendvai goes on to report the issue <maximed>attila_lendvai: You aren't the only one seeing it (I have encountered it myself I think, some time in the past). <maximed>However, dozens of tiny reports scattered through comments #guix and guix-devel etc are a mess to work with. <maximed>So I recommend a single, centralised location, to have the backtraces, speculation, etc, with a nice searchable subject line. <maximed>Also, ruby@3.0.4 is reviewed except for actual build-testing. <davidl>Im repeatedly getting the following error when building from master: <davidl>ice-9/eval.scm:293:34: error: copy-build-system: unbound variable <davidl>hint: Did you forget `(use-modules (guix build-system copy))'? <davidl>sorry: I found the error immediately after posting. <maximed>It isn't reflected in debbugs either. <maximed>oops I sent it to 56006 instead of 56005 previously <maximed>it's corrected now, hopefully that will help future debugging <fps>ok, interesting: if i put (kernel hello) in my config.scm guix system image doesn't complain about it ;) <maximed>attila_lendvai: I've found why the backtrace is obscured. <maximed>catch / #:unwind? #true strikes again. <maximed>If that's changed, hopefully the backtrace will contain something useful! <attila_lendvai>maximed, do you have the commit bit to change the #:unwind #true? or who should do what otherwise? <silicius[m]>I want to set an env variable before the check phase in python-build-system. wrap-program didn't work because the wrapped file is run by directly invkoing the interpreter (python) <silicius[m]>Oh, I guess just setenv worked. I wrongly assumed build phases are somewhat distjointed <ncbfg36>I'm installing Guix on a system with libreboot using grub as a payload. Does the graphical installer, when choosing to encrypt a partition, use luks1 or luks2 by default? <maximed>Also, converting from catch (which doesn't support #:unwind?) to with-exception-handler seems non-trivial to me -- <maximed>catch/throw uses ‘old-style exceptions’ whereas with-exception-handler uses RnRS/SRFI conditions. <maximed>(there's some automatic conversion between the two) <maximed>It shouldn't be too difficult but it's not ‘simply add #:unwind? #false’ either. <maximed>attila_lendvai: FWIW, this is in a part of the daemon, and you can hack on the daemon locally <maximed>(./configure --localstatedir=/var && make etc, stop the daemon, start it from sudo ./pre-inst-env guix-daemon --the-right-arguments-...) <maximed>not sure about sudo before or after ./pre-inst-env <rekado>civodul: congratulations! Good to see a new paper. <rekado>topics include OS, administration, development — all topics that match Guix. <civodul>rekado: isn't the CfP over? (June 12) <attila_lendvai>maximed, i have this in my notes: sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild <silicius[m]>libmpv patch is almost ready but the check phase doesn't want to end at all, it just stops giving any output after one of the tests <maximed>In case anyone likes running signal-condition! after the run-fibers instead of inside the fiber, and in case people like to start fibers in run-fibers, waiting on a condition but never succeeding (because it is only signalled after run-fibers returns and all fibers were abruptly stopped) <civodul>maximed: how did you hit that problem? <maximed>civodul: My test suite for gnunet-scheme (scheme-gnunet?) does exactly that. <wingo>maximed: i added you to the repo fwiw, plz get review from someone before merging anything :) <maximed>gnunet-scheme is based on Guile-fibers, so the test suite often does (run-fibers ETC), and it's a bit lazy so it doesn't make sure all fibers stop before exiting the run-fibers. <maximed>(wingo: Used by gnunet-scheme, where it seems to work nicely) <silicius[m]>I meant python-mpv eariler instead of libmpv (this one is already included with mpv). running the tests by hand has the same effect, it stops doing anything at test_wait_for_prooperty_event_overflow *attila_lendvai is itchy to send a patch that disables the demand of define-configuration for a docstring <efraim>I don't know what it is with SBCL but it never builds for me on aarch64-linux <podiki[m]>before I file a bug, is there anything known about the "herd rules udev" command mentioned in the manual? doesn't work for me (service 'udev' does not have an action 'rules') <GNUtoo>btw, is it possible for a given package to run a phase multiple times? *GNUtoo would like to run the build phase for android-ndk-build multiple times, once with LOCAL_MODULE=foo and another time with LOCAL_MODULE=bar <GNUtoo>or should I teach the android-ndk-build to do that instead? <efraim>GNUtoo: yes, I have a couple of examples <efraim>the key for searching is likely '((assoc-ref %standard-phases' <efraim>x265 isn't as fancy but it gets the job done <GNUtoo>Thanks a lot, I'll try to do something like with keybase <GNUtoo>Basically I need to run the build phase several times for different modules, so it's a bit similar, but in my case what changes is just the extra make arguments <efraim>I have a bunch of more examples similar to keybase in the golang module <efraim>I think there are more examples using the linux-module-build-system or whatever its called <silicius[m]>I don't really know what might be happening here. So If anyone can confirm it's not just my setup acting up <GNUtoo>silicius[m]: it hangs in python-mpv tests? <efraim>See if you need to patch references to xorg in python-xvfbwrapper <silicius[m]>GNUtoo: Yes, exactly at the test_wait_for_property_event_overflow test. But earlier tests run just fine <GNUtoo>test_wait_for_property_shutdown looks almost identical, and I'm not sure what things like "with self.assertRaises(mpv.EventOverflowError): " really do <GNUtoo>so I've no idea here, beside trying to understand better the issue and try to understand if it's really hang or if it's just super slow <silicius[m]>I had my friend run it on another distro and it's not slow there <silicius[m]>I tried running xvfb like in python-pytest-xvfb but it didn't change anything <jpoiret>SAIHAZE[m]: doubtful, since it uses electron <silicius[m]>the python-xvfbwrapper certainly works in python repl so I think no patching is needed there <efraim>perhaps you need to set something with DISPLAY to tell it that it is offscreen <lfam>I'm curious if any Guix-izens have begun planning for "Rust in the kernel"? <unmatched-paren>lfam: I've seen a small amount of chat about it, but not any concrete plans, at least as far as i know <lfam>That's my impression as well, but I have been absent for the last few months <lfam>I'm hoping it won't be too much of a challenge for the community <nerthus>it wont be anything significant until the GCC frontend is done is my belief atm anyway <nerthus>they said a while back it will be restricted to newer modules/drivers for the time being, tho they may have changed that stance <lfam>It could be that the Linux team will stick with GCC, but who knows <lfam>Anyways, I hope that some volunteers will start to plan for this. I won't be able to participate <efraim>I tried to build gccrs by inheriting from gcc-12 but wasn't successful ***aeka` is now known as aeka
<unmatched-paren>efraim: I believe they're talking about rust_codegen_gcc (something like that...) which is a GCC backend for the _existing_ Rust compiler ***lilyp_ is now known as lilyp
<nckx>It got stuck in a lift on its way to your inbox & I was working late. ***cnx_ is now known as cnx
<podiki[m]>sneek: later ask jts I saw in the logs you mentioned packaging haxe? I was also giving it a shot, curious if you got it working <silicius[m]>I managed to disable that neverending test and almost all of them passed. test_read and test_write failed while trying to access homeless-shelter <unmatched-paren>silicius[m]: /homeless-shelter is what $HOME is set to in the guix environment <silicius[m]>(setenv "HOME" "/tmp") worked and now "all" tests pass. <unmatched-paren>silicius[m]: I *think* (!) (setenv "HOME" (getcwd)) might be a better choice <unmatched-paren>That would break isolation. But I still think cwd might be better for $REASONS. <unmatched-paren>Looks like both are used in various places throughout the source code, /tmp is fine, ignore me. <jpoiret>nckx: oh, i didn't realize that debbugs was in front of the ML moderation <nckx>Both work, but it's a 'correctness' issue. /tmp is a hard-coded name, even though it will almost certainly work $forever, getcwd avoids that and hence is nicer. That is all. <nckx>jpoiret: Hush, don't advertise it :) <nckx>It is the megasuck, yes. <nckx>unmatched-paren: I'm 99% sure it's cargo-culted, so once /tmp pulled ahead it only reinforced that loop. <silicius[m]>Can I submit python-mpv with one test disabled if I write a comment explaining that test never ends? <nckx>I was about to ask: do you know what it's doing then? <nckx>But yes, silicius[m], you can! <nckx>My cargo-culted was a bit too strong, lots of things are coded by example in Guix, and it's fine, but hence important not to tolerate too many ugly things. You'll come back in a year and they'll have magically reproduced. <nckx>There are many way to do nothing :) <silicius[m]>nckx: It plays the test video, sets a trap that tests mpv.eventOverflowError exception is raised in its block (the first with block). In there it waits for 0.001 and then sends a command to mpv 10k times. It appears to be nullyfying all errors in the most-inner block though <silicius[m]>Now that I took a closer look, maybe changing the amount of sent command get me at least a failed test <nckx>Fixing the test would be ideal, but it's not a blocker if disabled selectively with a clear comment. <silicius[m]>changing it to one didn't change much. So the problem is in the command_async command <unmatched-paren>sorry for the slightly-offtopic question, but is there some -config tool for libintl to locate its headers, libdir, et cetera? doesn't seem to have a pkg-config file ***mark_ is now known as mjw
<unmatched-paren>Hmm, looks like it literally expects you to use autoconf, which I will do when hell freezes over. <civodul>the winner receives a beverage of their choice at the ten-years-of-Guix meeting in Paris <nckx>'Metered connection users: Be aware that the instructions in this article download quite a bit of data from the internet.' WDYM 'translate'. <nckx>civodul: I thoroughly enjoyed your supply chain PDF. <vagrantc>civodul: yeah, that PDF was a nice read ... not much i didn't already know, but ... nice to see it all put together in one very well worded document :) <vagrantc>i feel compelled to read one-off licenses roughly in the same way i feel compelled when someone says "wow, that smells really awful! smell this ..." ... and i just do not resist <nckx>Restrictions on fork names *might* be an issue (I don't actually know) and 'requested' is always a facepalm when amateurs cosplay as licence authors. It might not be free. It's definitely going to be a pain. <nckx>vagrantc: Graphic... and relatable. <unmatched-paren>nckx: isn't a restriction on fork names basically the same as a trademark like with Firefox? <nckx>All names are trademarked. But I do see your point, it occurred to me as well. <jackhill>gnuplot requires modificates to be distributed only as patch files… <vagrantc>that workman license ... seems to lack *clear* permission to redistribute modifications <vagrantc>i vaguely recall the workman license coming up somewhere with a more ... thorough analysis <nckx>I read it again. It's a very bad 'licence' (not deserving of the name). <nckx>I'm surprised there is no issue on the repo. Do you remember whereish, vagrantc (debian-legal would be ideal, if probably fatal). <nckx>I found a bug report adding it to xkeyboard-config, implying it's already 'in Guix'? <nckx>What are you actually packaging, ulfvonbelow? <mbkamble>Hi. After installing emacs-geiser and emacs-geiser-guile packages, the info for Geiser is missing. Is the package definition for emacs-geiser incomplete? <ulfvonbelow>well, at some point I got the impression that I should be looking for keyboard layouts in /run/current-system/profile/share/keymaps, and I didn't see anything about workman in or below that subidrectory, so I was gonna try adding the linux_console subdirectory of https://github.com/workman-layout/Workman as a package similar to kbd-neo <ulfvonbelow>according to the manual there are three different places keyboard layouts can be specified: bootloader, console, and xorg. Do those all use the same file formats and look in the same places? <nckx>(In case it's not clear, my main concern is if & how you can claim & licence a keyboard layout to begin with, although I know Dvorak tried. The 'official Workman repo' might be non-free, but maybe the raw data as distributed in xk-c can't be.) <singpolyma>IANAL but no way is a keyboard layout copyrightable :P <nckx>How did you look? Keymaps aren't distributed as <name>.xkb or anything like that. It is much different. <nckx>And yes, everything is generated from XKB layouts. GRUB, Linux, ... it all just works, even with xkb modifiers where possible. It's really very im.ressive. <ulfvonbelow>find -L /run/current-system/profile/share/keymaps -iname '*work*' is what I tried <nckx>You don't need different formats of each layout packoged. <nckx>ulfvonbelow: No, it doesn't work like that. <nckx>Just look up the xkb name for workman (total guess: "us" "workman") and define a koyboard-layout from that. Use that in all o-s fields with a keyboard-layout field. Done. <nckx>Packaging layouts should not be a thing. <nckx>Apologies for the typos. I use Dvorak, clearly inferior. <vagrantc>speaking of which ... my latest packaging of guix for debian revealed a few more ... <nckx>mbkamble: I'm looking right at geiser.info.gz, it's in emacs-geiser. <nckx>Opens with info -f, at least (I don't have geiser installed). <nckx>guix shell --pure info-reader emacs-geiser -- info geiser also works. <nckx>I think you might not have installed what/where you think you do. <nckx>...or! Something has broken very recently; also possible. <civodul>didn't know about this channel, that's interesting <mbkamble>If a given package (say emacs-geiser) is available in multiple channels (eg. guix and third-party channel), is there any command option to show which channel it uses to fetch/install the package? <nckx>mbkamble: Asking 'Is the package definition for emacs-geiser incomplete?' is rather meaningless then. How could we know. <nckx>mbkamble: The Guix CLI will pick the one witt the highest version, here the custom channel one. Also: guix show PACKAGE <nckx>We're never actively hostile. <vagrantc>one person's welcoming is another person's ... hostile? <mbkamble>I am not knowledgeable enough with the build system, so I posted the open ended question about incompleteness. <mbkamble>But atleast, now I can try installing the one from emacs.xyz.scm and see if it contains the info files. <nckx>mbkamble: location: emacs/packages/melpa-generated <nckx> Vs. Guix's gnu/packages/emacs-xyz <nckx>(Too) subtle but know you know. 