IRC channel logs
2025-03-11.log
back to list of logs
<apoorv569>Rutherther: I was wondering what if install cloning whatever the latest commit is on master branch, what about if I configured the CI/CD stuff to build and then make a tarball or something for which then I fetch unpack and copy easy simple.. for each version I release a new tarball will be created by CI/CD. <apoorv569>this might move me one step closer to reproducible builds as well.. <apoorv569>not sure if its a great idea if I wanna upstream the server/package definition in future. by upstream I mean PR to merge in guix channel. <nomike>Rebooting Ubuntu didn't change anything. git itself works fine without issues. <nomike>Ahh....wait. I think this might be apparmor again... <lechner>ieure / i wasn't able to see orbitron in guix shell, either, but i think it works when using in the Home profile <ulfvonbelow>how does one distinguish passing an optional or keyword parameter from passing the default value? <Aurora_v_kosmose>Huh, I'm surprised to find that there's no equivalent to Common Lisp's way of having a separate variable that tells whether an argument was passed or not. <ulfvonbelow>it looks like it's either manual argument parsing or case-lambda or something like that <Aurora_v_kosmose>It's also a lot noisier than simply having a name for parameter-passing status. <mange>You could set the default value as a non-exported value, then use the "real" default value if that's the argument value. <mange>Like (define %default-blah (list)) (define* (my-fn #:key (blah %default-blah)) (let ((blah (if (eq %default-blah blah) (list 'real-default) blah))) ...)) <xelxebar>What are some nice channels you all use? <xelxebar>I've got guix-past, guix-science, and guix-hpc sitting in my channels.scm <apoorv569>xelxebar: checkout https://toys.whereis.social you can search for package, services and the channel they belong.. this is basically a webring which lists different guix channels that are known, if you like your channel to be in the list let them know. <xelxebar>apoorv569: What a mic drop! I asked for some suggestions and you give _all_ the suggestions plus some. <apteryx>hm, it seems xournal stopped being able to export or print pdf <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, ArneBab says: thank you for the info (re gnome branch) <apteryx>hm, "fun": I have some ready to print form in a .xoj (xournal) file that I can open, but there's no way to produce a valid PDF with either Xournal or Xournal++ (xournalpp); Evince says they are corrupted. <apteryx>attempting to export as PDF in Xournal++ it says: 'Cairo error: out of memory' <kimapr>is it possible to enable TRIM on a LUKS mapped device in an os configuration? <cehteh>you know that TRIM compromises encryption a bit? <PotentialUser-77>kimapr I read that could leak some meta-info. But I guess it could be possible to do. <cehteh>otherwise the kernel supports that, somehow it should be possible <kimapr>I'm using an SSD though so NOT doing this would surely cause performance issues from what i've gathered <cehteh>wear leveling and GC algorithms are pretty good, it shoulnt be a total desaster w/o trim .. and alternatively you can schedule a monthly (or weekly) fstrim if your filesystem supports that <kimapr>I can't use fstrim specifically because TRIM is disabled on LUKS.... <cehteh>as long you dont fill the ssd up or have long lasting constant write loads its prolly ok to leave trim disabled for luks <PotentialUser-77>A quick question about nettiquete: I posted a Guix bug report to bug-guix@gnu.org, and got an email reply to me@myaddress from friendlycontributor@hisaddress with CC to 1234@debbugs.gnu.org. I did not get a copy of this message from debbugs or bug-guix. How should I address my reply? <PotentialUser-77>I expected that the bug tracking system would handle all the message forwarding but it seems to be a simple email repository. <kimapr>cehteh: erm.. the ssd used to have ~40 gb free out of 1 tb <Rutherther>PotentialUser-77: yes, it's quite simple. The reasoning is that not everyone wants to be pinged I think. You typically reply to everyone, sending it to the debbugs is important so that it's tracked in debbugs. Sending it to the person who replied is important so that your message doesn't get lost (the person might not check it) <quezt>i want to add (colord-service-type) but dbus-system-services.drv fails to build because it already exists. how may colord be added? <cehteh>kimapr: thats more of a performance problem than the lack of trim <efraim>for debbugs I normally reply-all <Rutherther>quezt: the only error 'already exists' on drv itself I know is caused by disk corruption <PotentialUser-77>How do you filter email related to debbugs and does the "deb" in "debbugs" come from "Debian"? <cehteh>kimapr: ssd firmware can decide by itself when a block is free, just because you write to it and then redirect the write to another flash region for wear leveling, no dire need for trim, but when there is little free space no matter if you have trim or not it cant spread writes <Rutherther>quezt: please send the whole error to confirm that. <efraim>I dump all my email from debbugs into a guix-patches folder unless I'm addressed specifically in To or Cc, and I'm pretty sure the deb in debbugs is debian <PotentialUser-77>efraim Thank you. Do you manually sort it or do you use some header to do it automatically for you? <apteryx>is it just me or canonicalize-url in (guix gnu-maintenance) is odd in having that lack of trailing '/' on URL means take the dirname out of BASE-URL before combining them? <efraim>I have a sieve rule for if the header contains List-ID for guix-patches.gnu.org or bug-guix.gnu.org, or if "X-Gnu-PR-Package" matches guix-patches. then if To or Cc include me it goes to the inbox, otherwise to the guix-patches directory <efraim>apteryx: locally I've switched (dirname base-url) or base-url (around line 562) to get it to work with gnupg, but I haven't tested it enough to see how to fix it <apteryx>I was investigating cairo refresh being broken too <quezt>PotentialUser-77, thank you and sorry <apteryx>efraim: I guess we must ensure the base-url provided to canonicalize-url ends with '/', as mentioned in the later docstring: "If URL is a directory instead of a file, it should be suffixed with a slash (/)." <Rutherther>quezt: okay, that's something else then, I thought you meant a different error <decfed>what is the difference between declaring packages in the packages field of a home-environment or declaring them by extending the home-profile-service-type? <efraim>the gnome mirrors in (guix download) have a trailing / <Rutherther>decfed: no difference in what will happen. The reason you can do it with services is that if you add a service, it can also add packages to your profile for convenience. But you can put also to packages for convenience if you just want to add packages yourself, which is again more convenient <efraim>the gnupg mirros have a trailing gcrypt/ that keeps on getting dropped, so I'm not sure <efraim>maybe it was just the qemu URI that was the problem? <Rutherther>quezt: so the error means there are two dbus service packages adding the same file. Unfortunately it doesn't say what files those are. It's important to first figure that out so the error can be resolved <quezt>Rutherther, i suspect gdm and avahi. <quezt>Rutherther, do i generate a graph? <PotentialUser-77>efraim I see. Thank you. I am getting a better feeling for how to do things now. <Rutherther>quezt: no that will be too complicated to get it from a graph. Better to just find your current dbus-system-services folder in gnu store and run tree on that. Then run tree on colord and see the same *.service file <quezt>Rutherther, do a guix build of colord first? <Rutherther>but on second thought the service doesn't really add colord to dbus services. Are you sure the failing build is for derivation dbus-system-services? <Rutherther>can you also send log of guix system reconfigure maybe? <Rutherther>quezt: sure, but I did that already and can tell you the only two services there are org.freedesktop.ColorHelper.service and org.freedesktop.ColorManager.service <apteryx>efraim: looks like I did a poor job at preserving some edge case in the original canonicalize-url code in commit 6fb8cc312dc <apteryx>and all these problems probably stem from it <efraim>no one's complained this far. just wait until someoneā¢ finally gets around to filing a bug with 'guix import' and gnupg-2.4 <Rutherther>quezt: okay, it really is that derivation. So there must be two packages with org.freedesktop.ColorHelper.service or org.freedesktop.ColorManager.service <kimapr>cehteh: how can ssd firmware decide by itself that a block is free if it's all occupied by completely opaque random bits that it can't know to drop without risking data loss? <kimapr>i mean i guess even with trim my disk usage would be pretty bad, but i can't even actually release any space as it stands without trim <Rutherther>quezt: sence it's just two, you can try searching for either of those under the store with find and see what has those services. My guess would be that you added colord to dbus services twice, but it seems unlikely that would happen unless you made your own colord service. But I really have no other ideas. another would be using colord-service-type twice, but you should get error about that earlier before this would even be building as far as I can... <cehteh>kimapr: when you want to write to it, it knows that the data there is not used anymore, thus it can mark it as free <quezt>Rutherther, at the earliest points of the system installation, i was experiencing this conflict when i tried to install gnome and colord because colord is a depends. <quezt>Rutherther, i guess if i replaced gdm with say greetd, it may resolve the conflict. <apoorv569>`npm config set ignore-scripts true` before `npm ci --omit -dev` and `false` after it seems to fix it.. everything copies fine as well <cehteh>kimapr: getting a bigger ssd and/or leave more free space would be better for performance than trim <Rutherther>quezt: this is not how deps work on guix, gnome doesn't propagate colord in any way, yes, it depends on it, but it won't end up anywhere else than in gnome's output files references <Rutherther>quezt: sence it's just two, you can try searching for either of those under the store with find and see what has those services. My guess would be that you added colord to dbus services twice, but it seems unlikely that would happen unless you made your own colord service. But I really have no other ideas. another would be using colord-service-type twice, but you should get error about that earlier before this would even be building as far as I can... <Rutherther>quezt: I am pretty sure that won't resolve the conflict, gdm doesn't contain either of those services, and if it was the case, the default system config guix system installer makes wouldn't work, as it contains %destkop-services which contains both gdm and colord services <Rutherther>apoorv569: yeah that's what I was talking about when I said it will probably not be reproducible. Using npm ci instead of install could help with that <apoorv569>Rutherther: I see.. I'll replace `npm install` with `npm ci` and see if it fixes the issue. <quezt>Rutherther, i search for *dbus-system-services*? <Rutherther>because install might change the package-lock.json, whereas npm ci has that forbidden. Anything changing the package-lock.json will definitely cause non-reproducibility in the long term. On the other hand in short-term npm should probably update to the same packages, so it might not be the case this helps <Rutherther>apoorv569: if that doesn't fix it, it will probably be easiest to check what files are actually different each time you run it <Rutherther>quezt: rather search for org.freedesktop.ColorHelper.service or org.freedesktop.ColorManager.service <apoorv569>Rutherther: nope.. hash changed still.. how do you check which files are different? is there a guix way? or like manually run commands to compare files? <apoorv569>BTW what do you think about what I said yesterday, about creating a CI/CD pipeline which build the project and pakcages it as I am doing in this define-gexp-compiler and then I use that tarball from the CI/CD releases and just copy where I want it? <apoorv569>this way I can avoid this gexp-compiler thing I think. <quezt>Rutherther, so far there are so many org.freedesktop.ColorHelper.service. <Rutherther>apoorv569: I missed that. Yes, it's a workaround that will fix the issue, but won't be reproducible as you can see you're getting different results here (which might not be important for you, and if it isn't then it's completely fine) <Rutherther>quezt: that is not so important, what is important is what paths have them, is there anything else apart from colord and dbus-system-services? And as for the dbus-system-services, if you check one of the files, where does the symlink go to? is it colord package or something else? <apoorv569>but won't the tarball be same always? it will be built per-version so only changes once every version. <apoorv569>damn.. I am seeing first hand making something reproducible is not easy. <Rutherther>quezt: okay, so that could be the issue then, that something is pulling colord-minimal to your dbus services list. Can you send your config? Does any of the symlinks in dbus-system-services point to colord-minimal? <Rutherther>apoorv569: what I mean is that if you were to rebuild the tarball. As long as you keep using the same tarball it's of course fine <ekaitz>hi! i'm fixing ngspice package, adding support for X so it can plot outputs but when I do that the tests fail with "No X server running"... should I just didisable the tests? or is there any trick i'm missing? <apoorv569>Rutherther: Yea, I mean if I release a new version a new tarball will be built and I have to change package definition anyway to update the hash and all, I can change hash for tarball as well when I update package definition.. <Rutherther>apoorv569: yeah that's what I was talking about when I said it will probably not be reproducible. Using npm ci instead of install could help with that <ekaitz>csantosb: oh! thank you for pushing that and for testing Kicad9! <quezt>Rutherther, recommendations on what to redact or what to replace for security? <apoorv569>Rutherther: I think you accidently send a message again.. <Rutherther>apoorv569: but imo it's questionable if we can call that reproducible, because if we just always use one built system iso, it never changes, is the system reproducible then? I wouldn't really call it that, that's just because I would call reproducible only processes where you build some inputs and get outputs. Here you just keep using the same file. But this is just a definition thing <Rutherther>quezt: rather search for org.freedesktop.ColorHelper.service or org.freedesktop.ColorManager.service <apoorv569>Rutherther: Hmm.. in this the inputs are built somewhere else.. but I get what you mean. Yea.. not sure what to do here. this is tricky. <apoorv569>well the `--keep-failed` directories in `/tmp/guix-build-foo-deps.drv-0` and `1` are both empty. so can't do `diff -r dir1 dir2` here. <apoorv569>I mean I can always just use the docker container as the official way of installing my app on guix.. but I really wanted to do it without it like a pure guix package. <Rutherther>quezt: that is not so important, what is important is what paths have them, is there anything else apart from colord and dbus-system-services? And as for the dbus-system-services, if you check one of the files, where does the symlink go to? is it colord package or something else? <Rutherther>apoorv569: yeah I noticed that, my matrix bridge is misbehaving :( <Rutherther>quezt: okay, so that could be the issue then, that something is pulling colord-minimal to your dbus services list. Can you send your config? Does any of the symlinks in dbus-system-services point to colord-minimal? <Rutherther>quezt: if you run stat on those paths, does any from the dbus system services link to colord-minimal? <Rutherther>apoorv569: what I mean is that if you were to rebuild the tarball. As long as you keep using the same tarball it's of course fine <Rutherther>apoorv569: I think that is because you're building in /tmp directly in the container, that is not actually mounted anywhere on your system. Only thing mounted is cwd and what's under that in the build environment <apoorv569>the packages usually use the system's /tmp not sure what I did here that it doesn't use that. <apoorv569>well I haven't releases my app yet.. so there are no tarballs to fetch.. I can create one locally to test though. <quezt>Rutherther, sending both home services and system <Rutherther>apoorv569: they do use only part of tmp, not whole tmp. Only their folder is mounted, the /tmp/guix-build-foo-deps.drv-0 you already saw <Rutherther>quezt: colord is part of desktop-services, so you actually have the same service twice. I would expect that to throw different error, that's why I ruled it out. But turns out, it's that then. <quezt>colord is not visible anywhere though, Rutherther <quezt>the service nor a way to apply calibration <quezt>not seeing a dbus method or such <apteryx>efraim: I've removed the foot gun doing dirname in canonicalize-url, which two usages didn't meant to be using anyway. <Rutherther>quezt: colord is part of desktop-services, so you actually have the same service twice. I would expect that to throw different error, that's why I ruled it out. But turns out, it's that then. <quezt>Rutherther, if i install gnome, colord utilities and the service appear though gnome does not work here. do i delete colord from %desktop-services and declare it on its own? <Rutherther>quezt: please be more specific - what do you mean by installing them? there are numerous ways to install stuff on guix <quezt>Rutherther, declare (gnome-desktop-service-type) <apteryx>./pre-inst-env guix refresh gnupg --target-version=2.4 -> gnu/packages/gnupg.scm:310:13: 2.4.7 is already the latest version of gnupg <apteryx>without --target-version -> gnu/packages/gnupg.scm:310:13: gnupg would be upgraded from 2.4.7 to 2.5.5 <Rutherther>quezt: try removing that and put colord to your packages list <Rutherther>quezt: try removing that and put colord to your packages list <quezt>Rutherther, remove colord-service-type? <quezt>Rutherther, or remove gnome-desktop-service-type from %desktop-services? <Rutherther>quezt: definitely keep the one in desktop services, it's essential <Rutherther>quezt: gnome-desktop-service-type is not in %desktop-services <quezt>Rutherther, i definitely have not grasped the scheme paradigms. been mucking around in sicp and introductions but still no clue on probing such things in guix repl <quezt>how would i list the elements of %desktop-services? Rutherther ? <quezt>or Rutherther, how would you avoid or fix this? <Rutherther>quezt: You said putting gnome service type fixes the issue. I said to remove that and instead try putting colord to packages. If that fixes the issue as well, you can keep that solution so that you don't have full gnome just because you want colord. The issue is likely that your dbus session doesn't see the colord interface, because system colord service type installs it to a place that is visible only by system dbus <apteryx>efraim: would you like to review the small change? else I'll push it <apteryx>quezt: ,pp %desktop-services should do it <Rutherther>just the names would be something like " ,pp (map service-type-name (map service-kind %desktop-services))" <apteryx>quezt: less verbose: ,pp (map service-kind %desktop-services) <quezt>thanks, Rutherther and apteryx. now i only need to readup on how to load the symbols and such. feel work is going to call me any second now... <Rutherther>it's just ",use", so ",use (gnu services desktop)" <quezt>no it was not... but i will get there <quezt>Rutherther, to clarify, gnome-desktop-service-type is not loaded. here mate gets finnicky because of mate settings daemon not being active when other x11 config daemons are active. <Rutherther>quezt: I have no idea what you mean by ' is not loaded' <quezt>Rutherther, not to mention having .xsession crashes mate <Rutherther>quezt: prior you said you fixed the issue with adding gnome-desktop-service-type to your services, didn't you? <quezt>Rutherther, must i redo system config? <quezt>Rutherther, gnome does not work. but colord becomes available in mate <quezt>Rutherther, i see. put colord in the packages! <Rutherther>quezt: yes, so I understood correctly then, so I don't really understand what's wrong with the instructions I provided <quezt>Rutherther, it is me not understanding scheme basics <Rutherther>is there a reason debbugs can't look at in-reply-to for patch series? <Rutherther>is there a reason debbugs can't look at in-reply-to for patch series? <rekado>Rutherther: IIRC this is a problem only with the stale GNU fork of debbugs. <Rutherther>so it's like for lack of work, not that there would be a deeper reason in why it's not supported? <apteryx>Rutherther: do you mean why it isn't CC'ing everyone by default? <Rutherther>so it's like for lack of work, not that there would be a deeper reason in why it's not supported? <apteryx>lechner mentioned it was by design per Debian's preferences in the Codeberg GCD, as bug reporters TEre are often non-technical and the system spares them from the noise, messages them only when the bug gets closed. <apteryx>but there are definitely some bugs/behavior fixed in the upstream Debian Debbugs version, such as merging multiple X-Debbugs-CC instead of keeping just the first (or was it the last) one. <apteryx>rekado: would you say mumi is hard to keep running at this point? this seems to be one of the things put forward in the codeberg GCD, but I don't see it. <apteryx>it seems arun has taken over the maintenance/sysadmin part of it for the most part <Rutherther>apteryx: no. I am asking about in-reply-to header that is typically used for patch series so that you don't have to first send the cover letter, wait for answer, and send next emails to that issue. <dthompson>has anyone attempted to package forgejo-runner? <rekado>apteryx: a few months (years?) back I decided to step away from developing mumi and let nature take its course. I didn't want to give the impression that mumi and debbugs and all that relates to it is forced onto the community by old timers like me. <apteryx>fwiw, I've never had that feeling; it was always this nice shiny extra, that was available *on top* of the other means we were already accustomed to. <rekado>apteryx: there are many annoyances I had with mumi, but my impression at the time was that public sentiment had turned against mumi. I remember reading a lot of negative feedback here and in emails complaining about it. So I vowed to never fix another bug in mumi. <apteryx>I'm sorry you felt such backlash, it's unfair. <rekado>so it would be wrong of me to say that it is *hard* for me to keep mumi running, because I have successfully removed myself from being involved. <apteryx>right. and when you were running it, was it a pain to keep running? did you burn a lot of time doing so? or was it mostly stable and not needing too much attention? <rekado>the running itself was never terribly problematic <rekado>I remember that guile-xapian would often crash, though, because the bindings were pretty rough. <rekado>the implementation of the interface with debbugs had become a little gross since the early days. <rekado>originally I wanted to use the SOAP interface provided by debbugs, but that turned out to be very buggy. <rekado>(truncated messages, for example) <rekado>so we eventually ended up with a copy of all of the emails that debbugs receives. <apteryx>yes! that's currently something to improve; it takes 30 min to reindex all this 20 GB of mail data completely <rekado>the rsync from the debbugs servers to berlin is pretty gross, in my opinion, but that's what we needed. <apteryx>it's not elegant, but it gets the job done :-) <rekado>my biggest annoyance with the whole shebang is the fact that we don't get to do fix anything in that shared debbugs instance. <rekado>we can't change the very generic emails it sends to bug submitters, for example <rekado>so we still get people who use the raw debbugs URLs instead of issues.guix.gnu.org <rekado>this lack of control (which is understandable as it is a shared system held together by a generous helping of pre-chewed gum) is frustrating. <apteryx>the savannah admins taking care of Debbugs were receptive of anyone attempting to rebase GNU Debbugs on top of Debian Debbugs. They offered me access to VMs and such. I think lechner may have experimented with that? <rekado>Arun has done a wonderful job of improving mumi, and more than made up for my stubborn unwillingness to contribute again. <apteryx>they have mumi running at patchwise.org, which may be interfacing with a custom debbugs too (not sure) <rekado>but sorting out that haphazard debbugs fork... I don't know. I wouldn't wish that job on my worst enemy (if I should ever get one) <apteryx>It's probably very light hacks here in there more than anything substantial. Knowing the original version it's based on, it should be doable. Could be fun even. What am I waiting! haha <rekado>I wonder where exactly the point lies right between extending a maintained new forge-style system and restoring life to a moribund system that does one thing reasonably well (email) but fails at many others. If we can find that point, perhaps we could figure out how far we are from it. <rekado>all the patch prettification in mumi, for example, isn't really great. It was a low effort addition. Some line processing of email text. Not context aware at all, because it doesn't work on git commits but on arbitrary text. <rekado>a forge has all the juicy git data <rekado>we can't keep stretching text processing; it won't ever reach where forges with git info start the race. <rekado>personally, I think extending forgejo with email capabilities would be easier than extending our little mumi experiment. <rekado>I have no skin in the game any more and I'm sure I'll manage to get my brain confused by either system. But I think with might be reaching mumi's design limits sooner that we'd like. <apteryx>the advantages on paper do not always translate to advantages in real life <jcabieces>Hi everyone. I'm trying to follow the documentation to hack guix packages from my local git checkout using pre-inst-env command, but guix keeps using some already built package no matter the modification I make. <Rutherther>jcabieces: 1. are you sure you're building the package you're modifying, 2. are you sure your modification actually changed the package? <jcabieces>Rutherther I try to add native-search-path to the qtsvg package and I launch ./pre-inst-env guix build qtsvg <jcabieces>Rutherther If I type "./pre-inst-env guix describe", it shows me my distant git repo defined in my channels.scm, not the local checkout. Is it OK? <Rutherther>jcabieces: native-search-paths of the package do not change the package itself. So there is indeed no change, so no build, the previous package is used. Also note that there are two qtsvg packages in guix repo, so guix build qtsvg builds the latest version 6 <Rutherther>that being said, your pre inst env guix describe shows me my local repository. So you probably also have an issue there. Have you done the configure and make steps? <jcabieces>Rutherther I'm targetting the qt 6 version so that's fine for that. <jcabieces>Rutherther Regarding the native-search-path, how can it not has changed the package? If I type ./pre-inst-env guix shell qtsvg --search-paths, I'm expecting to have the new paths defined. and this is not the case <Rutherther>jcabieces: yes, --search-paths should change as long as there are directories in the output profile that the search path points to. But that doesn't mean the package needs rebuild. The search paths are definted in the package definition, not form the build process. The built package stays the same when search paths change. <Rutherther>jcabieces: You sent a paste with commands, but without the make command. Did you execute the make command? <Rutherther>I don't know if it's strictly required,but if you ran the previous steps without errors, I can't think of anything else that would be causing you to see the behavior you're seeing <jcabieces>Rutherther OK. I try to follow instruction on Building from Git, see if it helps <jcabieces>Rutherther it seems it changes things. My modifications did step in the way while triggering make <jcabieces>Rutherther I'm gonna continue this way. Thank for your help š <bjoli>I decided to switch to guixSD after playing with it on an old computer. After killing that computer I realized I hate gnome. What is the status of KDE on guix? <bjoli>(i had to switch to gnome when I made Aeon my main distro, but then accidentally played with an opensuse slowroll live image and realized I miss KDE soooo much). <ngz>bjoli: I never used it, but Plasma is available on Guix system. <jA_cOp>I ended up with Sway based on %base-services for my Guix system so I haven't tried it, though <ieure>bjoli, I've run KDE on Guix, it seems to mostly work, but has a few gaps. Some of them seem to be KDE gaps (the volume control buttons do nothing), others are Guix gaps (things like Okular don't get installed). <ieure>bjoli, So tl;dr, it's there, it mostly works, it might need a bit more tweaking than Gnome. But also I haven't daily driven KDE since maybe version 2. <jA_cOp>w.r.t. the volume control buttons, are you referring to the keyboard keys? <vhns>I thuoght people just used GNOME as a platform to run emacs and be done with it :^) <jA_cOp>ah ok. FWIW, I think KDE global shortcuts work on both X and Wayland now (using KDE on a different host), so that might be a workaround <ieure>vhns, I daily drive EXWM. Gnome has a bunch of annoying defaults that make it irritating to run Emacs under. At least for me. <ieure>jA_cOp, I got brightness controls to work, volume is still elusive. Some searching seemed to indicate that this wasn't a thing that just works out of the box with KDE. Or indicated that was the case at the time. <jA_cOp>I'm using KDE on a desktop computer, but apropos special keyboard keys, I noticed Plasma now has a "power management" widget in the system tray. I'd be curious to try KDE on a laptop sometime to see what it's like these days <ieure>jA_cOp, I was running it on a laptop, it was fine, the usual stuff you'd expect to work works. <ieure>jA_cOp, My gripes were that plasma-desktop-service was missing stuff like Bluetooth support & Okular; it takes a weirdly long time to log in, longer than any other DE; and volume keys didn't work OOTB. <jA_cOp>Yeah, I'm using Plasma on a system with Void Linux, and I get the impression that the startup logic for non-systemd distros is somewhat second class. Login issues on Plasma are not fun to debug <jean0t>I am currently in brazil, everything runs ok, fast and beautifully <jean0t>but when I try to download the guix iso or any Free Distro like Parabola, the download goes to Bytes/s <jean0t>or Kb/s extremely slow like 69Kb/s <jean0t>I tried using tor socket but it doesnt change the result <jean0t>it is particularly strange because other distros like debian or fedora <jean0t>probably their server is bad asf? <jA_cOp>but I don't know if ftpmirror.gnu.org is geo-distributed or something <jA_cOp>I suppose if it's also slow on Tor it's less likely to be a geo-distribution problem <jean0t>I used torsocks and the option of --socks5 in curl <jean0t>because I thought it was a browser thing <jean0t>and I use a different dns from my lisp <jean0t>I will see if changing the dns will solve it, maybe it is the system dns <jA_cOp>Oh actually, ftpmirror.gnu.org seems to redirect to a mirror, sometimes different when I reload it - so it's definitely distributed. You can try opening https://ftpmirror.gnu.org/ in a browser and see it too <jA_cOp>I am guessing it's doing HTTP redirect based on geo-IP location, in which case your DNS settings will not affect the chosen mirror <jean0t_>is there a way to force to use a different geo location? <jA_cOp>It's probably not ideal from Brazil, but if the problem is a broken mirror somewhere close to you, maybe you'll see a difference at least <jA_cOp>I don't know. Maybe on gnu.org somewhere? <jA_cOp>I hope you figure it out, good luck :) <abralek>i decided to finally run openconnect in a container (not docker) and curious what would be a good way to set capabilities <abralek>I thought maybe i could do setcap during the build, but guix-daemon cannot do it <Rutherther>abralek: yes, you cannot have privileged executables in /gnu/store, that would be a privilege escalation. Instead, you have to use privileged-programs in your operating-system / privileged programs service type if you're making a service <lfam>gabber: I suggest looking at debbugs.gnu.org, because that is actually the canonical source of information for issues.guix.gnu.org, and it often stays online when our own page goes down <abralek>Rutherther: well i would not call it a service per se, but what I would like is to run shepherd in a container which would run openconnect. I also run darkstat and socks their <lfam>I can confirm that issues.guix.gnu.org is not responding <Rutherther>abralek: by service I mean the service you put to services list of operating-system <gabber>lfam: thanks! i usually try issues.g.g.o first since i know how to easily get the thread of an issue i get emails for <lfam>Yeah, it's a nice interface <abralek>Rutherther: somethings like guix-container $PWD or something looks more appealing <lfam>I presume it's been mentioned, but it looks like our Git repo at Savannah is offline too <abralek>Rutherther: not sure about PWD but i have shepherd running under my account, and can run other containers. No capabilities thought <abralek>lfam: I am sure we want capabilities. Right? <lfam>Not sure what you are referring to, abralek :) <abralek>lfam: do you have some ideas of how linux capabilities should be implemented in Guix? <lfam>Oh, no, I don't really know. It's definitely an interesting area and something that other Guix hackers want to make use of <Rutherther>abralek: they are already implemented in the operating system privileged-programs... <Rutherther>abralek: they will never be implemented to gnu store as that is, as I said already, a privileged escalation risk <abralek>Rutherther: i see. I saw tobias changes yes. so you think deploying libcap binaries there would be a first step? let me check what we have there <lfam>I think it actually contradicts your message Rutherther. People are working towards using capabilities with the guix-daemon <lfam>Basically replacing the use of root privileges with Linux capabilities and namespaces <Rutherther>abralek: deploying libcap where and for what use? <lfam>Rutherther: Did you see the link I sent just two minutes ago? <lfam>Did you see that link I just sent? <eikcaz>lfam: not sure if you saw my latest patch for the Syncthing service revamp. Since fixing the initial errors is backwards incompatible, I'd like to get the patch through sooner than later. <abralek>Rutherther: in our case /run/privileged/bin. But the thing is even though I would have setcap there, we do wrap things, and it wont work. <lfam>eikcaz: Ah, I didn't realize it was still pending. Let's get that in <lfam>eikcaz: What's the "upgrade path" for people who will have to do an incompatible upgrade? <Rutherther>lfam: okay, I skimmed through. Can't find anything that would contradict my statements, could you tell which e-mail there you had in mind. The only mentions of capabilities I read are for guix-daemon to give it the CAP_CHOWN capability <eikcaz>(1) update record names if you used any of the few that changed and (2) move contents of ~/.config/syncthing to ~/.local/state/syncthing <eikcaz>(2) is actually relevant to anyone with a particularly old syncthing install as well. I made a note of this in the guix.texi, and a meta-note in the latest patch annotation <eikcaz>actually, the latest patch version (v4) patch annotation gives a good summary, so just skip to that one <jA_cOp>I set up the syncthing home service three weeks ago and it's already using .local/state/syncthing, so I guess it strictly doesn't affect all users <Rutherther>abralek: I really have no idea what you're talking about, sorry. You put binaries to /run/privileged/bin that get capabilities by setcap or setuid/setgid added. I don't know why you would put setcap there, that again would pose a privilege escalation vulnerability as everyone could just setcap anything <lfam>Rutherther: I was speaking more generally about your statement that Linux capabilities will "never be implemented to gnu store". It's kind of a vague statement, but I wanted to point out that the project is planning to use them to mediate access to the store, rather than the mechanisms that we use now <lfam>I don't understand the details, but it's a big change in the implementation of the access model <eikcaz>I was able to maintain a lot of backwards incompatibility. I.e. if you specify records as strings, it will still work. Even "false" -> #f. <eikcaz>(which would be pretty bad if "false" silently was interpreted as #t) <Rutherther>lfam: yes, it was deliberately vague statement, because it was just a reference to a previous message I sent: yes, you cannot have privileged executables in /gnu/store, that would be a privilege escalation. Instead, you have to use privileged-programs in your operating-system / privileged programs service type if you're making a service <lfam>Oh, yes, that's true. I misunderstood your point <lfam>Sorry to make you spell it out <abralek>Rutherther: hmm but how that would work? I don't install openconnect globaly. What I am doing is having a direcotry with shepherd configuration. I want spin up this shepherd in a different namespace net proc etc, and run openconnect (VPN which needs *some* capabilities) <lfam>eikcaz: I'm struggling to find the relevant emails. Which ticket number is it? <Rutherther>abralek: if you want to use capabilities with guix system declaratively, there is no other implemented way (at least in guix channel) than what I suggested, and yes, that means installing it globally. If you want to hack something yourself you of course can, but it will still have to be ran as root initially to setup or you will have to install globally something with setgid that will deploy what you want where you want. The main thing to note is that... <Rutherther>... you will not be able to use capabilities just from a package itself, it needs 'outside' support <Rutherther>lfam: if that apology was for me, no worries at all <lfam>I see why I couldn't find the email, eikcaz. The subject says "Syncthnig" [sic] :) <abralek>Rutherther: yeah you are right. That is why I decided to brainstorm it here) <eikcaz>I can't even count the number of times I have made that spelling error in the last few months <abralek>Rutherther: Usually i do guix shell ... I can also run it and add to local shepherd. creating a network namespace with netns. but not sure how to let openconnect to bring tun interface up <Rutherther>abralek: there is many ways to do it, so it depends a lot on what you prefer. I would probably make a guix service that would create sort of a 'setup' script that would run under root (so be put into privileged programs with setgid) and copy the necessary binaries like openconnect and give them the needed capabilities <russell`>Does selecting tor services during guix system install route /most/ traffic including guix pull through the tor network? <lfam>sneek: later tell eikcaz: I have to go afk for a while too, but my goal is land the syncthing patch tonight. If the patch submission doesn't contain instructions for the "upgrade", please send an email describing the process. I'll make it into a Guix news entry so that users can hopefully handle it themselves <attila_lendvai>so, apparently pip also installs binaries (wtf!). i was running home-assistant happily on guix, but this upgrade broke, because venv/bin/uv is a binary that doesn't find libgcc_s.so.1 any hints/ideas? shall i just switch to the docker edition? <abralek>Rutherther: the copy part I don't understand. I want to keep using guix shell that is for sure. I am now think that I could put setcap/capsh in privileged, and make it so that guix and guix shell could pass exiting caps down iff i ask <podiki>attila_lendvai: you could run it in a guix shell --container --emulate-fhs; takes a bit to figure out what you need in there sometimes and what to share/expose, but then you have it <abralek>Rutherther: sorry I mean do something sudo setcap guix shell <abralek>Rutherther: so that it would not be passable to run setcap by everyone as you said <Rutherther>abralek: well you can't setuid what is in /gnu/store, so if you want setuid a binary from the store, you need to first cp the binary out of the store and then setcap it <Rutherther>abralek: sorry I don't understand what sudo setcap guix shell means, setcap is executed against executables, but guix shell is a subcommand of guix executable <russell`>reading through the (guix)Networking Setup texinfo page, I don't see that guix would use the tor network as a proxy and my config file has nothing outside the default. Perhaps the guix pull is just taking a rediculous amount of time today <abralek>Rutherther: Why setuid? Can I run a setcap with sudo (I am root) and get all the privileges. guix process will geth those. right? If I ask guix to keep the caps I need they will go down to shell ... right? <Rutherther>russell`: yes, the tor service is only for configuration of the tor daemon service you use to connect to daemon, it doesn't mean anything is routed through proxy <Rutherther>abralek: yes, but I am talking about a way to execute the script without root rights. If you want a script that you execute with sudo, it's fine without setuid of course <Rutherther>and re setting setuid on gnu store executables: just substitute for every time is say that setuid or capabilities. It doesn't matter. You just have to copy it out of the store always <jA_cOp>The recommendation from the Tor Project is to integrate the Tor proxy in a per-application manner to reap the full privacy benefits, so a Guix service that would configure a system-wide proxy might not be a good thing anyway <abralek>yeah, don't want to do setuid. I know that this container would need these caps, hence I do run it with root, however I ask guix explicitly to pass the one I need. <attila_lendvai>podiki, that got me going, thanks! but my problem is exactly with gcc: the only place where i find libgcc_s.so is in gcc packages, but when i try to use gcc:lib then it's obsolete, and gcc-toolchain doesn't have that .so... :/ <podiki>attila_lendvai: i'm not on my guix machine, but gcc:lib was added to gcc-toolchain some time ago (mid last year maybe?) <podiki>in b47ae1ecc43baaf726701ab2d2f810ecfaa75428 <jA_cOp>attila_lendvai: I have no idea why, but in some manifests I have written for guix-shell I have had to use "gcc-toolchain@12.4.0" to solve that linking error. Maybe that GCC version will work for you? <attila_lendvai>podiki, `find /gnu/store | grep libgcc_s.so` only gives me matches in gcc packages. i have gcc-toolchain in the shell --container, but ldd says: libgcc_s.so.1 => not found <podiki>interesting, perhaps there is a bug there <attila_lendvai>hrm, i may be confusing myself. this is a separate user with its own profile, and i didnt do a guix pull. let me see all this after a guix pull and guix package -u <podiki>if it is a really old guix, that could be why yes <podiki>(the guix pull will be enough, since you are using guix shell and not installed packages) <attila_lendvai>how can i see where `guix describe` is getting its state from? IIUC if i never do a guix pull then it comes from the system? <podiki>workaround if you are before that gcc-toolchain change is to use -e '(list (@@ (gnu packages commencement) gcc) "lib")' <podiki>(a way to get at the non-public gcc:lib output) <podiki>guix describe tells you the guix that "guix" is <podiki>guix should always be from a user, even when using sudo on a guix system it uses user's guix <attila_lendvai>so, if i want to avoid having to guix pull for each user, then i can just guix package --uninstall guix? (to inherit the one from root (or the system?))? <russell`>jA_c0p: agreed, I'm was just having performance issues with guix pull today and trying to rule out things (in this case tor-service-type) <podiki>no, you never guix install guix or guix unintsall guix <podiki>every user gets their own (perhaps same) guix; that's a key feature of guix for user independent installs <podiki>maybe i meant user dependent packages, meaning different users can have different versions of the same packages without issues <attila_lendvai>...which is what i need here: runing home-assistant and updating it rarely (because it's a headache) <podiki>so you have separate user for that i take it? <abralek>So now I am kinda thinking that we need something like a AppArmor <podiki>you could also pin the guix (and all other channels) to some commit for that user in their channels file <podiki>so you can keep guix in a particular state, but will need to handle the pip part separately to keep fixed <attila_lendvai>podiki, and i assume there's no point to pin packages in the manifest, because a guix pull may get rid of some versions. the way to pin is to pin the channels, right? <jA_cOp>russell`: I think you can rule it out, but in general, I think you could look at /etc/resolv.conf, /etc/hosts the output of iptables-save, and if using a local DNS resolver, looking at its configuration; if nothing stands out as being Tor-related, a system proxy could be ruled out with pretty high certainty <podiki>attila_lendvai: right, packages can change without their version changing or their version will change but not anything you can fix in the manifest <podiki>unfortunately guix shell with emulate-fhs doesn't work with a manifest (since it has to add a separate glibc); it should, just hasn't been done <attila_lendvai>podiki, that's what i used, though, and it didn't error. what do you mean by it doesn't work? <podiki>attila_lendvai: i thought guix shell --container --emulate-fhs --manifest manifest.scm might error or not include glibc but maybe i'm wrong <abralek>Rutherther: ok in terms of a service. What if we could see process creation and match it with some scheme. restrict OR even ADD capabilities <jA_cOp>podiki: it works for me, I am using it - but I have had to manually include gcc-toolchain (and invariably major version 12) <podiki>it would just be the glibc-for-fhs that emulate-fhs adds to the environment <podiki>maybe i'm thinking about if you had a glibc in your manifest. been a while since i looked at it <podiki>emulate-fhs doesn't add any packages besides the special glibc; main thing it does is set up /lib /bin and that sort of thing <podiki>special glibc as guix's glibc is patched to not use global loader <lechner>sneek / later tell apteryx / Hi apteryx & Rutherther, I packaged both GNU's and Debian's Debbugs for Guix and deployed both on my own equipment, but at the time the GNU folks were committed to Trisquel so we never upgraded. There is a lot of inertia at FSF. I have admin access on debbugs.g.o <attila_lendvai>ACTION is staring at "indexing objects" that takes way longer than his patience <anticomputer>this is a new one: on sys reconfig I get "guix system: error: unrecognized boot parameters at '/var/guix/profiles/system-34-link/parameters'" and my boot parameters is empty as opposed to being a bootparam sexp, don't think I changed anything dramatically, just did a guix pull ... known issue? <lechner>anticomputer / that doesn't look good. is 34 your current "system generation"? <anticomputer>lechner: to wit, I'm booted into generation 33 because 34 was breaking boot, just roll back to 33 I reckon, but odd <lechner>anticomputer / was there an earlier error in the reconfigure that would have prevented the parameters from being written? <tschilp>does anyone have an idea how I would get hand on the ~gapplication~ command for GNOME desktop. Yesterday I noticed that gnome-maps is not visible in my gnome applications, and noticed that it's being called by ~gapplication~ in its .desktop file. https://gnome.pages.gitlab.gnome.org/libsoup/gio/gapplication-tool.html tells me that it's part of glib. If I install glib to my home environment I still cannot use ~gapplication~. Mhm <anticomputer>lechner: not that I caught, but I was moving swap devices so probably I missed something getting interrupted <anticomputer>ick the current profile having the borky parameters prevents switches and rollbacks through guix system apparently <anticomputer>lechner: any way to hard prune the current generation off the top? <lechner>anticomputer / you need an expert for that, but I would reconfigure with a known good revision <anticomputer>lechner: right, kind of chicken/egg as the current profile prevents most guix system commands from working, I'll re-align my swap partion and boot into an older generation to see if I can prune from there with delete-generations <lechner>anticomputer / i only use deploy and that works most of the time <lfam>anticomputer, lechner: I also experienced empty files in the last few days. I thought it was just me. <lechner>actually, i meant it positively. we are a group ready to help <lechner>anticomputer / what did you do to your swap partition? <lfam>Also, I was not doing anything to my swap partition when this happened, so swap might be a red herring <lfam>IIRC correctly, I worked around it and was able to switch generations by running the activation scripts from older generations "by hand", like this: `guile -s /var/guix/profiles/system-96-link/activate` <lechner>i think anticomputer knows the previous gen won't boot <lechner>anticomputer / lfam is the expert i meant <lfam>I'm far from the expert on Guix System! But I was able to poke around and use the knowledge I have to do this <lfam>I was also able to run switch-to-system.scm and install-bootloader.scm scripts "by hand", but they weren't enough on their own to fully switch <lfam>I'll report the bug now, with the scarce details I have <podiki>i wonder what changed, only thing system related i remember in past few days is shepherd logging <podiki>i did a reconfigure (but did not reboot) a few days ago without issue <lechner>podiki / better check the parameter file of the latest generation <podiki>....i shut down that system and now am away for the rest of the week <podiki>guess we'll find out eventually! <anticomputer>lechner: I just swapped from a swapfile to a regular partition, thing is i did the exact same migration on my other system, same config, no problem, so just now I reconfigured the partition as swapfile config and booted into previous generation, but current system profile empty files prevent any guix system commands from pruning <lfam>Well, I did not make any changes to filesystems or partitions when I got the bug <lechner>anticomputer / well, your issue may be compounded in that you would be going to a less welcoming place <anticomputer>lfam: my current issue is rolling back with a current system profile link linked to a broken guix profile that interrupts based on "guix system: error: unrecognized boot parameters at '/var/guix/profiles/system/parameters'" which is due to the current system profile having the empty parameters file ... which also prevents that profile from booting at all obviously <lechner>maybe it should be a bug that guix doesn't boot without swap <lfam>Yes, did you see my message about my workaround? Running the activation scripts from a previous generation "by hand"? <anticomputer>lechner: yeah I'm about to hard link out this profile by hand <lfam>It's not enough to change the system profile link. You have to activate the generation that you are switching to as well <lechner>anticomputer / there is a medal for you at the other end <lfam>Maybe related, before this happened to me, my `guix time-machine` and `guix pull` commands were failing to build a 'guix-package-cache.drv'. I just kept running the commands, trying different commits, etc, until it worked <lfam>Does that ring a bell for you anticomputer? <vhns>I don't know if Carlo Zacanaro is in the channel or not, but thanks a lot for implemeting auto-start? in <wireguard-configuration>. <vhns>I needed something like that for my laptop for the longest time. <lfam>anticomputer: Curious which kernel version you use? <podiki>lfam: for your bug report, did you get any output when you couldn't boot? or messages from the reconfiguring? <lfam>podiki: When booting, the bootloader complained that it basically couldn't find any information <lfam>Like anticomputer said above, the boot parameters file was zero bytes <lfam>Reconfiguring appeared successful, although I didn't study the output of it <anticomputer>podiki: it just breaks on the boot init because the parameters sexp is entirely missing <podiki>the boot parameters being empty was reported during reconfigure though right? lfam did you get that on reconfigure or you are not sure and may have missed it? <lfam>Like I said, it looked okay but I didn't study it. It's worked so many times before :) <lfam>Is there supposed to be some validation? <lfam>To be clear, every file in the system generation was empty. Not just the boot parameters <anticomputer>lfam: ok using your manual activation + rw remount of / and manually resetting the system link to non-broken profile i was able to prune out the offending current generation <lfam>Great anticomputer. Glad to hear we have a workaround <podiki>anticomputer: the error you reported above about guix system saying empty parameters file, that was on reconfigure? <podiki>(and then booting failed, per those empty parameters) <anticomputer>podiki: no it was after a reconfigure that completed without error (that I saw anyways), and then on reboot it borked and on boot into a previous non-broken gen the empty parameters file became apparent to be the issue on the current gen <anticomputer>podiki: subsequently all "guix system" commands failed due to parameters on current being empty etc. <podiki>(i don't have anything useful to say, just wanted to be clear on what was messaged by guix or not) <lechner>lfam / i know folks here don't care but I set the bug to 'grave' <lfam>Thanks lechner. It's certainly grave <lfam>One of Guix's promises is broken here <lechner>anticomputer / yay! maybe lfam deserves the medal <lfam>Lol, hardly. I didn't even report it <attila_lendvai>jA_cOp, podiki, after a guix pull it works. and i don't need to use specific gcc-toolchain either. `guix shell --manifest=manifest.scm --container --emulate-fhs --network --share=/srv/hass=/srv/hass` <jA_cOp>ah, nice! I've been contemplating running home-assistant on Guix too. Would be cool to package it, not sure how much work that would be <anticomputer>lechner / lfam: reconfiguring now, will check the resulting parameters before rebooting :P <lechner>anticomputer / will you please confirm the workaround by amending the bug for others, please? <podiki>and guix describe or related guix system so we know the commit it happened on <podiki>attila_lendvai: great, glad to hear it! FHS is sort of a last resort fall back, but i'm glad it works when needed <lechner>by the way, in case there are duplicate bug filings for this, the standard way to merge bugs on Debbugs is to "forcemerge". Sounds scary but only makes sure bug metadata is compatible <anticomputer>lechner: sure thing, waiting on all the substitutes to finish fetching <attila_lendvai>podiki, FTR, it used to work fine by installing the necessary packages in the user's profile and using a custom shepherd service to start it from the activated venv... but a recent update added uv (some python package manager) dependency that broke due to the above issue. <podiki>oh boy and uv is written in rust if i'm seeing the same thing <anticomputer>it's definitely this generation that's causing the issue <anticomputer>guix channel commit: 8f844e6af095fa86871474150700068a114af9fa for reference for me <ieure>potatoespotatoes, mra is working on some of that stuff. <potatoespotatoes>cool! I have an ISO I'm building to bootstrap a zfs-on-root guixsd (it's sort of short) and I would love a pair of eyes to see if I am doing anything wrong <Aurora_v_kosmose>It's better for per-service integration to be used still, but one can work with a global daemon anyway. And actually, with per-application integration & the control/service socket, one can still use a single daemon without downsides. <lfam>anticomputer: Whatever information you can collate, please send to the bug ticket <lfam>You might be the only one who still has the broken generation available. I accidentally deleted mine <anticomputer>lfam: yeah I am, just seeing how/if I can reproduce, not sure if this empty drv is an artifact of the bug or of a borky current generation state :) <attila_lendvai>hrm... i seem to remember something that a `guix shell` inside a shepherd service had some issues... and that's why i switched to installing into the user's profile. aaaand i'm seeing: "guix shell: error: mkdir: Permission denied: "/tmp/guix-directory.sfpIhA/real-root"" <attila_lendvai>probably i'm the only one crazy enough to try to run a `guix shell` inside a shepherd service... :) <attila_lendvai>podiki, any idea how/why `guix shell` inside a shepherd service would break with the above error? <anticomputer>lfam: oh commit: 8bc831325a905dbd9015739b58e3a5138d2217da actually for the broken system generation, the other is from guix home <sneek>eikcaz, lfam says: I have to go afk for a while too, but my goal is land the syncthing patch tonight. If the patch submission doesn't contain instructions for the "upgrade", please send an email describing the process. I'll make it into a Guix news entry so that users can hopefully handle it themselves <anticomputer>yeah something is very broken on this generation, drv files are randomly ending up as empty files <lfam>Okay, it happened to me a few days ago, so we can try to start narrowing down the commit <lfam>anticomputer: It happened to me on a kernel-updates branch that was based on 9866d32e173050ba99dc520b0a4d5aacb85e3fa0 <lfam>I also use another channel to provide a kernel variant, that was current <lfam>But on the bug report, Tomas Volf said it's been happening to them for months... <anticomputer>I submitted the data I have to the bug report, should go through fine even though I'm not subscribed to any mailinglist presumably? as long as topic and to address are correct or no? <podiki>attila_lendvai: i never even imagined running guix shell inside a shepherd service, but i guess something about what user it runs as/permissions....not sure <attila_lendvai>wild guess: maybe its the fork+exec-command switching user in the middle of mkdir <podiki>maybe as a service better to use the internal commands rather than "guix shell" <anticomputer>lechner: so what "fixed" my current generation from spitting out empty files at random during the derivation process was a regular guix gc, followed by a guix pull, I had about 35GB of crud to cleanup (but plenty of disk space), then the reconfigure completed without incident and I'm now booted into that generation (including swap-change) <anticomputer>for folks following along, so TL;DR workaround for mystery empty file bug: reboot into old/working generation, perform manual activation of the working older system profile (sudo guile -s /var/guix/profiles/system-XX-link/activate) + remount rw / to adjust the current system profile link to get "guix system" commands working again, guix system delete-generation to prune out the offending broken/current generation, guix pull + guix gc to <anticomputer>clean state, then reconfigure the system to get back into a clean current state <podiki>attila_lendvai: have to run, but what i mean is calling the actual scheme procedures directly <attila_lendvai>hrm. i think that's beyond me, unless i find an example somewhere... <graywolf>Hello Guix, I am reading manual for krb5-service-type, and I see "It does not cause any daemon to be started.". Well, how do I start the daemon?