<bmk>Okay, this really will be a quick question this time: <bmk>What features do I not have access to while using Guix on another GNU/Linux system? <bmk>It seems to me that'd you'd basically just lose system generations and configurations, but still have vm/docker-image/(containers, maybe?) and deploy? <bmk>I tried to RTFM, but the manual isn't super clear on what is and isn't available <leoprikler>you basically lose anything that deals with your system generations, because you don't have any <leoprikler>notice, that this also concerns packages, that need to be installed system-wide/as a service, though <bmk>GuixSD has a few little teething issues for me, so I'll bounce over to another distro for my laptop for now <leoprikler>so stuff like mumble-service-type? Nope, need to hack one up on your own or use whatever you base distro offers <leoprikler>though possibly this might get better with guix home <bmk>It's a shame; Guix is so close to being perfect for my personal use <bmk>I'll give it a year or so and it'll be right as rain <zacchae[m]>Is there much functional difference between making an efi-raw, volatile, image that takes up the whole drive, and a normal system install (guix system image vs guix system init)? As far as I can tell, the only difference would be that the image option will make partitions for you, and you would loose the ability to make it LUKS encrypted. <acdw>hi guixers! I am wondering what i need to tweak to move /gnu/store to say, /home/gnu/store. Due to a small disk for my /, /gnu/store won't fit there. I'd rather not have to repartition if I can help it. Thanks! <podiki[m]>i've done that there, but not for guix system <acdw>podiki[m] yep! debian 11 <podiki[m]>okay, so depending on what you have going, you may need to stop the guix build service in order to delete/move things (and maybe easiest if you are starting fresh) <podiki[m]>steps: make the directory you want to use, bind it like `sudo moun t--bind /path/you/want/to/use /gnu` <podiki[m]>then you'll need to modify the installation script of guix to not check for existing /gnu (since it does exist from the bind mount) and to move to the folder e.g. `mv /tmpdir/gnu/store /gnu` <podiki[m]>then add it to your /etc/fstab to have in future reboots `/path/you/want /gnu none defaults,bind 0 0` <podiki[m]>(and I have it running this way on a laptop on top of Arch, no problems, just the install needs those tweaks) <acdw>honestly i can start fresh. so should i just like systemctl stop guix or something <acdw>podiki[m]: ohhhh you mean like, totally remove guix, restart <podiki[m]>well if you have stuff installed, I guess you can just move over your /gnu/store to where you want it and follow those steps <podiki[m]>(I didn't do that, but I think should be fine, again, stopping the guix daemon first) <acdw>i don't have anything /installed/ yet, per se... but i can try that <acdw>i'll try it and let you know! thanks :) <podiki[m]>then skip the install script modification, just need to do the bind mount basically <podiki[m]>let me know how it goes, you are not the first so maybe should add it as something for the cookbook? <acdw>is the cookbook wiki-style? <acdw>okay on the `mv /gnu/store /home/gnu/` invocation I've got a lot of `mv: cannot remove '/gnu/store/...drv': Read-only file system` <acdw>well i can't `rm` that stuff either <podiki[m]>make sure the daemon is stopped and any guix processes <podiki[m]>cookbook is not wikistyle, but is meant to demonstrate more real world how to do stuff in guix (as far as I can tell) <acdw>the issue was it was mounted <acdw>then yes i think it should be added <acdw>podiki[m]: I /think/ I've got it... it's computing the guix derivation for 'x86_64-linux' <podiki[m]>check what is filling up on the disk, and you should be set <podiki[m]>acdw: you are back. was just saying double check what disk is filling up, and should be all set (don't forget fstab) <acdw>ummm also what was the fstab <acdw>(sorry i'm on kiwi rn and it's doofy) <podiki[m]>`/path/you/want /gnu none defaults,bind 0 0` <acdw>thank you :) i was about to check the logs <podiki[m]>no worries! and for future reference this channel is logged, you can find it on the guix website with a handy search <acdw>lol yep :) thanks so much <acdw>i can't wait til i have my trusty emacs and can better-search the info manual <podiki[m]>there is a guix package for emacs ('emacs-guix' in guix) that is helpful too <acdw>i saw something like that somewhere... i should see how it helps out <shoshin>hello! i just installed GuixSD on a linode instance following the recipe in the cook book. i was successful, but there were a few bumps in the road, and i thought i might contribute some additional info to the cook book article. anyone know where i might look to contribute? <podiki[m]>shoshin: I don't know the details exactly, but I think the cookbook is treated as any other source (submit a patch against the cookbooks source files) <podiki[m]>or else file a bug report maybe with what you encountered that needs to be changed? <shoshin>ok. i'm looking at the sources right now and i'll see if i can find it. otherwise i'll email the list. <podiki[m]>thanks for contributing! (I've been meaning to add to the cookbook too, so that would be a good first step for me too...) <shoshin>its nice to have the recipes to get started. learning bit-by-bit :) <shoshin>cool i think i found the source, thanks :) <acdw>does it take like,,,, a long time to build with guix? I've installed emacs-pgtk-native-comp on arch and it didn't take this long to build, i feel like ***notzmv is now known as zimmybot
***zimmybot is now known as notzmv
<vagrantc>acdw: depends on several factors ... substitutes available and enabled? are dependencies available in the store already? <acdw>it was taking a long time building libgccjit, acutally even failed <acdw>i do think my computer fell asleep while building, that might've done something? <vagrantc>guix rebuilds the entire chain of software any time anything fails somewhere in the dependency chain, recursively... <vagrantc>er, any time anything *changes* somewhere in the dependency chain ... <acdw>yeah this is a fresh guix install <acdw>so def building evetrything... it failed building ... libgccjit-10.3.0.drv <vagrantc>or do you *want* to build everything from source? then the answer is probably "yes, this is going to take some time" <vagrantc>installed on a foreign distro or Guix System? <lfam>What depends on libgccjit 10? <acdw>i don't care about building everything from source .. but the emacs-pgtk-nativecomp is sourcebuilt b/c ther's no build farm afaik <acdw>it's a foreign distro, debian 11 <lfam>Is that a package in Guix? <lfam>Or is it from a 3rd party channel? <vagrantc>acdw: and from the guix package in debian 11, or from the guix binary installation ? <lfam>Looks like libgccjit-10 is from that channel too <acdw>guix binary installation vagrantc <vagrantc>not likely to get substitutes from arbitrary channels... *vagrantc hasn't done much of anything with guix lately ... <acdw>i'm not 100% sure what that means.. i'm extremely new to guix <acdw>me neither vagrantc.. thanks for the thoughs :) <acdw>i'm gonna try building it again w/o letting my computer sleep <lfam>That 2nd link describes how to limit the amount of building you do, but unless this other channel has a build farm, there won't be substitutes for it at all, and you'll have to build whatever packages are defined there <acdw>libgccjit-10 build failed on void as well <lfam>"collect2: fatal error: ld terminated with signal 9 [Killed]" <lfam>Did the user kill it or something? <acdw>i don't know, the issue only has that info <lfam>Its not that easy to find the real error in a hundred thousand lines of log <lfam>I think the person running that channel is actually in this irc channel acdw <acdw>it is late in the US, they might not be around <podiki[m]>libgccjit can take a long time to build (but I haven't seen it updated, building emacs is faster) <acdw>podiki[m], thanks! I'm trying it again here, it might've been my fault <podiki[m]>it has built for me from that channel, but on a guix system <podiki[m]>(and I've built it before on Arch, but different packaging) <acdw>well, i'll keep yall posted! and possibly write a comment on that issue <shoshin>acdw: maybe it doesn't help you, but my first experiment with Guix was on top of my debian, but i now have guixSD on a Linode instance. maybe it doesn't help to have your Emacs on a remote machine but, i'm learning a lot with a machine that doesn't go to sleep and i can leave building stuff <acdw>shoshin: mm that's not a bad idea tho... i could at least try building the thing and make it like a ... substitute or smethig <raghavgururajan>podiki[m]: Hi! I remembered that you use stumpwm and wanted to ask if you know how to config timedate on top-right corner and workspaces on top-left corner, like in i3, dwm etc. <acdw>hey ! i'm tryig to build libgccjit-10.3.0 from your guix channel <acdw>for emacs-pgtk-nativecomp <acdw>and it failed the first time... tho that might've been b/c of me letting the laptop go to sleep <acdw>so i'm building it again on debian 11 and it's going slow, but still going so far <flatwhatson>the libgccjit failures i've seen previously, it's because the computer ran out of memory. <acdw>ahhhh that kinda makes sense actually, yea <acdw>okay i'm going to closeout firefox and all and just build... i'll comment on that one other issue with my build file if it fails again <flatwhatson>if it fails, do guix build --log libgccjit and upload the log to a github issue and I can have a look <acdw>will do ! thanks so much :) <flatwhatson>that libgccjit build is pretty heavy, i can tune configure flags to make it less demanding but haven't got around to it yet <rgh[m]>Does anyone know if GuixSD will boot from an lvm volume with btrfs? <MysteriousSilver>flatwhatson: what's the difference if one uses native-comp with libgccjit@9.x <flatwhatson>MysteriousSilver: worse performance, gcc-10 had bug-fixes for libgccjit which native-comp needs to work around <podiki[m]>raghavgururajan: been a while since I used Stump, and I think I always used with polybar <iskarian>Is it possible to, essentially, specify --without-tests for all the packages listed in your command? <iskarian>so, `guix build <100 packages> --without-tests=<those packages>` <tpefreedom>I get "error: failed to get list of supplementary groups for 'username'. <rgh[m]>bricewge: Cool! I've installed it on a machine but it wont boot so it looks like the problem is elsewhere. ***janneke_ is now known as janneke
<bricewge>Do you used `mapped-device` for the LVM part? <bricewge>The btrfs doesn't involve any specific guix idioms <rgh[m]>Do you know if xfs is supported? <rgh[m]>I get the impression that it isn't but I haven't seen anything concrete. <rgh[m]>It's interesting that bcachefs is in the list but not xfs. Do you know why xfs isn't? ***rowanthorpe1 is now known as rowanthorpe
<bost>Is there any estimation how many people use Guix? Or have many installations we have? <bost>we have 273 people in this chat, plus ??? ***wielaard is now known as mjw
<efraim>can I set the GUID on a partition when creating a disk image? where is the partition record defined? <efraim>the record-type of partition is in gnu/image.scm <attila_lendvai>this is driving me mad: i'm used to having a clipboard manager, and go back to previously copied texts, but when i select an older entry in the gnome clipboard history, then emacs sees NIL in the x clipboard; (gui--selection-value-internal 'CLIPBOARD) returns nil. any hints? <attila_lendvai>it's not the internal thing, same for (gui-get-selection 'CLIPBOARD) <attila_lendvai>hrm, this is probably a bug in gnome-shell-extension-clipboard-indicator, because after selecting one from the history, i get: $ xclip -o -selection CLIPBOARD => Error: target STRING not available <attila_lendvai>i installed v1.3.0 (i.e. stable)... then does a guix pull get me the latest from the master branch of the git repo? i'm happy for pointers to read. my ultimate goal is to update a guix package, and test it locally. <attila_lendvai>is it safe to just pull master as my main linux? i thought i'm only pulling the updates to v1.3.0 <attila_lendvai>sorry for all these questions, one last: what's the high-level outline of the workflow for patching a package, and trying it locally as part of my guix system reconfigure? <apapsch>attila_lendvai: yes, it's master branch. It can be unsafe. The other day I updated my custom guix from upstream and got a mysterious "no code for module (xxx)" error <apapsch>I tracked it down to somebody forgetting to add a Scheme file to automake config <attila_lendvai>apapsch, hrm... and is there a way to make it more safe? i.e. pulling from the version-1.3.0 branch? but then it doesn't have any updates since the release... <apapsch>re your ultimate goal: for quicker iteration times might be easier to define a package outside guix tree inheriting from the in-guix package and run `guix build -f your-file.scm` <attila_lendvai>apapsch, but it's the gnome-shell-extension-clipboard-indicator that is integrated into gnome... i.e. to properly test it i need to update the entire system, not just build the package. i already have a channel set up... can i "shadow" the guix package with my own copy in that repo? <apapsch>I don't think there is a technical way to make master more stable, it's an organizational thing <apapsch>(and it's mostly stable, worth the risk) <attila_lendvai>well, that was my 4 days experience also, but i'll keep this in mind <apapsch>in your operating-system config you add gnome packages. you can replace the in-guix package with the package from your channel <apteryx>do we have a package for adding the python 'test' module which is not installed with our default python? <apteryx>uh, and it depends on a ton of fonts <attila_lendvai>apapsch, i managed to update the package, thanks for the hints! now, how do i designate a specific channel when i install a package? the doc doesn't seem to get me all these non-trivial use-cases... <roptat>attila_lendvai, you can't "shadow" a package, but you could use your package instead of the default one. Like, define a gnome package that uses your package instead of your default one, and use that package in the gnome service instead of the default one *attila_lendvai goes to eat and thinks about this... thanks! <roptat>when you install a package with "guix install" or "guix package", it will look for all packages that have the given name and select the one with the latest version <roptat>if both packages have the same highest version, there's no way to make it choose one over the other *attila_lendvai has managed to update the package and needs to restart the gui <attila_lendvai>oh well, it got worse... probably a gnome vs extension incompatibility <apapsch>attila_lendvai: as the saying goes "out of the frying pan into the fire" :-) <attila_lendvai>looks like none of the later releases work than what's in guix. and it's persisting the history on disk, which is even worse, i'll need to look into that too. damn, i miss gpaste, i'd prefer not to mess with this, but it's crucial for my workflow... <roptat>oh, maybe you need the same release series as gnome itself? <roptat>our gnome is quite outdated now, although there is some work to update it <apapsch>gnome extensions are not sandboxed and they like to break API between releases <roptat>it feels like everytime it gets close to be up to date, gnome releases a new version and the people working on the update focus on that ^^' <apapsch>roptat: how do arch linux and other rolling distros achieve their up-to-dateness? more people, less manual work? <roptat>more people, less work needed to adapt to their distro <the_tubular>Dumb question, I'm trying to learn emacs from guix perspective, do I need to bother with ELPA, MELPA and the likes ? <dstolfa>that's up to you, some people choose to base their emacs setup around guix, some choose to do it through various elpa sources <ruffni>g'day! i've set up a fresh install of cuirass (with a cuirass-service). now i'm waiting for it to start building. does cuirass only trigger builds on a git repo update? is there a way to trigger new builds? <leoprikler>for the record, guix has a marvellous elpa importer and unlike gs-elpa that one has been maintained since 2015 <the_tubular>I mean most pakcage that a a emacs noob is going to use are already going to be in the repo right ? <the_tubular>There's hundreds of emacs package in the repo right now <leoprikler>there is certainly a point in the curve where you hit "so experimental, that no package manager will have it" before at some point falling back to more reasonable defaults <dstolfa>my experience with years of emacs (after getting really pissed off many times for my config breaking across emacs version upgrades) is that i actually just want to depend on as few things as possible, and then my configuration can survive for years <leoprikler>but yeah, Guix should have everything to cover your needs <dstolfa>you'd be surprised how many things emacs has built-in that is only marginally improved by third-party somewhat unmaintained things in melpa <dstolfa>yeah, i just use emacs autocomplete, never installed anything <ss2>The thing about Emacs itself is, that is has enough to offer even before you need to consider using any plugins. At some point I went all vanilla, and had slowly added several plugins after feeling comfortable with the basics and pulled them in to appreciate the extras that the plugins offer. <leoprikler>tbf I still have a bunch of emacs, but I manage them using the holy trinity of Guix, leaf and customize <dstolfa>i have like, 12 or so, which my org config just bootstraps on startup if needed <lfam>Good, the patches worked :) I booted and logged in successfully <lfam>I need to write my email reply <muradm>lfam: after yesterday discussion i would suggest to move seatd to gnu/services/base.scm as well <muradm>as we clarified purpose of it and clarified lack of connection to freedesktop, be it official or technical <muradm>lfam: from the list you may see that i added libseat package also, which is actually is standalone lib, on which applications should depend, not on seatd daemon package <muradm>pineapples: i think i hit your Alt+PrnScr+k issue today :) <muradm>that happened when i SAK'ed on sway/gtkgreet greeter terminal without login <muradm>i don't think it is show stopper, wayland/sway is young in under active development, there are many such issues <pineapples>Well. This issue is not reproducible under the GNU/Linux distribution of the choice of the developer of seatd AFAIK <muradm>at least i know how to reproduce the case, whenever i will do reboots again, i will try to look at debug logs to identify the root cause <pineapples>at least when using the version of seatd built from the `noholdtty' branch <pineapples>however, with this version, it's still reproducible under Guix <efraim>I ran into the bug about cross compiling to yourself when building system images <muradm>once we identify the root cause, we can solve it where it will be targeted, be it sway, wlroots, greetd or seatd <muradm>since this does not happen on pure terminal with seatd/greetd, i tend to think that it should be related to wlroots/sway more than to seatd/greetd, but i'm not sure at this point of course, just speculating <pineapples>My bet is on GNU Shepherd because, according to the system logs, it terminates `seatd` on every SAK attempt even though the latter doesn't have a file descriptor referencing `/dev/console' open <pineapples>muradm: Hmm.. Actually, months ago when I was still troubleshooting this, the seatd developer told me that the virtual console interface (again: or whatever it is called) would be improperly handled by wlroots on unexpected Wayland session shutdowns but, if I'm correct, the fix on the wlroot's side landed in 0.14.0 <muradm>does it happens with gtkgreet to young? <muradm>from what i see in /var/log/messages for SAK <muradm>pineapples: try it, if you reproduce it, write down terminal it happend on <muradm>then try to reproduce it on the other terminal <muradm>from what i see, it will happen on tty1 <muradm>and it should not happen on any other <muradm>so if you normally switch your main terminal to tty2 for instance, you can avoid this issue <muradm>if this is so, this is nothing to do with seatd <muradm>after all, if you look in logs, SAK will kill any process having fd on tty1 <muradm>killing seatd should not freeze system, what freezes is death of shepherd i think <pineapples>I must've been confused because SAK'ing an empty TTY indeed does not freeze the screen... <muradm>SAK just looks for processes having fd on target tty <muradm>neither syslog or seatd will be affected <muradm>here, tty tty1: SAK: killed process 1084 (login): by controlling tty <muradm>and here, tty tty1: SAK: killed process 321 (syslogd): by fd#4 <muradm>"by fd#4" which most likely is tty1 also <muradm>this is all because technically these processes start on tty1 which is default on boot <muradm>with new greetd-service-type, you will be able to specify default terminal like "terminal-switch #t" <muradm>then you will be able to set which terminal should be activated initially <muradm>why SAK is going on "by fd#<N>" should be investigated separately, and addressed somewhere else i beleive <pineapples>Hmm. You've got right. Also, SAKing on TTY2 didn't affect the Sway session on TTY1. Anyway, shouldn't we take our findings to the developer of seatd and confront him with them? I really can't recall him claiming this is the intended behaviour unless my memory is failing me again <muradm>since it is not only seatd dying, and death of seatd should nothing to system, but shepherd dead will "freeze" system in the way that it is working, but stopped services are not getting restarted <muradm>you can ssh to system if sshd remains up for instance :) <muradm>but for me, sshd, shepherd, bluetooth everything started by shepherd is dying on tty1 <muradm>may be just use another tty as your main tty, and leave tty1 alone in terminal mode <pineapples>muradm: Have just tried that: left tty1 alone, logged to my user on tty2, started Sway and then SAK'd it; this led to the system "freezing" <muradm>pineapples: sudo more /var/log/messages | grep SAK <pineapples>According to the logs, `seatd' was once again terminated <muradm>i want to see what else was terminated :) <pineapples>A bunch of processes started by Sway, nothing special to see <muradm>as you can see pretty much everything and note last gmain :) <muradm>SAK is just killing your guix system intil pid 1 :D <muradm>which is nothing to do with seatd actually, it just falls under the mess <muradm>instead of opening issue to seatd, issues should be opened to guix and shepherd i suppose <muradm>it should release console in the first place <muradm>that should be alezost and ludo consulted <muradm>or shepherd it self could be openining console after that piece, which is most likely, because it does stdout <muradm>once this is is fixed, we can look at ls -l /proc/[0-9]*/fd/* | grep console again <muradm>then either fix it in shepherd how it starts services, and/or go over each service one by one <muradm>but fixing pid 1 holding on /dev/console should be fixed in the first place <pineapples>Thanks for your insight into the problem! Nonetheless, this is outside of my league; I don't know how to help in fixing this :) <muradm>i just sent issue to bug-guix@gnu.org, as reminder <muradm>may be some one more competent will comment <muradm>or later next week i may create test case for it <muradm>still this is not seatd problem :) <muradm>pineapples: could you give a link to sr.ht related to noholdtty <muradm>i remember you pasted it yesterday or day before, can't find it now <Gooberpatrol66>How do I see what version of a package I'm using if I did not install the package manually? (i.e. it is included from a service or %desktop-services)