IRC channel logs
2024-11-10.log
back to list of logs
<jakef>raghavgururajan: hi! I tried using the lts kernel and was still unable to log into a graphical session. should i share with you the /var/log/gdm/greeter.log and greeter.log.1 files? <apteryx>jakef: what is your GPU and which driver are you using? <apteryx>GDM/GNOME (the default) has 3D requirements for the compositor, won't show the login screen if you use e.g. amdgpu without proprietary blobs :-( <apteryx>one solution is to switch to something like slim and xfce if that's the case <jakef>apteryx: nvidea gpu with nouveau driver; but the strange thing is it worked before a guix update <jakef>i am on the roll-back right now and its fine <jakef>but yeah, doing some off-topic activity would be my next thing to try <jakef>the gdm log has e.g. (gnome-shell:565): Gjs-CRITICAL **: 13:51:04.761: Object Gdm.GreeterProxy (0x18e03710), has been already disposed — impossible to access it. <jakef>(gnome-shell:565): GLib-GObject-CRITICAL **: 13:51:04.761: ../glib-2.78.0/gobject/gsignal.c:2777: instance '0x18e03710' has no handler with id '13984' <jakef>and i won't spam any more without a pastebin, sorry <jakef>maybe its related to this mesa update to 24.2.2 that also caused tests to fail for u-boot-tools <jakef>the working system has 24.0.4 <jakef>(seen in *system canonical file*/profile/manifest) <apteryx>jakef: ah, then it's probably related to some cache <jakef>apteryx: intersting! I'll try deleting some cache. thanks <meaty>Hi guix! how do I suspend the system? most stuff online says to use systemctl or pmi but Guix has neither of those <meaty>I found there is echo mem > /sys/power/state but that requires sudo priviledges <meaty>I would also like to just switch off the display backlight sometimes when I want something running in the background <meaty>yeah it seems to do nothing but freeze lol <hako>if you're using elogind, it has a `loginctl suspend` <meaty>hako: that works for suspending thanks! <apteryx>I wonder why 'guix build --with-debug-info=gnome-boxes gnome-boxes' gives the same exact thing as 'guix build gnome-boxes' <raghavgururajan>jakef: I received the logs in the DM. Thanks! Could you also let me know the commit hash of guix system generation (`guix system list-generations`). The working one and the not working one. <jakef>certainly! not working: 3dc63f8ca7af8d4fee32a03c206b571896a3a70a and working: dd63cd7876f8c6a6eb42170219c17659ff4daf42 <vhns>Hi. Does Guix already have a way to start the emacs daemon/server on login? <vhns>I couldn't really find anything under Home services <apteryx>not yet contributed in home services but i was told it can be found in the rds project <apteryx>any tip to "reset" a borked gnome-boxes? <vhns>Ah, ok. I'll look into it. Thanks! <Rutherther>apteryx: --with-debug-info only adds to arguments to not strip binaries. But if there was nothing to strip in the first place, the package will be the same. So I suppose in this case meson just doesn't use the debug flags to build gnome-boxes <PotentialUser-2>What does this mean? "GC Warning: Repeated allocation of very large block (appr. size 68 KiB): May lead to memory leak and poor performance" <cipherself>Hi folks, I just recently started using guixSD, and now I am trying to do `Home Configuration`, the part I am kinda wondering about is how to handle the following situation: I have a .ssh directory at $HOME with a bunch of key-pairs. I am interested in keeping that while using `(home-environment)`, I am not sure what's the best way to do that. I've tried a `home-dotfiles-service-type` like so https://pastebin.com/2JWYjnDe but that just <cipherself>copied (rather symlinked, alas, not relevant) the files in .ssh to the new home. I've tried creating a `dotfiles` directory and symlinked .ssh into that new directory and then changed my `home-dotfiles-configuration` to use `dotfiles` instead of `.ssh` directly, unfortunately this caused guix to crash https://pastebin.com/2f37pnrn, how do people normally handle this? <Rutherther>cipherself: could you clarify on what you mean "I am interested in keeping that while using (home-environment)"? There should be nothing needed to "keep them", they are kept by default if you don't do any additional home-environment configuration <apteryx>Rutherther: it's supposed to, though <apteryx>the default build type for meson-build-system is 'debugoptimized' <cipherself>Rutherther: So, I now have my default user $HOME, that was created when I installed GuixSD and created my user. I am trying to migrate to using https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html, so I've created a `home-configurations.scm` file that uses the `home-environment` function (or macro IDK), and to test it, I run `guix home container src/guix-config/home-configuration.scm` to test it first. In the shell <cipherself>that's opened in that container, my .ssh doesn't exist as it existed in its original form, but rather it contains the authorized keys which I configured in the scheme code, a default config, and I can't find my keypairs that I had in the original $HOME (outside of the container) <Rutherther>cipherself: I see. And why does it matter to you that there are no keys in the container? keys are a secret that isn't usually really supposed to be managed by guix home <cipherself>Rutherther: Well, I don't really care about having them in the container, but if I use guix home to reconfigure my home, I want my keys to remain there. <Rutherther>cipherself: the container doesn't provide your file system, so it doesn't show you files in your home, it just shows you empty home with applied home configuration. It doesn't mean everything else will disappear <nutcase>cipherself: maybe, you can get a better preview of your resulting home environment with "guix home container --share=$HOME home-configuration.scm"? <nutcase>cipherself: or better use "guix home container --expose=$HOME home-configuration.scm" since this does includes your $HOME read-only <Rutherther>nutcase: I would not think that would work, I see two possibilities and not sure which one is going to occur: either the home will actually be applied if the folder will be shared first, or all files from home-environment will just be shadowed, so you would end up just with your original home. <nutcase>Rutherther: ok, I didn't try, that's why I wrote 'maybe'. Sorry for confusion. <cipherself>Based on this, I ran guix home reconfigure, and indeed the files are as I expected them. I was thinking that the container will have a complete accurate representation of the new home, but given that it assumes an empty home, then I get it. And it makes sense that the container will not share the dir. Thanks! <futurile>I'm going to announce it more widely later today / tomorrow. So trying to make sure there aren't too many spelling mistakes!! <apteryx>hm, u-boot-tools is currently broken <marmar>is there anything I have to add in to the nix-service to make it work with flakes apart from `extra-experimental-features = nix-command flakes` <Rutherther>marmar: no, flakes are built-in in nix, so only telling it those features are allowed with extra-experimental-features is fine <ekaitz>janneke: in your patch set why do you need to convert from gexps to sexps? <Rutherther>marmar: not necessarily. Nix will create the symlink itself as soon as you install anything. It's probably even better to leave it up to Nix, since /nix/var is not the only possible location for profiles. Nix can be configured to respect xdg home directories and put the profiles to ~/.local/state/nix/profiles <Rutherther>marmar: also you should be using the devel manual, the one you are looking at is for old version of guix - put "/devel" after "manual" in url <cipherself>I have an `.emacs.d` directory that I keep under version control, I want this to be managed by `guix home`, such that when I do `guix home reconfigure` it either clones that repo from a remote git forge, or if it's easier I can just put that directory in my home configuration directory and it will make sure it's in my new generated home, what's the recommended way to do that? <noe>cipherself: have you considered using a git submodule? <cipherself>noe: I hate git submodules, regardless, if I have `.emacs.d` under `src/guix-config` and I do `guix home reconfigure src/guix-config/home-configuration.scm`, it doesn't put it in the new home. <Rutherther>cipherself: one way to do this would be to make a shepherd service that will check if the folder exists, and if not, it will call git clone on it. Another would be to make it an activation script, but I wouldn't recommend that as it's easy to fail if there is no connection, and the activation would take unnecessarily long for the initial clone (even if the repo is small it would probably be the thing that takes longest time) <Rutherther>cipherself: as for making it a submodule / keeping it in your guix config repo somehow, it's then a question what exactly is supposed to happen. Should it copy it there? (in that case again shepherd/activation). Should it symlink it there? Should the symlink be to the store (then the dotfiles symlink service) or to your guix config (then make a package with output being symlink to that folder and use dotfiles symlink service to symlink that second... <Rutherther>... link)? Or something else that haven't occured to me... <cipherself>Rutherther: Ok, I'm gonna read about defining user services and defining packages and think about it. Thanks. <Rutherther>cipherself: in this case just something like "(computed-file ".emacs-d-symlink" #~(invoke #$(file-append coreutils "/bin/ln") "-s" "/path/to/your/config/.emacs.d" #$output))" should work for thepackage I had in mind. (though strictly speaking it's not a package type) <marmar>so I put the nix-service in my config but I'm getting the error error: nix-service-type: unbound variable <marmar>I put it in with the list with plasma and swap, so I'm pretty sure it's the right place <janneke>marmar: you need to use (gnu services nix), eg, (use-service-modules nix) <janneke>doesn't guix give you a hint about that? <marmar>janneke: also, if there's a hint, I don't really know where it is. the error's mostly about raised exceptions ._. <civodul>janneke: hints don’t work in this particular case i think <janneke>ACTION thinks the hints are pretty neat <aemogie>hi! i have an problem(?), https://paste.debian.net/1335097/ most of these mentioned to be built locally sound like they should have substitutes. for additional context, i'm using guix on a foreign distro (nixos), and am trying guix with `guix system container`. additionally, with time-machine i'm locking guix on commit 8a602183. <civodul>aemogie: hi! did you enable and authorize the project’s build farms? <civodul>‘guix weather hello’ (or similar) should provide hints <aemogie>it says substitute available on ci.guix.gnu.org and bordeaux.guix.gnu.org, which i assume means it's autherised? the sources are being substituted, and some packages areproperly substituted (as shown in the paste) <Rutherther>aemogie: note that not every commit has substitutes. The commit you provided seems to be one that was never head on master, it was part of mesa-team branch that was recently merged, so for that one I would not be surprised if there weren't any jobs ran, ever, and if a lot of stuff was changed due to changes prior to it to mesa / its dependencies <Rutherther>aemogie: do you have a particular reason to stick to that commit? why don't you update to latest master? <aemogie>i think i wanted to try out guix system vm, and it failed on a u-boot-tools compilation. noticing someone mention it in the irc logs, and referencing it was due to a mesa issue i wanted to see if rolling back to a commit before the merge would fix it. does the ci delete old substitutes? <aemogie>i will try again on master and give an update <PuercoPop>futurile: I do think that the propietary driver question could be allow for nuance in the responses. There is I use propiertary drivers as in the nvidia or the AMD drivers GPU drivers and there is I use propiertary drivers as in I use propietary drivers in the firmeware. <Rutherther>aemogie: it doesn't delete old substitutes. The jobs were never ran since it was intermittent work that got shadowed by new work which got picked up by the build farm <Rutherther>aemogie: in your particular case it would be good to go prior to mesa-updates merge, though there is no merge commit, so it's not as easy to know what commit was the one on master before the merge happened <Rutherther>aemogie: I think it could've been 4c56d0cccdc44e12484b26332715f54768738c5f, but I am not completely sure <futurile>PuercoPop: OK, yeah can see why that's interesting to know. I can't make changes to structure now as it's all be laid-up (without starting again and I don't want to do that having spent all week on it!). It's been difficult to figure out reasonable dividing lines in a bunch of these questions. If that's something that should be captured add it as a note at the end - that will give us more info in <PuercoPop>Yeah, maybe next time. Thank you for taking the iniative to do survey. FTR I do like Guix valuing copyleft and and free software. Just would draw the line a little more to the 'practical' (I don't like using such a loaded term, but I can't think of a better one right now) line <iska>is there a particular reason why OpenJDK is only distributed until version 18? <iska>i.e, is it some build issue or just that someone didn't get to packaging it <iska>I installed Guix to have a nicely bootstrapped GraalVM install <aemogie>Rutherther: that commit worked, thank you! <lilyp>iska: openjdk is distributed up to version 21? <Kolev>Are there any security implications to running a media server and a desktop on the same machine? <dariqq>I cant seem to reproduce the shepherd-1rc tarball. A lot of different dates (POT-Creation-Date, stamp-vti , version.texi), different version of gettext macros, ... . When I try on my Fedora machine (not using guix) even the info file is different. <dariqq>On the positive side the "wrong" tarball reproduces for me on 2 different machines with 'guix shell -CP' every time <janneke>dariqq: different dates sounds like a bug. full reproducibility is only expected when using the same guix shell and version <janneke>usually, guix.scm will mention a time-machine curse, something like: <janneke>guix time-machine --commit=f977cb2b609f7122db2cf026cac5ab9d6d44a206 -- shell <janneke>disclaimer: haven't checked the shepherd sources for that <janneke>civodul: i'd suggest adding such (see^^) a guix time-machine curse to guix.scm <janneke>(we don't need that in guix, because we assume ./pre-inst-env on HEAD) <dariqq>Updated everything earlier today (to test out the rc). Not sure where the different gettext macro version is coming from? <bdju>pcmanfm-qt thumbnails still broken <janneke>dariqq: yeah, could be autoconf, getext, gnulib even? <dariqq>I think i found (one of) the reasons : The POT-Creation-Date in the rc tarball is at the commit that bumped the version in configure.ac but the tag is at 1 commit later <marmalade>Bro I am so lost rn, i don't understand why there are like 5 different versions of what to put in GUIX_PROFILE for it to function correctly <marmalade>is it supposed to be $HOME/.config/guix/current, or $HOME/.guix-profile <Rutherther>marmalade: none. It should not be exported. It should be set only for the given profile you are sourcing <civodul>dariqq: d’oh! could you email the details to bug-guix? <civodul>dariqq: FWIW, i ran “make dist” in ‘guix shell -CP’ with a current Guix (4e6df8040e539e4635420eef1a2a26af209b614d) <marmalade>i genuinely don't understand how to parse what you said <marmalade>partially because i don't understand what's happening <marmalade>i'm just trying to get emacs installed and it's doing my head in just getting guix functional <Rutherther>marmalade: the point of it is this: the profiles etc/profile will give you search paths from that profile, like PATH going to its bin. By default the profile doesn't know its location outside of the store, so it would put /gnu/store/....-profile in the variables. That might be fine, but you usually want to be able to update profiles. So that's why, when sourcing ~/.config/guix/current/etc/profile, you set GUIX_PROFILE to... <Rutherther>... ~/.config/guix/current/etc/profile. That way the variables like PATH will be pointing to ~/.config/guix/current, instead of pointing to the store. So when you update, your variables point to new profile instead of the old one and you don't have to update your environment <Rutherther>marmalade: so you should have something like "GUIX_PROFILE=<PROFILE>; . <PROFILE>/etc/profile" for each profile separately, the environment variable is set only for the sourcing itself <Rutherther>marmalade: sorry, it's not even environment variable, just variable <dariqq>the info file embeds the version in the beginning: makeinfo verson 7.1 (fedora) vs .texi2any-real version 7.1.1 (guix) which is causing the rest to be different as well (i think) <marmalade>I'm sorry I'm trying to parse the first thing you said here. When you say the profiles etc/profile, what are you referring to? <Rutherther>marmalade: etc/profile file under the profile folder. The file you are sourcing <dariqq>civodul: How did you bootstrap autotools? i am starting from a fresh checkout , guix shell -CP, autoreconf -vif, configure,make,make dist <civodul>dariqq: i didn’t start from a fresh checkout, but i ran “autoreconf -vfi”, which should be equivalent <marmalade>I can't tell if this is a really hard thing to understand or I'm just stupid. <marmalade>I don't understand the difference between current/etc/profile and etc/profile <futurile>marmalade: it's hard to understand initially. <futurile>marmalade: how are you running Guix, did you install it on top of your existing distro? If so what is that? <Rutherther>marmalade: ~/.config/guix/current is the profile, so etc/profile is under it. ~/.config/guix is not a profile, it's just a directory <marmalade>futurile: debian - i just used apt to install it <dariqq>civodul: no idea why things are different then: e.g. gettext.m4 serial 66 (gettext-0.18.2) vs gettext.m4 serial 68 (gettext-0.19.8) a lot of different dates in the copyright headers of other macros as well <Rutherther>marmalade: the "current" name means it's your current guix profile, the one you obtained after last guix pull <futurile>marmalade: so how did you install emacs from Guix, so the manual tells you to do "guix pull" right and that updates the archive. <futurile>marmalade: each time you do that Guix does a 'transaction' - you can see it updates the archive and any packages with 'guix package --list-generations' <futurile>marmalade: under the hood it's using these things called 'profiles'. That's what people are trying to explain. <dariqq>civodul: when using the source-tarball variable from the guix.scm things again match the ones i am creating (apart from the date timestamp being set to 1 and a lot of /gnu/store/*bash-minimal mentions) <dariqq>si think you had some old things in m4/ and the xgettext.scm did not rerun <marmalade>Is a guix profile distinct from the concept of linux profiles? <sneek>librehawk, you have 1 message! <sneek>librehawk, gnucode says: I use the Hurd on bare metal on a T43 with 1.5 GB of RAM. It works really well. crashes once or twice a week. Sometimes lots in one day, if I am trying to abuse it. <Rutherther>marmalade: what's a linux profile? you mean stuff like ~/.profile, /etc/profile? <marmalade>idk that's the only time i've heard profile referneced and we're referining .profiles <marmalade>bruh idk i can't keep track of what profile is what <Rutherther>marmalade: guix profiles are basically a symlink merge of multiple guix packages into one package, with the addition of etc/profile file that will give you search paths of the packages (search paths are a mechanism to get packages do be able to do you want, ie. for emacs you have EMACSLOADPATH search path. So if you add both emacs and an emacs package, you will get export of EMACSLOADPATH in etc/profile of the profile package) <marmalade>feels like i'm trying to unravel six balls of identically colored yarn <futurile>I think it's not helping trying to learn this right now - all you really need to do is to do `guix package --install package` and when you do that it tells you to export an env variable. <Rutherther>marmalade: you can try for example "guix shell emacs emacs-magit", then look at directory specified by $GUIX_ENVIRONMENT environment variable. That is a profile, so you can inspect it to see what it is - you will find emacs under bin/emacs, magit under share/emacs/site-lisp... <bdju>dang my compose key stopped working after rebooting <bdju>any other Sway users have that happen? <marmalade>bdju: probs a way to check for inputs. im p sure there's a wayland tool for this but i don't know what it is unfortunately. <efraim>did you change anything recently in your sway config? <bdju>nothing related to the keyboard/input stuff <marmalade>bdju: if it only started after the most recent change i'd review the change and see if there's any way the config could be malformed maybe? <bdju>well nothing was wrong after last config change + sway config reload, just after last guix upgrade + reboot <bdju>last change was adding another shortcut for focusing a specific window, of which I have many similar ones <efraim>I actually spent almost an hour today moving my sway config into home-sway-configuration <Rutherther>marmalade: there is no wayland tool for that, every compositor manages it on their own, so this is about sway config itself, there is no general tool that would allow you to change your keyboard layout in wayland world (the most they can do is implement some protocols that are implemented by specific compositors) <efraim>I use: xkb_options "grp:lalt_lshift_toggle,compose:caps,lv3:ralt_switch,eurosign:e" <marmalade>Rutherther: Oh yeah I just meant like for showing inputs. I'm /pretty/ sure there was a tool for that to check to see what inputs wl was recieving but I could totally be wrong about this. <bdju>my capslock has just reverted to being an actual capslock <efraim>Also useful for those media keys on your keyboard <bdju>like the config thing is not doing anything <ekaitz>efraim: what does the xkb_numlock enabled do? just enable it by default? <efraim>ekaitz: that's a good question. Probably, but I think it must not because I have my numlock lit up but I haven't lost my other keys. Maybe it uses them as numbers instead of directional keys? I'm sure I turned it on on purpose <Kolev>efraim, how do I avoid doing (gnu packages librewolf) etc.? <efraim>Kolev: (specification->package "librewolf"), or (specification->package+output "git:send-email") <ekaitz>i need to configure my system with guix home but I'm lazy <efraim>input <identifier> xkb_numlock enabled|disabled <efraim> Initially enables or disables NumLock on startup, the default is disabled. <efraim>I started with just packages and then recreated files to be able to drop my dotfiles repo <ekaitz>oh, but it's not a xorg.conf thing but a sway thing... hmmm <ekaitz>now I want to put it in my system but I don't have sway :( <attila_lendvai>what's the reason that gnugp in guix is 3 years old? or is this a user error? i see v2.2.39. <attila_lendvai>hrm... "version 2.3.0. This release marks the start of public testing releases eventually leading to a new stable version 2.4." <bdju>my compose key is working again after replugging my keyboard (actually I hit the button on my usb switch twice) <efraim>sounds like when I need to unplug my webcam so I can finish booting <efraim>attila_lendvai: there's a disagreement about some of the internals of the PGP compatable software so we're sticking with the 2.4 branch until it gets figured out <attila_lendvai>efraim, thanks! sounds reasonable, but then running security related software that is 4 years old... i hope someone keeps an eye on the upstream commits and CVEs. <attila_lendvai>2.4.6 seems to be a stable release, though. it's pretty fresh, 2024-10-29 <efraim>oh, maybe I had my versioning wrong and 2.4 was the one with the disagreement? <efraim>it looks like there's a 2.2.45 that we should probably check out <attila_lendvai>then maybe we could have a gnupg-next? or is this some politically charged thing, not just some technical stuff? <efraim>there's standards bodies involved and some of it isn't backwards compatable <attila_lendvai>guix shell --with-latest=gnupg gnupg => guix build: error: connect*: Connection refused <Rutherther>attila_lendvai: I guess that is caused by the first mirror in list of gnupg mirrors being down (it's been down for days at least). And with-latest is probably too _dumb_ to check for next mirror links <marmalade>also am i supposed to have two GUIX_PROFILE entries in my config? <Rutherther>although now it loaded for me... hm, so I am not sure <Rutherther>marmalade: you are supposed to set GUIX_PROFILE variable whenever you source etc/profile file, and since you probably want to source both ~/.config/guix/current/etc/profile and ~/.guix-profile/etc/profile, then yeah, have two every time set for the relevant sourcing <nckx>sneek: later tell gnucode: As you can tell, I haven't been around much but all's good. You? <nckx>It's pronounced gweks though. <nckx>Did they not tell you this. <futurile>nckx: would you mind pushing my blog post announcing the guix user survey by any chance? <nckx>Uh, OK, maybe. Has it been consensussed & all such jazz? <nckx>ACTION will be at a proper keyboard with GPG keys soon. <futurile>nckx: yes, it's been reviewed by Ludo/Fabio and others - feedback on guix-devel etc <fnat>futurile: Thanks for the latest round of changes and for your email this morning. <futurile>fnat: no worries, thanks for the thorough review :) - hope we get a good response <marmalade>Rutherther: so it should just be like GUIX_PROFILE="$HOME/.guix-profile" and then under it GUIX_PROFILE="$HOME/.config/guix/current/etc/profile"? <clarkf>marmalade: I'm familiar with what you're after, but have you tried using guix home? The bash service ought to set all that stuff for you <marmalade>not familiar with it no - i'll check it out rn <Rutherther>marmalade: yes, exactly. Each line sourcing profile can just be "GUIX_PROFILE=<PROFILE>; . <PROFILE>/etc/profile", for <PROFILE> substitute $HOME/.guix-profile and/or $HOME/.config/guix/current <marmalade>I don't understand, isn't that just going to generate conflicts when I'm trying to run something if each profile has the same thing installed? <marmalade>Not that it matters I guess since I can't build things now soz <marmalade>but I've been at this all day and I just cant get emacs latest installed and it is driving me up a wall <attila_lendvai>the most important feature of a git forge with PR's compared to emails is that PR's are kept in a list. my non-controversial shepherd cleanup patches sent to guix-devel have long been forgotten... even i needed some time to find them. <Rutherther>marmalade: I don't know what you mean by conflicts. The potential "conflicts" are resolved by the behavior of individual variables, like PATH, where first matching path with the executable is chosen. <clarkf>marmalade: there are varying defintions of "emacs latest," but emacs-next exists. If you need something newer or special build flags you could modify that derivation <Rutherther>marmalade: also note that with those two specific profiles, ~/.config/guix/current has only guix, and your ~/.guix-profile shouldn't have guix. So there should never be conflict between these two profiles