<podiki[m]>even better, upstream fontconfig will use xdg_data_dirs in upcoming release (merged, in current release candidate)
<lambdalove-sadvi>Hi, folks! Has anyone made progress towards building the Haskell Stack tool through guix build? I was giving it a shot after having downloaded a package definition using guix import, but I'm stuck with the dependencies, such as casa-client
<podiki[m]>lambdalove-sadvi: I have not tried, but did see a patch for it some time ago
<podiki[m]>yeah, that was probably it, could be a good starting point
<podiki[m]>having stack would be nice, and guix should be having haskell packages following stackage lts resolver (so it would be good to actually have stack for that too)
<lambdalove-sadvi>I was just curious about the synergy between 'guix import hackage' and 'guix build', since the list of inputs generated from the former, as it appears, comes exclusively from the 'dependencies' section of hackage.org, and has no relation to the available Guile 3.0 modules
<GNUtoo>hi, is there some way to not compile the manual and/or the translation as when runnig guix pack I have "building /gnu/store/v6w1wb2jffrpcqshs59s16y5f0ki061r-guix-translated-texinfo.drv..." and it has been like that for ~7 hours
<GNUtoo>it runs some po4a-translate that somehow does things with the german and spanish manuals
<GNUtoo>It runs "/gnu/store/ysk9g469f4pvw7i318kbk1hnrfrydanl-perl-5.30.2/bin/perl /gnu/store/ipsrd28j9i8hxkjhnbqb94yzvnnqlj5m-po4a-0.63/bin/.po4a-translate-real -M UTF-8 -L UTF-8 -k 0 -f texinfo -m guix.texi -p ./guix-manual.es.po -l guix.es.texi.tmp" which takes a lot of CPU (same for the de version)
<podiki[m]>lambdalove-sadvi: I think I found it a bit hit or miss, it picks up on some that are already in Guix, but not always (might depend on versions too)
<podiki[m]>If you specified the same LTS resolver from Stackage that the Guix packages are from (I don't remember off hand) maybe that would line up better? not sure sorry
<GNUtoo>I think it does that with guix time-machine
<lambdalove-sadvi>GNUtoo: couldn't find anything in the manual correlated, neither in 'guix pack' nor in 'guix build options' sections
<GNUtoo>*It does that with guix time-machine but probably not without
<GNUtoo>Beside configure.ac I found it only there: guix/self.scm: (invoke #+(file-append po4a "/bin/po4a-translate")
<GNUtoo>Maybe compiling guix has become very long somehow?
<lambdalove-sadvi>podiki[m]: I was trying firstly with the hackage IMPORTER (email@example.com), but I can confirm that the 'inputs' property generated by both are different, and the stackage IMPORTER doesn't include the weirdo 'casa-client' input
<lambdalove-sadvi>Problem is: stackage importer fetched max version 18.104.22.168 (guix import stackage stack)
<GNUtoo>d548fa91446d4738adb1a5289746bf9363fff398 is probably HEAD or not far behind
<GNUtoo>The idea was to try a patch to see if with and without the time machine the generated provenance file would be the same with the patch (it's not without, even if HEAD match the commit)
<podiki[m]>lambdalove-sadvi: not sure, I was working on a huge import of packages at one point, but mostly spend my time adding inputs for things like pkg-config and external libraries. but do file a bug report if it doesn't work as expected or there is better behavior you'd want
<iskarian>podiki[m], just a note: fontconfig in core-updates should no longer require `fc-cache -f`
<podiki[m]>iskarian: and is it also updated to use XDG_DATA_DIRS now too? I saw that is in upstream (but is only at a release candidate stage?)
<iskarian>I'm not sure about that; the cache fix is from a Guix patch
<lambdalove-sadvi>What can I do to further investigate when a given input is listed correctly and is available as a substitute in the guix channel, but in the build process I get something like 'encountered missing dependencies: <pkg>'?
<lambdalove-sadvi> (inputs ... ("ghc-base16-bytestring" ,ghc-base16-bytestring)) and then, at the end of the build process: Setup.hs: Encountered missing dependencies: base16-bytestring >=1
<podiki[m]>added it manually to the keyring seems to have helped
<vikanezrimaya>Given a `guix repl` (or maybe a plain guile shell for added challenge?), how to produce the same effect as running `guix system build <something>`, given an (operating-system) definition, say, in a variable?
<vikanezrimaya>I feel like Scheme is powerful enough for it to happen but I don't know enough Scheme or Guix to attempt to solve this myself
<vikanezrimaya>surely if Guix is written in Guile then it must be callable from Guile
<moshy>least ya alive. also I think I may have found a game that could steer towards using a nonfree app. Safe to ignore or would it need to be patched in some manner?
<KittyOwO[m]>I think usually they don't like that type of thing in the repository/channel (I believe its one of the main reasons firefox isn't in it), just out of curiosity what's the exact situation?
<boeg>Anyone else here using swaylock and getting an error when trying to reconfigure? I `guix pull`'ed and then `guix system reconfigure my-config.scm` and are getting: In procedure setuid-program-program: Wrong type argument: #<file-append #<package firstname.lastname@example.org gnu/packages/wm.scm:1554 7f9aceeaf0a0> "/bin/swaylock">
<apapsch>Hello Guix! I have downloaded grafana prebuilt binaries and running bin/grafana-server just returns "no such file or directory". The file exists, has executable bit set and can be probed with readelf. ldd shows all libraries are found. strace shows ENOENT is really about the executable itself (https://paste.debian.net/1208670/)
<apapsch>Can I get the foreign binary up and running?
<bricewge>apapsch: I managed to run it a few week ago on previous Arch that was infected by Guix system, it worked because of the remains of Arch. Wen run on a clean Guix system it didn't worked
<bricewge>I think the binary need a run of patchelf on it. I didn't try but if you do, I'll be happy to get your feedback on it.
<apapsch>bricewge: thanks a lot! `patchelf --print-interpreter grafana-server` returns "/lib64/ld-linux-x86-64.so.2" which is not found. `patchelf --set-interpreter /gnu/store/...glibc-2.31/lib/ld-linux-x86-64.so.2 grafana-server` does the trick
<apapsch>efraim: yeah I had checked out `ldd grafana-server` and it showed all libraries as found. It even printed "/lib64/ld-linux-x86-64.so.2 => /gnu/store/...-glibc-2.31/lib/ld-linux-x86-64.so.2", which I guess is a guess by ldd, as patchelf --set-interpreter was needed
<bricewge>BTW, is there a channel for such packages that we can't package yet but where upstream provide binaries
<rekado_>…which is for scientific packages that can’t yet be added to Guix proper
<apapsch>bricewge: I have a guix fork that I keep in sync with savannah and "stern-kit", a channel that adds an ansible like experience to `guix deploy` (such as <machine> discovery) and explores composability of <operating-system>. It's very much in flux: https://devlab.sterndata.eu/guix
<apapsch>The channel will contain grafana-bin and prometheus-bin and I think I'll move Shopware from the Guix fork to the channel as well
<rekado_>roptat: on my HPC deployment of Guix I see a *lot* of guix-profile.lock and current-guix.lock files. Users report that they can’t run “guix pull” or upgrade their profiles because Guix refuses to work when the lock file exists.
<rekado_>roptat: the localstatedir is mounted over NFS.
<pkill9>dstolfa: normally root, but it still shouldn't matter because i have a lot of system generations created by root
<bricewge>apapsch: Thanks that's interesting. I have a similar setup too, but it's always interesting to look how other I configuring their system.
<bricewge>I was looking for a more generic channel, using upstream binaries for package we can't yet properly package in Guix.
<bricewge>MysteriousSilver : guix-science is close to what I'm looking for, but still focused on, hum science software so not so generic
<apapsch>it usually is the case when someone asks about firmware. though if it's a linux module that does not need nonfree firmware, check out linux config and maybe build a custom one for the time being
<attila_lendvai>i don't fully understand which licence qualifies for inclusion into GUIX yet... would Signal Private Messenger qualify if it is compiled from sources? if not, why? i'm considering packaging it... somewhere (i'm an old time lisper who just came over from nixos to guix)
<dstolfa>attila_lendvai: guix follows FSDG. generally if the FSF lists it as a "free software license", it's all good
<roptat>rekado_, not sure why the lock file is not removed
<attila_lendvai>so, if i want to contribute to guix, but i will need time to develop these packages... then does it make sense to 1) set up my own channel/git repo, and use the guix packages namespace, and when ready, send the patches? or 2) should i rather fork guix.git and open a new branch that i keep rebasing?
<dstolfa>attila_lendvai: i make a branch that i keep rebasing personally, but whatever is easiest for you. guix patches are sent via email to the appropriate mailing list, so it doesn't really matter how you do your local workflow :)
<roptat>rekado_, looking at the code "NFS mounts can return ENOLCK. When that happens, there's not much that can be done, so warn the user and keep going."
<roptat>I don't know NFS, but it seems we already handle that case?
<attila_lendvai>pinentry-qt doesn't seem to work for me, even after killing gpg-agent (installing pinentry or pinentry-gnome3 do work, but i prefer the modal dialog). gpg just prints "gpg: signing failed: No pinentry"
<podiki[m]>did you set it in the gpg-agent conf? (I've had trouble in the past with this setting, sometimes having nothing works better than what I put, for some reason)
<attila_lendvai>podiki[m], i didn't set it. i was just changing which packages are installed using guix package -m mystuff.scm (and killing gpg-agent)
<attila_lendvai>i left it as a TODO and keep moving towards a channel of my own where i can add my own packages
<podiki[m]>might want to try in ~/.gnupg/gpg-agent.conf at some point (I need to set it usually or else pinentry fails for me)
<rekado_>roptat: it’s weird. There are hundreds of lock files and I’m confident that we aren’t violently killing Guix processes left and right.
<rekado_>I’ll play with this in the coming days and send a proper bug report.
<attila_lendvai>yay! i managed to set up a channel and guix pull it. more hacking awaits! but not before dinner... thanks for all the help!
<attila_lendvai>podiki[m], indeed. i must set the pinentry-program to the full store path of the executable in gpg-agent.conf, otherwise it seems to be ignored. too bad, because it's prone to fail with updates...
<podiki[m]>you shouldn't have to do that, just the pinentry program name should work, or maybe just the /path/to/profile/bin/pinentry
<lfam>The / fallback is just a fallback that is not expected to work
<lfam>I don't remember now but maybe it's the default style of lookup fallback in GnuPG
<lfam>I don't think it makes sense to have the gnupg and pinentry packages in different profiles on Guix. One can do that but it's not something that anyone has planned for
<GNUtoo>With 'guix pack --format=deb hello' or 'guix pack --format=deb le-certs' it works, with 'guix pack --format=deb hello le-certs' it fails, with 'guix pack hello le-certs' it works
<podiki[m]>they are in the same profile, just not in system (only barebones to get to graphical) or user (empty except for testing). but I was moving things around before, maybe it was on my end
<attila_lendvai>lfam, that's cool. now, the only qestion is how it is decided which variant the "pinentry" points to. by default it seems to point to pinentry-gtk2, even if i don't install it for my user
<muradm>checked that, and could not identify a pattern, some put crates-io some don't, last week i asked here, and some one suggested just to be consistent, these commit messages are my understanding of consistency, but i'm flexible to adapt
<pineapples>muradm: You might've guessed it buy leoprikler had suggested that it had been put under that namespace. I, personally, had been intending to introduce it in an entirely new namespace named after it
<leoprikler>And I will always argue we don't need more single-package modules, but less :)
<leoprikler>that being said, I did leave some options back the – was admin one of them?
<muradm>i would agree with leoprikler on namespace thing, per package namespace sounds evil, thousands of packages, never ending namespaces, from user perspective grouping is much more useful
<pineapples>leoprikler: I don't recall any namespace but the freedesktop one being brought up. Anyway I don't object to that choice; it's completely fine by me as-is now :)
<muradm>that said, from my experience of last few months with seatd/greetd setup, namespace should be gnu/packages/admin.scm :)
<muradm>another question on dbus.. back then for years on arch i was running dbus-broker in place of dbus
<pineapples>muradm: Correct me if I'm wrong but do `seatd-user' and `seatd-group' of `seatd-configuration` allow one to configure which user or group of users is allowed to "connect/use" to the `seatd' daemon?
<muradm>pineapples: true, seatd -u -g flags for socket owner
<muradm>and revision of: Building the following 2766 packages would ensure 7167 dependent packages are rebuilt
<muradm>just imagine declaring dbus services within service it self
<pineapples>muradm: Question: seeing how more correct your `seatd' service is, compatibility-wise; I'm wondering if you can reproduce an issue I personally have with `seatd` under Guix; namely, does the `SysRQ+K' Magic System Request Key Combo render the virtual terminal interface inoperable on your system?
<muradm>pineapples: what does SysRQ+K does? not aware of it completely
<pineapples>muradm: It is supposed to terminate all programs on the current virtual console. What it shouldn't supposed to do is terminate `seatd`, which it does.
<muradm>pineapples: seatd is started by shepherd, which drills down to fork+exec-command which calls setsid, making seatd a session leader, not bound to any vt
<muradm>since not bound, should not be killed by your key combination or whatever
<pineapples>I and the developer of `seatd` tried to solve that. First, we discovered that `seatd` leaves a `/dev/console' file descriptor open. They patched that in an experimental, git release but the bug remained an issue on Guix, whereas it was gone on their system
<pineapples>I kind of gave up after that, not knowing what else to do
<muradm>pineapples: i had some issue of getting my screen blank, but i blamed sway for it, because it happend when i reload sway config on demand
<muradm>pineapples: i'm trying to understand usecase for now, so let's say i have VT2 where i go to with Alt+Ctrl+2, then i login there, then i start htop for instance, then i press that magic combination (whatever it is) and i should expect htop and bash started by greeter to be killed leaving login prompt on that VT2?
<vldn>my filezilla try to rebuild recently, but a lot of programs then not depend on mesa that i use maybe.. not much compilation lately
<vldn>But will change to core updates Frozen anyway
<roptat>I wouldn't recommend that yet, some big packages are still failing, and master hasn't been merged on core-updates-frozen in a few weeks at least, so some leaf packages will still be at an older version
<pineapples>muradm: It's okay! Anyway.. I guess it does not come across well to make such a request and that I should get to work myself but.. other eye-candy that I'd love to see alongside Greetd is working Plymouth :)
<podiki[m]>speaking of updates, I know there is some discussion on the mailing list, but would be great to get some of these core-updates packages in a faster turn around (like Mesa, lots of quick bug fix releases, but shouldn't have breaking changes on the point releases)
<muradm>lol, it was not freezing issue :D it was redshift :)
<muradm>brightness was so low, that it was looking like black screen which is not
<muradm>pineapples: i have greetd with gtkgreet on my setup, which will be next step to do after #49969
<muradm>but i wan't a) sway 1.6.1 with wlroots 0.14.1 to see how it works, that means i have to test and patch core-updates-frozen
<muradm>for plymouth, that would be step after that
<podiki[m]>muradm: sounds like fun to me, hacking on guix/packages for the eyecandy
<podiki[m]>the package transformations are nice, should be easy to try out some experimental versions of picom (there's some with animations which actually work pretty well for me)
<pineapples>podiki[m]: Guix Home, `mcron' that behaves anachronistically, like systemd timers; greetd; Plymouth; `xdg-desktop-kde-portal` for replacing the GTK file picker with Dolphin; dbus-broker; presence of `qtwayland' across all qt-related package definitions' inputs so that our Qt packages work natively under Wayland; Pipewire as an audio server (Guix Home will address this); all Sway/Wlroots-related goodies
<pineapples>that NixOS and nixpkgs-wayland may already have, and perhaps many more I've forgotten about :')
<podiki[m]>pineapples: ah, wayland. I haven't gone there because there's not stumpwm or xmonad :-/ (I know there is sway, and I did use i3 some time ago)