IRC channel logs
2024-09-21.log
back to list of logs
<aswjrisp>I can start this ntpd service. I looked at the man for ntpd and decided to start it with -d. But it still starts three processes that do not stop when I use herd stop. <ieure>aswjrisp, You'be been tilting at this windmill for at least 2-3 days now. Maybe its time to reevaluate whether this approach is worth it? <ieure>I believe this is all because you don't want to have a service which provides networking... really seems not worth it to me. Have you considered using `rfkill' to forcibly disable the WiFi radio instead? <ieure>I think you wanted this setup so you could focus without distractions, right? But you've been distracted for multiple days with making the setup work. <aswjrisp>ieure: I would like the networking services on my system to have auto start disabled but that is not an option. So I am making shepherd services that have auto start disabled. <aswjrisp>I have been making progress creating these services because I have recieved assistance here for tricky aspects. <aswjrisp>I do not know why herd stop is not working for openntp. <aswjrisp>ieure: When the system boots rfkill tells me all the interfaces are blocked. So I made a service to unblock the interface I want but it has auto start disabled. So it unblocks when I ask it to. <aswjrisp>I am finding making services a useful learning excercise with the bonus that I am building services that I want. <nick>Hey, I am trying to package a lisp application. I was wondering the proper way to install a .dekstop file. I noticed that in most other applications this is done in a makefile using a datadir parameter. Not sure how this would be achieved with a pure lisp build, using asdf-build-system. <the_tubular>I though message in queue would wipe if sneek disconnected <nutcase>mange: "/root/.cache/guix" was, what I was looking for. I removed it, thank you (I know, that I'm a bit late :-) ) <amano>Why does guix rely on search paths instead of symlinks to dependencies in packages? <amano>If there are N library modules, loading N modules will take O(N^2). <amano>With direct symlinks, it's O(N). <nckx>Where would these symlinks go? <amano>Search paths to dependencies in guix packages <amano>Search paths are used to seek modules in guix applications. <amano>For example, PYTHONPATH and GUILE_LOAD_PATH. <amano>They are used in guile library packages. <amano>If A depends on B, and B depends on C, then B has symlinks to C, and A copies symlinks from B to itself and makes symlinks to plain files in B. <amano>Symlinks will go into packages. <nckx>So this replaces wrapping? <amano>Symlinks take more disk space, but it takes O(N) to load N modules from symlinks. <nckx>We really wouldn't care about the disc space usage of a few symlinks. <nckx>amano: Never mind then, if you obviously weren't talking about wrapping. <amano>With search paths, it takes O(N^2) to load N modules. <amano>I don't know whether search paths take O(N) after loading the first module due to RAM caching. <amano>I just see that guix doesn't seem to use symlinks to dependencies in packages. <vagrantc>well, for C libraries, it just links directly/explicitly and doesn't use search paths <vagrantc>for some reason python is a bit different, hence GUIX_PYTHONPATH and whatnot <amano>There are dynamic C libraries. <vagrantc>not static linking, they are still dynamicly linked, but explicitly so ... e.g. it does not use a library search path <amano>What about interpreted languages? <nckx>amano: What's a good example package to demonstrate this O^N complexity? Ideally a few levels deep. <nckx>> If there are N library modules, loading N modules will take O(N^2). <nckx>Which package, which modules? <amano>Let's assume that search paths include N library module paths for python. Loading one module takes O(N) because you have to search N module paths. Multiply O(N) by N modules, and you get O(N^2). <nckx>amano: This is a thought experiment. <amano>Yet, it is the only scenario I can think of for N library module paths for a scripting language. <vagrantc>any specific package in guix that demonstrates this behavior? <amano>I haven't looked for one, but it is a thought experiment. <vagrantc>it is also assuming that the library you actually load is always in the Nth search path <amano>Does guix use symlinks to dependencies in packages? <vagrantc>guix uses way more symlinks than any other system i have ever seen, so if symlinks were the solution, guix would surely not shy away from it <amano>A depends on B. B depends on C. B contains symlinks to C. A copies symlinks from B to itself and contains symlinks to plain files in B. <nckx>What we're asking is why, which problem (not hypothetical) are you solving. <amano>However, guix manual only mentions search paths and doesn't really tell me how to utilize symlinks in build systems. <nckx>It's a pretty simple idea, I'm not sure what there is to tell. <amano>Do some guix build systems actually use symlinks for scripting languages or any programming language? <amano>I mean symlinks to dependencies. <amano>I want to see one build system that utilizes symlinks instead of search paths. <nckx>I'd suggest you implement it, then measure it against whatever O(N^2) overhead you're talking about (this requires finding a good example package), to see if the savings are meaningful. <nckx>I'm not aware of any build system that does things that way. <amano>So, all build systems you know of use search paths? <amano>For C and rust, there would be no O(N^2) overhead during runtime. <amano>For scripting languages, there can be O(N^2) overhead in my thought experiment. <amano>Because there is no compil-time linking. <amano>Scripting languages have runtime module loaders. <vagrantc>run ldd on a C package in guix, you'll see it does not use search paths. <amano>vagrantc: I already said that above. <amano>Interpreted languages that have runtime module loaders, such as python have to search search paths for each module. I guess. <amano>Combine runtime module loaders with search paths, and loading N modules takes O(N^2) theoretically. <nckx>If you say so. It's your thought experiment :) <amano>For janet language, this would be the case for guix shell scripts. <amano>Janet language allows you to compile everything into one binary executable which doesn't need to search for modules. So, compiled binaries don't need search paths during runtime. They only need search paths during compile time. <vagrantc>you could generate a single thing that has all the symlinks and then set GUIX_PYTHONPATH/PYTHONPATH appropriately to that one thing ... but i am not sure the added overhead is all that costly of having multiple search paths ... <amano>vagrantc: Wouldn't it require FHS-compliant guix shell? <nckx>vagrantc: That is (more or less, handwavy motions) how I interpreted amano's idea. <nckx>(OK, now with the FHS stuff you've lost me again…) <vagrantc>amano: there's no need for FHS compliant anything in guix <vagrantc>amano: most python "binaries" in guix include a wrapper (what nckx mentioned earlier) that sets the relevent PYTHONPATH stuff ... maybe take a look at that. <amano>If A depends on B and B depends on C, my symlink idea is B contains symlinks to C, and A copies symlinks from B to itself and contains symlinks to plain files in B. <nckx>Trust me, we got that the first time. <amano>vagrantc: You mean a python application package constructs single directory that contains symlinks to all dependencies? <vagrantc>amano: no, just a big wrapper that specifies only the relevent search paths <amano>Combine python runtime module loader with N search paths. You get O(N^2) in theory. <nckx>Right, and there's no ‘recursive’ nesting of PYTHONPATHs for each dependency that would lead to the trivial case of O(N^2) complexity. <nckx>An example would really really really be helpful here. <amano>That example contains 18 search paths. <amano>Does that mean there are 18 (transitive) dependencies? <nckx>I think you should implement your symlink idea and benchmark it against python-pyqt5 as it is today. <vagrantc>but there are only 18 directories that it will ever even try to search in. <vagrantc>and each of those directories has very few modules <nckx>If there are measurable time savings, creating this symlink union is something that build systems could probably do more or less transparently. <nckx>Even if it doesn't save time it might be advantageous by (say) reducing the number of ad hoc wrapping phases in Guix. <vagrantc>amano: and i *think* while what you are saying holds partly true, in that there will be a large number of searches for each module ... it will be less than the explosion you describe as at least one of the modules will be loaded on the first try, one on the second try, etc. <vagrantc>it's only the 18th module that will take 18 tries <nckx>It might also fail completely for unforseen reasons. Hence the reluctance you might sense to review your imagined perfect solution (that doesn't have to do difficult things, like exist) to a currently hypothetical worst case. <amano>Direct symlinks to (transitive) dependencies will require more disk space, but I have disk space. Can I write a build system that uses direct symlinks instead of search paths? <nckx>Nobody cares about the few extra bytes, this is not a serious objection. <nckx>amano: Is it possible? Sure. Can you? That's a question only you can answer. <vagrantc>the big question comes down to ... is it actually worth doing? which ... someone has to prototype it to actually do it. <amano>So, in theory, someone can write a build system that makes symlinks to (transitive) dependencies in packages. <amano>gnu guix maintainers have no problem with a new build system that uses symlinks intead of search paths? <amano>For example, janet language. <vagrantc>in my experience, guix is pretty willing to explore ways of doing things if it does not fundamentally break guix and is fairly easy to transition <amano>A new build system for a new language won't break existing users... <vagrantc>although there may be prior art on a julia build system already worth peeking at <amano>guix currently doesn't have a build system for janet modules and janet executables. <nckx><gnu guix maintainers have no problem with a new build system> This doesn't even enter into it, the maintainers have no say over which code people write and test and submit to the mailing list. <nckx>If you prototype your build system, and present it, and it's good, why would maintainers object? <amano>julia build system uses search paths. <vagrantc>oh, and janet uses lots of parens. will fit right in. <amano>search paths are easier because I don't have to write an algorithm to copy or make symlinks. <vagrantc>easier is sometimes a compelling argument. :) <nckx>I'm going to hell for saying this but… it doesn't sound *that* hard? (No, I'm not in the least tempted to try it myself, no nerd-sniping me this time.) <nckx>If it's the bare mechanics you're worried about getting right, there's already symlink union code in Guix, if only for inspiration. <meaty>can anyone help me troubleshoot why my qt5 apps arent detecting my qt5ct theme since a few reconfigures ago <nckx>amano: This is how I conceptualise your <B contains symlinks to C, and A copies symlinks from B to itself and contains symlinks to plain files in B>, in general. Of course you'd tweak it to your needs. <amano>Let's say that I want to construct a guix shell environment that contains direct dependencies only. Does guix shell construct search paths out of all transitive dependencies in this scenario? <amano>I gave only direct dependencies to guix shell. <amano>Does guix shell construct search paths out of all (transitive) dependencies? <amano>meaty: You probably didn't run garbage collector? <meaty>amano: I'll give that a shot <amano>When I asked guix help mailing list, someone told me I should use search paths instead of symlinks, but his reasons were vague. <vagrantc>amano: i believe it will construct a search path out of all relevent included python bits <amano>Without transitive dependencies in search paths, the search paths are incomplete. <vagrantc>which is why it includes the relevent ones <amano>I think guix shell can work with a build system that uses symlinks instead of search paths.... <vagrantc>guix shell is for composing transient environments ... build systems generally build packages ... this feels like an apples and oranges comparison <amano>guix shell extracts search paths from packages. <amano>Packages are written against build systems. <vagrantc>at that point, packages are just a bunch of files in a directory <amano>A build system that uses symlinks instead of search paths doesn't make you write packages that specify search path environment variable. <amano>Either way, you only have to give direct dependencies to guix shell. <vagrantc>packages don't specify the search path environment variable (generally) <vagrantc>you don't even give dependencies to guix shell ... you just say what you want in guix shell and it makes sure everything you asked for is in there, including all the relevent dependencies <vagrantc>barring a packaging mistake or soemthing <amano>I still don't understand why guix seems to use only search paths when symlinks can be used. <amano>is there any good reason to not use symlinks? <amano>Even if I try to use symlinks as much as possible, search paths make sense in some cases... I could mix symlinks with search paths... <vagrantc>implement something different and find out <vagrantc>you could even do it manually ... e.g. replace a wrapper script with a link to a directory of symlinks as the only item in the search path <meaty>amano: just did a gc and a reboot, still no luck :( <apteryx>also, shouldn't our website more prominently mention this script? Currently as a new user, I'd probably download the Guix binary tarball, then wonder what I'm supposed to do with it. <apteryx>ok, there's actually a 'can be installed' link to the doc, which mentions the script <apteryx>not super direct, but if someone reads a bit, they'll find it <apteryx>about SELinux on fedora; Guix doesn't work with it yet, right? <apteryx>hm, I get in 'cling': /gnu/store/bs6q65ds38ns2v1m5wf7jgxbz2cx4189-profile/include/stdio.h:34:10: fatal error: 'stddef.h' file not found #include <stddef.h> <apteryx>this file comes from the linux-libre-headers, under linux/stddef.h it seems. Any idea why glibc can't find it? <apteryx>not glibc finding it, but clang I believe (cling uses llvm/clang under the hood) <apteryx>perhaps I should use cling with the clang headers instead of cling with the GCC/glibc headers? <apteryx>looks like it's using libLLVM-16 with gcc 11 libstdc++.so <apteryx>crashes with vtable for __cxxabiv1::__class_type_info in __restore_rt <apteryx>'cling -v' helped; it prints all the include paths it looks up; clang's one had changed; packaging now adjusted <apteryx>ACTION now tries to wrap the cling binary with the gcc-toolchain INCLUDE paths <apteryx>that is odd: a simple wrap-program wrapper that doesn't wrap anything meaningful causes cling to segfault <necto>Do I need to register anywhere to send a patch to guix-patches@gnu.org ? <mange>No, but the first time you send something it might get stuck waiting in the moderation queue until someone gets to it. <apteryx>yay, got cling to work correctly, with default gcc-toolchain headers wrapped in <Rutherther>I really didn't understand what amano meant yesterday, since Guix already does symlink the deps, it's called profiles. So when I go into a shell, all python deps get symlinked to $GUIX_ENVIRONMENT/lib/python3.10/site-packages, and pythonpath has just one path. https://paste.debian.net/1329950/ <Rutherther>or did amano mean the dependencies of python binaries built by Guix and not ad hoc environments? <apteryx>any idea why adding gcc-toolchain this way as an input: (@ (gnu packages commencement) gcc-toolchain) would introduce a module cycle? <bdju>I would like to use mpv's remote-file-playing feature ( mpv sftp://host/path/to/file ) which seems to require ffmpeg to be compiled with networking support. would it be possible to enable that in our ffmpeg builds? it seems to be enabled by default on Arch. <pjals>apteryx: The list is still evaluated at the time of definition, and so are the expressions inside it. <nutcase>Hi guix. I want to add some files to a package (modem-manager) and create links in the build: <nutcase>1. add files to $(guix build modem-manager)/share/ModemManager/fcc-available.d/ <nutcase>2. ln -s $(guix build modem-manager)/share/ModemManager/fcc-available.d/* $(guix build modem-manager)/etc/ModemManager/fcc-unlock.d <nutcase> Do I need to modify the modem-manager package definition locally and install that local one to achieve that or is there a more elegant way? <pjals>Do not touch anything in /gnu/store, Guix shouldn't even let you because its read-only. Make your own package definiton and add the files by snippet or by patch. Though it seems like this is a job for XDG_DATA_DIR, not adding files to the package. <apteryx>pjals: true. I'll check if there are other examples <pjals>Though, why do you even need to add gcc-toolchain to inputs? <pjals>Also, unless you're doing some very deep hackery, you shouldn't need to use @ at all. Just use the module (gnu packages commencement) at the top.. <apteryx>(gnu packages commencement) is problematic (full of module cycles, because it binds top level definitions outside of lazy fields) <apteryx>I see benchmark.scm uses some delay trick, I'll try that <nutcase>I don't (and can't) touch /gnu/store directly, but by building a customized package, I'll do. Can you elaborate on the XDG_DATA_DIR thing? <nutcase>Maybe other people are also interested to include and link additional unlock scripts and it's worth to provide a way in the modem-manager-configuration? <apteryx>the reason I need gcc-toolchain is because the package, cling, relies on having access to correct headers, and gcc headers alone are not complete <pjals>nutcase: I mean adding the files to your XDG_DATA_DIR and then launching ModemManager <apteryx>it could be argued that users should manually set their environment themselves, but given it already captures the libstdc++ and perhaps other things at build time, I think it's better to have it fully functional out of the gate, including the headers. <pjals>(nevermind, it's some dbus trickery, can't help you there) <pjals>I think the user should be responsible for having the headers they want in their development environment.. <apteryx>I'd generally agree but cling is special; it's a compiler itself <apteryx>and it expects to have access to the GCC headers it was built against <apteryx>(goes to great length at resolving that by custom code, of coures which fails on Guix) <apteryx>so wrapping C_INCLUDE_PATH and CPP_INCLUDE_PATH with gcc-toolchain's ones ensure it works correctly, whatever other toolchain the user may use in their profile <nutcase>pjals: I think modem-manager expects the enabled scripts in its etc-directory (e.g. /run/current-system/profile/etc/ModemManager/fcc-unlock.d) and not in its share-directory. How can I achieve that? I think etc-service-type is not suitable, right? <Rutherther>nutcase if that is the folder, then no, etc service wont help you. To write to that folder you would make a separate package that has etc/ModemManager/fcc-unlock.d, and put that package to your system packages list <nutcase>Rutherther: ok, thanks. I think that this is still cleaner than modifying the modem-manager. <Rutherther>But it is a bit strange it would read from that one. Are you sure about it? But maybe yeah, it could read "$0/../etc" <pjals>Packages rarely have /etc. Use an etc-service-type <pjals>Or, poison your cat imperatively and write directly into /etc <Rutherther>Etc service wont help if the package expects it in the current profile <pjals>Wouldn't modemmanager be in the same profile as the system? <Rutherther>Exactly, so it suffices to package the 'plugin' and put it to system packages <apteryx>I tried to clear the .a files from clang-cling, but it seems the CMake generated files contain references to these, barks when they are missing when the next project attempts to link against it? <apteryx>seems they are all baked in LLVM's lib/cmake/llvm/LLVMExports-release.cmake <apteryx>perhaps I could clean it up, but I'd be even happier if I could tell it's build system (cmake) to not generate those <nutcase>Which (if any) of the (guix licenses) could I use for my package definition? Does "fdsg-compatible" appy here? <nutcase>Rutherther: I think the idea with an own package doesn't work, since /run/current-system/profile/etc/ModemManager is a symlink to the modem-manager package in the store :-( <Rutherther>That should not matter, it builds the symlink according to what packages there are <Rutherther>Or did you get an error upon adding your package to packages list? <Rutherther>(assuming it is the profile builder that puts it there, and not other package having the symlink - then you would indeed get an error and that package would have to be modified or not included) <nutcase>Rutherther: you're right. The files are now linked into /run/current-system/profile/etc/ModemManager/fcc-unlock.d <amano>Can anyone paste any apparmor profile in /etc/apparmor.d in apparmor package? <Rutherther>I dont understand your question. Like non-root users? <amano>Rutherther: It doesn't matter whether you install it as root or user. <amano>I just want to read the content of any apparmor profile on guix. <amano>I want to know how guix apparmor package modifies apparmor profiles. <pjals>Hello. How do I use guix deploy with a password? I know ssh with a password is ill-advised. <pjals>Ok, I've gotten public key authentication instead of password, but now I cannot use it because it says that it can't read my private key (RSA) <ngraves>I'm attempting to package pdfium to decouple it from Chromium build. <ngraves>In file included from ../../third_party/abseil-cpp/absl/container/internal/hashtablez_sampler.h:42: <ngraves>In file included from /gnu/store/86fc8bi3mciljxz7c79jx8zr4wsx7xw8-gcc-11.4.0/include/c++/atomic:41: <pjals>Anyway, that smells like a cross-compilation/toolchain issue <pjals>On an unrelated topic, there seems to be a bug where Guix does not properly set the callback for getpass when decrypting the private key. I'll go make a patch for this soon. <ngraves>Indeed cross-compilation. Probably something about adding the right include path based on the system we compile on. <mrh57>should the guile package have "GUILE_EXTENSIONS_PATH" pointing to "lib" in its search path? <mrh57>so that it can find foreign libs? <bigbookofbug>quick question: if making a script to automate templating out `guix shell` calls, and would like to host it on my channel rather than as just a local file. if i do this, whats the best way of installing the script to the current system's bin path? would i just make a channel module and wrap it in an extra-special-files call, or is there a more effecient means? <bigbookofbug>what i want, essenctially, is to be able to add the module to my system config, and have it install the script at /run/current-system/profile/bin/my-script.scm <h4>How to do Rust coding in Guix? It seems that many crates are available on Guix repository, so how to use these and avoid internal Cargo downloading these himself and so? <Kabouik>nckx, Re: ""guix install libxfce4util gconf" — does that work?" No it doesn't, it will endlessly complain about another package, it just lists the first when it shows the error. If I try to upgrade both, I get a similar error adding polkit to the list. What is weird is a plain `guix package -u` worked, but I still have this glib issue when starting a shell or trying to upgrade a single package. <rovanion>Does anyone know anything about qtquickcontrols version 6? I can't find it packaged, only version 5. Has it been renamed in a way? <rovanion>Same question but about Qt6StateMachine. Anyone know if it's packaged? <mrh57>is there a way to convert a scheme expression into a file-like object? <galois`>I am getting this error: ./main: /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6: version `GLIBC_2.38' not found (required by /home/user/.guix-profile/lib/libvulkan.so.1) I'm not sure how to fix it :( <galois`>So I guess my gcc has a version mismatch? <aldum>you have 2.35, which understandably doesn't support programs compiled against 2.38 <galois`>aldum: Yeah.. What can I do about it? <galois`>Compile from source with the older glibc? <aldum>either that, or upgrade glibc <dariqq>does anyone know why an idle guix-daemon is making network requests? <dariqq>it seems to come from the guix substitute process <rovanion>Wild guess: Downloading substitutes, i.e. prebuilt binary packages. <dariqq>but i am not doing anything atm on the machine <mrh57>%desktop-services is a list of services <mrh57>(remove proc %desktop-services) returns a new list of services <mrh57>in your os config, (services ...) expects ... to be a list of services <dariqq>mmh somehow the guix substitute process was still alive. Not sure why though <h4>How to do Rust coding in Guix? It seems that many crates are available on Guix repository, so how to use these and avoid internal Cargo downloading these himself and so? <galois`>h4: Create a container with all the Rust crates you need or run guix shell.. <futurile>jamincollins: you could try a later image or nonguix - that screenshots not showing that much 