<nckx>As to why, I suspect 'confused by the complex XDG spec' + 'it worked on my machine'.
<normeo>it bothers me that anything would presume xdg in the first place
<nckx>My answer from earlier applies here: this is not a 'distro' (Guix) thing, it's a 'do you run elogind' thing. If you do, it will create that directory. If you don't, 'guix home' is forcing a wrong setting.
<nckx>Well, end users (programmes) are supposed to do the falling back.
<Guest53>Ay! I dropped in yesterday, was setting up an Erase Your Darlings config, just kinda blabbering to myself but that's ok; have got things rolling now, just setting up persistence for what matters
<Guest53>Haven't used Nix, but it looks like a lot of services have their directories configured, which I can work around
<Guest53>Currently seeing if I can get my activation service to run before others but changing their declaration order, feels kinda like I could use some Shepherd dependency resolution there
<Guest53>But tbh I feel that most in my mapped-devices, bc I'm going for FDE and boy is there some work to do! Learning a lot tho
<Guest53>Wasn't able to get ZFS on root working, shame R5AMH's patches, uh, didn't work out...
<Guest53>But LUKS keyfiles need implemented too, I guess I could have a shot at that, initially informally
<Guest53>And oof, we can't boot off of /boot? I mean, my LUKS-on-Root config is booting just fine (and I believe it's even formatted with LUKS2!), so I guess that isn't a big deal, but I wouldn't want my keyfile (in the initramfs) in the store...
<Guest53>I've been meaning to hack together my own secrets system, but it's a tough nut
<Guest53>Might just hack my keyfile into the custom mapped-device-kind-open proc that I'm already using for rollback-on-boot, but open to doing at least *some* of this "the right way" in the future and up-streaming it
<Guest53>Priority right now is still "everything working pls"
<Guest53>Ah, but that still address the secrets aspect
<Guest53>Neat, can even hibernate with an encrypted swap, though... I roll-back on mount, and don't like that resuming from hibernation rolls back too, that could cause issues. My current solution is that all ephemeral mounts should be mounted with overlayfs on top, which is preserved when hibernating; '/' is basically a tmpfs
<Guest53>Re: keyfiles and secrets, I'm gonna bite the bullet and just adapt this script into one that concats the initramfs cpio with one containing the keyfile
<Guest53>There's been a lot of papercuts in this process, and, I don't mean to be a downer; I know resources are scarce, and hope to be able to upstream something myself-- collecting gripes is just the first part of that process and for posterity
<Guest53>with that said, one more nag is that I have an encrypted swap partition; I mark it needed for boot, so it's available for the kernel to RESUME from, but every LUKS partition is also put into grub.cfg, which (between this and the keyfile WIP) means putting in my password(s) 4 times
<Guest53>So, what I'm doing right now is using `(type (mapped-device-kind (inherit luks-device-mapping)))`
<Guest53>because that doesn't `eq?` `luks-device-mapping`
<Guest53>and thanks a bunch for answering sandwich, I've just kept rambling to myself but wanted to be sure to let you know that I really appreciate the contribution c:
<Guest53>Did the search engine rounds' a while ago
<vagrantc>so, tests suite of python-pypdf depends on non-free .pdf files licensed under creative commons Attribution-NonCommercial-NoDerivatives 4.0 International ...
<vagrantc>which makes me think i just need to disable those tests ... but is that allowable as non-functional data? it is a bit of a stretch, as PDF is in a strict sense a programming language (or very nearly so)
<mirai>but I don't see the problem of running the tests
<mirai>and since they're tests, I don't think they'll end up in the package anyways
<mirai>vagrantc: we could go on a turing rabbithole there
<vagrantc>well, i figured out how to disable those tests, which ... at least avoids the licensing issue question entirely
<vagrantc>obvously, it is missing some test suites, but ... meh.
<vagrantc>well, that license allows distribution without changes and without commercial ... both of which are not very free at all ... i'm inclined to say we just don't include that in guix, and will wrap up my patch just disabling the tests.
<Guest53>Took a break, stayed up late, all working great now!
<Guest53>Encrypted, including a boot partition, with a keyfile in the initramfs (but not in the store), rollbacks (which are redundant bc of tmpfs, lingering hibernation issue here), and a lot of ugly code abusing `mapped-device-kind`
<Guest53>Will clean it up soon, maybe not tomorrow, maybe ZFS next time (getting this box up and running was more important, but I can try to boot off the array in the future without screwing with the current boot disk)
<Guest53>Going to go sleep on secrets management ideas, and /home (ie. home-environment) will be getting the same erase-your-darlings treatment (no more litter!)
<lebowski>hi guix! in which package i can find rustup command to add wasm32 target for the compiler?
<tschilptschilp23>Hi guix! Is it only me, or are you also having a 'memento-effect' using ungoogled-chromium in combination with ublock-origin? I mean, that even if I deliberately chose 'stay signed in' or similar on home pages, as soon as I close my browser, I will have to sign on to the service the next time I start it up. I cannot recall to have tweaked anything -- is this the expected default behaviour?
<tschilptschilp23>OK, that was too quick writing, I guess I just found it, I have 'clear cookies and site data when you close all windows' active...
<rekado>tschilptschilp23: you’ll need a synthesizer
<rekado>tschilptschilp23: e.g. fluidsynth with a soundfont or timidity++
<rekado>you can wire them up to your midi device with aconnect (when using ALSA MIDI)
<tschilptschilp23>rekado: thanks for the infos. I guess for now plain timidity will do what I need (simple midifile playback for experimenting)! I mistakenly thought my built-in soundcard can do hardware-midi-sequencing, but it doesn't look like it...
<tschilptschilp23>aplaymidi lists a midi-passthrough-port though, maybe that might prove useful somewhere in the future though...
<tschilptschilp23>I'm just trying to build GNU solfege from a guix shell with 'guix shell make gettext python gcc-toolchain texinfo swig lilypond docbook-utils pkg-config gtk+ python-wrapper python-pygobject', but at the configure stage I receive 'checking for PYGTK... no'. That's kind of expected, because I don't mention it (since I cannot find it in guix), but how does the available guix package build (or get around pygtk missing)?
<civodul>tschilptschilp23: try "guix edit solfege" to see the package definition
<isf>how I can remove a program with his dependencies as with 'sudo apt purge && sudo apt autoremove' in Guix?
<civodul>isf: Guix works differently because it allows you, by default, to roll back to a previous state ("generation")
<civodul>so the approach instead is to periodically run, say, "guix gc -F20G -d2m"
<civodul>which means: delete generations older than 2 months, and delete everything that's no longer needed until at least 20GB are free
<isf>so for do it I need back to a previus generation?
<civodul>no no, you just run that "guix gc" command when you need more space
<yarl>isf: You don't have to worry about dependencies in guix. If you use it using "guix install some-package" and you want that package no longer to be accessible, just use "guix remove some-package". If you want space to be reclaim, use what civodul told you. Did you read some documentation about guix?
<tschilptschilp23>civodul: thanks, I just notice that the guix source points to savannah, and this repo does not contain any readmes or install information (at first glance)... i guess I'll stay with our solfege-version (was thinking about fixing the missing/messy program-docs, but what I see with 'guix edit solfege' is quite above my head...).
<yarl>isf: Now if you use "guix home" or "guix system" that might be a different story.
<isf><yarl> isf: You don't have to worry about dependencies in guix. If you use it using "guix install some-package" and you want that package no longer to be accessible, just use "guix remove some-package". If you want space to be reclaim, use what civodul told you. Did you read some documentation about guix? > just a little because im spanish native speaker and the documentation isn't completely translated
<isf>you say about that packages 'guix home' and 'guix system'?
<yarl>isf: I can only tell you again that packages work very differently than with apt. You should read the documentation. You can't just translate commands from another distro to guix.
<isf>im not trying to translate commands, I just have questions about how work something in Guix
<isf>im exactly doing the opposition because I want know how that work in Guix
<civodul>cbaines: hey ho! i'm going to reconfigure bayfront to get the latest hpcguix-web running
<civodul>isf: también puedes hablar en castellano aquí; creo que hay algunas personas que lo entienden
<yewscion>Hello all, could anyone help me with a system configuration setting? I'm unfamiliar with the underlying systems, and so I'm having difficulty translating it into my Guix system config file. Basically, I need to run `echo 15000000 > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw` and another similar command every time I boot to avoid an unexpected shutdown, per this comment on a forum for my machine
<yewscion>Even if it is just something like the old SysV rc.local, where I can have that command executed at the end of boot with elevated permissions, that will suffice for now. Hopefully this is just a stopgap pending a firmware fix.
<yewscion>In case it helps someone else: I've decided to make a small shepherd auto-start service to run the command when shepherd starts during system initialization. This way I can easily re-run it if needed, as well as extend it in case of future needs.