IRC channel logs
2023-05-04.log
back to list of logs
<jacereda>No luck, black screen with linux-libre... I'll try sway <gabber>sway... instead of what? i thought you were on Wayland before? <gabber>GDM is the default in Guix (for sway as well as i3) <jacereda>I'm on wayland, gdm should also be wayland (I have (gdm-service-type _ => (gdm-configuration (wayland? #t)))) <jacereda>libEGL warning: MESA-LOADER: failed to open crocus: /gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/crocus_dri.so: cannot open shared object file: No such file or directory (search paths /gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri, suffix _dri) <jacereda>00:00:00.076 [wlr] [EGL] command: eglInitialize, error: EGL_NOT_INITIALIZED (0x3001), message: "DRI2: failed to load driver" <gabber>please refrain from pasting multiple lines in here. and yes, starting sway (or i3 or anything else) from the command line in guix is often a pain to get to work <jacereda>sway was working in previous configurations... <jacereda>I guess mesa should be configured to include that crocus driver <jacereda>in the dri directory I can find the usual suspects, but crocus isn't present <bjc>is anyone else having issues with suddenly needing gpg to work on the repo? <bjc>seems to be coming from ‘etc/git/gitconfig’ now requiring gpgsign <podiki[m]>jacereda: this has been reported and will be updated in mesa, that driver was forgotten <podiki[m]>bjc: probably the recent changes to the git config for the repo the other day from apteryx <bjc>it also broke ‘guix shell --pure -D guix’ <mekeor[m]>ACTION uses user.signingkey=/path/to/ssh/key.pub and gpg.format=ssh in git configuration and finds that signing hasn't ever been easier <mekeor[m]>sounds worth a bug report, cc'ing apteryx :D <bjc>yeah, i'll get to it at some point <podiki[m]>I haven't updated my local repo yet, but if it gets in the way of noncomitters easily hacking for patches, we should make it easier <gabber>definitely feels like one.. i mentioned it here a couple of days ago but people seemed reluctant to dub it an "error" <bjc>i appreciate what's being attempted, but it's definitely broken things <podiki[m]>jacereda: you should see the mesa patch series recently, if you want to try locally, but no substitutes yet <gabber>how is `guix shell --pure -D guix` broken? <podiki[m]>I haven't followed these recent changes so I can't comment just yet, I'll catch up soon <bjc>gabber: ‘make’ now requires git, which isn't included with ‘-D guix’ <gabber>ah yes, i actually ran into both issues these days <gabber>ACTION is glad it isn't just them <podiki[m]>Oh, I've always included git in my guix shell, along with others recommended in manual (too minimal otherwise) <gabber>this does make sense, but shouldn't `guix shell -D guix` be able to do the job.. i mean, it is a shell for guix Development after all <sughosha>Is this commit message fine: "gnu: zynaddsubfx: Switch to Zyn-Fusion interface."? Or should I mention the replaced and added inuts? <sughosha>I anyways add the changes in the next lines. <sughosha>Just want to know if this is fine as subject to send the patch. <gabber>but i'm also pretty tired and not sure how to feel about giving advice, so.... :) <stevenroose>So I have glibc 2.33 and 2.35 installed it seems. But rustc is complaining it doesn't find glibc 2.34 in the location of 2.33. How does it find the 2.33 location? How can I point it to the 2.35 folder to see if it's happier there? <stevenroose>This is the error: /var/cargo-target/debug/build/proc-macro2-17cd4904dd099445/build-script-build: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6: version `GLIBC_2.34' not found (required by /var/cargo-target/debug/build/proc-macro2-17cd4904dd099445/build-script-build) <mekeor[m]>hello. when i attempt to recompile xmonad, i now get "ld: cannot find -lrt". how to fix this? :) <bjc>librt is gone with the current glibc, iirc. you should just be able to delete the -lrt from the linker step <VesselWave>Hello, what are options to autostart something with root privileges? <gry>run it as a separate user that has sudo nopasswd access to that particular command <VesselWave>With shepherd? How to run shepherd automatically for that user? For my user I do it with sway config <podiki[m]>what is going on with libstdc++? it is in gcc (variable name) but not gcc-toolchain, there's a make-libstdc++ procedure but that seems to not produce the same thing <podiki[m]>e.g. strings /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so.6 | grep "_ZNSt18condition_variableD1Ev" finds something but strings /gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so.6 | grep "_ZNSt18condition_variableD1Ev" does not <podiki[m]>since gcc-toolchain doesn't use the lib output of gcc <podiki[m]>i don't think so, but it is just scheme code I believe that just needs to evaluate to a list of channels in the end <lemos1898>could i test a unique package from a scm file with a lot of packages? <lemos1898>but still haven't figured out how to test from that file <FloraGordon[m]>!!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW on TG <atka>plasma situation on guix these days? <ade`>hello guys, do i need to create desktop sessions manually, after i install new window mnager/desktop environment? <ade`>im a bit confused where to put that new desktop session entry, i tried putting it in a `/var/guix/profiles/system/profile/share/xsessions`, but it's bad idea cause it's read only filesystem <ade`>and also putting it in a `~/.local/share/xsessions/` did not work <ade`>sorry for nooby questions <iyzsong>ade`: the session file should be included in the package, install into $out/share/xsessions. then it need to installed as a system package, which will link the session into /run/current-system/profile/share/xsessions. <ade`>ah, but i installed sway and cinnamon and i dont see them in the `/run/current-system/profile/share/xsessions` directory. also what is $out? <ade`>it needs to be installed as system package? <ade`>i used this command `guix install sway` <ade`>and included `(specification->package "sway")` in my scheme config file in `packages` list and reconfigured the whole system <iyzsong>yes, system packages are what listed in the packages field of operating-system (in /etc/config.scm) <iyzsong>well, sway should in wayland-sessions <ade`>ah, so my mistake was that i didn't put it in wayland-sessions <iyzsong>$out is alias to the package store directory, 'guix build foo' return /gnu/store/xxxx-foo, the $out directory of foo. <ade`>i get `guix system: error: symlink: Permission denied: "/var/guix/profiles/system-6-link.new"` <ade`>sudo guix system reconfigure ~/.config/guix/system.scm <ytc>since the mesa update; icecat, mpv, picom etc. complains that they cannot find crocus driver in the store. <ytc>so, i would like to graft all packages with my own mesa package. <ytc>i know how to write a manifest to transform profile packages, but i don't know how to do it with system packages for GDM, X server etc. <ytc>how can i accomplish this? thanks in advance. <mekeor[m]>2023-05-04 00:19:14 podiki: jacereda: you should see the mesa patch series recently, if you want to try locally, but no substitutes yet <ytc>i saw those patches, but -Degl=enabled argument might be also given. <mekeor[m]>cool. and oh, that sounds worth reporting to the mail thread! <mekeor[m]>concerning your actual question, personally, i don't know <ytc>in general, there must be a way to define and use customized system packages and use them instead the default ones. <mekeor[m]>many services allow specifying needed packages. but i'm not sure if that helps <jpoiret>yes, there's no way to generically transform packages included in a system configuration, you'd need to transform arguments of servicecs, which might not cover all uses of the package <mekeor[m]>bjc: for me, gcc-toolchain@12 is shipped with librt.so.1 which is present in my ~/.guix-profile/lib folder which is listed in my $LIBRARY_PATH variable. still, ghc can't find it :/ <jpoiret>mekeor[m]: that's because ghc and others look for librt.so, not librt.so.1 <jpoiret>we forgot to include an empty librt.a in the out output of gcc unfortunately <jpoiret>you can add gcc-toolchain:static for now <mekeor[m]>jpoiret: is there a workaround? :) also, is there a patch already <jpoiret>basically librt.so.1 is empty now, since everything is provided by libc <mekeor[m]>the "static" output fixes my problem. thank you very much, jpoiret! <jpoiret>the problem is that it'll require a world rebuild so it's not an easy change to make now. But we'll probably have to do it anyway <jpoiret>might as well batch some other important changes like updating the glibc again <civodul>jpoiret: we could add an empty librt.a in gcc-toolchain, rather than gcc? <civodul>that would address most practical issues, no? <jpoiret>but still, it's probably a good idea to have it in gcc, zig wanted it and I had to patch out -librt <civodul>yes, that'd be the right fix, but in the meantime we could have the easy fix :-) <ngz>civodul: OK. I can push it to the tex-team branch. <ngz>civodul: I'm currently working on a simplification on texlive package definition that will affect most packages in "tex.scm", but it may take a couple of days. Maybe it would be wise to start a ci job right after your patch set is applied, and again once my own set is ready. <jpoiret>civodul: how could we propagate the elogind dependency on services using PAM, when elogind is enabled? <jpoiret>I don't really see any good way of doing this, and if shepherd gets updated to 0.10 in the near future all users of elogind+greetd will run into the same issue as I did <jpoiret>my current workaround is just adding 'elogind in the requirements of the shepherd greetd service in the guix sources, but that's very ugly. I would also argue that manually having to add this anywhere is not very robust for downstream users, they'd have to know which services actually use PAM <civodul>ngz: alright, i'll apply it and start building again <civodul>jpoiret: do we know of services other than greetd that are affected? <civodul>the question being whether we can look into a greetd-specific solution/workaround first <jpoiret>as long as they manage to attempt a PAM authentication before elogind can get started <jpoiret>GDM comes to mind as well, but it's maybe too slow to start to actually manifest <jpoiret>athough it might happen on low-memory, low-smp-count machines <civodul>also, what are the symptoms exactly? <civodul>apparently mingetty doesn't depend on elogind for instance <civodul>so if you type really fast and you're lucky, you might be able to get a login failure <civodul>in practice, if you wait a couple more seconds it's all fine <jpoiret>for greetd, the service tries to start but instantly fails, and does that a couple of times before getting disablde <jpoiret>DMs actually have their own greeter sessions that they run the greeters with <jpoiret>so it needs to authenticate with PAM instantly rather than wait for user inupt <cbaines>civodul, have you seen the v3 for #61363 ? Assuming there aren't any strong objections, I'd still like to make this change. <civodul>i'm somewhat reluctant, but i should take time for a better analysis <ngz>civodul: I pushed the first patch of your set on tex-team branch. Apparently, the second one was already applied (?). I think we can now build that branch. <cbaines>civodul, it's only a nice to have for me at the moment, so I am prepared to wait until we can address this more comprehensively <civodul>cbaines: ok; ideally grafts wouldn't spill over everything around <civodul>it would be great to not mention grafts in (guix self), for instance <civodul>jpoiret: i see; for now, i think we should have the greetd service depend on elogind, with an "XXX" <civodul>then there are several possibilities <civodul>one would be to rely on dbus activation <civodul>where elogind can be started on-demand <jpoiret>civodul: that's not possible either to do indiscriminately, since some users don't use elogind <civodul>jpoiret: or as an option? like letting users pass extra requirements? <civodul>and arrange so that the defaults are correct? <jpoiret>we could add an (additional-requirements ...) field for now yes <cbaines>civodul, indeed, and I think if grafts become a concern within gexp's, that should be possible <civodul>jpoiret: how about this: if we allow dbus activation of elogind, we can turn the elogind shepherd service into a one-shot service that makes a dbus RPC to trigger elogind startup :-) <civodul>or maybe dbus can even be told to start it eagerly? <jpoiret>eh, I'm not too keen on relying on dbus here, it would kind of mess up the shepherd depedency graph <jpoiret>I'll think about it, if there's something we can do to manipulate the shepherd service from the pam service <jpoiret>but in the meantime it seems like an okay thing to do. I just think that this shows the limits of the current services structure :( if you want to add an elogind requirement, you have to copy-paste the whole definition <civodul>dbus services are usually meant to be started on-demand by dbus-daemon <civodul>here we make an exception because elogind must be able to deal with events such as "lid close", in addition to taking care of logins <jpoiret>how does being started by dbus preclude that? <civodul>if you don't log in, elogind is not started, and thus these events are left unhandled <civodul>(that wouldn't happen with greed since greetd would cause elogind to be started early on) <jpoiret>ah, so just this! I'm not sure it's such a huge problem though, especially if we also eagerly start elogind via shepherd <cbaines>I should really do other things today, but it looks like there's a low level problem with the hurd stuff <apoorv569[m]>I cannot seem to start ardour using JACK, it gives error "Could not reconnect to Audio/MIDI engine". <cbaines>looks likely that the gexp stuff in gcc-11 is maybe ending up mixing with the non gexp stuff in gcc-boot0 <cbaines>this should show the problem clearly: wdiff /gnu/store/kx5zh0wx6gq436vmm9lf89cinqps2xqw-gcc-cross-boot0-11.3.0-builder /gnu/store/690519adhsp0531n0d1b90ddjb55rfgc-gcc-cross-boot0-11.3.0-builder | colordiff <civodul>jpoiret: that's the point: we start elogind via shepherd just because of this <civodul>hmm rereading the bug, there's more to it than just "lid close" and similar events <civodul>eureka! have dbus activation launch a script that does "herd start elogind"! <rekado>apoorv569[m]: do you have jack2 installed? It should be dbus-activated. <apoorv569[m]>Also I wanted to ask, which or how to have a dbus service running. <apoorv569[m]>I found one for the home-dbus-service-type would that be the one? <mekeor[m]>jpoiret, civodul: i hope it's ok that i reported a bug concerning gcc's lack of librt.so, CC'ing you both :) <civodul>jpoiret: actually we're already doing what i described, see elogind-shepherd-service <civodul>could you report a bug with /var/log/messages for greetd on shepherd 0.10.0rc1? <jpoiret>civodul: i could but the long isn't very informative, just one line of PAM complaining about a service error 5 times and that's it <jpoiret>but yeah, we need to keep track of the bug <civodul>yes, because it seems to me it should just work already <jpoiret>I haven't tested it extensively, but it didn't boot at all twice and after adding this it always booted <jpoiret>also, the new shepherd fixed my problem of network manager not being able to automatically connect to the wifi for some reason <civodul>ah well, pam_elogind doesn't trigger activation, so there's still that problem <jpoiret>we could probably patch that, although that'd incur some rebuilds <jpoiret>but still, imo the fix should be to somehow add elogind to the requirements of services that use PAM <jpoiret>just like how PAM can add the "service .... pam_elogind.so" line to new pam entries itself <jpoiret>but the pam-service-type and shepherd-root-service-type extensions don't really communicate :( <jpoiret>general question, civodul: do we want to update to glibc 2.37 soon? <jpoiret>doesn't seem too outlandish to me, we could also batch the librt change there, and see what happens. Could be the first core team feature branch <jpoiret>I wonder if there are more pressing matters though :) <jpoiret>I have a hard time keeping track of bugs I should work on, I just have them as unread mails. Maybe I should integrate them more into some org-mode file, but then I also don't really maintain todo .org files properly 🙃 <cbaines>jpoiret, flapping as in every time you compute the derivations/outputs, they change <civodul>jpoiret: upgrading glibc would be nice but yeah, there are more pressing matters :-) <civodul>jpoiret: i mark things i should look at in debbugs.el and sometimes add them to my Org agenda <jpoiret>where does debbugs store that data? I don't really like having all this state stored in a weird way <jpoiret>cbaines: I can have a look this evening <jpoiret>unless you already know what's happening <cbaines>I'm busy today so I should really stop doing Guix stuff <civodul>ngz: oops, i' messed up on tex-team; i applied the patch, had to rebase, but now i realize you had applied it or part of it already <ngz>gah; sorry. Miscommunication :) <ngz>It's not a big issue however, since only the two of us are modifying that branch at the moment. <_graywolf>Does anyone have any experience running Guix inside kubernetes (basically I want to be able to use `guix shell ... - ...' inside a container inside kubernetes)? Any ideas how/where to store the store? I'm curious if someone did something like this before. <civodul>ngz: we should have the right version of the patch now! <civodul>lemme know when we should start building <ngz>civodul: I think it is fine to run it now. I need more time for the next iteration. <sughosha>Is there any example of using cargo with meson-build-system? <apoorv569[m]><rekado> "apoorv569: do you have jack2..." <- I just installed `jack2` but still getting same error. <civodul>ngz: it should start building again soon <sughosha>Hi all, is it possible to use #:cargo-inputs with meson-build-system? <mekeor[m]>iiuc, you need to use cargo-build-system and add phases for meson, but im a noob <apoorv569[m]>Does guix import just gives a package definition for given language-tool/package? <mekeor[m]>you can then use that code in a channel or in a folder from GUIX_PACKAGE_PATH or so <mekeor[m]>(or to submit a new package definition to guix upstream) <mekeor[m]>the use case is writing package definitions for yourself or for contributing <apoorv569[m]>So its kind of a helper tool to create package definitions.. <apoorv569[m]>I will definitely try to create some.. this will definitely come in handy. <mekeor[m]>afaik, some importers work better than others. elpa (for emacs packages) worked great for me so far :) <cbaines>I've forgotten how to offload to a childhurd: error: SSH public key authentication failed for 'localhost': Access denied for 'publickey'. Authentication that can continue: publickey,password <cbaines>I can ssh in, but offloading doesn't work, and I'm not sure how to work out why <jpoiret>cbaines: you got a childhurd running after c-u? <efraim>cbaines: do you have something setup in /etc/childhurd? that's what the manual seems to suggest <cbaines>jpoiret, no, I haven't attempted to update my laptop ye <cbaines>indeed, which is a shame as I've been getting the bordeaux childhurd's back building things again <jpoiret>cbaines: while I agree that the issue is problematic, I'm not sure it's a good idea to read the whole thing in the guix process <jpoiret>do you have an example of code that would generate such # objects in the builder string? <jpoiret>There's probably some way to error out earlier if we're using gexps <cbaines>often it's a gexp ending up in an sexp <jpoiret>ah, but the last example was from an older style sexp :( we could probably traverse the s-exps to see test types of everything in them <cbaines>I don't really mind the how, but I do want to do something about this sooner rather than later <jpoiret>ie in the sexp we should only find basic types, not gexps. <jpoiret>how would you want it to error out? just raise an exception? <jpoiret>Wouldn't that block computing all derivations for a commit? <cbaines>nope, there's already cases where computing derivations leads to an error, and tools like the data service catch them and continue <jpoiret>in any case, that shouldn't happen if we fix all such errors :) <jpoiret>oh wow, is there an overview of all such errors? <jpoiret>also, what's the nifty url for the worker status? <cbaines>the data service doesn't currently store those errors, I wanted that to happen through the derivation linter (to not reimplement more things in the data service), but the derivation linter is problematic, so the data service doesn't currently use it <cbaines>you can try running the derivation linter locally, but it'll likely die due to memory issues before it lints everything <attila_lendvai>please, please, please, first do signal the errors, and then fix whatever else needs to handle them. the guix codebase swallows errors and backtraces at way too many places. <cbaines>I need to test/enable the agents in the childhurds to send the regular status updates, which if it works will fix the "Status unknown" display <civodul>cbaines: your patch got me to look at the issue more closely :-) <apteryx>apparently it's not possible to use a channel referring to removed packages (it fails at 'guix pull' time when building the packages cache)? I was hoping inferiors could satisfy that, but they work post guix pull, right? See #47949. <attila_lendvai>guix deploy seems to trigger my 10/min ssh new connection limit, even though i have a control master connection. i guess it's not using that, right? <apteryx>guix deploy doesn't reuse the connection, IIRC. There was an issue about it. <apteryx>so it can probably trigger that easily <apteryx>the pipeline status page shows a 502 though <attila_lendvai>hrm, there's a session slot on machine-ssh-configuration, and it seems to be an memoized lambda. <civodul>apteryx: Cuirass is down, cuz it's being debugged <civodul>attila_lendvai: right the connection is supposed to be reused <apteryx>civodul: any tip as to how to contribute to guix-past? <apteryx>I'd like to submit 'python-pycrypto' <apteryx>'Guix-Past' in the subject prefix then to guix-patches... ok! <civodul>apteryx: yeah, it's not ideal, but it should work <civodul>i'll apply it, though i'll remove the %BUILD-SYSTEMS-WITHOUT-CONFIGURE-FLAGS bit <civodul>i guess we can add an entry in etc/news.scm too <attila_lendvai>civodul, FYI, i might be wrong about my firewall ssh rate control, but it sure seems like guix deploy triggers it (10/minute) <civodul>attila_lendvai: does /var/log/messages show multiple ssh connections? <cbaines>I've hopefully put the i586-gnu fire out now jpoiret, at least the broken builder script part of it <attila_lendvai>civodul, good point, and the answer is no. that nftables also has a parallel connection limit, which must be the one that gets triggered. sorry for the noise! <Guest19>since upgrading the system d-feet isn't building anymore <apteryx>bjc: I've sent a patch to conditionally invoke the git auto-configuration targets in 63261@debbugs.gnu.org <Guest19>and docker-compose isn't working anymore ,too "ERROR: for samba Cannot start service samba: Unknown runtime specified /gnu/store/kwcwp71sb8dwsh8zg4vz6pgz2bjq8yj3-runc-1.1.1/sbin/runc" <attila_lendvai>certbot service seems to be broken for me. the generated mcron command line is wrong, the --webroot arg must contain the domain name. is it me, of could it be a bug? i assume i'm running a very simple, although multi-domain setup. <Guest19>is there a site that lists all sites related to guix? like packages.guix.gnu.org issues.guix.gnu.org and so on? <apteryx>Guest19: try clearing the docker cache <apteryx>how can I test if a channel builds with an old guix revision? <Guest19>apteryx: Thanks, this fixed my issue with docker-compose. Where exactly is that list on guix.gnu.org? I can't find it <apteryx>About -> Contribute -> Test and Bug Reports <apteryx>or the Contribute button from the home page <apteryx>Guest19: note that we have a samba service, if you are using Guix System <apteryx>ah fun, this works: guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 -- search -L ~/src/sfl-guix-channel sflvault <Guest19>Ah thanks, though it doesn't list qa. There is some domain that starts with qa but I don't know it anymore. I am aware of that service, though still thanks for pointing it out. <apteryx>civodul: it's silly, I have to add 'python-pycryto' just to please the package-cache.drv, although python-pycrypto was still available in 9ed65e6af77893b658a7159b091b5002892c2f95, eh <apteryx>perhaps package-cache.drv should be more lenient? <civodul>apteryx: the package-cache.drv build failure shows a real issue in the packages, in this case an unbound variable <apteryx>and this old guix version does include the needed python-pycrypto <etienne_>Hi! I am new to guix. What is the recommended way of installing python? I am getting build errors for both python-anaconda-client and conda, .. and so does ci.guix apparently. <apteryx>etienne_: python itself, or python dependencies? <apteryx>'guix weather conda' does suggest it is currently broken (unavailable) <etienne_>Oh that's a nice command to know about, thanks. Love the name. <apteryx>so if we were to fix the client, conda would probably be fixed too (hopefully) <apteryx>there was a recent big branch merged into the main branch, with Python 3.9 updated to Python 3.10 for example <apteryx>so perhaps using a newer conda release would help <etienne_>@apteryx I am used to managing conda environments, and was hoping to be able to do the same thing. For now, because I am creating a specific guix profile for that project, I am probably fine simply guix installing python. <apteryx>etienne_: yes, or you could submit an issue for it to give it more visibility, by sending an email to: bug-guix@gnu.org <yewscion>Hey all, how does one install a version of libstdc++.so alongside the current gcc-toolchain package? It used to live in gcc:lib, but with recent changes the gcc package has been superceded, and I haven't had luck finding where it might have moved to. <podiki[m]>gcc-toolchain doesn't include gcc:lib so it doesn't get libstdc++ <podiki[m]>there's make-libstdc++ but it doesn't seem to create the same libstdc++ even called with gcc as an argument <podiki[m]>e.g. strings /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so.6 | grep "_ZNSt18condition_variableD1Ev" finds something but strings /gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so.6 | grep "_ZNSt18condition_variableD1Ev" does not <yewscion>podiki[m]: Oh, so it isn't something I'm missing, then. Good to know! <etienne_>Thanks @apteryx, I will do that. In the meantime, I guess I can also simply guix install my python packages individually, instead of doing it through conda environments. Please do tell if there is a better way though: it feels that conda becomes largely irrelevant when you use guix. <podiki[m]>maybe gcc-toolchain should include the lib output of gcc as well? <apteryx>etienne_: right, managing python packages via guix should be the preferred way <apteryx>you can write them in a manifest, or guix install them and later 'guix package --export-manifest' <yewscion>I think that would be a quick fix, but maybe there is something I'm unaware of that prevents that. <yewscion>podiki[m]: Is there an issue yet related to this? I'd like to monitor for a fix, see if I can help at all. <apteryx>shouldn't the 'dependencies' field in '(guix) Declaring Channel Dependencies' be a list? <podiki[m]>you can do e.g. guix shell -e -e "(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc-12))" for instance to get a libstdc++ package, but I get missing symbols with that lib sometimes <etienne_>Yeah, that's what I have started doing, in a separate manifest.scm that gets installed in its dedicated profile stores/folders. (pardon if I get the vocab wrong!) <podiki[m]>yewscion: good question, haven't searched, let's see... <evilsetg[m]>I want emacs to be able to use the pinentry I configured for gnupg. I configured both emacs and gnupg as home services, but I can only use the configured pinentry if I start emacs manually. The instance that gets started by shepherd does ask for pinentry and just fails if I want to do something with gpg (auth-source-pass). I suspect this is because of lacking environment variables. <podiki[m]>yewscion: I'm not seeing one. if you are creating one could you cc guix-devel? seems worth a discussion or maybe we are just both confused <podiki[m]>searching the logs, this has come up before and a suggestion of gcc:lib being in gcc-toolchain was mentioned but don't know if it got anywhere <podiki[m]>anyone know if there is a reason why that isn't the case? <podiki[m]>civodul: do you have any insights on libstdc++ and our gcc-toolchain packaging? <apteryx>evilsetg[m]: which pinentry package did you install to your user profile? <evilsetg[m]>I am using the pinentry-gnome3 package. But I am using /bin/pinentry-gtk-2 from that package since /bin/pinentry-gnome3 did fail somehow. <civodul>podiki[m]: what kind of insights? there's a bug? :-) <podiki[m]>ah I think replies will create new bug reports whoops <podiki[m]>civodul: the current structure of libstdc++ packages, is there a reason gcc:lib is not in gcc-toolchain? makes it hard to get at libstdc++ <yewscion>Oh dang, I didn't realize that... Sorry everyone! <podiki[m]>yewscion: no worries, I'm always guessing at the x-debbus-cc headers or things like that; maybe a quick self-reply cc'ing the bug number instead of bugs address <podiki[m]>civodul: make-libstdc++ also seems to make a different libstdc++ than in gcc, which maybe is the point but I wasn't sure <Parnikkapore_m>is there a 'python -m build' build system, or plans to make one? <evilsetg[m]>apteryx: I tried with pinentry now, but it's the same thing. Pinentry works in emacs but not if start it through shepherd. <podiki[m]>pyproject-build-system is the newer one using build, not used everywhere in guix but moving that way; should become the default I think <Parnikkapore_m>context: was trying to update Gajim, it has a pyproject.toml with a builder-path (or the like) which the pyproject-build-system on master does not support <civodul>podiki[m]: normally you'd use g++ and g++ knows how to get at libstdc++ <civodul>if there's another use case, we should discuss :-) <etienne_>@apteryx .. you seem knowledgeable about the interaction of guix and python, is that right? <etienne_>After having guix installed python packages, how do you call them from within python? :D <Parnikkapore_m>copout solution is that it would work with the python from Guix afaik <apteryx>evilsetg[m]: do you use guix home or hand-crafted shepherd services? <podiki[m]>civodul: my current use case was for some binaries (after failing to build from source) that want libstdc++, normally I'd just use gcc:lib to find it; which I still can of course but trickier now with gcc-toolchain instead <etienne_>Ah... it looks like you have to create a specific guix shell to merge the two. <evilsetg[m]>apteryx: use guix home with a hand-crafted emacs service <apteryx>etienne_: right, you need both the consumer, e.g. Python, and the libraries <apteryx>then Python will find them via the GUIX_PYTHONPATH environment variable <Parnikkapore_m>would `export PYTHONPATH="${PYTHONPATH}:${GUIX_PYTHONPATH}"` work? :evil_grin: <civodul>podiki[m]: ok; well i guess we could add libstdc++ to gcc-toolchain <apteryx>Parnikkapore_m: it should, but PYTHONPATH takes precedence on GUIX_PYTHONPATH, so beware <podiki[m]>civodul: is there some reason gcc:lib isn't in gcc-toolchain? I'm not really familiar with the details of the packaging beyond having looked at it briefly. and is make-libstdc++ (at commented for non-gcc toolchains mostly) meant to make a different libstdc++ from that in gcc even if called with gcc? <civodul>podiki[m]: i don't think there's a good reason, other than it's usually unnecessary <apteryx>are channel depenencies private, e.g. invisible to the packages exposed to the user-facing 'guix' command? <etienne_>@apteryx Awesome, thanks a ton! Much appreciated. I have also managed to use them within notebook kernels. Perfect. <jpoiret>Also, I don't think there is dependency isolation like in Guix, you can't use the same channel at 2 different commits because one of your channel has a specific commit as a dependency <apteryx>jpoiret: OK, if that's so, it'd mean that a channel depending on an old guix revision is not currently possible <yewscion>civodul: podiki[m]: Just spun up a different solution in my personal channel, creating a package "gcc-unhidden" which inherits from the hidden gcc package and uses (properties (alist-delete 'hidden? (package-properties gcc))) to expose it. If the standard use-case—what is expected for most uses—doesn't require these libraries, maybe it would be better to create a dedicated package for the edge cases that might need <podiki[m]>civodul: got it. and the make-libstdc++ procedure, by design (make-libstdc++ gcc) would not make the same libstdc++ as in gcc:lib? from the hide-gcc-headers phase? <jpoiret>apteryx: maybe it can be as long as you don't manually pull guix with it. I don't know if our code supports that use-case <apteryx>I'm creating an issue for discussing that use case <podiki[m]>how does one get a particular package output in code, e.g. at the repl? something with store-monad and package-output? <ulfvonbelow>you mean like the store path? Lower to <derivation>, <derivation> has <derivation-output>s. <podiki[m]>maybe? I'm thinking when doing something like guix build -e "...." and the package built has multiple outputs, how would I just select the one, like guix build package:debug for instance <civodul>so the instance at guix.bordeaux.inria.fr is failing because of the infamous connect* issue <civodul>ACTION tries "make update-guix-package" <zimoun>A colleague (I do not have an access to the machine) installed Guix. But many things failed because SElinux etc. So, my colleague tried to reinstall applying some civodul’s patch. <zimoun>The issue is that /gnu is still there and impossible to remove it. <zimoun>It’s about permission. Even using chattr +i does not change. <zimoun>What is the solution for removing /gnu and so reinstall? <mirai>is there some technical impossibility regarding selinux and guix? <mirai>can't guix get some selinux rules? <civodul>if you'd like to give a hand, that's most welcome :-) <civodul>specifically, we're missing a rule to allow guix-daemon to remount the store <civodul>oh sorry, i hadn't noticed you were replying to zimoun <civodul>zimoun: see the gnu-store.mount systemd service <zimoun>yeah, but that service is normally off. I had already been bitten once by this. :-) <zimoun>Well, I am going to double check with my colleague <mirai>zimoun: have you tried the gui utility “SELinux troubleshooter” <mirai>it can give some automatic suggestions when you hit the permission issues <PotentialUser-56>Hi, How can I debug that my private channel is failing when doing guix pull? <PotentialUser-56>(exception %exception (non-self-quoting 140737182970656 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>")) <zimoun>mirai: thanks for the tip. That’s not an issue with SElinux. It is (more or less) solved by #62487. The issue is just about the removal of /gnu. <podiki[m]>zimoun: I remember having issues with this before, it was something like stopping the guix service, unmounting /gnu/store, and then being able to delete, but sounds like your friend did that? <zimoun>My friend did that (well, that’s my understanding from their explanations) <zimoun>Now, they get when running “guix build hello” > remounting /gnu/store writable: permission denied <podiki[m]>hrm. something I guess has gone wrong where the build daemon should have permissions to write there? sorry, not sure <apteryx>hm, seems XDMCP stopped working (black screen) with latest core-updates changes <apteryx>connecting via vncviewer I see a black screen instead of the login manager <apteryx>if true, that means the xvnc system test should fail <ulfvonbelow>when I run "guix package -u ''" it complains that my profile contains conflicting entries propagated from certbot@1.28.0 and certbot@2.3.0. But I only have 1.28.0 in the profile (guix package -I certbot only shows that), and that's supposed to be upgraded. Why is it claiming that an upgrade will cause both the old and new version to conflict with each other? <mirai>apteryx: ouch, I'm reliant on XDMCP as well and turns out I haven't done a guix pull+reconfigure since the c-u merge <apteryx>mirai: yeah, 'make check-system TESTS=xvnc' fails <mirai>the gpgsign = true in 8b972da068708a8b17f3ab153ea940690ca49ca9 might be problematic <mirai>git config --local solves it <panosalevro>what can i do if a guix package has no substitutes + the build fails? example: `guix weather zrythm` <ulfvonbelow>option 1 is to look at the build log and try to figure out what's causing it to fail, option 2 is to try to get someone else to do that. Of course, these options aren't mutually exclusive. <ulfvonbelow>oh, and option 0 is 'guix pull' fervently in the hope that someone is fixing it right this minute <jpoiret>panosalevro: in general if the build fails there's no way the package will have substitutes <ulfvonbelow>ehh, I've run into several nondeterministic build failures in my time <ulfvonbelow>where things like how fast your storage medium is or how much memory you have or how loaded your system is can cause failures <panosalevro>i lack the knowledge/skills to fix it myself unfortunately <zacchae[m]>What are the odds? I was just trying to use libbacktrace to package tvm <zacchae[m]>ulfvonbelow: About your failure. I think I recall having a similar failure that I addressed by using a manifest file <ulfvonbelow>it happens even when I tell it to upgrade everything all at once <zacchae[m]>Yeah, I understand that my fix "shouldn't" affect your problem, but suggesting that it might. <mirai>Are there ways to connect to a VM launched by the system tests without using port-forwarding <zenzen[m]><unmatched-paren> "zenzen: try /msg sneek help" <- Oh, hey thanks. I did get a PM from sneek but as I couldn't see the room I wasn't sure it worked for me. Now I can see all the messages normally. Just trying out Matrix for the first time so still a bit confused <g_bor>We have some news about GSoC, the community is accepting a new intern, Sarthak. The agreed on internship project title is Parameterized Packages for GNU Guix. Welcome on board, and we are looking forward to working together. <g_bor>As there was quite a lot of competition for places this year we only got one internship slot assigned, but we are encouraging all prospective interns to stay around, and try again in the next round. The distributed substitutes proposals are still on the radar, and it would be nice to keep interested people around. <unmatched-paren>zenzen[m]: personally(tm) i would just cut out the intermediatery and use irc by itself :) <jpoiret>the bridge sometimes goes down, i've heard <zenzen[m]>Probably best, for sure but one step at the time :) <podiki[m]>luckily the bridge hasn't had a problem in a while (has only happened a few times in last year or two), but I hope I don't jinx it <podiki[m]>I like having all my messaging in one place which is why I use matrix here <podiki[m]>and actually if you could just put the dates/times here for both arrival and departure so I can put them in my calendar, that would be helpful too <civodul>font-abattis-cantarell used to depend on Java, now it still depends on Rust 😱 <bjc>oh no. can't wait to find out my font has a dependency on a library that spawns an http server when i render text <unmatched-paren>bjc: why wouldn't you want built-in support for Amazon FontX Premium Pro Rendering as a Service?! <zacchae[m]>zenzen: To give a contrasting opinion: Matrix is newer, more decentralized (room still exists even if libera.chat and matrix.org die), and is a very extensible protocol. Federation is the future: Go Matrix! <mekeor[m]>hello. what's the post-core-updates gcc:lib? <mekeor[m]>alternatively, does anybody have a "guix shell --container --emulate-fhs ..." command for rustup to work? <Altadil>mekeor[m]: I’m no expert but for Tor Browser, it was libgccjit <gabber>how can i make guix not check signatures? i'm trying to create a system vm to test my patch but ./pre-inst-env guix gives me a "commit lacks a signature"... <civodul>gabber: you're testing (gnu system install), right? <civodul>in current-guix-package, add: (arguments '(#:authenticate? #f)) <zacchae[m]><unmatched-paren> "how does that work with matrix...." <- Every matrix server with a user in this room has a copy of this room. If matrix.org dies, then all the other matrix servers keep the room going (and still sync between themselves) <ieugen[m]>I send an email but it might get stuck as well. <civodul>ieugen[m]: hi! nice! feel free to close them with an explanation <civodul>to do that, email N-done@debbugs.gnu.org, where N is the issue number <civodul>closing old issues is always pleasant :-) <ieugen[m]>I sent the messages civodul but I did not get a reply or see the bugs close in the web interface. <ieugen[m]>I imagine it takes some time or messages are being moderated <civodul>ieugen[m]: if it's your first message, it'll take a while, but it'll get there eventually <ieugen[m]>thanks. I can wait, just wanted to make sure I got the process right. <Guest19>my mb doesn't support m.2. If I buy one and use an adapter to usb, would it be possible to use it as my main drive and install guix on it? I just wonder how smart that would be or should I better go for sata? <Guest19>nvm, my mb is only usb 3.0 therefore only sata makes sense. the funny thing is that m.2 is cheaper than sata ssd... <ieugen[m]>I found this project out while researching to use guix for CI (inside docker) https://github.com/metacall/guix . I did not got it to work, but I am curios if there is any work being done to remove the two limitations that prevent guix to be used for such scenarios: <ieugen[m]>- guix without forking ( with threads maybe ?!) <ieugen[m]>I am not familiar with the issues, just pasting what I understood 