IRC channel logs


back to list of logs

<pashencija[m]>> <> I am trying to pack my program that uses networkmanager-qt... (full message at
<pashencija[m]>Had hard time getting it to work because it could not resolve localhost (no binding to in /etc/hosts)
<pashencija[m]>Oh, previous message was sent to the wrong chat. Sorry
<acrow> pashencija[m]: You could modify your config.scm to add that binding in /etc/hosts...
<pashencija[m]>It was on arch. I meant to send it about another problem to another chat. It's night here
<antipode>sneek: later tell mala: I don't know if you can do that in the REPL, but in Guile programs, you can use 'continuable exceptions' to do things like that (try raise-continuable+with-exception-handler), and remember to _not_ use catch which doesn't preserve continuability)
<sneek>Got it.
<lilyp>Using debian to nuke Guix is somewhat ironic, given that it's usually the other way round.
<lilyp>pashencija[m]: do you have a vague idea what kf5 might be looking for?
<lilyp>I suppose it's something from the kde suite rather than pure qt
<lilyp>ahh, yes, kdeframeworks
<shcv[m]>is there a way to have `guix shell` start a different shell? I think my zsh configs are messing with the way it sets envars
<shcv[m]>at some point I need to figure out how to use guix home to manage that
<KE0VVT>Guix lacks systemd-homed. :-(
<shcv[m]>KE0VVT: what's that?
<pashencija[m]><lilyp> "pashencija: do you have a..." <- It works now. Thank you!
<KE0VVT>shcv[m]: systemd-homed lets you keep your home dir encrypted while your laptop is on suspend. It also lets you physically detach it as an encrypted flash drive that can be shared between computers.
<shcv[m]>doesn't sound too hard to replicate, but maybe I don't know what I'm talking about
<KE0VVT>shcv[m]: So, when you're not logged in, your data is just... not there.
<KE0VVT>shcv[m]: Also, everything about your user is contained in the home directory. There is no /etc/passwd.
<shcv[m]>then how is the decryption performed?
<KE0VVT>shcv[m]: I think there's some minimal information kept in /home/ in place of the home dir.
<KE0VVT>shcv[m]: I'm not sure on the details. I just watched a demo of systemd-homed a long time ago.
<lilyp>shcv[m]: I think guix shell uses your current shell as base, so simply start bash from zsh, then guix shell
<lilyp>but do fix up your zshrc
<lilyp>to be fair, guix home lets you keep an unencrypted copy of all your config :P
<KarlJoad>How can I use a file in a local directory to test my substitute* regexp in a guix repl?
<shcv[m]>lilyp: when I run guix shell from bash, it starts zsh again... I think it's running it because that's my user shell?
<nckx>KarlJoad: Just… do? There is no daemon/magic involved.
*nckx → 😴💤
<KarlJoad>nckx: Ok... I guess my syntax is just wrong then.
<nckx>KarlJoad: I have a minute. What's your syntax?
<KarlJoad>(substitute* "module.lisp" (("\(pathname-as-directory [a-zA-Z\(\)/.\"]*\)" "test")))
<KarlJoad>guix-repl is running in the directory with module.lisp too.
<KarlJoad>The repl is complaining about a "bad let in form"
<KarlJoad>Nevermind. I got it. Needed to move a parentheses around the regexp.
<lilyp>shcv[m]: (define %default-shell
<lilyp> (or (getenv "SHELL") "/bin/sh"))
<NaturalNumber>anyone know why installing a simple package takes a long time at the last step, building a new profile, and causes my inode usage to drastically go up? thx
<sneek>Welcome back NaturalNumber, you have 1 message!
<sneek>NaturalNumber, antipode says: NaturalNumber: Are you using Nix somewhere? Maybe one of the NIX_... environment variables are set, leading Guix to talk to the nix daemon instead of the guix daemon.
<acrow>vagrantc: There is more code to share. :)
<KarlJoad>Can I add a list of patches to an inherited origin without needing to re-write the origin record manually?
<podiki[m]>e.g. (from a WIP patch, but see the top for inherit and deleting a patch)
<podiki[m]>do the same with appending I would guess
<KarlJoad>podiki[m]: Perfect! Exactly what I want to do! Thanks!
<podiki[m]>and that's the general scheme with inheriting, things override if you write the same field (like arguments) but you can instead modify the inheritied package fields (as lists of strings I believe)
<KarlJoad>Ok. I need to look into the construction of the package record and its component fields. I got the inheriting part, but am still getting familiar with what can be inherited and how I can manipulate it.
<KarlJoad>Changing the patches list is different than changing the arguments key-value list for instance.
<KarlJoad>On another note, can I change %patch-path so I can do (search-patches "patch") in my personal channel?
<podiki[m]>if it is a local file you can just point it to the path (I think just '("/path/to/patch"))
<podiki[m]>you don't need search-patches then
<KarlJoad>Fair enough. I just want to make my channel mirror Guix as much as possible is all.
<KarlJoad>Because now I am trying to resolve the patch's location relative to the CWD of the shell where I start the build.
<podiki[m]>I think you just need the patch in your channel (where you've pulled including that channel) for it to find it with search-patches? I forget if you need to define anything else
<podiki[m]>just make sure it was added (with git) and you have pulled with the channel, I think
<KarlJoad>I have added it to the repo that is the channel. I have not pulled the channel since though. But, I have the directory in my load path with -L.
<KarlJoad>podiki[m]: With '("stumpwm-module-dir-easy-regexp-replace.patch") I get an error on canonicalizing the path, and (search-patches "stumpwm-module-dir-easy-regexp-replace.patch") I just get an error.
<KarlJoad>But with '("synnax/packages/patches/stumpwm-module-dir-easy-regexp-replace.patch") AND running at the root of the channel, everything works.
<podiki[m]>not sure, I would just use the absolute path maybe?
<KarlJoad>Also, is I did try with a leading . (./synnax/...) and it did the same thing.
<KarlJoad>Now my build is failing because of "cycle detected in the references of #$out"
<podiki[m]>(funny just went back to stumpwm and was seeing the discussion on module-dir...)
<KarlJoad>Yeah... That's been a fun issue to tinker with all day...
<KarlJoad>I _do_ manually add a reference to #$out in a file so it can find its modules. Is that not allowed?
<podiki[m]>#$out in the same package?
<podiki[m]>dunno; feel free to link a paste to your patch later and I can take look
<KarlJoad>I think I tracked it down, but still do not understand why it is happening. In the stumpwm-lib output (where Lisp source files are installed), I manually create a reference to the stumpwm #$out directory.
***Xenguy_ is now known as Xenguy
<KarlJoad>podiki[m]: (The stumpwm-with-patch one). The patch just replaces *module-dir*'s value with "REPLACE-ME", so I can substitute* on it easily.
<gnucode>hello guix!
<podiki[m]>KarlJoad: not sure the details, but not sure why you use a patch. if you want to modify the source (for guix specifically), I would probably just add a phase after 'unpack and use substitute* there
<podiki[m]>just as the stump package does with 'fix-tests
<KarlJoad>My reason why was because I didn't know a good enough regexp to replace just the argument to pathname-as-directory in `(pathname-as-directory (concat (getenv "HOME") "/.stumpwm.d/modules"))`. The patch was just easier for now.
<podiki[m]>and since you say something about the lib output, maybe it is how these are built (i haven't tinkered with the lisp packages in guix)
<podiki[m]>if the (concat...) part is unique, you could match to that whole string, though the escaping is annoying
<podiki[m]>anyway, good luck for now, happy to help later, feel free to leave a message (either just mention my nick or use sneek)
<KarlJoad>Aight. I'm about to head off too.
<podiki[m]>(my first guess would be to do this after 'unpack anyway, next would be look at details of how the lib output is constructed in this build system for clues of what's going on)
*podiki[m] off for now
<KarlJoad>I'm thinking the cycle issue is because of the asdf stuff pointing to the stumpwm lisp source, which points to the compiled output, which points somewhere else.
<KarlJoad>Has anyone seen this before? `package has an invalid input: ("_" ("sbcl-alexandria"`. It is coming from a package where inputs are defined as `(inputs (append (list new-pkg) (package-inputs original-pkg)))`.
<raghavgururajan>Hello Guix!
<gnucode>well that's weird, is giving me a nginx 502 bad gateway error ...
<gnucode>I am using a VPN
<namtsui>gnucode: I see the same
<gnucode>namtsui: that's interesting...
<lechner>same here without vpn
<lechner>Hi, I switched to Guix Home. Would someone who uses the Fish shell share their configuration, please? Thanks!
<gnucode>lechner: fish shell is awesome!
<gnucode>I personally just start my shell via termite -e fish, and it autostarts the shell in fish.
<lechner>gnucode: i think there may be some benefits in letting 'guix home' handle it, no?
<gnucode>lechner: probably. I don't use guix home. I haven't migrated over yet. :)
<podiki[m]>for those mentioning above, issues front end has been down for a few days (known problem)
<trevdev[m]>Since you guys are "fishy", can you tell me what fish does for you that a more standard shell (such as zsh + plugins) cannot? Fish deviates from the usual command-line/script syntax. I'm stubborn and don't want ot learn a way to shell, but I'm still curious
<trevdev[m]>want to learn a new* way to shell
<gnucode>trevdev[m] I prefer it, because when I take 5+ minutes writing out a complicated command, I never have to remember it again. It will help me remember the command.
<elais[m]>I like fish because more often than not I get vanilla fish what zsh + plugins gives other people
<elais[m]>I get from vanilla fish*
<lilyp>NaturalNumber: re: inode usage, profiles have symlinks to all the packages within them, so if you have a lot of packages, you'll create a lot of extra inodes
<lechner>trevdev[m]: like for gnucode, it remembers my workflow---totally
<apoorv569[m]>Do I need a `use-module` form for using the `(dependencies mapped-devices)` in the `btrfs` `file-system` definition? Because I am getting this error, `error: mapped-devices: unbound variable`.
<gnucode>hmmm, I'm not certain how to finish the final bit on this opensmtpd-filters...
<Guest63>i installed guixsd it comes with a default emacs that i would like to remove, how do i know where its defined ?
<rekado_>Guest63: is it listed in the ‘packages’ field of your operating system configuration?
<rekado_>what does your operating system config look like?
<Guest63>it has xfce-desktop-service-type which pulls in some extra stuff like thunar, is there a way to view system packages graph ?
<antipode>sneek: later tell KarlJoad: I find it easier myself to do (patches (list (local-file "patch-file-1.patch") (local-file "patch-file-2.patch")), where file names are relative to the location of the module it is used in, IIUC.
<sneek>Will do.
<antipode>sneek: later tell KarlJoad: (at least, for channels, for Guix itself there's search-patches)
<sneek>Will do.
***Dynom_ is now known as Guest9867
<unmatched-paren>lechner: I use fish with guix home
<apoorv569[m]>Do I need a `use-module` form for using the `(dependencies mapped-devices)` in the `btrfs` `file-system` definition? Because I am getting this error, `error: mapped-devices: unbound variable`.
<unmatched-paren>apoorv569[m]: please show your whole config
<unmatched-paren>I see what you mean, sorry.
<unmatched-paren>I hadn't read the btrfs page in the manual :)
<unmatched-paren>I'm not sure why it's giving you an unbound variable error; the manual seems to imply that it's an implicitly bound variable...
<lilyp>apoorv569[m]: can you paste the config.scm (use or similar if 0x0 doesn't handle text)
<apoorv569[m]>The `config.scm` file works fine as it is auto generated via the `installer`. I have a`base-system.scm` file and multiple other `MACHINE_NAME.scm` files that I am trying to use to configure each system independently by running `sudo -E guix system -L ~/.config/guix/systems reconfigure --verbosity=3 `/.config/guix/systems/machine1.scm`
<lilyp>just paste the one that causes errors then
<apoorv569[m]>This is the `base-system.scm` file,
<apoorv569[m]>I have redacted some things like timezone and username, for privacy reasons..
<lilyp>no mapped-devices there
<apoorv569[m]>and this is the `machine1.scm`,
<nckx`>Are you not using m-d before it's specified?
<nckx`>Wait, where is it specified?
<nckx`>If you copy/pasted this from the manual, note that those examples specify a mapped-devices value before using it later.
<apoorv569[m]>I took the example code from here,
<apoorv569[m]>Do I have specify a `mapped-device` before using in the `file-system`?
<apoorv569[m]>I am not using `luks` so what would be the `type`?
<apoorv569[m]>They only list 3 types here,
<nckx`>Only if you have mapped devices. What (dependencies mapped-devices) means is 'yo, make sure you assemble my RAIDs and LVMs and LUKSes before you try to mount things'.
<apoorv569[m]>`lvm`, `raid` and `luks` I am using neither.
<nckx`>If you don't have any, why would you need that?
<apoorv569[m]>because that is what the `btrfs` section lists for using subvolumes..
<apoorv569[m]>but maybe that is if using encryption I guess.
<nckx`>It literally says '...hence the dependency...' above that. If you're not using mapped devices, don't depend on them.
<apoorv569[m]>I'll remove (dependencies mapped-devices) then.
<nckx`>Success will soon be yours.
<nckx`>(Or a new error :)
<apoorv569[m]>Ok new error :D
<lilyp>you don't define base-operating-system in MachineX
<apoorv569[m]>Yes, that is supposed to be inherited from `base-system.scm` because the module `base-system` is defined in that file. in my `machinex` config I include `#:use-modules (base-system)`
<apoorv569[m]>the `guix system -L` should help with that.
<apoorv569[m]> -L, --load-path=DIR
<apoorv569[m]> prepend DIR to the package module search path
<roptat>apoorv569[m], this usually happens when there's an error in (base-system) and guile refuses to load the file, then its variables are not defined and it reports only this error
<roptat>that's terrible :/
<roptat>try to run the guix repl and ,use (base-system)
<roptat>that should print a better error
<apoorv569[m]>is `,` part of the command?
<unmatched-paren>apoorv569[m]: yes
<unmatched-paren>,... is a guile repl command
<apoorv569[m]>While executing meta-command:
<apoorv569[m]>no code for module (base-system)
<roptat>you must be missing a -L (--load-path)
<roptat>the same that you use with the guix system command
<apoorv569[m]>Ok got an error,
<apoorv569[m]>no code for module (gnu packages neovim)
<apoorv569[m]>found couple of errors
<PotentialUser-13>Hi, how can I add a match host to the openssh config? doesnt appear to have anything about that. I tried to add an `extra-content` to the `home-openssh-configuration` but didnt work :p
<unmatched-paren>apoorv569[m]: why are you using (gnu packages neovim), that module doesn't exist
<unmatched-paren>There's a (gnu packages vim) though
<apoorv569[m]>Yes I changed to `vim`
<apoorv569[m]>is my `lightdm` configuration wrong?
<apoorv569[m]>I am getting error abour `lightdm` now
<roptat>I don't think we have a lightdm service?
<apoorv569[m]>so how to use `lightdm` then? I don't want to use `gdm`
<unmatched-paren>you could use greetd
<unmatched-paren>or slim
<unmatched-paren>or a tty -.o.-
<unmatched-paren>we currently have a gtkgreet greeter, along with the basic agreety
<unmatched-paren>i've done a wlgreet greeter, but i haven't upstreamed it
<apoorv569[m]>never heard of `greetd` I have heard of slim though
<unmatched-paren>and i'm working on tuigreet, but it's a steaming pile of Rust
<unmatched-paren>greetd is basically a daemon that implements the hard parts of login managers
<unmatched-paren>and provides a JSON protocol for 'greeters' like gtkgreet and tuigreet
<unmatched-paren>so those greeters only have to implement a UI, not the tricky authentication code
<apoorv569[m]>`greetd` looks fine with `gtkgreet` greeter
<apoorv569[m]>How do I set this up?
<Maya[m]1>i love finding new bugs in guix packages! apparently guix doesn’t change opensmtpd’s smtpctl gid and it doesn’t work!
<Maya[m]1>I have found the issue, during the build process the gid does not exist, how should I fix it? Can you create groups during package build process?
<unmatched-paren>Maya[m]1: are you running opensmtp with the service?
<unmatched-paren>apoorv569[m]: look for greetd in the manual
<unmatched-paren>the devel manual, specifically
<unmatched-paren>because i think it should work with the service...
<Maya[m]1>unmatched-paren: yes, but it runs chgrp during build process and the group is not available
<unmatched-paren>Ah, right
<unmatched-paren>I'm not sure how to fix it, sorry, i don't use opensmtp
<Maya[m]1>i think this is a guix issue, unmatched-paren the executable must be owned by the smtpq group, this is done in a makefile, but the group is not present on buildtime. Is there a way to ensure group existing during build?
<apoorv569[m]>Now I am getting about this,... (full message at
<apoorv569[m]>am I missing some module?
<unmatched-paren>Maya[m]1: I'm not entirely sure how unix groups work, but i'd think that if you created the group during the build process, then used guix system's opensmtpd service, which presumably creates such a group, they wouldn't be the same group?
<Maya[m]1>unmatched-paren: if you’re create them with the same gid i think they will
*unmatched-paren opens gnu/services/mail.scm
<unmatched-paren>it does create a smptq group
<unmatched-paren>but i can't really help you here
<unmatched-paren>apoorv569[m]: (gnu services linux)
<Maya[m]1>unmatched-paren: i think you can specify gid with user-group and in filesystem there’s only stored uid and gid
<apoorv569[m]>Yes thanks that worked. And now a new error :D... (full message at
<unmatched-paren>apoorv569[m]: Ah, I see, you're trying to use the naughty driver :)
<unmatched-paren>You'll need to go to #nonguix for help with that
<apoorv569[m]>Yes, I apologize for my sins :D
<Maya[m]1>i’ll probably try the dev mailing list
<apoorv569[m]>Oh! Finally the command started running..
<apoorv569[m]>let's see if I see further errors... it is downloads lots of substitutes for now.
<nckx`>Generally a good sign.
<apoorv569[m]>Hope so..
<andrzejku>do you know how to add to services geoclue-service
<andrzejku>-> (services (list geoclue-service %desktop-services))
<apoorv569[m]>andrzejku: I think it might be called `geoclue-service-type`. Usually when you added to the `(services ` you also add `-type`.
<roptat>the manual doesn't have geoclue-service-type, but it has geoclue-service
<roptat>the difference is that geoclue-service is a procedure, so you use it like this: (geoclue-service)
<apoorv569[m]>If you are adding these to the `config.scm` file the syntax is,... (full message at
<nckx`>The old-style -service names are usually procedures, so you'd need (), but use the new-style -service-type if available.
<nckx`>Can you please type slower?
<apoorv569[m]>type slower?
<nckx`>@ roptat,
<apoorv569[m]>lol, how do you know he/she was typing fast :D
<roptat>I love my bépo keyboard too much, that's why
<roptat>(and really, that's because I have a tendancy to reply just before nckx` :))
<nckx`>I have a Dvorak layout on my touchscreen which is like supergluing a spoiler to your Lada.
<apoorv569[m]>Ah! I think I got it.
<andrzejku>apoorv569[m]: id doesn't work no value specified for service of type 'geoclue'
<andrzejku>it expects an argument
<andrzejku>I am not sure
<roptat>try (service geoclue-service-type (geoclue-configuration))
<andrzejku>hmm it tells to configure geoclue
<roptat>what's the exact error message?
<roptat>ah there's no default value in geoclue-configuration
<roptat>would be easier to use the deprecated (geoclue-service)
<andrzejku>I see the same
<andrzejku>in desktop.scm
<andrzejku>geoclue-service is already defined
<andrzejku>but type have no default values
<andrzejku>ok I think I add it correctly but now there is a build error dbus-system-services.drv failed
<andrzejku>may it be a missing package
<roptat>you'd have to send us the log
<roptat>I meant the content of /var/log/guix/drvs/yg/9n3pss34p2xh01lxl2gag7hkawxbk8-dbus-system-services.drv.gz
<andrzejku>roptat: I tried tar -tf this file but it is empty
<roptat>it's not a tar, only compressed with gz
<roptat>try with zcat
<roptat>do you have a dbus service declared in your system config?
<andrzejku>no only desktop services and geoclue
<roptat>mh, I don't know then
<roptat>you could try sharing your os definition, maybe we'll find something in it
<andrzejku>may it be that geoclue has some dependency
<roptat>geoclue is already part of %desktop-services, so you don't have to repeat it, do you?
<andrzejku>roptat: I am not sure if it really is
<andrzejku>because when I reconfigure with installed geoclue
<andrzejku>I have no geoclue service
<andrzejku>in herd
<andrzejku>herd status
<roptat>that's expected
<roptat>geoclue doesn't extend the shepherd
<roptat>it's a dbus thing
<andrzejku>how can I know that it works?
<roptat>I don't know
<andrzejku>roptat: gammastep
<andrzejku>^Cpoll: Interrupted system call
<andrzejku>Error: Unable to get location from provider.
<andrzejku>gammastep is not working
<andrzejku>roptat: wait maybe I will try to get soem tool to check dbus services
<podiki[m]>I believe there is a sample in the geoclue package
<podiki[m]>look for the geoclue demo agent and where-am-i I think
<podiki[m]>and if you are watching /var/log/messages you should see some output of geoclue being activated
<podiki[m]>(mine doesn't get a location but I also haven't tried setting it up)
<roptat>200 strings left to translate in the manual :)
<andrzejku>well you were right it is but it doesn't work
<andrzejku>maybe glib-networking is needed
<apoorv569[m]>andrzejku: What did you use for the `geoclue` service?
<apoorv569[m]>Can you share, I use that service as well.
<andrzejku>it is a redshift for wayland
<andrzejku>you can run this daemon from console
<andrzejku>hmm is that a bug?
<andrzejku>I am actually connected to wifi
<apoorv569[m]>I use `xorg` for now.
<apoorv569[m]>You can just set a static location in the command.
<andrzejku>apoorv569[m]: true but this is more a hack :P
<andrzejku>guix seach geoclue
<apoorv569[m]>You want geoclue for redshift right?
<andrzejku>for gmmastep
<andrzejku>ok I will set up it manually
<muradm>hello guix
<podiki[m]>hi all
<podiki[m]>any stumpwm users here? (just going back after a while away)
<KarlJoad>podiki[m]: I know for a fact there is me.
<sneek>KarlJoad, you have 2 messages!
<sneek>KarlJoad, antipode says: I find it easier myself to do (patches (list (local-file "patch-file-1.patch") (local-file "patch-file-2.patch")), where file names are relative to the location of the module it is used in, IIUC.
<sneek>KarlJoad, antipode says: (at least, for channels, for Guix itself there's search-patches)
<muradm>is there any news on 56690 (seatd-service-type) and 56699 (greetd-service-type)?
<unmatched-paren>muradm: I still haven't packaged the first web framework required (somehow) for tuigreet :( I've had to add updated versions of serde, syn, rust-openssl, quote, and many, many other packages, and I'm still not there yet...
<podiki[m]>KarlJoad: found an odd bug with closing a pop-out video window wondering if anyone can reproduce/understand what is happening
<unmatched-paren>according to `git log --oneline 8a5a2a7~1.. | wc -l`: I've made 142 commits to guixrus so far
<muradm>is there any news on 56579 (fail2ban) and 56608 (fail2ban-service-type)?
<unmatched-paren>for this one package's one indirect dependency
<unmatched-paren>keep in mind that this one package is a text user interface that writes json to a socket
<unmatched-paren>the rust ecosystem is absolutely insane... if i wasn't already convinced of that, I am now :)
<apoorv569[m]>The `guix system reconfigure` is stuck compilation of a file some `bdcsvd_8.dir/bdcsvd.cpp.o` I have been waiting for quite some time now it hasn't moved past this file
<muradm>unmatched-paren: i was on the road last days, after updating my world let's see what is with greeters
<apoorv569[m]>the cursor in the terminal is blinking though (TTY)
<apoorv569[m]>my RAM is fully in use though 8GB only.
<lechner>unmatched-paren: thanks!
<muradm>is there any news on 56688 and 56689?
<unmatched-paren> <- this is the oneline log. I *think* i'm nearly able to package rust-axum (the first web framework)
<KarlJoad>podiki[m]: That is an impressively obscure bug. I'll try to reproduce later after a reboot.
<podiki[m]>well not obscure if your mouse policy is click and you like to watch a video everywhere :-P
<KarlJoad>Fair enough.
<podiki[m]>of course thought it was one of my modules, other random settings, never guessed mouse-policy
<podiki[m]>muradm: by news do you mean someone reviewing/committing? since it has only been a few days and is the weekend, think you'll have to wait a while (plus with the mumi frontend down there may be more pressing matters)
<muradm>unmatched-paren: could you paste upstream link to tuigreet you are dealing with?
<unmatched-paren>once i've packaged rust-axum, i'll still have: rust-poem, rust-rocket, rust-salvo, and rust-warp to deal with, which are all web frameworks
<unmatched-paren>muradm: Well, it's a dependency of tuigreet that's causing all this: rust-rust-embed
<unmatched-paren>It seems to have integration with multiple Rust web frameworks
<muradm>podiki[m]: yes, that what i was meaning.. then should be back in year i suppose... :D
<unmatched-paren>which means they must all be provided as input
<podiki[m]>muradm: haha hopefully not! I think the usual procedure is to send a ping or ask around after 1 or 2 weeks if there's no indication
<unmatched-paren>it also depends on rust-actix-web, but we already have that fortunately
<podiki[m]>or when there's people about here that can review/commit to ask them when you haven't heard anything
<muradm>podiki[m]: last time it took 10 months for seatd/greetd make to commit :D any way i'm done on my part at least
<muradm>just stopping to continue working further
<podiki[m]>I feel you
<podiki[m]>sometimes it takes a while, but I know you sometimes need to try to get some attention before it gets lost in the deluge
<KarlJoad>podiki[m]: Did you have a chance to look at that cycle issue I was having? I don't know how Guix is finding the cycle and I do not know how to query Guix to find it.
<podiki[m]>I would go with trying that phase after 'unpack first, since that should be before any other build steps happen (and where I would normally do a patch)
<podiki[m]>in case that makes a difference
<podiki[m]>KarlJoad: what bug are you trying to fix? what is the exact change you want in the end?
<KarlJoad>I am doing after 'unpack. The phase ordering is: unpack -> fix-tests -> patch-usr-bin-file -> patch-source-shebangs -> module-dir-point-to-store -> copy-source. All of which succeed.
<KarlJoad>I want to be able to install Stumpwm's contrib modules into the store and point my running instance to it.
<KarlJoad>In the end, *module-dir* should point to a directory in the store to find modules.
<podiki[m]>you mean besides the ones that are already packaged?
<unmatched-paren>muradm: I've made brief replies to the greetd and seatd patches
<unmatched-paren>obviously i'm not the best person to be reviewing patches, due to my inexperience :)
<KarlJoad>podiki[m]: I know they are packaged, but I don't think Stump picks them up because *module-dir* gets set to /tmp/.stumpwm.d/modules during build time.
<podiki[m]>and you don't want to set-module-dir but have it by default point somewhere? (the problem is that stumpwm-contrib is not needed for stumpwm, so at build time you don't have stumpwm-contrib by default)
<podiki[m]>if I'm understanding, you want stumpwm-contrib to be an input for stumpwm, then patch module-dir to point to the store path of stumpwm-contrib
<unmatched-paren>couldn't there be some search-path for this?
<KarlJoad>Yep! That's exactly what I am doing! This is a custom package in my channel, so only I will use it, probably.
<KarlJoad>Where the store path of stumpwm-contrib could be a union-build of all the contrib modules I want.
<podiki[m]>unmatched-paren: stumpwm has a variable you can set already, in user config
<podiki[m]>why not just the full stumpwm-contrib source?
<podiki[m]>you don't need to build it I don't think, just need the source
<unmatched-paren>podiki[m]: I mean having a native-search-path specified for the packae
<podiki[m]>unmatched-paren: I don't think stump uses any env for this, but within the lisp code
<KarlJoad>Either or, I'm not sure yet. How the contrib modules are put into the store is not as important right now.
<unmatched-paren>We could patch it
<unmatched-paren>to use GUIX_STUMPWM_MODULE_PATH
<podiki[m]>unmatched-paren: otherwise I would say it would use an XDG dir would be better (maybe it does somewhere, haven't checked)
<unmatched-paren>some packages already have GUIX_* env vars patched in
<podiki[m]>I don't think there's a need to complicate it like that, it should use what is available already
<podiki[m]>these would be in share/... or lib/.. anyway
<podiki[m]>yes but that I think is only by necessity
<unmatched-paren>having every stumpwm module package as an input for stumpwm doesn't sound ideal thoug
<podiki[m]>KarlJoad: what I'm saying is that there is already stumpwm-contrib, you add that as input and do your subsitute* to do module-dir to #$(this-package-input "stumpwm-contrib") or similar
<KarlJoad>That should work. Seems like exactly what I want.
<podiki[m]>ah, but stumpwm-contrib has stumpwm as inputs, I see what you were hitting
<podiki[m]>yes, I know, but doubt it'll be needed here, and is for one package
<KarlJoad>I have redefined some of the contrib modules I want to use a copy-build-system. So maybe that will work...
<unmatched-paren>okay then. though how would other packages that provide stump modules be handled? you surely couldn't just add every stumpwm-* to the inputs of stumpwm?
<podiki[m]>stumpwm doesn't need the modules
<podiki[m]>it is like extras a user might want in their configuration that are loaded at runtime
<KarlJoad>Stump runs completely fine without these modules.
<unmatched-paren>I know
<podiki[m]>anyway, KarlJoad why don't you want to just set the module-dir in your config?
<podiki[m]>I think that is the expected way
<KarlJoad>It is the expected way, but if I use the contrib modules in the store, then the directory could disappear with a GC. If this becomes impossible to do, then I will resort to that.
<unmatched-paren>But is stumpwm-contrib one of several extension module packages available? Or is it de facto the only one available?
<unmatched-paren>*the only useful one
<podiki[m]>why would it disppear if you installed the module?
<podiki[m]>stumpwm-contrib is the full source of all the modules, only some are made as separate packages inheriting from that
<podiki[m]>perhaps you want to make stumpwm-contrib installable as is, so one could have the full set rather than just picking and choosing
<podiki[m]>in fact, not sure why it was done that way, probably that is the better change
<podiki[m]>otherwise I think you can get around the circular dependency by just using the source of stumpwm-contrib (you don't need to compile it anyway for stump to use)
<KarlJoad>You cannot install the stumpwm-contrib package because it is not `define-public`. The modules would be installed through guix system.
<KarlJoad>So a GC may change the path to the modules, that my config is not aware of.
<podiki[m]>my point is to make it public
<podiki[m]>gc doesn't remove or change anything that is installed, btw
<podiki[m]>I think you should be thinking in terms of changing the guix packaging, if this will be useful
<podiki[m]>either we make packages for all the different contrib modules, or I think should have the full set available as one package (could be source only, that would work for stump anyway I believe)
<KarlJoad>Fair enough, but one step at a time. I want to figure out if what I want is even possible and usable first.
<podiki[m]>I think you are making it more complicated by trying to work around the current packaging
<podiki[m]>better to define what it is you want that should be possible from guix, and then go from there
<podiki[m]>if it is too "personal" and particular setup, then maybe not for upstream guix, but sounds useful to me to have all the contrib modules available, one way or another
<KarlJoad>Good point. But @@ will make it possible to at least test what I want.
<KarlJoad>When using `(inputs (append (list (@@ (gnu packages wm) stumpwm-contrib)) (package-inputs stumpwm)))`, I get an error saying `package `stumpwm@22.05' has an invalid input: ("_" ("sbcl-alexandria"`. Am I missing an unquote or something?
<podiki[m]>i'm not sure, hard to parse the one line here
<unmatched-paren>KarlJoad: You need to use old style inputs here, I think
***daviid` is now known as daviid
<unmatched-paren>(cons `("stumpwm-contrib" . ,(@@ (gnu packages wm) stumpwm-contrib)) (package-inputs stumpwm))
<unmatched-paren>sorry, drop the . in the `(...)
<podiki[m]>btw, the other thing to do it seems you want is to patch *module-dir* in stumpwm to use XDG_DATA_DIRS with added "common-lisp/sbcl/" to the end; that is where modules are installed in guix in a more robust way to find them
<KarlJoad>unmatched-paren: That worked. Thanks! Now to figure out why stumpwm-contrib does not build.
<podiki[m]>so yeah, I would say that (xdg_data_dirs) is a good guix patch for stumpwm so that it can use guix installed modules; the other issue is getting all the contrib modules
<podiki[m]>KarlJoad: because it is a collection of different modules that need different builds it seems; just need the package-source I think
<KarlJoad>podiki[m]: Perhaps I will get around to patching stumpwm-contrib to make it available soon.
<podiki[m]>anyway, I think that's it for me for now, but i would recommend the xdg_data_dirs patch as certainly what we want for things to work properly first
<podiki[m]>as for all the contrib modules, a source only package (public) would do the trick
<podiki[m]>good luck!
<KarlJoad>I think I am using only the package-source now.
<podiki[m]>no, the stumpwm-contrib in inputs I mean
<bullethead>latest up, pulseaudio needs work as does bluetooth, other than that everything relevant
<podiki[m]>so you don't have to build it, since you are only using the source
<KarlJoad>Ah good catch. Thanks.
*podiki[m] off for now, good luck
<KarlJoad>Everything built and the path is correct in the copied source file. So I think we got it.
<muradm>unmatched-paren: tuigreet looks like really mess :) while it says minimalistic (face palm)
<unmatched-paren>Yeah, I now have to package the latest version of rust-rand, apparently :)
<unmatched-paren>Do you think I should just give up on it? I'm seriously considering that option.
<muradm>i doubt that it feasible to support it this way
<unmatched-paren>There are probably crazier Rust packages. Probably.
<unmatched-paren>And tbf greetd itself is Rust.
<muradm>screenshot leads to thinking that it is ncurses like which it should be
<muradm>but implementation is total mess
*unmatched-paren looks
<unmatched-paren>well, it uses rust-tui
<unmatched-paren>which is sorta ncurses-like i guess
<muradm>unmatched-paren: i'm giving up :) better to rewrite it i guess :D
<unmatched-paren>Why not? Let's do it :)
<muradm>some dependencies even has wierd licenses
<unmatched-paren>Oh, yeah, I spotted a CDDL in there.
<unmatched-paren>which is a copyleft license
<muradm>unmatched-paren: let's write minimalist ncurses like :D
<muradm>will be cheaper i suppose for porting and for inodes :D
<unmatched-paren>Should we move this to DMs?
<unmatched-paren>I'll leave the guixrus branch I made, but I'll abandon it for now.
<unmatched-paren>btw, i came up with an idea that i think might be useful
<unmatched-paren>for guix
<unmatched-paren>`guix pull --use-patch=PATCH`, where PATCH could be a debbugs bug number, mailbox containing a patchset, or .patch file
<unmatched-paren>and a (patches ...) field for <channel> that does the same
<unmatched-paren>sorry, seems to have gone kaboom
<bullethead>is there anything I can use instead of arp-scan?  anything for guix like that?
<bullethead>because arp-scan doesn't seem available
<muradm>bullethead: guix install arp-scan
<muradm>bullethead: guix package --search=arp-scan
<florhizome[m]>How would guix fare in this 🤔
<the_tubular>There's a lot more to talk "Security Wise" than those few points ... I feel that's just a classical distro review that reviews the wallpaper...
<nckx>Seems like the usual ‘do these distro's default settings match my arbitrary personal tastes, or is it BAD??’ nonsense dipped in ‘did I mention I'm a CyBeRsEcUrItY PrOfEsIoNaL so you're not allowed to laugh why are you laughing stop laughing you're not allowe—’ sauce.
<nckx>Speaking of updates, respect to lfam for bumping linux-libre. My laptop has been deblobbing for *hours* so far.
<the_tubular>Well I mean, the default they suggest aren't bad recommendations, it's just very simplistic way of looking at it.
<Gooberpatrol66>do I ever need to run guix package --delete-generations or guix gc as root if i don't have any packages installed as root?
<nckx>No, in the sense of ‘regular’ gc. Some (e.g., repair) options require root.
<Gooberpatrol66>if i run guix system reconfigure as root, and then run guix gc as non-root, will it still clean up garbage from old system generations?
<nckx>Depends on how you define ‘garbage’.
<nckx>It will not make live roots dead.
<nckx>I.e., *turn them* into garbage.
<nckx>If you use ‘sudo guix system delete-generations’, a unprivileged ‘guix gc’ will certainly clean up the corpses.
<nckx>(= free the space).
<Gooberpatrol66>ok thanks
<formbi>I'm trying to package a program which uses CMake
<formbi>and it tries to install some stuff to /gnu/store/…-dbus-1.12.2/share/dbus-1/system.d
<formbi>how to change the location to the package's own directory?
<nckx>Depends entirely on the CMakeLists.txt.
<nckx>Which programme is this?
<nckx>formbi: Could you share your current package?
<formbi>wait a sec, I think I found where it defines the dbus thing
<nckx>Prolly src/helper/CMakeLists.txt
<nckx>I don't want to interrupt your research, but I have to go, so I'll just leave ‘#:configure-flags #~(list "-DINSTALL_DBUS_FILES_IN_PREFIX=ON")’ here as what I would have recommended otherwise.
***ChanServ sets mode: +o nckx
***ChanServ sets mode: -o nckx
<formbi>not that you're interrupting, I just don't wanna bother people too much
<formbi>nckx: it did work, now the same thing about polkit xD
<podiki[m]>Oh hey actually I have a package of corectrl
<podiki[m]>Which works as far as I can tell
<podiki[m]>Let me find a link to share ...
<podiki[m]>formbi: I don't think this is maybe the best package def (it is old): would patch paths rather than wrap-program, there's now hw pci package in guix, ... but in case it helps:
<podiki[m]>formbi: feel free to use whatever is helpful, and can help you sort it out to make it ready for guix proper, I just never got around to it
<formbi>podiki[m]: I have this: I have this
<podiki[m]>and it builds/works so far? I had a lot more inputs (some optional), and looks like a few tools would need absolute (store) paths, rather than wrap-program preferrably
<formbi>it fails on the install phase
<formbi>because it tries to install the polkit stuff where it shouldn't
<podiki[m]>and instead of pciutils-no-zlib use hwdata:pci probably
<formbi>the dbus thing seems to be dealt with
<formbi> file INSTALL cannot copy file "…/src/helper/org.corectrl.helperkiller.policy" to "…-polkit-0.120/share/polkit-1/actions/org.corectrl.helperkiller.policy":
<formbi>podiki[m]: what does the uncompressed pci-ids do?
<podiki[m]>corectrl wants plain uncompressed files for pci info (as do other programs), that's all
<formbi>the polkit thing is weird
<formbi>the polkit package path appears like out of nowhere
<formbi>I can't seem to find any mention before the src/helper/cmake_install.cmake file
<podiki[m]>let me build the latest with my package def...
<podiki[m]>mine still builds fine for 1.2.4
<formbi>hmm, interesting
<formbi>yours doesn't have anything about polkit
<podiki[m]>right, other than just "polkit" as input
<podiki[m]>but I do have polkit rules in output
<podiki[m]>e.g. share/polkit-1/actions/org.corectrl.helper.policy
<formbi>I do have polkit as in put as well
<antipode>Is there any update on unsticking
<ogey>Hello, I am having trouble building python fontpens while doing a full system
<ogey> update with guix system reconfigure. When I look at the build log for
<ogey> the failed package (pythonfontpens-0.2.4), it says that it failed the
<ogey> estimated quadratic curve length test. It says the expected result was
<ogey> 107.70329614269009. The result I got was 107.70329614269008. This seems
<ogey> like it could be a floating point error to me. Is there anything I can
<ogey> do to get my system to upgrade?
<antipode>Also, any ideas on 'how far' antioxidant should go before considering it sufficient? E.g., is support for compiling examples and benchmarks and running stand-alone tests needed? (TBC: often there are a lot of non-stand-alone tests, which are already compiled and run)
<antipode>ogey: Already reported at
<antipode>Which architecture?
<ogey>ok It is good to know that it is already reported. I use x86_64.
<podiki[m]>antipode: still the weekend, likely need to wait until later in the week
<antipode>I assume you can work-around it by removing the python-fontpens or its relevant dependent from the profile.
<antipode>If you didn't add that or the font manually, I would guess it's pulled in by some graphical environment
<antipode>Alternatively, if it doesn't cause a world-rebuild, someone could replace python-fontpens with python-fontpens-bootstrap as a temporary work-around.
<antipode>podiki: ok.
<antipode>ogey: It consistently passes over here ...
<antipode>(also a x86_64).
<antipode>ogey: does "guix build -e '(@@ (gnu packages fontutils) python-fontpens)' --cores=1 --check --system=x86_64-linux" pass or fail for you?
<antipode>(Testing if parallelism is somehow relevant)
<antipode>Looks like it is reported upstream: <>.
<ogey>I will check if it works.