IRC channel logs
2025-02-18.log
back to list of logs
<guixgoblin>Hello everyone. I installed guix system over the weekend to try it out and have now hit a problem. I have moved some of my stateful data(images,music,some game files, etc.) to several btrfs subvolumes on a lvm logical volume. I want to share this volume between multiple users on the guix system and on my previous linux distribution and mount it in <guixgoblin>such a way that the uid etc. is mapped to the corresponding user with the mount option X-mount.idmap, but util-linux 2.37.4 (newest on guix-channel) seems to not have this option yet. Any recommendations? I found bindfs as an alternative. Is there a guix-way to set it up? <gorilla>Are there plans to replace isc-dhcp with isc-kea as the default dhcp server? <janneke>sneek: later tell civodul, re #75658 me neither but thanks for the reminder, i've only been looking at core-packages-team a bit where glibc 2.41 landed just when i was working on 2.40 <anticomputer>(the run-maestral script just activates the python virtual env and then sets LD_LIBRARY_PATH and QT_PLUGIN_PATH to their appropriate venv locations for PyQT6 before starting the maestral gui) <csantosb>anticomputer: you may have an idea of packaging maestral with `guix import pypi -r maestral > pkg.scm` <csantosb>Difficulty comes from dependencies, not the package itself, `guix import pypi maestral` <apteryx>why is texlive substitutable, according to 'guix weather texlive', while being marked with #:substitutable? #f ? <sneek>apteryx, you have 1 message! <sneek>apteryx, mirai says: Heya, I've got a swtpm package definition sitting here <apteryx>mirai: nice! could you please send it, even if it's a draft? I was about to package it myself otherwise :-) <mra>apteryx: sorry, what's up? <efraim>mra: apteryx would like your package definition for swtpm <mra>efraim: that's not mine, that's mirai's <mra>apteryx pinged me about 41602 <efraim>doh, thanks, I need to increase the font on my IRC client, apparently I can't distinguish the names from my chair <jlicht>efraim: I'll bring some of my old computer glasses at the next Guix days ;) <efraim>I might need that and a magnifying glass. I still haven't fixed the console font size on my new laptop <apteryx>ACTION uses 200% scale in GNOME. Everything is comfortably fat. <mra>apteryx: could you clarify your concern about 42602? I don't think that I quite get it <mra>I've only really briefly skimmed things though <apteryx>mra: my concern is that if we fix 55231 and the foundation assumed to work the way we expect, the problem we aim to fix wouldn't be truly resolved <mra>apteryx: oh, I see the concern. frankly, I have no idea where to start with examining 42602. I agree that if non-substitutable packages are being substituted, then any protections that we put in place are moot <mra>it would also represent a very substantial bug... <mra>if the construction of the derivations is correct, then the only place where I can see there being an issue is in the daemon, and there be dragons <apteryx>anyone has a trick to run the local ./guix-daemon with M-x gdb within Emacs? <apteryx>the problem is that it needs to run as root, which doesn't seem to be possible within emacs <apteryx>ACTION fallsback to good old terminal <apteryx>ACTION wonders why I don't see the debug logs of the daemon even starting it with --debug <apteryx>nevermind, it seems to work after all <jlicht>not at a machine where I can send patches, but I'm seeing some silly deprecation messages /w "<greetd-user-seesion>" <look>jlicht: greetd service got some updates recently, theres now a new way to declare greetd commands with the service <jlicht>I know, I'm just talking about the <greetd-user-seesion> vs <greetd-user-session> in some places :-) <look>Oh, you're right, sorry I didn't notice the typo even when you pointed it out, thats true its indeed a typo <apteryx>if you put a breakpoint on nix::LocalStore::querySubstitutablePathInfos in the daemon with 'set follow-fork-mode child', and run 'guix build texlive', it stops about right before it starts fetching the substitute <mra>apteryx: I'll have a look when I get home. I just did my head in working on a proof in coq <mra>I should also note that I know... nothing about C++ <mra>is there a chance that this is an upstream issues with Nix? it's their daemon, right? <apteryx>I was asking in their irc, matrix channels, but no reply thus far <apteryx>I also checked the git log but didn't see anything obvious <apteryx>with the few forks happening (first for the process job, then for the the substituter), there's a fine sequence of breaks and set-follow-mode to do to see an interesting backtrace <mra>I could also ask around with some of the Lix people I know. they deal with daemon internals a lot iirc <mra>is there a reason that Guix uses such an old pinned version of the Nix daemon? it seems... not great for maintainability. are there issues with newer versions of the daemon that make it unsuitable? <ieure>mra, I might be wrong here, but I believe the Guix version is a fork with some Guix-specific changes. The long-term plan is to rewrite it in Guile, rather than track upstream. <mra>ieure: that makes a lot of sense <mra>I'm for anything that lets me avoid learning C++ <apteryx>we have a ~2012 nix daemon code base with a bunch of changes on top <mra>thanks. where does this leave 55231? do we think that it shouldn't be merged until this issue can be fixed? <mra>seems like until this is fixed the additional checks are basically pointless <apteryx>mra: i think it would be nicer if we could understand that bug better before yes, to make sure our assumptions will hold true <apteryx>actually i think texlive may be a test case for our fix! the 'texlive' package is not marked as non-substitutable itself, but it takes texlivetexmf, a hidden package, which *is* non-substitutable. but since texlive simply embeds texlivetexmf, it's the same situation as the initrd! <apteryx>so i believe we can test our fix on texlive too <apteryx>it's weird, if I try to build /gnu/store/v10c5wzji81pkwq2fhj123gw3d8il0ic-texlivetexmf-20240312.drv directy, it downloads only the source (would build it locally) <apteryx>but if I try to build texlive, it downloads the output of the above .drv! so it's like if #:substitutable? #f was lost when it's referenced from the texlive package or something. <mra>apteryx: fair enough, yeah <mra>apteryx: yeah, the package which ought to be non-substituable substituting anyway was the same problem that I ran into <mra>I don't understand how the #: substitutable? #f is being "lost". it's like it's just ignored <yarl>I am trying to get mesa to cross compile. libclc is a runtime dependency (I tried to put it into native-inputs). If I am correct, building libclc on either host gives the same results (include/ and share/, intermediate code?). But if I try to cross-compile libclc it fails for whatever reason. Is it possible to fool the build of mesa to say "build libclc for the build machine (native-input) but don't worry it'll ran <yarl>on the target (input)" or the build of libclc itself "if the request it a cross-compilation, native compile me instead, we're the same"? <yarl>I guess libclc is not the only package in this case. <Rutherther>yarl: what is in native inputs is built for the build machine. So I dont understand the problem you're having <Rutherther>Of course its possible to fool it, but its probably not going to be easy (will need to replace build tools with native ones) and is not the right way when it is a runtime dependency <yarl>Rutherther: libclc is in mesa's native-inputs but If you try to cross build it meson complains that libclc is missing. <yarl>"Run-time dependency libclc found: NO (tried pkgconfig and cmake)" <yarl>Honestly, I assumed it was because libclc is required on the target, but I might be wrong. <Rutherther>Okay. If it really is a run time dependency, then it shouldnt be in native inputs, but in inputs, and be built for the target architekture, not build <yarl>Right. Does what I said after saying "hello" make sense now? :) <Rutherther>No, not at all. You seem to want to build it for build architekture even though it is run time dependency <Rutherther>Run time dependencies need to run on the target architecture <yarl>Rutherther: but libclc is only share/ and include/ directories. <yarl>I don't know much about these but I think that's some kind of intermediate code. <Rutherther>If it indeed doesnt contain anything architecture specific, then it should be easy to cross compile it <yarl>Rutherther: What is generated and keep in the output is, I think, generic. But. An architecture specific object code (generator program) seem to be built, used, then throwed away. <Rutherther>But seems strange that a package with prefix lib wouldnt contain a library. Are you sure there is no library in lib output, pointed to by pkg config pc file in out output under share/pkg-config? <yarl>As I said, it's opencl stuff. <yarl>I don't know how it works, and I don't really care. I am only trying to get mesa to cross compile :) <Rutherther>If it is like you said, then probably the easiest workaround will be to modify the pkg config path environment variable to point to the share pkg config folder <Rutherther>Inside the build, before configure phase (or how is the meson 'configure' phase called) <yarl>Rutherther: the second statement, ok. The first, uh? <Rutherther>I dont know what to explain. How pkg config works? How its used in build environment etc... <yarl>Rutherther: first, you suggest to move libclc from native-inputs to inputs, right? assuming my hypothese is true? <yarl>Rutherther: before going any further. <yarl>Is a native dependency is keeped during gc? <yarl>(just thinking about why it would) <Rutherther>As far as I know even native inputs should be scanned for usage and reference created if they are used. You can check this afterwards by looking at the references <yarl>Rutherther: I guess I'll try to find in existing package definitions some example of pkgconfig variable. <Rutherther>yarl: you will probably not find any as this is a workaround. Most packages just have the packages in inputs and pkg config path is set automatically, as it is a search path. But it is of course not set with native inputs, as those are not usually running on the target. As for the discussion on keeping native inputs: see https://paste.debian.net/1350997/, try: "guix gc --references $(guix build -f ./file-you-put-it-in.scm)". You can see hello is... <Rutherther>... referenced, even though it is a native input. The stage of the build that scans for references doesn't distinguish between 'native' and 'non-native' dependencies. You can of course see it even with --target= set to something <yarl>Rutherther: Thank you a lot to clarify things. <yarl>I have to make dinner, I'll get back on that later. <cbaines>I see bayfront is back up with the new shepherd :) <cbaines>I'm looking at why the bffe isn't working <bjoli>So, friends: I am trying to update the owncloud package, which would be my first ever try at making a package. It will depend on a library that seems unique to the owncloud-client. Can I declare two packages as files and have the owncloud-client depend on the "libre-graph-api-cpp-qt-client", or do I need to make my own channel? <bjoli>So, to be clear: can I refer to a local file in the (inputs ...)? <ieure>bjoli, You're using `guix install -f some-file-containing-owncloud-client.scm' here? <bjoli>yup. Just to see if I can make it work <bjoli>but I do need to learn about having my own channel sometime, but I am not sure tonight is the night... <ieure>bjoli, So I'm going to answer your question, but also tell you not to do it like that. <bjoli>haha, well. That I already knew <ieure>bjoli, I am 99% certain you can have multiple packages in a single file, and the one which gets installed is the one held in the last expression in that file. <ieure>bjoli, So ex. (define-public libre-graph-api-cpp-qt-client (package ...)) (package owncloud-client (package ... (inputs (list libre-graph-api-cpp-qt-client ...)))) <bjoli>I won't tell anybody you told me <ieure>bjoli, But since this package is already in Guix, you'd be much better served by following the "Running Guix before it is installed" section of the manual. <ieure>Which is, basically, clone the repo (you can locally clone the copy you already have, in ~/.cache/guix/checkouts/, which is fast and uses almost no additional disk space); run `guix shell -D guix --pure'; run `./bootstrap && ./configure && make'. <ieure>Then, hack on the package in situ, using `./pre-inst-env guix build owncloud-client' to test it out. <bjoli>I am copying that to an org buffer. I will learn how to do it properly before trying to send any patches