<podiki[m]>anything you have to do to get fonts installed in a non default profile (user or system) to be seen by programs? xdg_data_dirs is properly exported... <podiki[m]>for anyone else: solved by making a .config/fontconfig/fonts.conf file to add the profile/share/fonts directory (in my case a "desktop" profile, but maybe worth just making a font one) <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 (stack@2.7.3), 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 2.1.3.1 (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 <lambdalove-sadvi>Perhaps just naming issue? (ghc-base16-bytestring vs. base16-bytestring?) <iskarian>lambdalove-sadvi, is the version packaged in guix too low? It sounds like Setup.hs wants a version >= 1 <lambdalove-sadvi>Ahhh, true... I thought I had seen '1.1.1.6' in the output of 'guix show ghc-base16-bytestring', but it is giving me version 0.1.1.6 <podiki[m]>anyone have tips on guix refresh and having problems with keys? <podiki[m]>getting `gpgv: Can't check signature: No public key <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 ***Server sets mode: +Ccntz
<moshy>Am well. Just poking around for some extra pkgs <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 swaylock@1.5 gnu/packages/wm.scm:1554 7f9aceeaf0a0> "/bin/swaylock"> <boeg>it has been working for ages <moshy>KittyOwO[m]: It's the game tome4. There's just a link to a discord server on the main menu. Otherwise there's nothing else I'm aware of <moshy>clicking it didn't work for me anyhow, not even opened icecat <bricewge>The error message was fixed in a subsequent patch <boeg>bricewge: ah, so i need to change my config. I have this in my services part of the operating-system declaration: (simple-service 'swaylock-setuid <boeg> setuid-program-service-type <boeg> (list (file-append swaylock "/bin/swaylock"))) <KittyOwO[m]>I need to set up swaylock some time, wayland is quite nice. <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>that allows me to go with a "bin" guix package for now (grafana build system is quite involved) <efraim>apapsch: run 'guix environment --pure --ad-hoc gcc-toolchain -- ldd bin/grafana-server' to see if it's actually linked to anything <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 <parnikkapore>I generated a custom iso that contains GNOME (so I will have sth to do after boot), and despite being officially unsupported it works pretty well <parnikkapore>1. Adding a Wi-Fi network crashes the settings app. nmcli works tho <parnikkapore>2. audio is broken - kernel is looking for the sof firmware, which Guix does not have packaged <apapsch>when you know the font is set too small: confusing arm64 with amd64. d'oh! <apapsch>parnikkapore: nonfree firmware is stripped from linux-libre, which guix uses <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 ***apteryx_ is now known as apteryx
<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 <MysteriousSilver>the dependancy list is large which makes it difficult to keep track of updates <attila_lendvai>MysteriousSilver, this means that there's not any electron based apps yet (for me as an example)? <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 dives back into the docs <roptat>rekado_, maybe NFS doesn't play well with lock files, or maybe it was never removed because it became inaccessible at the wrong moment? <roptat>or maybe if you kill the guile process violently, it can't exit properly and lift the lock? *attila_lendvai has trouble finding which package installs srm <roptat>attila_lendvai, if you already have srm, you can try `readlink -f $(which srm)` <roptat>attila_lendvai, I tried to grep through the packages, but "srm" only appears in package hashes <attila_lendvai>surprisingly enough, srm is its own pacakge on nix. i thought it's part of something <zap>Hello guixers! Long time no see :) <zap>attila_lendvai: btw you can also try `shred -fu`; shred is part of coreutils <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 <attila_lendvai>is there a way to force the replacement or priority of pinentry-gnome3 over whatever is the default (i think pinentry-gtk-2) <podiki[m]>make sure profiles being sourced, maybe need to login/reboot to get that in your graphical session ***chexum_ is now known as chexum
<doncatnip>can confirm .. i used just the name of the pinentry program pinentry-gtk-2 indeed ... until i saw the light ... it's now allow-emacs-pinentry :) <attila_lendvai>podiki[m], yay, thanks! this works without any fuss: pinentry-program /home/alendvai/.guix-profile/bin/pinentry-gnome3 <podiki[m]>just check on reboot, I've had a setting be fine in the moment, but didn't like it later (probably because of changes to a profile sourcing that didn't register until later) *attila_lendvai still needs to get used to the nix/guix way... <podiki[m]>and might depend on when gpg-agent gets called/the environment (this is true on non-guix too for me) <podiki[m]>if you are a yubikey + rofi/dmenu user, I have a package for yubikey-oath-dmenu (oath codes from dmenu) that I need to submit, but works *attila_lendvai has a trezor, but haven't migrated the pgp part yet <lfam>It used to be necessary to help gpg-agent find pinentry with Guix, but we've patched GnuPG to make it "just work" now <podiki[m]>lfam: another case of system/default user profile though right? <lfam>I don't know... I didn't read the previous messages closely <lfam>I'd say "don't put GnuPG in your system packages" <lfam>Note that the patch to which I linked is based on per-user lookups <podiki[m]>on my system I set it explicitly in gpg-agent.conf to /path/to/a/profile/bin/pinentry; don't remember if I tried much without that <lfam>Well, that will always work. But it was too much of a UX hurdle, so after years of telling people to do it here in #guix, we just patched the problem away <GNUtoo>hi, does guix pack --format=deb supports more than one package? <podiki[m]>lfam: curious, I'll have to try again when I'm back at that computer. pinentry will be in PATH, but not in /bin, or .guix-profile/bin (since it is in a different profile) <lfam>Things will never exist in /bin for Guix <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 *attila_lendvai is AFK for a while <lfam>The default is selected in the ((gnu packages gnupg) pinentry) package <lfam>I guess the GTK 2 variant is the most broadly useful <lfam>All the others are somehow "special" in comparison <efraim>It was the default at the time it was created <lfam>But, GNOME includes pinentry-gnome3 <lfam>I'm not sure how pinentry-gtk2 would be made available except by the user / administrator installing it <efraim>I've thought about suggesting turning pinentry into a deprecated package and making people choose one explicitly <lfam>I'm setting up a test for your seatd / greetd patches now <lfam>It will take some time to build everything; I'm testing on a really slow computer <muradm>lfam: great, if you have any issue, i will be around next 3-6 hours ) <lfam>I do have some preliminary feedback <lfam>The documentation should be added in the same commit of the thing being documented <lfam>So, patch 10/10 should be split up and added to the patches adding the respective services <lfam>Also, is greetd part of the freedesktop project? Or somehow affiliated with freedesktop? If not, we should find another module for the greetd package <muradm>greetd's author is kennylevinsen, same author of seatd <muradm>i'm not sure if there is official affiliation, i'm not sure if seatd is affiliated as well, i was surprised finding it in freedesktop <lfam>I googled 'seatd freedesktop' and all the hits seemed to be from our patch tracker :) <muradm>lfam: in my opinion, greetd should be near mingetty both as package and service <lfam>Yeah, so the admin package module? <lfam>And the base services module <muradm>seatd-service-type place near elogind is fair i think <muradm>since both target seat management <lfam>That should be sufficient for testing, right? <muradm>lfam: there is a test case in gnu/tests/desktop.scm <muradm>with sufficient configuration and 7 test cases <lfam>Oh great, I'll run that test too. I'll also want to boot it for real, however :)) <muradm>yes, that example may work as well <muradm>but i suggest to use %base-services <muradm>configuration from test case should be more reliable <lfam>I'll see how it goes and adapt my testing as necessary <muradm>i will be updating documentation again regarding this <lfam>So, most of my feedback at this point is cosmetic, as you can see <lfam>Also some cosmetic issues in the commit messages, which is something I could / would adjust when committing <lfam>For example, "gnu: admin: Add greetd-pam-mount" <lfam>That should be "gnu: Add greetd-pam-mount." <lfam>Well it's going to take a couple hours just to build things <muradm>lfam: no issue, i was asking about commit message format, and tried to be consistent, "gnu: Add greetd-pam-mount" is ok any way <lfam>No, core2duo (thinkpad x200) <lfam>It's my Guix System computer <lfam>We don't usually mention package modules when adding packages. And we always use "complete sentences", which mean we use punctuation. <muradm>does same apply to other commits with packages? <muradm>also just to understand what does "gnu: " states in commit, and when it is not "gnu: "? <roptat>I think it's the gnu/ subdirectory <muradm>hmm.. fair enough.. gnu, guix, doc etc. <lfam>It's also somewhat abstract... <lfam>Like, "GNU is a computer system" <lfam>So the packages and services compose the GNU system <lfam>Anyways, one learns how to write these things, with some time <lfam>I usually find out how to write it by doing `git log path/to/what/i/changed` <lfam>And copy what other people did ;) <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 <muradm>apapsch: definetly, however "gnu: " (and any other prefixes if any) supposedly should be manifested by project <lfam>Yeah, looks good for now! I'll have more feedback after I actually build everything and get it tested, later today <lfam>Going afk for real now :) <muradm>pineapples: initially you introduced seatd package in gnu/packages/freedesktop.scm <muradm>what was the reason to put it under freedesktop namespace? <leoprikler>muradm i think it belongs there as a seat manager along with elogind even if it's not strictly part of the freedesktop standard <leoprikler>we have a few packages in freedesktop.scm with a similar history <muradm>leoprikler: i suppose that it is beacuse seat management thing with XDG_* stuff introduced by freedesktop.org <muradm>seatd seems not to have any ties to freedesktop, should we consider fixing it by moving to another namespace like gnu/packages/admin.scm? <muradm>leoprikler: it seems that seatd has nothing to do with freedesktop in any way, not technically, not officially, not bound by any specification. <muradm>probably seatd is also fair candidated to other place, like gnu/packages/admin.scm <muradm>seat management is admin thing in my opinion, managing shared access to resources including hardware, switching sessions etc. <muradm>not specific to graphics, if you would ask, seat management between two virtual terminals also a case <apapsch>seems like BOFH would like that tool <muradm>this is how seatd defines it: Seat management takes care of mediating access to shared devices (graphics, input), without requiring the applications needing access to be root. *str1ngs do you here the people sing... <muradm>hard to get it when english is not your native... :) <muradm>but i suppose seatd is not for BOHF but systemd/elogind is.. :) <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 :) <leoprikler>Guess we didn't consider admin.scm back then after all <pineapples>muradm: Awesome! I was planning to package it myself but it seemed a chore to do hahah <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>effectively makes does "allowed to connect/use" <muradm>so now after seatd/greetd service types work i did for guix, i have some ambicious idea to make dbus-broker <muradm>without systemd dependency and replace "dbus-broker-launcher" which provides systemd-dbus compatibility layer with guix native implementation <muradm>that will do service management declaratively in scheme, instead of xml files <muradm>that whould be huge step forward <muradm>but will require huge scary effort :) <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 <muradm>not sure if i understand it at all.. ) <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? <pineapples>muradm: Correct. You should be greeted by the login prompt as soon as the magic key combination is pressed <muradm>cool, now i have to figure out SysRq, as i didn't see that key for years, and on my hhkb i hardly have other keys even :) <muradm>from docs i see that it should be Alt+PrintScreen+k <pineapples>Good luck! Remember about CTRL+ALT+DEL if it freezes for you :') <muradm>pineapples: yeah it works, no issue, seatd continue working <muradm>no freesing, just killed bash and prompted with login again <muradm>as of my understanding that thing in noholdtty is not related to my implementation of seatd-service-type for guix <muradm>setsid call by shepherd avoids your issue <muradm>590 ? Ss 0:00 /gnu/store/iclwa9ar5p431b8hkj9vi1f55id29p09-seatd-0.5.0/bin/seatd -u root -g users -s /run/seatd.sock <muradm>this is how it is list in processes <muradm>pay attention to ? which states no tty bound to process at all <muradm>most likely you are starting it manually some how, where seatd keeps attached to console, thus being subject for kill <pineapples>I can't wait to use greetd and your improved `seatd` service :) <muradm>man if you have trojan on your login propmt, it could be started far before greeter it self :) that SAK won't help you <muradm>but any way, it works what you want :) <pineapples>muradm: My usecase for the kernel secure attention key is recovering from soft `amdgpu' crashes where Sway has to be restarted hahah <vldn>any infos on restoring the bootloader from the rescue console? <vldn>or changing path from bootimage without grub access.. <muradm>pineapples: your config is very similar to mine, so i suppose you are hitting same issue as i explained with sway config reload <muradm>try to reload sway config with swaymsg reload, and you will be blank screened :) <vldn>grub is loaded but doesnt find the right bootimage <vldn>and i'm dropped to guile rescue console <pineapples>Still waiting for `core-updates' being merged until I can comfortably use 1.6 ***avoidr_ is now known as avoidr
<muradm>vldn: are you sure it is "guile rescue console" and not "grub rescue console"? <vldn>maybe grub guile rescue prompt? xD <vldn>the prompt with ,bt for backtrace and ,q for continue <muradm>vldn: i would speculate that your system profile is broken then... any error it shows before droping to console? reason? <vldn>could i Change via this console the grub config? <muradm>if profile is broken, may be btingoot with installation media, and attempt to run "guix system reconfigure" <vldn>okay so i need Installation media <vldn>Here is my Updated sway package btw <vldn>many not relevant Imports but works for me <pineapples>muradm: Incorporating your *-{next} packages might take some effort and time. I might try reproducing your issue tomorrow when I'm more willing to get my hands dirty on this <muradm>pineapples: as you whish :) just shared minimal config to run 1.6 i'm running <muradm>vldn: oh man, does your sway even works? i stopped attempting it because of mesa has to be updated because of libdrm, that requires rebuild of like half of the world <vldn>libdrm needed to build a New Version but mesa i'm not sure <vldn>better then 1.5 so far.. <vldn>i built it on my notebook <vldn>2 min to build it i guess <muradm>yeah i see it should be short, what stopped me is dependency of mesa on libdrm <pineapples>muradm: I'm on 1.6 now and I'm unable to reproduce your issue <podiki[m]>core-updates-frozen has mesa 21.1.6 (and updated libdrm) <podiki[m]>you can bump the version and hash for mesa from there up to very current 21.2.1 <muradm>vldn: guix refresh -l libdrm: Building the following 1394 packages would ensure 2539 dependent packages are rebuilt <muradm>podiki[m]: had a plan today or tomorrow for switching to core-updates-frozen <vldn>how to update to core-updates-frozen? <muradm>pineapples: let me try reload now, sorry of gone :) <podiki[m]>on x86-64 at least should be doing okay with substitutes <muradm>vldn: should be like "guix pull --branch=core-updates-frozen" <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 <roptat>of course you can always update to core-updates-frozen and roll-back if it's a total disaster :) <lfam>I think it's worth trying, so you can report bugs :) <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 <muradm>but eventually i hope reaching there <pineapples>muradm: Oh, lol! Anyway! Any idea how much effort would it take to have `tuigreet' for `greetd' working/packaged now that `greetd` is going to be effectively packaged? <muradm>that should be easy, if you look at #49969 i planted a way to have multiple types of greeters <pineapples>muradm: Also, I must say, I'm a fan of your work haha <muradm>there are two configurations provided like plain terminal and xdg terminal <muradm>after we sort out #49969, i may add other greeters, just don't want to do tons of things in one scope *muradm face palming after podiki[m]: ... master is not merged for weeks ... <pineapples>Understandable. Anyway, I really, really want to thank you for you work if it hasn't been obvious that I'm very thankful for it; basically, you have reignited my interest in Guix! :) <podiki[m]>muradm: I think that was roptat with that helpful note <muradm>podiki[m]: does not impact face palming thing :D but yeah thanks roptat <podiki[m]>much as I like to take credit for being on top of things <pineapples>Guix is kind of a beast under the hood but I've always felt like it lacked some user-facing eye candy; after all, the first good impression matters, too, if we want to attract new users :) <podiki[m]>but after install you can be in a full desktop :-) unlike when I've installed Arch for example, just a tty <muradm>guix's eye candy is scheme :) i suppose it will always be for advanced users who are able to understand "declarative" and "functional" terms <podiki[m]>I've replicated my Arch setup now though, xmonad, picom, etc. And yes, having Guile under the hood is so much nicer to work with, and close integration with emacs <muradm>other wise for user there who don't get them, has no reason of switching from ubuntu arch or whatever they got used to <lfam>Guix is definitely missing some eye candy during booting... <muradm>avarage user runs like "apt-get install ..." or "pacman -S ..." and forgets it <lfam>Everything that is missing, is missing because nobody worked on it yet <podiki[m]>or what is it when you have the boot output suppressed and see a picture or animation <podiki[m]>I do like eyecandy, I might have to work on some of that next <pineapples>I'm yet to study and effectively learn Guile but I love the declarative nature of Guix, which is why I've been using it despite the fact I have not been able to reproduce my dream setup <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) <muradm>podiki[m]: plymouth is what is asking crypt disk password, there should be integration between a thing called "display manager" and plymouth for graphical prompt <muradm>i used to have lightdm patched on arch for that, with move to wayland/sway i dont have plans to use it again, instead i'm looking for something more fresh <muradm>those codebases are ancient and don't get updated at all <pineapples>Ideally, we should be able to reproduce the most upvoted submissions of all time on /r/unixporn, a Reddit community centered around hacking on Unix-like OSes for the eyecandy, on GNU Guix <muradm>we need something more flexible and modular for guix <muradm>as far of my understanding, there is strong missing part in all linux environments for having graphical from boot till user <pineapples>as in, all the utilities, programs, applications, etc. required for reproducing them should be packaged so that potential users don't need to get out of their way just to do that <podiki[m]>I saw there was some patches for a lightdm service, but never got finished? have some options there would also be good <muradm>vldn: thanks for breaking my idealism :) seems like i built 1.6.1 sway 0.14.1 wlroots :) <muradm>will try it now and see how it plays with seatd <muradm>if works, i will share more clan way for your packages than copy paste :)