<muradm>if you use sway/i3 that should be pretty simple in their configs
<podiki[m]>I'm on xmonad currently. running them isn't a problem, just want to have easy control and output, figure it's time to give shepherd a go (had finally got around to some systemd and now moved to guix :-P)
<podiki[m]>I like stump too, but ran into a bug with plugging in another display, which I rarely do but still
<podiki[m]>maybe I should go back, lisp over haskell for me
<ennoausberlin>Hello. I host a guix instance on a virtual root server. I wonder how I can configure remote access with GUI. Normal ssh works. ssh -X does not forward. rdp gives me pam authentification error. vnc also fails. Have you a working setup lying around?
<moshy>hi guix. i noticed the newest linux-libre became available, however it didn't automatically upgrade from 5.13 and instead updated to 5.13.14-gnu1. can specific versions be declared in config.scm?
<moshy>MysteriousSilver: Looked into it and I found i had to simply declare (kernel linux-libre-5.14) under operating-system, then add (gnu packages linux) to modules, to successfully upgrade to 5.14.x
<moshy>Wondering if I can use something like linux-libre-latest to always point to the latest stable version
<MysteriousSilver>moshy: sometimes the definition of 5.14 might be removed as it becomes older, thus it becomes necessary to specify the commit. as for pointing to latest stable version, i have no idea (i manually increment versions)
<moshy>MysteriousSilver: I see. I'm guessing it behaves in such a way that, after 5.13 becomes EoL, then it automatically switches to 5.14
<ennoausberlin>It would be nice if someone can confirm he had ssh -X working on his guix machine
<civodul>ennoausberlin: "ssh -X" definitely works for me
<liltechdude>All articles that I found was about `How to run docker on guix`
<qzdlns[m]>ennoausberlin: did you look into your xauth configuration? and to clarify, are you running from guix<->guix, or is the 'remote' (the server) only running guix? in any case, you will need to ensure your xauth on both machines are properly configured
<ennoausberlin>qzdlns[m]: local machine is an Ubuntu 21.04 - remote is full updated GUIX.
<qzdlns[m]>cool, and you have entries on that remote machine when you run =xauth list= ?
<ennoausberlin>I can remote ssh -X from my local Ubuntu machine to a third debian 10 machine and ssh with X forwarding is working.
<ennoausberlin>unfortunately guix does not write special sshd logs. /var/log/messages, /var/log/debug and /var/log/secure does not give any hints
<ennoausberlin>It already costs me hours to find a solution. What about tigervnc-server, xrdp or spice. Is there a guix tutorial for this?
<dhruvin>How much time is normal for "guix pull" to run for the first time on a freshly booted (run on 2 core 4gb ram) qemu vm?
<dhruvin>context: I'm building a build image for sourcehut and it takes several minutes to run guix pull for build user (the first time).
<dhruvin>Followup question: the images will be built nightly. the system profile will be *almost* up to date. Is there a way to minimize the time taken bby "guix pull" by somehow using the system's profile?
<dhruvin>maximed: I used what you suggested. I understand that it'll help when ci doesn't have packages built for definitions in latest commmit of guix. Follw-up question: It will still perform "git clone/pull <guix repo>" (I saw some 1800 commits received), right?
<maximed>dhruvin: 'channel-with-substitutes-available' only verifies a substitute for guix itself is available
<maximed>it doesn't check substitutes for packages defined in that guix are available
<dhruvin>maximed: I believe when we create a system image, it should include the guix checkout it was built with. Correct me if I'm wrong here. Can't we just use that somehow? Since it'd be already pulled and authenticated.
<maximed>the guix the system image was created with is newer than the guix inside the system image (until the next guix pull)
<roptat>I noticed that libcxx gets a gcc native-inputs and a cross-gcc input, but even removing both entries from CPLUS_INCLUDE_PATH doesn't work, it looks like it can't find the correct headers and still defaults to gcc's headers that won't work with clang/llvm
<roptat>I know CPLUS_INCLUDE_PATH is not in the same order as in a native build, but I'm not sure how it can influence the build
<abrenon>oh, I see, so that's quite out of my scope, luckily for me
<maximed>Curious, everything under "tests" does not exist
<attila_lendvai>is there a simpler way to try a new package in the environment of my user? what i do currently, but takes too long: git commit the change, guix pull from my guix repo checkout, then guix package -u
<dhruvin>attila_lendvai: Did you try the ./pre-inst-env way?
<attila_lendvai>dhruvin, hrm... apparently i'm still lacking a mental model of that ./pre-inst-env... lemme try
<iskarian>looks like we've got a lot of rust packages failing now in core-updates-frozen
<raghavgururajan>sneek, later tell nckx:  I would like your advice in something. In non-master branches, if an update to a package break its dependants, should the dependants be fixed on same commit or different ones?
<iskarian>a lot of "error: failed to prepare local package for uploading
<sneek_>nckx, raghavgururajan says:  I would like your advice in something. In non-master branches, if an update to a package break its dependants, should the dependants be fixed on same commit or different ones?
<sneek_>nckx, raghavgururajan says:  Also, if fixing the dependants is a quite a line-of-work on its own, can it be delayed till the end of the intial work?
***sneek_ is now known as sneek
<maximed>it's not giving an error about perl, it's a warning and probably harmless. The issue seems to be from 'stat'.
<maximed>I think I've seen faimiliar issues before on the bug tracker
<nckx>raghavgururajan:  If the ‘fix’ doesn't break building against the old version, apply the fix first, then update the package in question. If it does break, it's not much of a fix^W^W^W^W^W^W include the ‘fix’ in the same commit as the update. The goal is to keep commits limited to only one logical change and never to introduce a regression between commits pushed together. If those 2 are incompatible the latter one wins.
<iskarian>Can "guix weather" take a glob? (What I'm actually trying to do is: get a list of failed cuirass builds matching a glob)
<nckx> Not on master, no. ‘We updated libfoo, now 23 packages are broken but we'll fix them later’ happens, but should not be done on purpose.
<sneek>lfam, dstolfa says: my download's done, i have 300G of stuff now (compressed) and can serve it if needed for a download
<lfam>sneek: later tell dstolfa: Thanks! I think we are still waiting for some clarification on what is going to happen next...
<attila_lendvai>so, the python app called trezor-agent (actually its libagent) uses sys.argv for something, but on Guix the wrapper script calls the renamed original file, which changes sys.argv and breaks the app. what shall i do? report this as an issue?
<attila_lendvai>it works on nixos. python is packaged differently there and it doesn't interfere.
<lfam>I don't have an answer but we must have encountered this issue before. There are a huge number of wrapped packages
<vats>Hello, does anybody have ideas about using Freenet on GuixSD? It requires gradle to compile which hasn't been packaged yet. Perhaps ArneBab has something to share from his setup? (Being a freenet developer who also uses guix.)
<moshy>I'm gonna try an alternate method to reproduce the build error, using a clean, minimal Guix 1.3 install in QEMU. TinyCC currently in progress