IRC channel logs


back to list of logs

<frog>mekeor[m]: i hacked this together with undocumented functions. i don't know if it's the right way to do it. (hash-map->list values (module-obarray (module-public-interface (resolve-module '(gnu packages libusb)))))
<mekeor[m]>frog: that's pretty awesome. thank you very much :)
<frog>it should actually be "list" or "cons" instead of "values".
<mekeor[m]>agreed. i like "list" most. and then, the actual <package> objects are still inside each element of the list, it seems.
<mirai>nckx: I decided to gun through the last mile and figured out the lua-ffi thing
<mirai>its just something that applies to luajit
<Kolev>Having trouble running Dino. Library not found. I even tried `guix shell dino -- dino`.
<mekeor[m]>Kolev: "Library not found" is all it reports?
<Kolev>mekeor[m] it says `Couldn't open cannot open shared object file: No such file or directory`
<mekeor[m]>Kolev: did you see bug#59364? you might want to try `export LIBGL_ALWAYS_SOFTWARE=1` or so. good luck!
<Kolev>mekeor[m] I did not see that bug. That variable makes Dino work! :D
<mekeor[m]>whoohoo :D
<takev[m]>I am trying to work with a package (guile-torrent), and when I go to build I see that the git repo it used as a source is no longer up. Does not seem to be in the software heritage foundation either. I think I found a mirror (, but I am unsure if it is actually a mirror or not due to the tags not being in the mirror. Is there a way to find out if they are the same so the URL can be
<takev[m]>updated? And if not, and the package is lost, should I submit a patch to remove it?
<mirai>takev[m]: guix build --source guile-torrent
<mirai>ah, should have read further
<mirai>well, not only the upstream is gone for that package, the author's email is also poof
<takev[m]>mirai: Ooh. I did not know about that argument. I am going to remember that for the future.
<mirai>so barring bitrot (which is going to happen at some point in Time), its safe to keep it around
<mirai>right now it lives at software heritage
<takev[m]>It does? I cannot find it there.
<takev[m]>Oh! Excellent. I was searching for "guile-torrent". Whoops.
<takev[m]>Thank you. :)
<mirai>iirc guile-torrent isn't used by anything
<mirai>are you packaging something that depends on it?
<takev[m]>Yeah. I am playing around with implementing an nREPL sever for guile, which requires bencode encoding/decoding, and as far as I can tell that library is the only thing that provides those operations.
<oriansj>anyone yet package up:
<mirai>apteryx: The GDM mystery deepens
<mirai>I just did a reconfigure and I'm getting the big black screen as well
<mirai>for the record VNC is somewhat working behind the scenes
<mirai>nc localhost 5910 (because its being SSH forwarded)
<mirai>shows 'RFB 003.008' which seems to be some VNC mumbo jumbo
<mirai>now why this isn't happening with the test suites I have no idea
<mirai>system test** I mean
<mirai>it works in the system tests, you can try to grab a screendump and confirm it yourself
<mirai>if you login first physically (i.e. without VNC), when you reconnect again in the VNC client it now works??
<mirai>I did a guix home reconfigure in between since emacs was complaining about funky GDK pixbuf loaders and other things
<mirai>nope, seems unrelated. Did a reboot and am back at a black VNC screen
<mirai>looks like it you have to physically login first before VNC will properly work
<mirai>figured it out a workaround: set (wayland? #f) in GDM
<juliana[m]>In a scenario in which two packages in the different channels have the same name, what happens when attempting to install or search for that package?
<juliana[m]>so if you have a package called "example" in a the main Guix channel, and then another package called "example" in another channel, with the same object and package name (hey share the prelude (define-public example (package (name "example") ...))), what is the result of running guix package -i example?
<juliana[m]>hold on i gotta test this huh
<juliana[m]>it seems attempting to pull during this situation throws an error
<ChocolettePalett>Don't channels have priorities? I assume the first channel from the list will be sourced for a package
<ChocolettePalett>Or maybe not... I can't find a proof. Though you can e.g. specify channel for "guix pull"
<juliana[m]>i realized my initial test failed for an unrelated reason (turns out you need all the necessary modules to be important what a silly mistake) so i am retrying
<juliana[m]>yes okay the channels do have priorities, this was my initial assumption
<juliana[m]>you cannot specify a specific channel for guix package, nor are you provided a choice when there is a channel conflict. nor, from my understanding, is there any way to specify a channel as there is to specify versions and outputs
<juliana[m]>idk if there are any compelling use cases for it, but a switch to specify channels might be a good idea, jic. this is what i was thinking about that initially led me to this question
<juliana[m]>is there any way to access the configure-flags list inside a g-expression without using (lambda* (#:key configure-flags #:allow-other-keys) ... )?
<mirai>juliana[m]: I don't think so, it's ok to use configure-flags within the lambda
<mirai>what can be omitted/substituted with the ungexp equivalents are out and %build-inputs (I think inputs as well)
<mirai>(assoc out …) becomes #$output, (%build-)inputs becomes (this-package-inputs …)
<ulfvonbelow>is the "gc-roots, initial" test of tests/store-roots.scm failing for anyone else? I get an error in delete-file-recursively complaining about it (that is, (string-append %state-directory "/profiles")) not existing in the first place.
<nckx>juliana[m]: -e '((my channel packages) foo)'
<jpoiret>nckx: you mean -e '(@ (my channel packages) foo)', right?
<nckx>ACTION yawns, looks at empty coffe cupboard.
<nckx>'Maybe' :-)
<jpoiret>oho, the Inria page on free software includes a link to Guix :)
<ChocolettePalett>This is very cool, imo, GNU/Guix is getting more and more popular — even I switched to it — and that's excellent
<bobbma_>Hi! I have a problem with connecting to libvirt. I got an error: "libvirt.libvirtError: internal error: Unable to get system bus connection: Could not connect: No such file or directory". I'm in libvirt and kvm groups and I added this: "(service libvirt-service-type (libvirt-configuration (unix-sock-group "libvirt")))" to my config.scm.
<bobbma_>When i open virt-manager with sudo it connects to libvirt without problems.
<jpoiret>bobbma_: what if you restart the libvirt service?
<jpoiret>currently libvirt is missing a requirement on dbus-system, I need to push that fix
<bobbma_>I restarted it and it start working, Thanks :)
<Martin[m]>Hello how to ssh using password to a fresh guix OS ?
<Martin[m]>I've added (service openssh-service-type) to my config.scm but secure log blames that "Failed password for invalid user..."
<ulfvonbelow>I assume you've set the password for the user in question using 'passwd', and the account isn't locked?
<ulfvonbelow>And I assume that the user in question is present in your config.scm
<Martin[m]>Yes at least gnome us working well for that user
<ulfvonbelow>and of course I assume you've tried running 'ssh <user>@localhost', entering the password 3 times, and it failed each time?
<Martin[m]>ok I've found the problem... I'm using the latest guix iso and during installation for some strange reason it mixed up my username with 'real name'
<Martin[m]>my /etc/passwd looks lile: 'username:x:1000:998:REALNAME:/home/REALNAME:/gnu/store/m6c5hgqg569mbcjjbp8l8m7q82ascpdl-bash-5.1.16/bin/bash'
<Martin[m]>so it works with ssh REALNAME@guixOS :P
<Martin[m]>no sorry with REALNME@guixOS it fails and works with username@guixOS
<Martin[m]>It's also confusing because usually I'm working with /home/username not /home/REALNAME
<nckx>But 'username:x:...'? Strange.
<oriansj>Martin[m]: did you remember to set your password in your guix configuration or manually set it up after prior to trying to ssh into your target system (or add an ssh public key)
<rekado>jlicht: I found the cause of the npm bug
<rekado>it’s hardlinks
<rekado>npm installs dependencies to node_modules by creating a tar stream from the source directory with node-tar and unpacking it again in node_modules
<rekado>node-tar creates “File” entries for regular files and “Link” entries when a file has hardlinks or is a symlink.
<rekado>npm uses pacote to call the tar extractor with a filter that ignores any “Link” entries
<rekado>and so it happens that on my laptop npm installs all expected files but on our cluster it ignores some files.
<rekado>the only difference is the number of hardlinks on the files in question.
<rekado>the decision is made here:
<rekado>and the fatal filtering happens here:
<ChocolettePalett>That's good
<pjals>why is it good
<rekado>I think we should patch pacote’s fetcher.js to remove the Link filter.
<podiki[m]>ACTION commences trying to update the rocm packages...
<razlix77[m]>hello how do I set this?
<razlix77[m]>(log ("some/file" debug)) fails
<razlix77[m]>it says symbols in the docs
<razlix77[m]>(log ('syslog 'debug)) also fails
<janneke>razlix77[m]: the docs say: (log '("some/file" debug))
<razlix77[m]>well yeah
<janneke>ah no...
<razlix77[m]>Wrong type to apply: "/var/log/nslcd"
<janneke>it seems that quote is missing from the doc, hmm
<razlix77[m]>hit a wall here
<janneke>but anyway, try that
<razlix77[m]>(log '("some/file" debug) ?
<razlix77[m]>yup that works
<janneke>you cannot apply a string
<razlix77[m]>thanks for the help still learning lisp
<janneke>the docs could (should?) be clearer here, i guess
<jlicht>rekado: that's some good debuggin'. Wouldn't that patch make sense to upstream too?
<jlicht>rekado: as in, I seem to recall some pretty basic npm functionality was broken on the cluster, ignoring guix constraints
<mirai>janneke: in theory ("foo" bar) could still be valid
<mirai>if its syntax
<janneke>yeah, in another context it could be valid; but here it's not
<mirai>the documentation says list, though due to a shortcoming of of the automatic documentation generator it's missing the comma
<rekado>jlicht: I’m not sure which of these things to patch. It seems to me that pacote should not dismiss files with hardlinks. Seems wrong to treat files that have hardlinks any different from files that don’t.
<rekado>node-tar on the other hand probably isn’t wrong in treating hardlinks differently.
<mirai>well, tbh the documentation for that service is in the outdated style
<mirai>it should be regenerated (but the apostrophe issue is still unresolved)
<janneke>Mari[m]: it's a bug indeed; info has:
<janneke> Defaults to ‘'("/var/log/nslcd" info)’.
<janneke>^ mirai
<janneke>but in the html output, the tick is gone
<mirai>note that some soul manually added a tick to the lists recently
<mirai>I believe the linked manual is the 1.4.0 one
<janneke>mirai: right, the devel html manual is correct; nice
<janneke>another great argument against reading documentation in a browser
<mirai>I think the 1.4.0 manual should be made *harder* to find
<mirai>at the very least it shouldn't be the first result returned by the search engines
<janneke>that would be nice
<mirai>janneke: I beg to differ, personally I find it much more pleasant to read the HTML manual than the info one
<mirai>some colouring and formatting goes a long way
<mirai>the 'info' experience well, requires some proficiency/learning to do
<janneke>ACTION hates the browser interface, for one
<mirai>certainly more effort than the 'web browser' which consists of: move mouse, click, press Ctrl-f with keyboard, type
<janneke>not for me, i'm terrible with the mouse
<mirai>I take it you're in the proficient emacs/kb users camp? :)
<janneke>i can work with text, but am terrible with graphics
<janneke>let alone shoving a mouse pointer to a n x-y point
<janneke>of course, emacs yeah
<rekado>the info experience requires less effort for me: C-h i i whatever RET
<rekado>jlicht: I’m reporting this to pacote.
<mirai>?? I'm getting ./pre-inst-env guix build maven-settings@3.0
<mirai>guix build: error: gcry_md_hash_buffer: Function not implemented
<mirai>what gives?
<rekado>jlicht: I just need an even simpler test case…
<ChocolettePalett>You should try "Nyxt" then, according to its description
<podiki[m]>anyone know cmake? getting an error on "string ( APPEND CPACK_RPM_PACKAGE_RELEASE "%{?dist}" )" in a cmakelists.txt for package
<pjals>this is the guix irc channel
<geri>i guess guix package is implied
<podiki[m]>not sure how to disable it trying to build rpm or whatever those are for
<podiki[m]>yes, I'm aware, this is for a guix package
<podiki[m]> trying to update the rocm packages
<geri>i don't really know cmake but looks like it's trying to concatenate CPACK_RPM_PACKAGE_RELEASE env var's value with whatever ${?dist} is and fails
<geri>hardest part is going to be finding what brackets do
<geri>well, its for variable interpolation, just ? left :D
<hwpplayer1>podiki[m]: Are you interested in high performance computing ? If so do you like to share your experience with our community ?
<hwpplayer1>maybe you can write a blog post somewhere podiki[m]
<geri>i just learned debian patches bash to source /etc/bash.bashrc automatically
<geri>guix team only applies patches for programs to function, nothing more, right?
<hwpplayer1>patches like what ?
<geri>like custom themes and everything like that
<geri>i was wondering why /etc/bashrc wasn't sourced, and that's because by default bash doesnt seem to care about the file
<geri>or at least our version doesn't, i haven't checked upstream
<jpoiret>geri: yes, /etc/bashrc isn't sourced per bash's manual
<geri>there's an option in config-top.h to source /etc/bash.bashrc, but it's commented out by default
<jpoiret>but guix does patch programs beyond just making them barely function
<geri>jpoiret: cool, maybe ill be able to fix this and contribute uwu
<jpoiret>fix what?
<geri>/etc/bashrc not being sourced in interactive sessions
<geri>only when interactive login
<geri>which makes bash completion not work outside of a login shell
<geri>oh, home manager makes bash source /etc/bashrc, fun
<geri>guix home*
<jpoiret>is /etc/bashrc standard? it's not mentioned in the bash manual
<jpoiret>if you want completion for your user's interactive bash sessions, shouldn't you use ~/.bashrc?
<rekado>correction: the problem is not merely with hardlinks; it’s when a hardlinked file with the same inode is encountered more than once
<rekado>so the hardlink must be to another file in the source directory (not merely to any location)
<HerlockSholmes>Hello guix people, I'm currently trying to write a package definition for
<HerlockSholmes>rnote ( but have hit a wall in my understanding:
<HerlockSholmes>As per their building instructions it uses meson, but one of the inputs
<HerlockSholmes>should be rust-cargo as it requires it for the configure phase.
<HerlockSholmes>I read the manuals in this case but have shortcomings as trying to add rust-cargo
<HerlockSholmes>as an input is signaled as an unbound variable even if I add crates-io packages
<HerlockSholmes>to the modules used.
<HerlockSholmes>If anyone wants to see what I've tried, the package definition in progress can be found in
<HerlockSholmes>Sorry, didn't mean to sent in that way.
<John66>Hi im sorry this question might be really stupid but I'm pretty new to guix and i was wondering if there was a way to define additional profile withing the system configuration file
<geri>jpoiret: rewriting your configs to check /etc/bash_completion on one distro, /usr/share/bash-completion/bash_completion on another and /run/current-system/profile/etc/profile.d/ on yet another one is a pain
<geri>actually it seems debian team has commented out completion code in system's bashrc, huh
<geri>wonder why
<geri>and bashrc in /etc/skel says it's enabled in the /etc/bash.bashrc XD
<nckx>HerlockSholmes: It's OK ☺ You can check <> to see if everything you wanted to say arrived.
<HerlockSholmes>John66 when defining your users you can cons more than one if that's what you're asking for
<HerlockSholmes>Thanks nckx it is complete
<John66>HerlockSholmes I was wondering if i could declare what packages i wanted installed in the user profile
<jpoiret>John66: not in the system configuration, no
<rekado>jlicht: my bug report is here:
<mirai>*sigh* I'm getting the impression that packaging anything java related is going to be highly non-trivial
<geri>that's what i've heard too
<geri>that said i still can't bump the version for libnotify, haha
<jpoiret>mirai: you know the serializing stuff, right?
<jpoiret>making complains with "gnu/home/services/ssh.scm:206:0: warning: possibly unbound variable `serialize-match-criteria'"
<mirai>jpoiret: somewhat
<mirai>let me see
<mirai>I think I have an idea what's happening
<mirai>preamble, IMO this is due to a few antipatterns converging at once; namely fusing define-configuration with plain old define-record-type*
<mirai>since the “main” configuration <home-openssh-configuration> is using define-record-type*, its not able to profit from serialize-configuration procedure and is manually synthesizing the config file
<mirai>quick fix is to put it as (define-maybe/no-serialization match-criteria)
<mirai>better fix is some moderate refactoring to the service; the “structure” used in mpd-service-type in gnu/services/audio.scm can be more or less straightforwardly adapted to work here
<jpoiret>i see the patch is by nicolas graves, i'll ping him
<jpoiret>i don't know enough to decide what's best :)
<vagrantc>so ... if someone acks a patch, does it still require waiting a week before pushing? it seems a bit ambiguous to me in the manual
<nckx>Nah. That would be more strict than the general case.
<nckx>Does Guix+GRUB+LUKS2 work only when booting from the encrypted drive? Surely not. And yet I get the dreaded ‘no such device’ error and a(n unusable) rescue shell.
<nckx>I can't boot from the encrypted drive.
<mirai>I think there's some issues with grub and LUKS2
<mirai>(not implemented?)
<nckx>I thought that affected only Argon2.
<nckx>I'll try LUKS1.
<nckx>Actually, no, I'll try an unencrypted /boot first.
<nckx>Because what the hell.
<jpoiret>that's the solution
<jpoiret>you can't have encrypted boot with LUKS2 with Grub 2.06
<jpoiret>unless you manually invoke grub-mkimage with the proper modules
<nckx>This might want to be mentioned in the ol' manual.
<nckx>Thank you both!
<jpoiret>how do i test a patch that affects only users of cyrillic locales if I can't read them 🤔
<nckx>jpoiret: Do you happen to have the working list of modules handy? Trial & error isn't a tenable option in this case.
<nckx>Each (re)installation attempt is a lot off manual work.
<nckx>By 21st-century soyboy standards anyway.
<mirai>jpoiret: by comparing it as if it were pictures?
<mirai>or rig some OCR machination up
<jpoiret>mirai: I actually realized i have enough muscle memory of the installer to do it completely blind
<mirai>afaik as long you don't get tofu blocks it should be fine?
<jpoiret>nckx: I believe the right modules are documented there
<mirai>or the obvious bogus mojibake as seen in the screenshots <>
<jpoiret>I was hoping we could update to a new GRUB version quickly so I never got around to properly documenting the issue
<jpoiret>and the patches I sent that ended up being accepted don't apply on to of 2.06 and I don't really want to backport them
<vagrantc>nckx: i did play around with recent grub and luks2 encrypted drives ... it is very limited in which PBKDF it supports ... but did get it to work more-or-less
<vagrantc>i thought split /boot still requires manually copying the kernel, initrd, etc. out to a separate partition...
<jpoiret>no, split /boot is only for grub files
<jpoiret>grub can still access /gnu/store once it has access to the luks-related modules
<nckx>vagrantc: ‘Which’ PBKDF? What fresh hell is this?
<nckx>I just used pbkdf2.
<nckx>There are several?
<vagrantc>yeah, that one
<nckx>I've only ever heard of -2, ever.
<jpoiret>the issue right now is that the grub userland tools don't add the crypto modules to the efi binary because they don't understand LUKS2. So then GRUB can't unlock /boot, where the modules are
<vagrantc>they're also all astoundingly slow, especially if you use multiple key slots
<jpoiret>there's argon2 and friends
<nckx>I think part of my pain (and failed experiments) comes from the fact that one drive is GPT and the other (boot) drive has an MSDOS partition table. Maybe this confuses grub-install if it tries to be clever^Wefficient?
<nckx>No, I meant I've only ever heard of PBKDF version 2.
<nckx>If Argon2 is a rebranded PBKDF3 tables are going to be flipped.
<vagrantc>ACTION prepares for in-flight tables
<jpoiret>pbkdf simply means 'Password-Based Key Derivation Function', so I think argon2 can be considered "a" pbkdf
<jpoiret>although it seems kdf is more in use
<vagrantc>i at least know of pbkdf2, argon2i and argon2id
<nckx>I see. I thought pbkdf* were a specific family of KDF, but then I never knew what pb stood for.
<nckx>ACTION finds instructions on The Internet to just slap that generated image onto the BIOS boot partition. Feels… OK, fine.
<vagrantc>peanut butter, obviously
<nckx>I included both part_* modules just in case.
<nckx>vagrantc: Speed checks out.
<jpoiret>I really want to replace grub with Linux at some point
<jpoiret>grub's speed penalty to unlocking LUKS volumes just defeats the whole thing
<jpoiret>either you choose a weaker setting or you're stuck with waiting 30 seconds on boot
<nckx>I too have this want, but not the time.
<nckx>I wanted to flash it as a Coreboot payload.
<nckx>I currently use LUKS only on servers, where the delay is acceptable.
<vagrantc>even 30 seconds doesn't seem that long to me ...
<vagrantc>i did once have such a setup on a pinebook ... that was slow enough to wonder if it had crashed ... something in the ballpark of 5 minutes ... only to find you mistyped the passphrase
<nckx>‘Installation finished. No error reported.’ 🤞
<nckx>‘no such device’.
<vagrantc>no empathy, even
<mirai>the sluggish input for the passphrase can be quite infuriating
<nckx>I've got it to freeze on the lie ‘GRUB loading.’ now, but I think I'll just switch to LUKS1 😒