IRC channel logs
2024-03-10.log
back to list of logs
<bdunahu>Hi, does anyone know how to have gdm start a few programs automatically before launching a window manager such as dwm? The x-session field in gdm-configuration says it defaults to running xinitrc, but I was wondering how I could have it run an .xinitrc file in my home directory. <lilyp>I think if it says xinitrc, it ought to be your xinitrc. <lilyp>It might however be that it instead just starts dwm – gdm is capable of doing that and allows you to switch between configurations with a keypress <lilyp>(IIRC it's F11, but don't quote me on that) <bdunahu>what do you mean by switch between configurations? <bdunahu>If I had multiple .desktop files (multiple available desktop environments and window managers)? <bdunahu>Hmm, I only have dwm.desktop right now. x-session says it is a "script to run before starting the X session" so I think it should be able to run it before starting the environment as normal <bdunahu>Maybe that is not how gdm works, because I see from other sources that gdm only reads x-session config files like dwm.desktop. But I don't think dwm can start programs like compositors automatically by itself <lilyp>welp, I looked it up, ~/.xsession is the file to configure <lilyp>I think there you can do stuff like "shepherd; exec dwm" (note that I assume a self-daemonizing shepherd here) <lilyp>Note that you might need to source your bashrc etc. in there, I haven't tried this <apteryx>hm, 'sh SPACE' in emacs replaces it by a blank <adanska>Hi Guix! Just wondering how the core-updates branch is going. There was some discussion on the ML a month or so ago, but I haven't heard anything since. <adanska>I really think the fear of world-rebuilds is something that needs to be addressed. I saw a suggestion that we have a time period where the substitute servers are paused to push world rebuilding commits <hapst3r>liliyp: do you happen to know why there is a separation between home and system services and what the rationale behind this separation is? <jpoiret>hapst3r: home services came afterwards, originally from a separate channel. The needs are also different so the base construction was duplicated. <jpoiret>janneke, apteryx: seems like the evaluation failed but i couldn't spot a reason so i've restarted it <jpoiret>(it failed at a dep of avahi but it builds fine locally, we'll see) <jpoiret>adanska: it's not just a "fear", it's a real problem for people working on it. The feedback loop is immensly slow when testing world-rebuilding changes. <jpoiret>Just 2 days ago we spotted a problem with a glibc patch for which I committed a fix yesterday, and my laptop has been building for a day now <jpoiret>And you can't just commit willy nilly and see if something breaks with CI, that's not how our commit hygiene is supposed to be. Changea have to be tested locally firat <janneke>hmm, the core-updates evaluation seems unruly <dariqq>how would I close a bug on debbugs? my big #69678 from yesterday is now fixed. <janneke>"When a bug is resolved, please close the thread by sending an email to ISSUE_NUMBER-done@debbugs.gnu.org." <efraim>jpoiret: I'm testing removing ruby-asciidoctor from cryptsetup on core-updates, since it depends (transitively) on pandoc <jpoiret>efraim: maybe just selectively for some systems? <jpoiret>i think they're needed for the manpages <efraim>oh, it's not as low in the stack as I thought it was. sure, that won't be a problem <jpoiret>"configure: error: newly created file is older than distributed files!, Check your system clock" <jpoiret>but it seems to be from a build node <jpoiret>tar: bison-3.8.2/src: time stamp 2021-09-25 09:10:40 is 54476670.571276949 s in the future <jpoiret>"offloading '/gnu/store/zhqyrxgknzmww86g4bf1a3npp4lxhlnj-bison-3.8.2.drv' to 'localhost'..." <jpoiret>does the unpack phase not reset timestamps? <jpoiret>maybe it is a childhurd as you mentioned <jpoiret>but in other news i've been running on c-u for 2 days with those pesky locale issues and it's been working fine <jpoiret>efraim: 185 is still acting up, it's the one that caused the new evaluation to fail for the same reason <Guest17>hi whenever i try to run guix pull i get the message guix pull: error: Git error: object not found - no match for id (7758e63f7a89f53fbb7c7a265ae472af0a8dfab0) <Guest17>my computer turned off while I guix was pulling is there anyway to fix this <Altadil>Guest17: Maybe guix pull --roll-back <efraim>sudo guix gc --verify=repair,contents <efraim>will check your store and make sure everything is correct <Guest17>Altadil: rollback doesn't seem to help it goes to the previous generation but still I can't pull <Guest17>efraim: I'm trying it right now it's says checking hashes, I would assume that it's going to take a while to finish right? <efraim>yes, but not too long. on my box with >1TB of store it can take more than an hour <Guest17>ok thank you that's a really large store btw '=D <efraim>with btrfs compression it takes up less space than that, but it takes long enough to run 'guix gc' to clear a large amount I just leave it. plus I have offload machines for most of the architectures and I'd rather not rebuild some of the stuff :) <Guest17>while this is verifying can I ask what's the process for adding a new package to guix official packages <efraim>I actually have to run, but the manual should have that covered <Guest17>guix gc --verify=repair,contents didn't fix it, is there anything else I can try <janneke>w00T, core-updates evaluation phase has ended <Guest17>janneke: seem like it's fixed thank you :) <jpoiret>i was worried one of our changes didn't build but it seems like it was more of a CI issue <jpoiret>apteryx: what's ;; Ignore native inputs, and set `PKG_CONFIG_PATH' for target inputs. for make-cross-pkg-config? <jpoiret>we're getting issues with cross guile builds on CI because libffi isn't found by pkg-config <andrewzhurov3>Is there a handy package that provides wasm32-unknown-unknown or do we do it manually, as in the link above? <andrewzhurov3>Oh, well, taking a hint from @peanuts, I guess manual it is! :D <andrewzhurov3>Ah, I thought the bot gives answers to FAQs. Question's open then, curious to know whether it's manual or there's a handy package for wasm32-unknown-unknown <efraim>we don't yet have a rust sysroot available for wasm32-unknown-unknown <fnat>How do I force "./pre-inst-env guix system image ..." to build an install image when a commit lacks a signature (as I'm testing a patch locally)? <fnat>The usual command returns an error about the last commit not being signed, understandably. <aarcov_>I'd like to pull the correct Cargo.toml file from GitHub and replace it <aarcov_>I've been using snippets to manually add the required fields in <aarcov_>I could also use a patch file, but I feel that a patch file is overkill for this <aarcov_>I'd like to ideally pull in the correct file and then swap it out <aarcov_>The a third option would be to try and figure out how to get guix to only build a sub crate and change the crate to refer to GitHub instead of crates.io and then build using that <msavoritias>hey. to generate a guix graph with d3js i just need to speficy the backend right? do i need to install anything? <msavoritias>the manual doesnt say but i also dont get any errors when i try to generate the guix graph <festerdam>Guix requires nscd to run on a foreign distro. Fedora has deprecated nscd and no longer provides it. I know that work is currently ongoing in preparing nscd for an nscd-free future (https://www.mail-archive.com/guix-devel@gnu.org/msg68359.html), but is there any workarounds that I can use before these efforts result in material changes? Someone mentioned recompiling glibc with nscd support. <futurile>festerdam: it looks like there's a specific discussion on guix-devel that you should look at. There's a post by Ricardo talking about a workaround of some form. <festerdam>Hmm. That one seems focused on guix pack for some reason. <festerdam>Ok, it doesn't seem to be about running guix on distros without nscd, but rather about running packs generated by guix on distros without nscd. Besides that I haven't found any other post on guix-devel with a workaround. <jpoiret>apteryx: hmmm, I'm getting some issues with the pkgconf patches. For some reason, without any changes to libblockdev or kmod, the .la file of libkmod includes -lzstd, so during the build of libblockdev -lzstd is added but it's not available <jpoiret>I don't get how the pkgconf patches could have changed that though because the zstd dependency hasn't been removed and would've been needed before