IRC channel logs
2023-05-23.log
back to list of logs
<tschilp>ACTION feels a bit forced to go linux-libre@6.3.3 in the system config to have things working. <tschilp>ACTION just found out that this is actually called linux-libre-6.3 <tschilp>ACTION thinks this note has to be cited: 'Hands out to nckx for compensating my dreadful scheme, and to roptat for pointing me at the needed build system.' Still true. <anemofilia>How can I get the (env) thing in my PS1 when I anter in a guix shell enviroment? <bjc>PS1='\u@\H:\w${GUIX_ENVIRONMENT:+ [env]}% ' <ytc>Hello. What is the difference between installing packages to the user's profile and declaring them in the "guix home" configuration? <anemofilia>I can't copy from my editor to my clipboard for some reason, just a sec <anemofilia>But it's trying to write a lock on /var/guix/temproots/4106 <anemofilia>acquiring read lock on `/var/guix/temproots/4106' <anemofilia>acquiring write lock on `/var/guix/temproots/4106' <anemofilia>downgrading to read lock on `/var/guix/temproots/4106' <dcunit3d>should it be trying to write to /var/guix/temproots/* for clipboard? <dcunit3d>can someone take a look at my logs and help me out? i've been dealing with this for the past 4.5 days and I really can't figure it out. I'm not even starting shepherd at this point. https://pastebin.com/cYJhXGbW <iyzsong>dcunit3d: well, what's the errors? does it works without gdm? <dcunit3d>iyzsong: i don't know. i have been toggling between Slim and GDM every few months for a while. here's an updated debug log (SMH i can't believe I didn't think of enabling that) https://pastebin.com/MJj9HPBU <dcunit3d>i created an alternate config that uses sway, but this requires changing the configuration for vty's from login/mingetty to to greetd. and i'm kinda nervous about that <iyzsong>dcunit3d: i see nothing wrong in the logs.. well, what's the situation, screen black / system freeze at gdm? :\ (i didn't see previous irc logs..) <dcunit3d>it goes to log in, flashes black, and resets the GDM login screen. <anemofilia>anyone have any idea about what could be the problem happening in my instalation? <anemofilia>Couldn't find anything that helped me to discover it <iyzsong>dcunit3d: okay, how about only start i3, put 'exec dbus-run-session -- i3' as the end line of ~/.xsession (need +x bit) <dcunit3d>anemofilia: what were you doing when you got the error? <dcunit3d>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <dcunit3d>Git error: config value 'safe.directory' was not found <dcunit3d>it looks like there's some git.config issue there <dcunit3d>anemofilia: how many generations of your profile do you have? <dcunit3d>iyzsong: .xsession is set to be executable (i checked... quite late into all this, but i checked) <dcunit3d>i think it automatically starts dbus-session. i've been confused about that in the past. <dcunit3d>i can try though. i was just about to try Slim instead <iyzsong>np, i think it's better to go sleep when late, it may solved itself in the next morning :) (happened to me multiple times) <dcunit3d>true, but when i wake up, i will find it just as hard to get help with misc linux issues. i just never actually work beside anyone, so it's hard to get misc info about things i don't know to ask about. <dcunit3d>and everything comes down to making the right bets about "too new, not new enough", like should i bite the bullet and use sway? in the past that's been a mistake and other times, sticking with what's comfortable has led to quite a bit more work <iyzsong>i think your system already got much working fine, just need some bisect to figure where the issue is, it may due to hardware or software issues, or config problems. <dcunit3d>there's two things i didn't keep in source control, per se: <dcunit3d>.xsession and .config/shepherd/init.scm ... <dcunit3d>i generally kept track of what i was making in files like .xsession.eg, but they weren't exactly what I had. i will probably change that, but it left me some flexibility since I needed to tweak these files for each laptop anyways, <iyzsong>that's fine, also I'd start with a minimal working config (eg: without .xsession) and later do small customization incrementally. <dcunit3d>thanks for the suggestions though. i just reconfigured for slim. if i need to try GDM again, i'll definitely seem about "exec dbus-run-session" <dcunit3d>that was something i was suspecting earlier, but when i try to log/output to files from .xsession, nothing happens. since everyone runs with systemd, it's really difficult to find information about older methods <iyzsong>'exec dbus-run-session' is not important, the important thing is at the end it should be a foreground X11 application running in .xsession (eg: not 'i3 &', but 'i3') <jpoiret>sneek, later tell anemofilia: Could you try removing the directories in ~/.cache/guix/checkouts/? <nutcase[m]>Hi all, I'm having problems with fwupd. I have fwupd installed, polkit rules are in /etc/polkit-1/rules.d, dbus policies are included in /etc/dbus-1/system-local.conf, /libexec/fwupd/fwupd is started, daemon ready. When I run `sudo fwupdmgr get-devices` I get "PolicyKit files are missing". What is missing, what should I check? <cbaines>we're close to catching back up to where we were pre core-updates, mesa and rust-team <ChocolettePalett>Btw, is it possible to install Guix leaving only the "bordeaux" substitute in default config.scm? <cbaines>what do you mean by the default config.scm ChocolettePalett ? <ChocolettePalett>The one that either graphical installer or a person creates, before installing the system, where all the users, services etc defined. <ChocolettePalett>I want to override the default substitute servers to leave only "bordeaux" one <Altadil>I think you can do that with modify-services <cbaines>it might be possible through the graphical installer (I think it might let you edit the config file), and it's definately possible if installing using guix system init directly <jpoiret>ChocolettePalett: i think the installer checks for the internet connection by doing exactly this :) <jpoiret>but that's only the graphical installer, yes <mekeor[m]>in guix source files, how do you manage modules? e.g. in emacs, do you get notified about redundantly used modules, or suggestions for needed modules? <maddo>hello, is there something analogue to systemd-homed where I can crypt my home on suspend for a laptop? <maddo>also is there anything going on with secure boot support? <jpoiret>no and no unfortunately. we have some support for pam mounts but I don't think they support your use case of crypting home on suspend <jpoiret>why do you specifically need to crypt on suspend though? what's the setup you're thinking of? <jpoiret>would your home folder be encrypted at rest, and the decryption keys dropped on suspend? isn't that very problematic for user-space once you resume? <jpoiret>secure boot has not been investigated at all. It's quite complicated to get working properly, and Guix's design decisions make it harder to integrate with it <maddo>more info about homed are available here, they make laptops, which are not always turned off, much more secure if you are away from it (coffee breaks for example) for a few minutes <abrenon>any recommended strategy for when a package you use daily has been broken by the latest core-updates merge ? <cbaines>abrenon, strategy towards what goal? <abrenon>towards being able to upgrade while still using that package ^^ <cbaines>I've only just guix pull'ed the core-updates changes in yesterday, so my strategy to avoid breakages was just to wait for others to find and fix problems <abrenon>like, I have a patch, so I could build it locally <cbaines>abrenon, is it installed in your users profile? <abrenon>oh, I thought that was just me, so that is a viable strategy ? ^^ <abrenon>yeah, I now have separated my users package installed in my users profile and the rest of the system <zimoun>Running “guix pull”, I get: « GC Warning: Repeated allocation of very large block (appr. size 1073741824): May lead to memory leak and poor performance » <abrenon>so I can actually upgrade the system <abrenon>but I usually try to keep everything in sync: guix pull, guix system, guix package <abrenon>but regarding my patch, since it's not a new version, I thought that if I was to add it to my private channel, I wouldn't know how to tell guix what definition to pick <cbaines>abrenon, are you using this package in your system definition or in a profile somewhere? <abrenon>(that's really stupid actually, that's just my music player, I like to listen to music while I work) <cbaines>maybe you can install your patched version (maybe using a different name temporarily), until the fix makes it's way in to Guix <abrenon>yeah, a different name why didn't I think of that <abrenon>sorry I was only considering the version <abrenon>but you're right I can just name my patched version quodlibet-tmp-fix and that's it <abrenon>and sorry for the not-so-useful question <cbaines>there's also --do-not-upgrade, but then you're mixing old and new, which can cause other problems <zimoun>cbaines: thanks but I hit it just running “guix pull” with the configuration ’channel-with-substitutes-available’. <abrenon>ok, I was also considering an inferior but I thought it would be a lot of trouble for such a small inconvenience <cbaines>zimoun, ok, I guess that could be an issue with channel-with-substitutes-available, but I don't know how that's meant to work <zimoun>the commit is not broken (guix pull passes when enough RAM). The exploding is about guix-package-cache.drv that is always locally computed. <zimoun>channel-with-substitutes-available picks commit that all the other derivations are substituable. <zimoun>BTW, I do not see a commit message fixing this issue. <abrenon>completely unrelated but I was also curious: what's the difference between --target and --system ? I was told by guix that it couldn't cross-compile librsvg because of cargo when I used --target, but it tried to compile it with --system, only to fail at some point with "Unknown architecture for asm!" <zimoun>the issue that building the package cache requires more RAM that my laptop has. So I cannot run “guix pull”. <cbaines>abrenon, with --system you're building for that system (which means you need to be able to run code for that system). With --target, you're cross building to some target, which doesn't (usually) involve running code for that system <cbaines>zimoun, which system have you seen pull'ing e499cb2 work on? (and how much RAM does it have) <abrenon>so the argument to --system isn't an architecture ? (e.g. i686-linux) <abrenon>what does the 'gnu' in the resembling target i686-gnu-linux mean ? <cbaines>that shows soem system and target pairs. Cross compilation is only done from x86_64-linux, as that's the common use case. <zimoun>My laptop (x86_64). Just running now “guix pull” with only the default channel using channel-with-substitutes-available. <abrenon>ohhhh so system is a kind of "source architecture" ? <abrenon>I could not run a --system=powerpc-linux on my x86_64-linux machine ? <cbaines>zimoun, I'm asking which system you've seen it work on, I know you've said it doesn't work on your laptop <cbaines>abrenon, you could run --system=powerpc-linux on a x86_64-linux machine, providing you used qemu-binfmt to enable running binaries for that system <zimoun>Ah, it passes on my desktop machine with 64GB of RAM. <abrenon>and so I guess that's what guix does ? <cbaines>zimoun, OK, that's interesting, I'd assumed that guix pull would never work for that commit. <cbaines>abrenon, in what context? At least on the build farms, native hardware is used as that avoids hitting bugs with the QEMU emulation <zimoun>Basically, the problem is about computing guix-package-cache.drv. <abrenon>in the context that I'm trying to generate a live system for my old i686 box from my modern x86_64 one <zimoun>If that commit introduces an issue, then it is not clear for me which one and which other commit removed that issue. <cbaines>abrenon, so, given that x86_64 hardware can generally run binaries for i686, you should be able to take either approach, using --system or using --target (but the arguments are different) <cbaines>zimoun, as I say, that commit I linked to was intended as a fix (make things better), it includes the problematic commit in the description <zimoun>Do you mean you removed a potential cycle? <zimoun>cbaines: thank you! And thanks for the pointers. It avoided me wasting some time. :-) <abrenon>yeah, but --target won't work for rust package because of cargo IIUC <abrenon>whereas --system would because the i686 code would be compiled by some i686 software ? <cbaines>some software and build systems don't support cross builds, which I think is what you're hitting with rust/cargo <abrenon>thank you very much for your answers ! <bilke>Dear guix-people, guix noob here: I have made my first patch submission some time ago (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62851, just a simple version update) and wanted to ask if I have to do some additional steps to get this into guix? Is there some CI testing the change? <cbaines>if you click on the QA Failing image near the top, you'll get to qa.guix.gnu.org <cbaines>bilke, looks like there are problems building python-pyopencl with your changes <bilke>ah thanks a lot! Will have a look into the pyopencl issue. <efraim>hmmm, it looks like my guix-publish service isn't working ATM :/ <efraim>I can query it from the host machine but not from the others, there it just times out <Altadil>Hi, I am trying to use guix publish to avoid building packages on both my guix systems. But it appears I’m doing it wrong, because my poor laptop still tries to build stuff I just built on my desktop. ^^ <Altadil>Herd says guix-publish is running. It is configured with advertise set to true <Altadil>and the laptop as guix-service configured with discover set to true as well <Altadil>How can I identify what part I’m still missing ? <civodul>Altadil: hi! guix-daemon is supposed to keep /var/guix/discover/publish updated <civodul>but it seems to be broken for me right now <Altadil>I don’t even have that folder at all, it seems. :) <Altadil>Oh, is it the one defined as "cache" in the service config ? <andreas-e>abrenon: Just reading up on your --system question. It also works when you can offload to a physical machine of that architecture. That is how cuirass works on berlin, I think. <bjc>is there a way to configure ‘guix offload’ to send a wake-on-lan packet before it starts building? <cbaines>zimoun, ok, although from the log that doesn't involve building the package cache, which is where the problem seems to occur <zimoun>yeah, I am openning an issue for that. <cbaines>I think the answer might be "packages that have themselves as inputs are bad, we should avoid that" <zimoun>The bug is that channel-with-substitutes-available is returning a “bad” revision. <zimoun>One of the aim of channel-with-substitutes-available was somehow to be sure that running “guix pull” will lead to a revision that builds. <abrenon>sneek: later tell andreas-e thanks ! <abrenon>'later everyone thanks for the help again <jpoiret>janneke: i'll reply to those by mail, but no I hadn't seen the new tag. Regarding the resolve-interface, you can't use-modules cross-base in base, otherwise you get a cycle <janneke>jpoiret: tried it, seems to work for me... <jpoiret>I wonder how ok it would be to have a cycle here. It only asks for trouble down the line though. <janneke>jpoiret: cycles are OK as long as the modules only depend on procedures of the other module, and not on top level variables, iiuc <sneek>andreas-e, you have 1 message! <sneek>andreas-e, abrenon says: thanks ! <acrow`>the guix binary on one of my guix systems continues to misbehave; so, 'guix pull' will not successfully complete and update my guix binary. Having been warned not to try to build the guix package manually (I don't entirely understand why this could not work), the problematic system has revealed a new clue and I thought maybe someone here might immediately see what's happening and see how I can fix it. Essentially, the same guix binary <bdju>FYI dolphin-emu is still failing to build <nutcase[m]>Hi all, I'm having problems with fwupd. I have fwupd installed, polkit rules are in /etc/polkit-1/rules.d, dbus policies are included in /etc/dbus-1/system-local.conf, /libexec/fwupd/fwupd is started, daemon ready. When I run sudo fwupdmgr get-devices I get "PolicyKit files are missing". What is missing, what should I check? <ae_chep>The editor I'm using doesn't show non-ascii characters (I'm on a foreign distro). I suspect I may have a locale issue but I don't know how to prove it <jpoiret>ae_chep: you clearly have a locale issue <jpoiret>acrow: you might want to try removing the link ~/.config/guix/current, as well as the /var/guix/profiles/per-user/..../current-guix-... links <jpoiret>also `rm -rf ~/.cache/guix/checkouts/`, then guix pull again <jpoiret>nutcase[m]: you might want to start `dbus-monitor --system`, then retry and have a look at the logs, it might have some more info <jpoiret>you probably need `sudo dbus-monitor --system` <bdju>oh my god swaylock is broken <ae_chep>jpoiret: my GUIX_LOCPATH variable is set, but I'm not sure it's set to something that exists. I removed glibc-utf8-locales a little while ago <ae_chep>(in trying to figure out what was happening) <bjc>jpoiret: are you still using pipewire? <bdju>I vote for rolling back the breaking swaylock change <bjc>jpoiret: can you share your config for it? i can't get wireguard started. it's complaining about systemd stuff, and ‘strace’ shows it trying to set up inotify on ‘/run/systemd/user’ when it fails <bjc>oh, i thought that was necessary <jpoiret>i really don't have any config for it <bjc>without wireguard it doesn't seem to probe my usb sound card <jpoiret>bjc: aren't you confusing it with wireplumber? <jpoiret>yes, I do use wireplumber, but have no config for it as well <jpoiret>nutcase[m]: right, I thought there would be some more info <bjc>oh god, i so am. and i have been for days <bjc>my brain needs a scrub <bjc>no, i made a typo. i *am* using wireplumber <jpoiret>when did you start getting these issues? <bjc>i just switched back to elogind to try and fix this <bjc>i was using greetd and had the same problem <jpoiret>nutcase[m]: you might need to manually start polkitd as root and see what it spews out <bjc>seatd/greetd yeah. i'm not sure which part of that handles what <bjc>i've pulled seatd/greetd and am using just elogind now <jpoiret>seatd is an alternative to elogind, while greetd is just a greeter system. Think of the latter as a DM. <jpoiret>you can use greetd with elogind no problem <bjc>wait. i may have forgotten to reconfigure *again* <jpoiret>polkit will *not* work without elogind <jpoiret>that's the main problem of using seatd <jpoiret>uhhh, now I'm conflating two people's issues :p <jpoiret>remark still stands for wireplumber though. It uses non-trivial stuff that I don't expect seatd to handle. <bjc>jpoiret: lemme reconfigure and reboot. i think i just forgot that crucial step <jpoiret>nutcase[m]: does /home/flake/.guix-profile/bin/pkttyagent exist? <bjc>it's nice that ‘system build’ exists independently of ‘system reconfigure’, but i wish i didn't constantly forget <bjc>that's my middle name <nutcase[m]>jpoiret: /home/flake/.guix-profile/bin/pkttyagent exists and links to /gnu/store/86madqdw2nz72m26x50dl5kv23b4fm8f-polkit-121/bin/pkttyagent <jpoiret>nutcase[m]: what if you add `G_MESSAGES_DEBUG=all` as an env variable to the polkitd invocation? <nutcase[m]>it's /gnu/store/k9xj13ag4l5rv4cg8p1i36vrdirwz3jd-fwupd-1.8.14 <nutcase[m]>the bin is /home/flake/.guix-profile/bin/fwupdmgr <nutcase[m]>btw I have (simple-service 'fwupd-polkit polkit-service-type (list fwupd))) in my system config.scm <bdju>apparently rolling back and restarting sway won't even fix swaylock. this is extremely horrible <nutcase[m]>and (simple-service 'fwupd-dbus dbus-root-service-type (list fwupd)) <bdju>it just doesn't work anymore <bdju>someone named Benjamin enabled PAM which breaks setuid apparently <bdju>I can't lock my PC, I feel like I can't even get up or go to sleep now <bdju>I restarted my session for another reason earlier which made the new broken swaylock take effect I guess <dcunit3d>bjc jpoiret i was able to rebuild my system last night from a xorg-based system to one with elogind/greetd and when it was ready, i reconfigured without restarting. then i tested restarting the tty's one by one until i could log in. it was a very enlightening experience <bjc>can you just remove it from ‘setuid-programs’? <bdju>from the sounds of the relevant thread the PAM support isn't properly working either <dcunit3d>yeh i'm about to start adding stuff like that to my system. is there an issue? <bjc>i haven't tried the swaylock changes yet, but it not requiring setuid is a win in my book <bjc>it means i can home configure it, or ‘guix install’ it, which is nice <bdju>well good luck getting it working at all <bjc>oh, if pam doesn't work then that's a problem, for sure <bdju>he's posted some hideous many-lined thing he used to get it to work, looks insane compared to the little setuid line I have that was working perfectly until recently <bjc>oh, it still requires system config level stuff. that's a bummer <bdju>and anything I try to test to see if I can fix swaylock seems to likely involve restarting sway aka closing absolutely everything I have open <bdju>I don't really understand why rolling back didn't work <bdju>how would I use that here? <ae_chep>jpoiret: Am I supposed to use glibc-utf8-locales-2 now? The version without the -2 no longer exists <jpoiret>nutcase[m]: it needs to be installed system-wide <jpoiret>polkit picks up the polkit rules in specific directories that aren't /etc/polkitsomething on guix <jpoiret>bdju: you would need to roll back the system <nutcase[m]>jpoiret: I tried that just now and it makes no difference <nutcase[m]>it's now /run/current-system/profile/bin/fwupdmgr -> /gnu/store/k9xj13ag4l5rv4cg8p1i36vrdirwz3jd-fwupd-1.8.14/bin/fwupdmgr <jpoiret>ae_chep: just use glibc-locales, it is smaller now apparently <jpoiret>the older glibc-utf8-locales is now hidden <jpoiret>nutcase[m]: you'll need to reboot probably <jpoiret>for dbus/polkit to pick up everything <jpoiret>bdju: the proposed change from Benjamin is exactly the proper workaround for now <jpoiret>nutcase[m]: everything should be handled by adding the polkit package to the system profile <jpoiret>the screen-locker-service isn't made for non-setuid screenlockers it seems <jpoiret>i'll try reviewing muradm's patch tomorrow <jpoiret>nutcase[m]: alright, my bad, it's not as simple as this. You need to add (simple-service 'fwupd polkit-service-type (list polkit)) to your services <jpoiret>tschilp: yes, the ESP partition often gets filled up by logs from ... Linux itself iirc? <nutcase[m]>tschilp: Yes, I also had "No space left on device" before <jpoiret>you need to clear the dump files in /sys/firmware/efi/efivars/ <bjc>jpoiret: indeed, i just forgot to reconfigure my system. with elogind, pipewire works great. thanks for being my rubber duck =) <tschilp>OK, good to know -- the only problem is, that this rendered my system unbootable. At first I thought it's a thing with my harddrive (it's not -- smartctl from my other box actually tells me all is very fine). So I got myself a new one -- I just tried to install from the current installer, same thing on the last step... <jpoiret>you'll need to boot with a live usb, remove those dump files, then reboot <jpoiret>then you can install properly, or try just fixing the efivar entry without reinstalling anything <jpoiret>you can use the installer since you have one :) <tschilp>that's exactly what I did on a new drive, please see above :) <jpoiret>just switch to a tty and remove those pesky dump files (that reminds me I should also remove mine :) ) <jpoiret>did you remove just the dump- files? <tschilp>I installed on an empty, drive freshly unpacked <tschilp>so this feels a slightly bit sketchy, once more ;) <jpoiret>efivars are not stored on a drive, they come from the UEFI storage <jpoiret>it's stored in your motherboard and is communicated to the OS via UEFI shenanigans <tschilp>I honestly did not want to go that deep <tschilp>guix once more forces me to do stuff, I've never planned to deal with... <jpoiret>it's just a matter of rm /sys/firmware/efi/efivars/dump-* <bdju>it never really gets better. enjoy the ride. <jpoiret>tschilp: this time it really is not Guix's fault <jpoiret>any Linux distribution has the same issue, but maybe they clear it up automatically for you (which might not be the best course of action either) <tschilp>so fire up my good old debian-rescue usb to save my guix ;) <jpoiret>you can use the guix installer for that, no need to use debian-rescue! <tschilp>but right now I'm writing from my bullseye box ;) <jlicht>nutcase[m]: I may have missed quite some context, but I opened an issue some time ago about something similar, with two potential workarounds <nutcase[m]>jlicht: yes, I came across your issue and suggestions the other day. Unfortunately, I am also not that familiar with that. In the first fix, isn't it required to treat the rules.d/ the same way as actions/? Ot is this already handled in 'set-polkit-rules-dir ? <Ricky>hey, I have a bug with logging in my account in guix, when I enter my password to log in I just loop back on the menu to log in, where I see my username. Yesterday I updated some packages, so I guess there is a problem with that. I'm still studying the manual so I don't know what to do. can someone help me out? <nutcase[m]>jlicht: is there something I can test that may help you with that issue? <tschilp>jpoiret: I just cleared those dumps, naively hoping for my 'old' disk to be revived... I guess the full efivar-situation blew something <jpoiret>you might need to reinstall the bootloader but that might be it <janneke>Ricky: you may try logging in from a console and guix package --roll-back <tschilp>is there a way to know when this folder gets too full (I'm thinking about something like guix weather $PACKAGE)? <Ricky>janneke thanks. yeah I just saw somewhere that I had to do that. I entered "c" to open the command line, now I see the grub> terminal. so I guess I enter that here? <Ricky>sorry if it's a dumb question, like I said I'm still busy reading the manual on my own but since it's urgent I'd rather ask <tschilp>Any hint how I would reinstall the bootloader on an unbootable disk from the guix live usb stick? <janneke>Ricky: ah, yes; that depends on which update broke your login, if it was a system reconfigure you can probably select a previous system generation from the GRUB menu <Ricky>janneke I already tried that just in case, but it was a package update so it didn't do anything. I'm trying to figure out how to log in from a console to enter "guix package --roll-back" now. <Ricky>janneke seems like I need to login there, but it doesnt want to in the console. Even though Ive never had a problem normally. <janneke>Ricky: ouch. can you login as root, and then somethnig like: su - ricky? <tschilp>ACTION is trying grub-install /dev/sda1 and feels very sick from the answers... <tschilp>needless to say I had to run guix shell grub-efi to have x86_64-efi available at all... <Ricky>janneke I'm trying but it just says login incorrect. I have no idea why. I'm literally giving it the name I use. I have no password associated to my profile, but the root I have one and I'm using it. but to no avail. <rekado>cups says “Backend /gnu/store/x…-cups-server-bin/lib/cups/backend/dnssd does not exist” <rekado>I couldn’t find where I could configure a different location <rekado>it clearly should be /gnu/store/…-cups-2.4.2/lib/cups/backend/dnssd, not the union directory of cups-server-bin. <rekado>perhaps the problem is that cups-minimal is used for the service <tschilp>ACTION thought the answer from 'guix shell grub-efi && mount /dev/sda1 /boot && grub-install --efi-dir=/boot/EFI /dev/sda1' sounded good, but rebooting blew this illusion <janneke>Ricky: there may be some tricks like booting from an installer USB and resetting /etc/shadow, but yeah, if you cannot login that's pretty much it <Ricky>janneke think I got lucky. I was able to run it on another desktop environment, stumpwm. And I rolled back the packages. <Ricky>If I reboot my pc and go on my main desktop environment, will it that rollback be saved? <Ricky>or will it automatically go on the latest version? <janneke>once roll-backed it will stay roll-backed, until you manually switch generations or --upgrade again <rekado>it seems to be impossible to kill cups <rekado>I disabled the cups service, stopped it, and killed the cups process, but it always respawns <rekado>gah, I just want to print a document for tomorrow <Ricky>but first I'll back my things up <rekado>there’s a separate cups problem: I cannot use authenticate via the web interface any more and cups-brf complains about not running as root <acrow>jpoiret: Removing the links seems like the right thing--but the outcome is the same -- gnutls.go failed, load-thunk-from-file: Invalid Arg, and undefined symbol __libc_pthread_init, version GLIBC_PRIVATE.