<akonai>does anyone have a working picom home service? I'm trying to make one but I can't get picom not to constantly die <paladhammika>In nix, does `doCheck` in the package definition refer to tests? <gordon1>so i defined my own version of glib package and trying to replace it everywhere, i use (modify-inputs (replace "glib" my-glib)) combination, the issue i discovered is following: for example poppler uses `(,glib "bin") in their inputs which, i assume, requests "bin" output of glib package, but modify-inputs does not repsect that and just replaces it with "default" glib, and because of that poppler's <gordon1>is there a way to make modify-inputs to respect requested outputs? <civodul>gordon1: i'd expect modify-inputs to respect outputs, no? <gordon1>replace-inputs called from replace in define-syntax modify-inputs <gordon1>tbf i can see where both approaches can be useful - i.e. replace input with and without wiping output information <gordon1>ideally something like replace replace (excuse my pun) with replace-respect-outputs and replace-disregard-outputs <paladhammika>making one more onlykey package that pulls the needed udev rules in order to enable use without root. the repo doesn't have a license but i just need a text file. is this prohibited? <podiki[m]>which has a license (not sure what license that is) ***jonsger1 is now known as jonsger
<podiki[m]>yeah, some sort of personalized thing before a more standard piece <podiki[m]>not sure how you indicate that in a package def, but someone will know <lfam>We have some generic catch-all licenses such as fsf-free and non-copyleft, etc <sughosha>Wow OK. Now got it. It should be set in `#:configure-flags`. Thank you! <sughosha>Also, is there a convient way for a merge request? In GitHub or GitLab I used to simply press a button, but here I don't see anything like that anywhere. It seems I should send an email. <lfam>You're right, we accept contributions by email <lfam>There's no GUI / web site <lfam>I mean, you can't contribute via that web site. We actually made it possible to contribute through the web site, but the functionality bit rotted and hasn't been fixed yet <lfam>It's still a handy way to search for things and follow the action <sughosha>Thank you Ifam for the information đď¸ <sughosha>I really like to contribute as much as I can. <mroh>sughosha: I just tried to build non-sequencer. I think it fails (in configure phase, not build/compile), because it doesn't find sig++2.0 <lfam>There's a package defined as 'libsigc++', which provides version 3.0.6. <lfam>There is another package defined as libsigc++-2, which provides version 2.9.3 <sughosha>mroh yes. It was failing for me before starting using Guix in Arch. `CXXFLAGS=$CXXFLAGS -std=gnu++11` worked for me. Now I want to try the same in Guix. <lfam>So I think that non-sequencer needs to change it's dependency from libsigc++ to libsigc++- <lfam>So I think that non-sequencer needs to change it's dependency from libsigc++ to libsigc++-2 <sughosha>Ifam I confirm that changing to `libsigc++-2` worked! :) <mroh>We are happy to receive your patch. Thanks for working on that package, sughosha! <sughosha>Yes, I am figuring out to modify the source to work with the latest libsigc++ instead of changing dependency here. I will check that and then send a patch via email (but which email and how, I don't know). <sughosha>I got it. It's guix-patches@gnu.org. Ifam, is there any rule or format to send a patch via email, or just attatch the patchfile with a description and send? <lfam>Attach the patch instead of copying and pasting it into the email, sughosha. <lfam>Beyond that, you can try the checklist in the manual, but don't let it discourage you from just sending the patch <sughosha>Wow, good to know that there is also maual for this. I will read that. Thank you for your help, Ifam! <sughosha>Now, more pro-audio goodies are on the way đď¸ <sughosha>I also would be happy to know how to stay up to date with latest releases of packages. Currently I check their GitHub or GitLab page once in a while and if there is a new release I update. I would like to know how people maintainings so many packages manage to stay up to date with their package releases. <lfam>You can use it on a Git checkout of Guix, and it tries to update the package definitions so you can test the changes ***califax- is now known as califax
<podiki[m]>paladhammika: I'm not sure exactly, maybe some other udev packages do something helpful? or just do a git fetch and just copy/install the one file? (sort of what you are doing already maybe) <mroh>android-udev-rules might be a good example. <apteryx>is it known that 'guix shell -- some-command' fails to load the environment from manifest.scm? <apteryx>it gets lost when I use the ' -- something' form <apteryx>guix shell: warning: no packages specified; creating an empty environment <Ribby>Is the ethernet internet connection for guix supposed to be unsteady? <apteryx>do you have weird messages in 'sudo dmesg -w' ? <apteryx>related to your ethernet controller? <Ribby>some characters in green, some in brown, a few in red? <Ribby>you mean messages around the end of the output? <Ribby>[ 85.971542] 3-3:1.0: Missing Free firmware (non-Free firmware loading is disabled) <Ribby>[ 85.971606] r8188eu 3-3:1.0: Firmware /*(DEBLOBBED)*/ not available <Ribby>[ 89.534139] e1000e 0000:00:19.0 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None <Ribby>I assume that 1000 means my ethernet. <Ribby>Flow control, I assume that it means to throttle down the data flow. <Ribby>And I cannot see if wifi usb is being read. USB disconnect, device number 2 indicate disassoc <Ribby>Mines is a TP Link something hold on. <apteryx>have you added the aircrack-ng linux module? <apteryx>perhaps it supports it, but we should validate this first <apteryx>what do you mean by 'unsteady' for your ethernet? <Ribby>Well, if I load a startpage sometimes, the connection flickers. The startpage would require me to reload to finish up on loading. <Ribby>It's on a Dell pc, I am sure that Dell isn't the most friendly for Linux-type brands. <Ribby> I have no tee: /etc/modprobe.d/realtek.conf: No such file or directory blacklist r8188eu <Ribby>I will just assume that not all hardware will be compatible with the os. <Ribby>Is there any wifi hardware out, that can work with guix, in steady connection? <Ribby>One that works just like plug n' play protocol? <apteryx>Ribby: the aircrack-ng module is not built into the kernel, you have to add it to your operating-system config <apteryx>like this: (kernel-loadable-modules (list rtl8812au-aircrack-ng-linux-module)) <apteryx>this should give you a usable wifi upon rebooting <apteryx>(well, reconfiguring then rebooting) <apteryx>ah, sorry, I'm confusing your model; it's 8188 <apteryx>8188eu which *is* built as a module in the kernel: zgrep 8188 /proc/config.gz -> CONFIG_R8188EU=m <apteryx>Ribby: does 'lsmod' lists the 8188eu module for you? <apteryx>it should be loaded if the hardware is detected <Ribby>Details say that My loopback is unknown, unmanaged. <Ribby>Oh, then maybe I do have it|! <Ribby>OH, the loopback is for my ethernet. <Ribby>WEll, maybe I'll just research for a working wifi device on guix. <gnoo>Ribby: wifi is hard to get working... in the meantime, have you considered using a 10m long ethernet cable? ;-) <pinoaffe>I have the opposite issue: my wifi worked from day one, but I don't think I've ever gotten ethernet to work over the course of several years of using guix on my thinkpad t470 <jpoiret>apteryx: I just replied to your email about `guix shell` <jpoiret>guix shell doesn't auto load manifest.scm on non-interactive use <gnoo>why does guix download packages every time it gets the chace? <gnoo>guix install package should not be updating other packages <gnoo>guix pull shouldn't be updating old packages <jpoiret>guix pull has to download packages as part of its bootstrapping process <jpoiret>guix pull basically asks the new guix to build itself, using the new guix's package definitions <jpoiret>so if the dependencies have changed, it will need to download them <AwesomeAdam54321>I learned something new today, I thought it used the current guix to build the new guix <jpoiret>as to guix install, well it's likely they're pulled as part of the dependency graph <jpoiret>AwesomeAdam54321: the relevant code is in build-aux/build-self.scm <gnoo>i did guix install gdb and it was downloading wayland and mesa and gtk and what not <gnoo>cannot build derivation `/gnu/store/pi2v455jjnvg0sl6y68a2rk2860kf987-profile.drv': 1 dependencies couldn't be built <jpoiret>does `guix packpage --list-generations` show any updates? <jpoiret>somewhere around that error, you should see something like "View the full build log at: /path/to/build.log.gz" <gnoo>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (packages)) (value #f)) <jpoiret>it may be an error with your channels <roptat>the profile hooks will use the latest version, some of them require gtk <gnoo>ok i think i found the problem <jpoiret>profile hooks are mostly run unconditionally <roptat>the condition is that the profile contains files the hooks act upon <jpoiret>at least nothing was updated in the profile then :) <gnoo>yup, but it did download, that's for sure <roptat>stuff in the store are not necessarily "installed" <roptat>they could be referenced by something else <roptat>like the hooks, a new package, or guix itself <jpoiret>right, hooks are only run if the base package the hook corresponds to is in the profile manifest <gnoo>ok, i'll need more time to understand there :) <jpoiret>ie, the gtk icons hook is run only when gtk+ is in the profile <gnoo>hmm, is there a condition when xdg-database hook is ran? <jpoiret>aaaaand one more set of kernel updates <gnoo>i was wondering, could there be a ~/.config/guix/profiles/{before,after} that is loaded by profile(s)?.scm at the top and/or end ? <gnoo>that way you could configure the profile easily <jpoiret>gnoo: wdym by configure the profile easily? <gnoo>jpoiret: e.g. configure the profile hooks, either remove some or add some <jpoiret>I hope this one fixes the i915 drm issue people have been having <jpoiret>gnoo: profile hooks _need_ to be run if the corresponding package is in the profile <jpoiret>looking at the changelog, I think so too <gnoo>jpoiret: somethings might not like that but i want to be able to break my own system ;) <gnoo>especially xdg-database, i want to remove that from %default-profile-hooks ***genr8eofl is now known as Guest8512
***genr8eofl_ is now known as genr8eofl
<vldn>Whats the disarchive repo? <vldn>And @guix'r'us Community, someone succeeded in running guix on mobile Like nixos-mobile? <jpoiret>damn, I'd love to run something similar on my phone. Dunno if that would be easy to do with A/B partitions <vldn>I try to build Something similiar <vldn>The U-Boot and partitions will be tricky <vldn>But it is possible to use existing Boot images from cfws <jpoiret>you'd need libhybris then no? to run most of the proprietary userspace <vldn>I think its Just needed for adb <vldn>Does postmarketOS use libhybris jpoiret? <efraim>civodul: bug 53895 looks to improve (guix cpu) <jpoiret>AwesomeAdam54321: you'd need to have a librem for that <jpoiret>a lot of hardware on phones rely on nonfree drivers that run in userspace to avoid license incompatibility with Linux <jpoiret>vldn: postmarketOS tries to use free drivers, but they may use libhybris for some hardware that doesn't have have them, I'm not sure though <civodul>efraim: i've just commented with some questions :-) <rekado>is there a way to fix up typos in channel news? <jpoiret>civodul: I've put that on hold since last week, but I've looked at the build-aux/build-self.scm and friends <jpoiret>the issue i see is that the channel-build-system requires a git checkout <jpoiret>we could use the .cache/guix/checkouts/ one but when running it through sudo it would have issues <civodul>jpoiret: ok; we could provide channel-build-system with a commit + URL instead of a checked out tree <jpoiret>we'd still need to check it out somewhere though right? <gnoo>../source/meson.build:54:0: ERROR: Invalid version of dependency, need 'wlroots' ['>=0.16.0'] found '0.15.0'. <efraim>civodul: sorting for riscv64 is actually going to be easy, literally only have to read the isa line from /proc/cpuinfo <gnoo>but i have wlroots-git in the package dependency so it shouldn't be the case <gnoo>while building sway-git package <jpoiret>why is wlroots-git in native-inputs? <jpoiret>it should be an input, it's a library <gnoo>i had that and it still errored out <jpoiret>yeah, that won't change the error, but still <jpoiret>when you build wlroots-git, does its .pc file have the right version? <civodul>per "ls /var/cache/guix/publish/{gzip,lzip,zstd}/rz3365gk8vawcammsnnpx9gwy6yskxsz-guix-packages-base.narinfo" <gnoo>jpoiret: no, it has 0.15.0 as the version <gnoo>jpoiret: thanks. i had that url from `guix show wlroots' <jpoiret>yes, since 0.15.0 is still available there <jpoiret>the move happened afterwards. i don't think changed the upstream git url would change the hash though, so it might not lead to any rebuilds <gnoo>ok thanks. i'll try building sway again <gnoo>almost all the dependencies need -git :/ <jpoiret>i would consider creating a package transformers that takes a package and returns a -git version <gnoo>jpoiret: ohh, thanks, didn't knew of that <jpoiret>and applying it with (package-input-rewriting ...) cutting at packages you don't need the -git of <jpoiret>civodul: rather than endlessly trying to find a better solution, i'll try a v1 with latest-channel-instance <jpoiret>when running as sudo, it won't use the user's cached checkout, but installers will 99% of the time be made without sudo <civodul>jpoiret: actually since channel-build-system supports any lowerable source, we could also do: <civodul>(package (source (git-checkout ...)) (build-system channel-build-system) ...) <civodul>well we don't need to solve that right away, just sharing random thoughts :-) <jpoiret>yes, that's what i was looking into first <jpoiret>the issue with that is that would require redownloading the whole guix repo <jpoiret>since we don't have caches for git-checkout, right? <civodul>git-checkout uses latest-channel-instance <jpoiret>i'll try doing that, and see if it downloads more code <jpoiret>i only have 3 checkouts in .cache/guix/checkouts/ though, that's weird <jpoiret>ah, i'm confusing git-checkout and git-fetch, my bad <jpoiret>wouldn't we also want git-fetch to use local checkouts? just a passing thought ***zap1 is now known as zap
<gordon1>is there a way for me to tap into the derivation process? put a hook or something <gordon1>so i'm trying to debug now that my input rewriting works well and packet in question is not getting installed <gordon1>unfortunately for now the only way of doing that is to reconfigure the system, wait for it to finish and then check if package got installed or not <gordon1>which, including occasional building steps, can take considerable amount of time for what could be done by just checking the dependecy graph before actual installation <vldn>Possible to ignore deps on guix import pypi recursive? <gnoo>../source/meson.build:179:2: ERROR: Problem encountered: Mesa's main branch no longer has any "classic" drivers, use the "amber" branch instead. <libh>Does the mypaint package come with the library libmypaint? <gnoo>libh: there's libmypaint <libh>Do you think that openblas can be a drop it alternative to blas/cblas? Because I don't think blas/cblas is in guix, but openblas is. <libh>I'm just going through opentoonz dependencies on parabola.nu and all except for cblas is in guix repos. <gnoo>libh: i had the package packed <gnoo>well at least the dependencies <gnoo>see the channel's logs right after you left <gnoo>i mean the package definition <gnoo>it's not exactly good but it started compiling <libh>One thing you should know, opentoonz uses a special static linked libtiff library under thirdparty directory, that is required to be compiled before opentoonz is compiled itself. The system libtiff WILL not work. <gnoo>if it's included, then you can probably remove libtiff as a dependency <libh>You got to compile the libtiff library before you compile opentoonz itself. That's why it's a bit tricky for me to make my own opentoonz package. <gnoo>you can replace the build phase and delete the configure phase <gnoo>have this in package definition: (arguments `(#:phases (modify-phases %standard-phases (delete 'configure) (add-before 'build 'fix-main-go (lambda* (#:key outputs #:allow-other-keys) <your own things here>))))) <gnoo>(replace the name, it's from my old package definition) <libh>I'll try to make an opentoonz package from what you showed me. Thank you very much gnoo. <libh>If I'm doing both traditional make AND cmake, do I specify both of them? <libh>Did you use openblas or cblas or what for opentoonz? <gnoo>it's not in the dependencies list, i think <libh>It says in dependencies it needs cblas and blas, but neither are in the guix repos. So that means one dependency is missing. <libh>Or maybe just cblas, but blas is a dependency for cblas, so might as well have both. <gnoo>it's not in: $sudo apt-get install build-essential git cmake pkg-config libboost-all-dev qt5-default qtbase5-dev libqt5svg5-dev qtscript5-dev qttools5-dev qttools5-dev-tools libqt5opengl5-dev qtmultimedia5-dev libqt5multimedia5-plugins libqt5serialport5-dev libsuperlu-dev liblz4-dev libusb-1.0-0-dev liblzo2-dev libpng-dev libjpeg-dev libglew-dev freeglut3-dev libfreetype6-dev libjson-c-dev qtwayland5 <gnoo>libmypaint-dev libopencv-dev libturbojpeg-dev <gnoo>which is what i based the dependencies off of <libh>It says under notes: "It's possible we may also need libgsl2 (or maybe libopenblas-dev)". So maybe it will work with openblas instead of cblas? <libh>Openblas is listed under the opensuse packages as well. I'll just use openblas instead of cblas. <gnoo>you can probably try the vannila way first, maybe they have taken care of in-tree libtiff with cmake <libh>They haven't yet fixed the issue with the libtiff library. It's on the TODO list, but not a high priority right now. <libh>Years ago as a hack job, the 2012 release of libtiff was modified to allow 16 bit tiff files without compression. Or something like that, nobody has volunteered to find a permanent solution. <gnoo>libh: they have this on the cmakelist: set(TIFF_INCLUDE_DIR ${SDKROOT}/tiff-4.0.3/libtiff) <gnoo>so i'll still try going the vanilla route first, without including libtiff as a dependency <gnoo>it looks like a heavy build or else i'd be building it too :) <libh>I'm not saying it won't work with system libtiff, but it won't work exactly the same way as the upstream opentoonz. <libh>Which may result in false bug reports. <gnoo>nono, i'm saying it will use it's own tiff <gnoo>just don't include tiff as a dependency <gnoo>i mean, don't have libtiff in (inputs ...) <gnoo>and if that fails then only you try going the manual route <libh>You know more about scheme than I do, could you help me finish this? I don't know squat about scheme and how to cd to thirdparty/libtiff-<version>/ and run make then cd to run cmake. <gnoo>the only scheme i know is from sicp chapter 1.1 <gnoo>so i don't really know scheme at all :) *gnoo should finish at least the whole of chapter one soon... <libh>All that needs to be done is 1. add openblas as dependency. 2. run make on the internal libtiff library. 2. use cmake to build opentoonz. <libh>As outlined in the "how to build on GNU/Linux" documentation page. <gnoo>ok, i'll try but please don't get your hopes up ;) <gnoo>ok, so it's chdir for cd <libh>Yup. I found out that with extensive web searching. <gnoo>lol, yeah, but i think -- maybe if we package tiff from opentoonz and then add that as a dependency -- that should work, right? <libh>You think it would be a good idea to package a tiff from 2012 into guix? <gnoo>why do the ./configure, make, ..., etc yourself when the build system will do that for you? <gnoo>just name it opentoonz-tiff <libh>Ok. I guess we could give it a try. <libh>I would suggest adding a note that this is from 2012 and only intended to be used with opentoonz. <libh>I think opentoonz static links tiff, but probably will work the same dynamic linked. <libh>gnoo, won't we have to modify cmake to let cmake know to use the opnetoonz-tiff package rather than the internal one? <gnoo>libh: if it uses the internal one, then we won't have to do anything at all <gnoo>that's why i was saying to just test if it compiles correctly or not <libh>It's path is setup to the internal one right now. Unless we decide to modify the environmental variable using -D option. <libh>I think we can compile the opentoonz-tiff as a package, and then set a cmake argument to not use ${SDKROOT} libtiff, instead use the guix package opentoonz-tiff instead. <libh>You think that will work out the best gnoo? <gnoo>probably, but, have you tried to just compile it without anything extra? because build tools should deal with it, ideally <libh>I got a very weak machine, so I rather not compile it myself because that could take an hour or two. <gnoo>well you will need to compile and test it before adding it to guix so... <libh>I'll just put this project on the backburner for now. Thanks for the help gnoo. <gnoo>you will also need to compile guix freshly and see if that breaks any tests <civodul>jpoiret: git-checkout performs the checkout on the client side, such that you don't need to know the hash in advance <jpoiret>i was more wondering about performance <jpoiret>so that people don't have to download whole repos again <civodul>jpoiret: note that people = maintainers building the installation image :-) <civodul>usually it's going to be in cache already, so little will have to be downloaded <jpoiret>i'll try adding something to specify the channels one might want to use <jpoiret>so that other channels are able to distribute installers with their own packages included easily <civodul>though again we can start small and make it specific to the way we build the official installation images <jpoiret>would it be okay for the (guix-with-channels channels) to just return a <derivation>? <gnoo>i was thinking, can't we have USE-like flags for guix? <gnoo>we already have that with services <gnoo>the substitute server only builds the default one <jpoiret>gnoo: it's entirely possible, but then no substitutes (or we'd need a wayyyy bigger build farm) <gnoo>only the default for each would be built by substitutes, except for say core packages <pinoaffe>hi guix! should a package such as pdf.tocgen (a commandline utility written in python) go in python-xyz.scm, pdf.scm, or somewhere else? <gnoo>pinoaffe: pdf.scm, probably <pinoaffe>and should the package be named pdf-tocgen, python-pdf-tocgen, or something else? <civodul>jpoiret: dunno, could be, unless there are places that expect a package? <jpoiret>i was wondering that. it's better to expect only a file-like i'd say, since in the end with profiles it's not just one package <jpoiret>i'll look at the uses of current-guix <jpoiret>or rather, we don't really want to modify current-guix anyways, just add something different <rekado>I get a crash with âguix build qtwebengineâ <rekado>could this be related to the move of /var/cache? <rekado>but Guix shouldnât fail when a 404 is encountered <rekado>itâs also likely that this is not actually a public link <rekado>in any case: the problem is that ci.guix.gnu.org advertises the substitutes, but when it comes to downloading it it returns 404 <civodul>ah, that's what cbaines reported this morning <civodul>i don't think "guix publish" would do that by itself <civodul>could it have to do with the roadworks on berlin? <rekado>I think it might be related to moving /var/cache <civodul>the only way it could happen i think is by deleting nars explicitly from /var/cache/guix/publish <civodul>could it be that rsync or whatever is used did that behind our back? <rekado>no, but could it be that there is an inconsistency somewhere? <rekado>like some db that got updated while /var/cache was copied? <rekado>we still have the old /var/cache, so making it consistent should not be a problem <rekado>(but Iâm not involved right now) <civodul>ah wait, so /var/cache has been swapped? <rekado>but⌠I still see that the old /var/cache is bind mounted <civodul>so it could be that /var/cache/guix/publish/{lzip,gzip,zstd}/xyz.narinfo are no longer hard-linked together <rekado> /dev/sdb1 on /var/cache type ext4 <rekado>and /dev/sdg3 on /var/cache type btrfs <civodul>that would explain the inconsistency cbaines reported earlier <civodul>like if things were copied in a way that doesn't preserve hard links <civodul>"ci.guix.gnu.org to stop offering Gzip substitutes" uh <civodul>"Dropping Gzip substitutes will free about 6.5 TiB of storage space from the build farm." <civodul>i don't think that's the case, unless we resign all the narinfos <civodul>rekado, apteryx: i sent a message to guix-sysadmin about these corruptions <civodul>i don't know what this entails but perhaps we should quickly revert to the old publish cache until a solution is implemented <singpolyma>If I use `guix system vm blah.scm` and then run the script to boot the vm, and then inside the VM I run `guix build -f blah2.scm` will the build results end up in the host store? <apteryx>rekado: hi! the old /var/cache is shadowed by the new one <apteryx>I didn't copy hard links to the new /var/cache (I simply used rsync -aP --delete) for performance reason, so that must be the problem <asdf-uiop>Icecat seems to be broken. /gnu/store/i6qvdb6haksamps0bify29jgc5qr4yx8-icecat-91.6.0-guix0-preview1 ==> 404 <apteryx>I didn't expect hard links to be relevant on /var/cache; a mistake in retrospect :-) <apteryx>civodul: resigning all the narinfos: that's the plan <civodul>apteryx: yeah and i had completely forgotten about this "detail", apologies! <jpoiret>can you insert monadic derivations into a gexp? <asdf-uiop>guix weather icecat shows available substitutes, though <apteryx>well, we have 3 weeks to devise a performant script (using guile-fibers?) to do so, and after we pull the plug on gzip on the 1st of March we can run it <apteryx>if it succeeds we can then clear the gzip-compressed nars <civodul>i'm not convinced this is top priority :-) <jpoiret>or do i need to do (call-with-store my-monadic-value)? <civodul>should we reswap the two /var/caches in the meantime, to address the 404s people have been reporting? <civodul>excellent, thanks a lot for doing all this <apteryx>(and then restart a rsync to the new storage with rsync -aPHAX) <civodul>i suppose we'll potentially lose nars baked earlier today, but that's not the end of the world <asdf-uiop>Looks like I came here just in time to see my problem will be resolved :) <apteryx>about the priority of this; I see the priority as high as 16 TiB of compressed NARs means we misjudged the situation about capacity requirements for the new array, meaning we won't be able to benefit from it before it is addressed. <civodul>you mean it's more than what "du" reported earlier? <cbaines>apteryx, I think I've missed some of the conversations about these new SSDs. Is the intent to use a bunch of SSDs to store the compressed nars long term? <civodul>the way i see it, storage requirements are going to grow linearly, endlessly (assuming we want to keep nars for a relatively long time) <civodul>seen that way, the linear factor is more important than the initial constant <civodul>but yeah, if we're already short on storage, we have a problem <apteryx>cbaines: the problem they intend to solve is managing a large /gnu/store and the unbearably long 'guix gc' times <apteryx>it's 22 TB of capacity with zstd compression, which should give us about the same capacity as the old array for *non-compressed* artifacts (such as /gnu/store) while allowing us to keep it well pruned with 'guix gc' in a reasonable time <apteryx>the /dev/sdb is forever saturated with IO and brings the performance of many things such as SQL lookups to its knees, hurting CI efficiency. <apteryx>'guix gc' running for more than half a day at a time means the build farm can't collect any built packages from the workers during that time <cbaines>apteryx, I think I'm missing bits of the picture here, since that would suggest you'd want to copy /gnu/store stuff on to the SSDs, rather than /var/cache bits <apteryx>the plan was to move everything to the SSD for now; I didn't expect /var/cache to be so... large. <apteryx>and running 'du' on the old HDD takes age, unlike on the new storage, so I didn't measure things much. <apteryx>it seems using /var/cache also freed up 30% of /dev/sdb IOs <apteryx>already providing some relief for the CI <apteryx>I expect the 14 TiB remaining to be perhaps half junk that we never manage to fully gc; so if /var/cache could be kept to a more reasonable amount (< 10 TB for a start), the new array should be able to hold it all <apteryx>(and /gnu/store compresses very well with zstd) <cbaines>actually, I think I'm just going to try and stay out of this discussion <cbaines>I think it goes without saying that some of my views on the subject of providing substitutes differ <civodul>cbaines: we're a collective, we're all on the same boat <apteryx>civodul: is the corruption problem induced by missing narinfo hard links severe? If it happens only rarely it'd be preferable to rsync from /gnu/cache to /var/cache (which is mounted on the new array) to get the hard links <civodul>apteryx: it think it's severe in that people have seen "guix substitute" crashes due to 404s <civodul>if it's not too hard to swap disks back, we could do that <civodul>that'd leave time to think about how to address the problem <civodul>(while being also a bit frustrating) <apteryx>oI was asking, because I haven't seen any reports to bug-guix, so I'd expect to be rather rare <apteryx>(I also ran guix pull and generated a new profile without issue yestarday after the migration) <asdf-uiop>Meanwhile, would it be hard to add a check for missing narinfos and return a more telling error message? I assume most people would be fine with either pinning to their current local version or recompile locally if they really want the new version? <apteryx>rekado: do you think if I issue 'unmount /var/cache', it'll unmount the last mount that shadows the previous one? <mbakke>would syncing again with the -H option to rsync work? <apteryx>I can run "time sudo rsync -aPHAX /gnu/cache/ /mnt/btrfs-pool/@cache/" now, and the problem should heal over the next hours <civodul>to be fair, i've only seen two reports here, by cbaines & rekado <civodul>i suspect it could crop up pretty quickly <apteryx>let's try this first; if an army of angry users turn here mentionning 404s I can instead go the more painful route of reswaping the mounts <apteryx>it's running now; pid 86250; you can strace it if you want to follow progress I guess <civodul>also note that "guix publish" relies on file atime for its cache eviction policy <civodul>that means the file system must not be mounted with "noatime" or anything like that <civodul>(which isn't great; we should change it) <asdf-uiop>I had an error 404, too, but I just temporarily removed icecat from my profile and I am neither angry, nor have I brought my army ;) <singpolyma>So, it seems that when running a `guix vm` you cannot run `guix install` or anything like that inside. So I guess one has to use global packages in the os definition? Or can I specify profiles in the system definition? <jpoiret>does anyone think it would be wise to add a <store-monad-derivation> record, for which we could define the gexp compiler as the identity? <jpoiret>so that you'd be able to insert monadic derivations into gexps <jxxxxxxxy[m]>i'm thinking as it was marked as done it may not be seen, and i should create a new ticket? <jxxxxxxxy[m]>```If a report is closed and receives no more mail for one month, it is archived. Before you can send more mail to it, you must send the command "unarchive 123" in the body of a message to the control server address.``` <jpoiret>jxxxxxxxy[m]: did you try with the "latest" installation image? <jxxxxxxxy[m]>jpoiret: I did yeah, I also tried one from back in June, as the original ticket mentions a new build from around then <jpoiret>can you open a tty (ctrl+alt+f3), log in and do `$(guix build -e "((@ (gnu installer) installer-program))")` <jpoiret>if the installer crashes that way, maybe we'll see an error message <jpoiret>there's no error message at all otherwise <jpoiret>florhizome[m]: are you sure you aren't doing funky things in your bashrc? <florhizome[m]>I just looked at it and decided to delete the ruby and conda path init since I donât need them actively and could use guix instead <jpoiret>what does `readlink -f $(which guix)` output? is it the expected guix? <jpoiret>simply `which guix` would help as well <jxxxxxxxy[m]>jpoiret: Ok thanks, should I update that original ticket with the response or create a new one? <florhizome[m]><jpoiret> "what does `readlink -f $(which..." <- inside the shell returns store path to guix-1.3.0-23.a27e <jpoiret>you can respond to the ticket and reopen it, or simply create a new one. I don't know know what the policy is wrt that <jpoiret>i don't think either of those will lead to anyone getting upset though :) <jpoiret>florhizome[m]: what does `which guix` output? <jpoiret>florhizome[m]: do you have `guix` as part of the shell invocation? <jpoiret>what exactly is your `guix shell` command? <jpoiret>you don't need to include guix in the manifest <jpoiret>the guix package is always out of date compared to master <jpoiret>the guix package is upgraded only in specific cases, because it's where the daemon comes from, as well as what the installer installs <jpoiret>florhizome[m]: why would you do that though? <podiki[m]>I think it is guix shell -D guix (and --pure etc) <jpoiret>well, guix shell guix, as podiki[m] said if you want to hack on guix it should be `guix shell -D guix` <podiki[m]>so you don't get guix itself but the dependencies to hack on guix <jpoiret>I understand, but why do you do `guix shell guix`? I don't see what that would achieve <jpoiret>by the way, your -- above got converted to an en/em dash <florhizome[m]>because as I remember guix shell âpure doesnât provide me with a guix command <jpoiret>i suggest running GUIX_PROFILE=~/.config/guix/current/ . $GUIX_PROFILE/etc/profile inside the shell then <florhizome[m]>podiki, jpoiret i guess it depends what exactly you do have in .bash_profile and maybe if you ran the env var switch jpoiret mentioned before in the session ? <florhizome[m]>Although, coming back to the original issue, that didnât help <jpoiret>it activates the .config/guix/current/ guix profile in the current shell <florhizome[m]>I pulled, did env var thing, ran hash guix, guix upgrade but the guix in the shell stayed the same <jpoiret>did you remove the "guix" package from the guix.scm? <apteryx>civodul: ok; rsync it's busy syncing /var/cache/guix/publish/gzip <podiki[m]>I think it is as was said before, that "guix" will refer to an older package version (it is not updated as a normal package) <podiki[m]>e.g. if you look at "guix edit guix" it is 1.3.0 <jpoiret>podiki[m]: it's not straight up 1.3.0, it's somewhat recent, but not master-recent <podiki[m]>yes, "guix" the package is a set thing from what I understand, versus the guix that is in a profile <podiki[m]>but did I get that right, in terms of guix the package vs guix in a profile? <jpoiret>basically, the guix package is upgraded only when changes are made to the daemon or whenever the installer relies on something that needs to be updated (maybe there are more cases) <podiki[m]>you need the one current with your guix pull to know whatever was in guix pull <florhizome[m]>jpoiret: actual guix instead of the guix library with all the package descriptions? <jpoiret>`guix pull` fetches the latest git sources, does some incantations to set up things and lets the `build-aux/build-self.scm` script in the new sources build the new guix <jpoiret>so guix doesn't use the guix package at all when guix pull'ing <jpoiret>no, in both cases it is still the whole guix <podiki[m]>more of guix package needed as part of e.g. a release or installer image? otherwise you run whatever is current from your guix pull <podiki[m]>hahah whoops! and was just about to say I learned something :) <jpoiret>florhizome[m]: basically, you never use the result of building the guix package when running `guix` <florhizome[m]>did you mean that a guix pull does not update the guix package in the store <jpoiret>unless 1) you've just installed guix and did not guix pull 2) you're the daemon <jpoiret>florhizome[m]: the store doesn't have a notion of packages <jpoiret>also, you don't "update" things in the store <jpoiret>the store is simply that, a big registry with a bunch of things <podiki[m]>I think was the point that being in the store or not is not related to it being a "package" <podiki[m]>maybe you can think of it as a bootstrap of sorts, you get a guix (the version you see in the guix package def) to start when you install from an image, but then running guix pull updates what you actually use locally, even though that "package version" hasn't changed, it is not what you use <florhizome[m]>you know what I really find ennerving is conversations that constantly diverge from the discussed problem because of assumed mistakes that might as well be miscommunications <podiki[m]>so to come back to your problem, it was that including "guix" in your manifest means it was using the "package version" of guix which didn't know about newer packages? <podiki[m]>and that when you did guix shell --pure you didn't have a guix in the shell? (that seems like a problem) <florhizome[m]>Iâm having this pretty often in guix, and lately on guix-patches <florhizome[m]>I can relate to the fun of nerding off, and i can conceive it as a semi-academic habit in those spaces as a somewhat science student, but for âoutsidersâ itâs not so nice <podiki[m]>I have to run, but with "guix" not in your manifest things work? <podiki[m]>and sorry if you feel anything was not so nice, I certainly didn't mean to derail the conversation but it was teaching me something <podiki[m]>(everything I learn about how guix works helps me understand or fix my problems, eventually) <podiki[m]>(guix can be a lot for newcomers, I'm still a newcomer) <podiki[m]>worth investigating! I'm still fuzzy on a lot of guix shell stuff <florhizome[m]>guix expands fast enough that Iâm gonna stay a newcomer I guess ;) <jpoiret>if you want guix inside a --pure shell, i really recommend using the script sourcing above, since otherwise you'll run into outdated guix problems :) <jpoiret>but ideally, you should avoid running guix in a --pure shell <podiki[m]>good luck florhizome, do report any bugs or weird cases you find with guix shell, I'm sure that will be useful to others <jpoiret>what's your usual use-case for running guix inside the --pure shell? maybe there's some way around that <florhizome[m]>the most thing I have done is checking if stuff inside the channel builds or lints <jpoiret>then, i think you should rather stay out of the shell, and use `guix build -L path/to/your/channel/ build yourpackage` <jpoiret>same for lint. i'm not sure you'd need anything from a shell to make that run properly, but i may be wrong <pranavats>Hi. Is there any package for multilib in guix? <vagrantc>not sure multilib would make sense in guix <jpoiret>pranavats: by multilib, do you mean 32-bit versions of 64-bit packages? <vagrantc>e.g. isn't multilib just a way to pass library paths that have both 32-bit and 64-bit libraries available? in a guix package, you would have whatever libraries are appropirate to the package you build <whound>Can anyone look into Elixir compiler def. It fails to build. <pranavats>I'm looking for 32 bit versions of some libraries, yes. <podiki[m]>you can specify --system when building, or in a package definition itself <pranavats>I'm setting up a build environment, and the debian package names are gcc-multilib, and lib32ncurses5-dev. I don't know what packages would those correspond to, in guix. <podiki[m]>florhizome: right, I meant for building something on its own. for inputs you probably need a variant of that package with system specified; I think wine or dxvk show that <rekado>apteryx: sorry, was away for a while. <rekado>apteryx: re umount: I donât know if it will peel off the most recently added layer <rekado>I just got notice that our budget for extending the SAN finally got approval. <rekado>weâll get some 300TB extra space, but obviously only a fraction of that will be available for ci.guix.gnu.org <rekado>still, this should help once the SSDs have been sent to France <rekado>(I expect that itâll take up to three months for the order to be processed.) <Noisytoot>How much space does ci.guix.gnu.org currently use? <theruran>what's the Guix way of building a chroot so I can run some software that isn't in Guix packages? <rekado>I canât successfully run âguix pullâ on the aarch64 nodes <jonsger>but removing gzip will save some TiB I heard :) <sneek>jonsger, you have 1 message! <sneek>jonsger, efraim says: I have in my .bash_profile (with other stuff too) and it seems to work for me for quassel and keepassxc: if [ ${XDG_SESSION_TYPE} == "wayland" ]; then\n export QT_QPA_PLATFORM=wayland\n fi <rekado>I keep seeing this message: âsysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w)â <rekado>weird because the machine has 32G RAM <jonsger>efraim: ah thanks, will try the next time I switch back from GNOME to sway :) <lfam>rekado: Does that message indicate OOM? <apteryx>rekado: one thing I was curious about; is that after shadowing the previous /var/cache location with the new Btrfs subvolume, I wonder if processes can keep a handle to the old place and continue writing there <apteryx>rsync has pretty much caught up copying hard links to the lzip directory, but I can't still download the file <jxxxxxxxy[m]>jpoiret: running this command: `$(guix build -e "((@ (gnu installer) installer-program))")` created an error with the canonicalize-path no such file installer/aux-files/logo.txt <jxxxxxxxy[m]>`guix build: error: canonicalize-path: No such file or directory: "/gnu/store/y1sk62ddg6lyn6mxhrkd76nmzcxnb3dy-guix-1.3.0-1.771b866/share/guile/site/3.0/gnu/installer/aux-files/logo.txt"` <jpoiret>that's understandable (totally unrelated to your problem) <lfam>Are you trying to build the installer ISO? <jpoiret>lfam: the installer crashes without any exception handling so I was suggesting to launch it manually using the above command <lfam>I see. That's not something I know about :) <lfam>I do know that you can build the installer ISO itself quite simply, like this: <lfam>`guix system image --system=x86_64-linux gnu/system/install.scm` <lfam>Depending on space requirements, I would add the option "-t uncompressed-iso9660", because the compression takes a looooong time <jpoiret>oh yes of course :) here, it's building the graphical installer program itself, that's what I use to debug and add features to it <jpoiret>that lets you launch it in a shell, in case you want to see things like "segmentation fault" <jpoiret>otherwise the install environment is configured to have it restart instantly so you can't see such errors <lfam>That's good to know how to do <jpoiret>although it doesn't work with the guix that's installed in the system profile (maybe it only works with a checkout ...) <lfam>I wonder if that missing file is expected to not be installed when Guix is built-and-installed? <lfam>It's worth looking into that <jpoiret>it's only needed when building the installer, and will be done while generating the image <rekado>lfam: I donât know if itâs OOM. Could be that the message is unrelated. <rekado>I donât really see much of whatâs going on because the serial console isnât very convenient to use. <rekado>(and I only have one free USB port, so I canât leave all three of them connected all the time) <podiki[m]>rekado: I don't know what is causing your message, but that seems like just what you'd see if you press the magic sysrq key and then h (for help)....curious <lfam>jxxxxxxxy[m]: Are you using the 1.3.0 installer? Or a "latest" installer? <jpoiret>jxxxxxxxy[m]: can you do `find /gnu/store -regex ".*-installer\$"`? <jpoiret>that will find the path to the installer script <lfam>And it still crashes after the partitioning step? <jpoiret>yes. Either there's a bug in libparted, or we are doing some nasty things with it eg use after free or double free <lfam>The original reporter said they used the default partitioning, "Partitioning Scheme: Everything in one partition" <lfam>Is that what you are doing jxxxxxxxy[m] ? <lfam>It's weird, I tested that extensively recently, and it worked fine <lfam>But I guess there are so many different environments that the installer can encounter <jpoiret>jxxxxxxxy[m]: can you enable core dumps with `ulimit -S -c unlimited`, and check the core dump patter with `cat /proc/sys/kernel/core_pattern` to see where they end up? <jpoiret>or if you already know how to use core dumps with gdb, you could directly report the stack trace <jpoiret>alright, it's okay (it'll create a file called `core` in the current working directory) <jpoiret>now, (you should be in /root), can you run the /gnu/store/pv7.... file? <jpoiret>do the same thing as before, trigger the crash, normally after logging out and logging back in with `exit <RET>` (because the installer will ruin the virtual terminal) you'll see a file called `core` <jpoiret>now, you should be able to run `guix shell gdb -- gdb /gnu/store/pv7nzrhlp... core` <jpoiret>ideally, you don't wanna send this anywhere as this will most likely have your password in it <tanner40>Question (guix/irc newbie here): I installed Guix System and I'm looking at the [Getting Started](https://guix.gnu.org/manual/en/guix.html#Getting-Started) section of the manual. It says that if you're not using Guix System, then you should update your GUIX_PROFILE bash variable and source the new profile. But since I /am/ using Guix System, should <tanner40>I skip this step? What should be the typical output of `which guix` at this stage and why? Thanks <jpoiret>tanner40: you should, unless you are using your own .bash_profile <lfam>tanner40: `which guix` will probably be the "system Guix", found in '/run/current-system/...', until the first time you run `guix pull` <jpoiret>jxxxxxxxy[m]: ah, right, then `guix environment --ad-hoc gdb -- gdb /gnu/store/pv7nz... core` <lfam>If `guix shell` doesn't exist for you, it sounds like you are using 1.3.0 <lfam>And not the "latest" installer <lfam>We added `guix shell` after 1.3.0 <tanner40>lfam: aha! so it was `guix pull` that changed things. that was the source of my confusion. why/how does `guix pull` change what `guix` points to? <jpoiret>tanner40: basically, `guix pull` downloads the latest guix sources possible, builds it, and makes it available to you under ~/.config/guix/current/ <jpoiret>~/.config/guix/current/ is even a (guix pull) profile, so you can roll-back in case the new guix doesn't work for you, etc... <jpoiret>there's a section in the manual "Invoking guix pull" <jxxxxxxxy[m]>I'm now getting a GDP prompt with an error on 0x7ffeb525fa20s not in executable file format not recognised <jpoiret>hmmmm, I'm not that used to core dump debugging myself, especially with guile programs <jpoiret>can you try `find /gnu/store -regex ".*-installer-real\$"` instead, and use that as the argument to gdb? <jpoiret>can you look up what the first line of the script said? (with eg. head) <jpoiret>it should be something like #!/gnu/store/XXXXXX/bin/guile <jpoiret>then, try `guix environment --ad-hoc gdb -- gdb /gnu/store/XXXXXXX/bin/guile core` <jxxxxxxxy[m]>Ok, I'll have to try in the morning I'll get back to you tomorrow <gordon1>so there are those hooks mentioned for the guix-build-coordinator in user manual, any hint on where i can read about it and how to define them? <jts>Hi! Does anyone happen to know how to get Julia package management working on GuixSD? Whenever I try to install eg Plots.jl through the repl, I get errors. I found a mention in a mailing list discussion from a couple months ago suggesting that there is a way to make it work, but I found nothing else suggesting what that way may be. <jts>(specifically, I get a "no file or directory" error on what appears to be a shell call to 7z) <civodul>apteryx: try "ls /var/cache/guix/publish/{lzip,gzip,zstd}/i6qvdb6haksamps0bify29jgc5qr4yx8-icecat-91.6.0-guix0-preview1.nar" <civodul>so hopefully we're almost back to normal! <civodul>jts: zimoun or efraim would know better, but i thought it was supposed to work? <civodul>many Julia packages are available via Guix, but it's still a fraction of what's available out there <apteryx>civodul: neat, thanks for the report <apteryx>looks like there's two options to enable in linux-libre to make 'atop' more useful, per 'man atop' <apteryx>with these it would be able to track per process IO usage <apteryx>right now it just gives a global % of the time waiting on IO per device <apteryx>I guess the difference is that iotop requires root privileges <civodul>i'm used to being a privileged user :-) <apteryx>also it doesn't seem to look at the same thing; iotop gives me the bandwith usages, while atop would give me a more fined grain IO per second count, I think <apteryx>civodul: and even with root, iotop also prints: CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO % <lfam>However, that option is enabled <civodul>it works on my laptop with 5.15.12-gnu; could it be a recent regression? <apteryx>zgrep /proc/config.gz would be nice but it's not yet on that machine :-) <lfam>The provenance should lead you to it <alanz>Hi all. I am trying to set up emacs-guix into a normal emacs on debian. But it is pulling in the one from elpa, not guix. Any pointers on how to initialise it? <apteryx>rsync has completed on berlin, the new substitutes cache should be as good as the old one <civodul>it's great you were able to solve it quickly <civodul>alanz: hi! in general, to use Guix-installed Emacs packages, you'll probably want to use the Guix-installed Emacs as well <alanz>I'm not sure I want to take such a big step at once. I recall trying this before, and there being some way of doing it. <Kolev>How do I use the package "readymedia"? <apteryx>civodul: luckily I hadn't disposed of the old /gnu/cache copy <apteryx>civodul: mathieu was saying a good test would be to clear the nginx cache and see if everything continues working well <apteryx>do you or someone here knows how to do that? <podiki[m]>alanz: maybe you mean with EMACSLOADPATH? if you do guix package --search-paths it will show you that as well for emacs packages <podiki[m]>otherwise just manually adding the right path for the package to your load-path in emacs (put it first) may help <alanz>podiki[m], thanks, I will try that. It looks promising <podiki[m]>if you have emacs and emacs packages in the same profile with Guix, that is set and used automatically; but should be able to do that manually <alanz>podiki[m], It looks like I was using "~/.guix-profile/share/guile/3.0/" instead of "~/.guix-profile/share/guile/site/3.0" <alanz>yes, I can finally see my guix-profiles command output. Thanks. <alanz>FWIW now running inside "guix shell emacs emacs-guix". So it *is* the guix emacs. But my normal config setups <alanz>I just need to add emacs-guix into my normal load path and I am good. <alanz>I love the way guix works. It seems so much more friendly than nix. <Kolev>alanz: That's nice to hear. I've never used Nix. Perhaps I should, to see the difference. <atomizedalex>I was weighing between the two, and went with GUIX because of its free software commitment <alanz>I last used nix some time ago, and it was quite a tricky thing to work with. Being a long-time emacs and lisp user, I can relate to guix more. Especially the tight integration into emacs <sailorCat>Hi people. There is a java-related problem. I've got an error "java.lang.ClassNotFoundException: jdk.javadoc.doclet.Doclet" when use openjdk (all versions), but don't have it on IcedTea. According to my understanding javadoc.doclet is a part of jdk, so every jdk-implementation should contain it, but my knowledge about java is very restricted. Can someone explain it for me? <atomizedalex>Previously I was on Gentoo and kinda annoyed that in the IRC people were saying things like "I use Google for all <alanz>Wrt nix, it has probably improved a lot since I last used it, so my opinion may not be worth much. <alanz>What I *do* like is I can just "apt-get install guix" on debian, and get on with it <civodul>apteryx: i believe there's no nginx caching for nars on berlin <apteryx>talking about nix, has someone else noticed the nix-service-type appears to not work anymore? e.g.: nix edit nixpkgs.emacs -> error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override. <apteryx>It's a shame, as it was a very good reference to survey for packaging tips. <jts>That's just because Nix uses hyphenated names for subcommands by default. <jts>They use different names than those listed by nix --help though. I had this same gotcha <podiki[m]>I see imgui was just added (though we have "dear-imgui" which is the same, older version though); maybe someone can take a look at https://issues.guix.gnu.org/53015 since half the work was covered by the new imgui and spdlog changes already? <apteryx>podiki[m]: oh! apologies, this was revived after sleeping 3 years on my side; I must have failed to look any imgui that had appeared since :-) <podiki[m]>haha no problem, newer than the one I have since I kept the debian makefile the current dear-imgui uses <podiki[m]>(I also missed it the first time due to the name) <apteryx>jts: I don't get it; which command should I use instead of 'nix edit nixpkgs.something' ? It used to work. <podiki[m]>means the mangohud patches is just the question of pciutils variant (uncompressed hardware pci.ids; probably we can split that out in the future as other distros do) <jts>apteryx: no idea, sorry; I just have Nix for one piece of software not in Guix <jts>The Nix manual seems pretty decen, though <podiki[m]>I could recheck/redo the patch on the current version later, if that is helpful; but if there's anything else I should rewrite be glad to do it all together <Kolev>Maybe I should just set up SMB instead of DLNA.