IRC channel logs
2023-05-05.log
back to list of logs
<podiki[m]>mekeor: see also the bug report/guix-devel discussion right now on libstdc++ (of gcc:lib) <podiki[m]>civodul: our count of people asking about gcc:lib grows by the hour! :-) <ulfvonbelow>am I correct in believing that the purpose of the 'parent' field of <manifest-entry> is to be able to track down *something* in the manifest that has the entry in question as a propagated input? <zenzen[m]><zacchae[m]> "zenzen: To give a contrasting..." <- Yeah I've been meaning to learn more about it and use more often. So far so good! <Guest19>I upgraded my system and now mpv is using x11 and therefore unusable. Does someone else have the same issue? <mekeor[m]>Guest19: what do you mean by "using"? depending? appearing in a window? <ulfvonbelow>alright, I think I've tracked my problem down. It's actually a problem with how collisions are reported. In (guix ui) it blindly follows the parent chain, but that chain was created *before any manifest transaction was applied*. Meanwhile the collisions are detected *after* the transaction is applied. So you can end up with a collision being reported between packages propagated from packages that were never in the same manifest at the <ulfvonbelow>of course, the collision still exists, it's just blamed on a package from the old manifest that might not even exist in the new one. <Guest19>mekeor[m] As using it to watch movies <mekeor[m]>Guest19: is that the log of executing "mpv"? <Guest19>mekeor[m] no, this is the output of mpv <file> <Guest19>nope, still broken. I did nothing to my system except upgrading it <mekeor[m]>yea, theres that issue with mesa. maybe thats the cause. hmm. <Guest19>Ah okay. Yep that should be the reason. <Guest19>but the good thing about Guix is, I can just rollback <mirai>nvm, turns out the spawn + void-port issue is present in 3.0.9 <zacchae[m]>It seems guix home does not add ~/.guix-profile/lib/python3.*/site-packages to ones GUIX_PYTHONPATH <zacchae[m]>Is this on purpose? Because it seems like a bug. But at the same time that seems too... obvious to be a genuine bug <vagrantc>if you explicitly add python to the same profile ... does it? <ulfvonbelow>guix home add's the guix home profile, under ~/.guix-home/profile IIRC <ulfvonbelow>and yeah, because of how environment variable definitions work, only profiles with python (the interpreter) in them will have GUIX_PYTHONPATH pointer at them <zacchae[m]>I have python installed in both my ~/guix-profile and ~/.guix-home. The general workflow (I think) is that you play around with packages with guix package, then integrate them with guix home. This caused me issues when I tried to test opencv but python wouldn't import it <zacchae[m]>guix home adds ~/.guix-profile/bin and ~/.guix-home/profile/bin to my PATH, so it seems like it should do similarly with GUIX_PYTHONPATH <zacchae[m]>I actually gave up on packaging several simple python packages for guix because I thought I would need to package a "python-opencv", but that was aparently already handled by "opencv" <zacchae[m]>Oh, maybe I just needed to run a login shell after installing python in my profile? Now it is getting added... False alarm? <ulfvonbelow>did you re-source ~/.guix-profile/etc/profile (either manually or by starting a new login shell) since installing any combination of python and a python package? <zacchae[m]>I suppose that makes sense. re-source ~/.profile for such things (when using guix home) <zacchae[m]>Alright, I bult a package approximately as simply as "git clone ... && cmake && pip3 install ./python". I'm trying to figure out the best way to build this package. <zacchae[m]>My thinking is to create one package using the cmake build system, then have that as a build (and runtime) dependency of a second package using python (or pyproject) build system <zacchae[m]>Is that how things are generally done, or am I supposed to integrate cmake calls into the python build system? <zacchae[m]>Maybe this is a question for the devel mailing list? <porcupirate>Hi guix, I'm trying to make cups server accessible on my LAN. <porcupirate>I'm getting an error when I try to access the web page, [Client 1] Request from "localhost" using invalid Host: field "mario.local:631". <porcupirate>Do I need to use 'localhost' for the web interface if I'm using the machine that's running the server? <zacchae[m]>You should be able to access it from 'localhost:631' on the machine that is running the cups server (that's how I do it with unmodified service config) <porcupirate>For more context, the plan is to put it on an old laptop I use as a home server. I'm experimenting on localhost because guix deploy takes a while. I want to make sure I can use a computer's .local domain to access the config from across the LAN. Is the flaw that I'm using the same machine to test it? <porcupirate>I tested it from my phone, the .local domain works fine. <porcupirate>I've got the interface working on the home server now. Thank you! <lemos[m]>i am updating a package from guix, i am new to all of this, how can i test if my changes from the file (in the repo that i cloned from git) are working? <lemos[m]>couldn't figure out how to test them using --install-from-file <zacchae[m]>lemos: I think it should work so long as you use ./pre-inst-env <zacchae[m]>If you make a change and do "guix build", then the resulting hash should be different <ulfvonbelow>is there a good way to print an object in guile such that you get a pretty good idea whether it is 'eq?' to other such printer objects? <lilyp>ulfvonbelow: eq? is pointer equality, so you have to figure out the object's address <xelxebar>Pulling finally worked. First time in 2 weeks. \o/ <xelxebar>Now curl is failing to build, however: /gnu/store/2527c4i59vc26d4p0qvbzs7llp7a809d-curl-7.85.0-builder:1:4614: Unknown # object: "#<" <mfg[m]>I have seen this error in a thir party channel where a package overwrote inherited attributes, but the original pack age used gexp whereas the overwritten arguments didn't. <mfg[m]>Using gexps magically solved the problem <abrenon>reading about the package responsible package, python-leather, I found that it doesn't state to support 3.10 but only goes as far as 3.8 <abrenon>so it seems like we went to fast ahead switching to 3.10 by default for packages like this; what is generally done in this situation ? a temp fix, possibly suggesting the upgrade upstream ? or just telling people who need the dependants to hold to their current version and upgrade later ? <civodul>abrenon: hey! for this specific error, you can search for "collections\.abc" in the code: there are quite a few places where we patched upstream code <abrenon>ohhhh, this particular change in python's libs occurs frequently and has been already fixed in other programs during the upgrade ? <apoorv569[m]>Why is Ardour not able to start with JACK? I have jack2 package installed and I'm using pipewire audio system. <apoorv569[m]>I have a recording session tomorror, I need to fix this before that. <abrenon>the substitute\* fix for collections is tempting, but to apply it I apparently need something called substitute*, and nothing in the example source where I've found it (gnu/packages/haskell.scm) points to a single clue as to where that could be defined <abrenon>grepping the source yields guix/build/utils.scm but including that module doesn't change a thing <abrenon>since it's a (define-syntax …) thing and not just a regular function I can understand I can only suppose it needs a special ritual for invocation, but not being a believer of the inner circle, I cannot use it <civodul>(guix build utils) is included by default on the "build side" <abrenon>but I added the import and it still doesn't work <abrenon>macros seem to be way beyond me, I can only understand one thing: functions ^^ <jpoiret>civodul: i see you updated guix, did you manage to resolve the proot issue? <abrenon>if I did get it, that might be enough XP to reach the next level <abrenon>(please don't answer till I test if you've got it too) <jpoiret>I thought I saw a commit that added support for elogind actions on system suspend, but I must have dreamt it <cbaines>is it possible that offloading to a childhurd is completely broken, as I cannot figure out what's not working. <cbaines>all I can get out of the client side is: ssh_packet_userauth_failure: Access denied for 'publickey'. Authentication that can continue: publickey,password <rmancini>How does guix know to install a service's package when mentioning it in the shepherd services #:start proc? What profile will the package be installed into? <cbaines>rmancini, installing is the wrong way to think about it here, it won't necessarily be installed in any profile (unless the service arranges it to be) <civodul>jpoiret: nope, but those tests aren't run in the 'guix' package i believe <sepi>cbaines: ok, what about building :). Just mentionning the variable that references the package will arrange for the package to be built? <cbaines>sepi, yep, using a package as part of a system service will ensure that package is built and available in the store <sepi>cbaines: also, how could the service arrange for the package to be installed into an environment? I would need to have that done in order to easily calculate the GUIX_PYTHONPATH needed for the services env. <sepi>cbaines: so the fact of evaluating the package means that it will be built. I don't need to put it in a gexp or anything? <cbaines>sepi, I'm not sure I follow the second bit of your first line, where does the GUIX_PYTHONPATH get involved? <cbaines>and the definitions of shepherd services in Guix typically use gexp's, so I'm guessing you might already be using a gexp <sepi>cbaines: well I'm trying to create a service that extends shepherd in order to run gunicorn (a python wsgi web server). The gunicorn process needs to have the right GUIX_PYTHONPATH set in order to be able to load the actual web application (and python dependencies) to be deployed. <sepi>cbaines: Let me paste my service... <sepi>cbaines: ah, very intersting. I'll need to study this example more in-depth. Thanks a lot for the pointer. I hadn't found any django application until now. <sepi>cbaines: I would ideally off course have the application manage its dependencies. Installing it in a profile would make that happen if I understand correctly. This way there would be a place where all dependencies would be collected. <abrenon>trying to commit my fix in order to prepare a patch, the command fails because I don't use gpg <abrenon>is it possible to send unsigned patches ? <cbaines>sepi, generally in Guix packages, it's good to try and avoid relying on profiles to provide dependencies <cbaines>sometimes this is useful because you want to load things in from the environment at runtime, but generally it should be avoided <sepi>ok, what's the rationale behind that? <cbaines>sepi, you want the behaviour of the software to be fixed at build time, so that things don't break <abrenon>(I've seen the git config file and I suppose I can always deactivate that there, but will the devel list accept an unsigned patch ?) <cbaines>if you build things with the approach of "hopefully stars will align every time this is run so it works", then things will be more likely to change in behaviour or break <sepi>Does guix work well with ssh-agent? I tried defining a package in a custom channel that fetches from a private git repo but get weird errors. Is there a way to get this working? <jpoiret>civodul: aaaaah you're right, I got stuck on fixing system tests not realizing that they didn't matter for the guix package :( <jpoiret>cbaines: that's one thing I don't really like, in the end we send unsigned patches over mail, wouldn't it be possible to send signed patches somehow? <cbaines>jpoiret, it seems like git format-patch has a signature option, so maybe it's possible to include signatures <jpoiret>cbaines: I think that's just a regular mail signature, which by default is the git version <cbaines>I think I've managed to get offloading to my childhurd working though, turns out I just needed to authorize the SSH key <cbaines>I thought I was testing using the key by asking ssh to use it, but it just ignores that instruction and logs in with an empty password <cbaines>so setting a password for root in the childhurd helped to debug this <cbaines>right, I can fail to build coreutils-boot0 now for the hurd :) <cbaines>jpoiret, I think you had some awareness of what needs fixing post core-udpates for the hurd right? <jpoiret>not really unfortunately, apart from upgrading everything <jpoiret>i'm not extremely familiar with Hurd, so I don't really know if the problem comes from having picked incompatible commits for MiG/gnumach/Hurd, or if it's our configuration that's missing something <jpoiret>coreutils-boot0 is failing though? that's pretty bad <jpoiret>I only fixed the compilation issues and cleaned up the hacks around %current-target-system <jpoiret>ah, I couldn't test native compilation on hurd <_graywolf>When trying to run `guix import go', it supports `-r' to `generate package expressions for all Go modules that are not yet in Guix'. Is there a way to manually create *some* package to it will not try to generate them? <jpoiret>cbaines: I don't really know much about the bootstrap process, but I wouldn't have expected that derivation to change <cbaines>jpoiret, yeah, maybe some patches got lost on core-updates <jpoiret>no but just looking at the definition, I don't think anything changed there <jpoiret>the only things that I touched were higher in the chain. Maybe the coreutils update? <cbaines>hmm, I can't see anything obvious in the package definitions either <cbaines>I also don't know C/C++, so I've got no real idea about this file_t thing <jpoiret>I would assume it should come from Hurd headers, but nothing has changed on that front, Hurd headers should be included in the bootstrap glibc iiuc <jpoiret>looking at the bootstrap glibc sources, time_t *is* defined there <sepi>cbaines: what do you think about the approach for django application deployment where the actual webapp package would create a shell script during build time that would set the environment and launch gunicorn by itself which would then load the actual application module. Configuration of the application could be done through environment variables passed by the shepherd service. <cbaines>sepi, that sounds like it might work, although avoiding using a shellscript and just sticking to Python sounds neater <sepi>cbaines: ok, I'll see if I can do that. <sepi>cbaines: the target being to be able to build a nice abstraction later on to be able to easily package and servicify arbitrary django applications <sepi>and later extend it to other web frameworks and languages <sepi>I want the problem of manual web application deployment solved :) <sepi>without relying on docker <sepi>it's 2023 and we still install web applications like in the stone age <cbaines>jpoiret, I'm trying to compare some coreutils build logs <cbaines>you mentioned headers, and there's no mention of hurd-core-headers post core-updates <jpoiret>do you have the corresponding derivations around? <jpoiret>the first one is not a boot0 coreutils though <cbaines>yeah, maybe I haven't found the right one in the graph <jpoiret>what's weird is that include/hurd.h does exist in the bootstrap glibc <jpoiret>do you have the build directory for it? could you send configure.log? <abrenon>patch sent! despair not, csvkit, you will be available again <cbaines>jpoiret, there doesn't seem to be a configure.log in the build directory <abrenon>but I think I read on quodlibet's issues tracker that the problem was tough to reproduce and din't occur everywhere <abrenon>what can be done in such situation ? submitting the patch anyway, assuming that the build will pass on CI and substitutes will be available ? <jpoiret>cbaines: that's weird, coreutils-boot0 has been in Guix since at least 1.2 from what i can see <jpoiret>i don't have a childhurd so I can't really test native compilation myself though <jpoiret>its weird that there isn't a configure.log though <cbaines>jpoiret, ah, gcc-cross-boot0 uses coreutils-boot0 in it's source <cbaines>this "evil hack" is probably a key difference compared to pre core-updates <PurpleSym>Can anyone successfully xmonad --recompile after the core-updates merge? I’m just seeing -lrt: No such file or directory. <PurpleSym>Looks like the symlink librt.so->librt.so.1 is missing now 🤦♂️ <Kabouik>Does `guix pull` actually builds anything? I installed Guix (package manager this time) on my phone and a `guix pull` is extremely slow <jpoiret>and guix's dependencies if they're not built yet and not available as substitutes <jpoiret>well, almost all build systems do not link against librt anymore (it's useless now that glibc has integrated its functionality), so it didn't cause any issues while building <jpoiret>for the couple of downstream users who need -lrt, well, I guess not enough people tested core-updates before the merge? <PurpleSym>I might have applied a patch to GHC in the past, which forces -lrt. <Guest19>xsane reports that no devices are available. I have installed xsane and sane-backends. I also added my printer to cups and I can print. My printer is a hp envy. What is required to make it work? <jpoiret>PurpleSym: that shouldn't be needed anymore, yes <civodul>jpoiret: the debugging session was fun though :-) <jpoiret>weird, I didn't get that mail in my inbox. Maybe my filtering rules are off <civodul>maybe you don't wanna hear about posix_spawn anymore? <jpoiret>civodul: ah, so the posix_spawn_file_actions_adddup2 call is just plain ignored when the second argument is -1, instead of erroring out?? <jpoiret>civodul: I'd rather move that code to piped-process, but yes, seems like a good idea <jpoiret>we already have the relevant if's, we just need to complete them <bovid-19>Hi! I'm trying to customize my grub theme on guix system, but I struggle with changing the image. So far I tried a string ("/home/bovid-19/Pictures/system/grub.png") and the same string in a list. <sneek>Welcome back bovid-19, you have 1 message! <jpoiret>ah, we don't check the return value, so it's our fault (oops) <jpoiret>i'll try to clean it up and add some error handling to do_spawn to actually report such errors <Kabouik>I realize now that I have Guix on a aarch64 machine that the packages in my private channel are not available for that architecture. How do I add support for it? There's no specific line in the package definitions setting the target architectures at the moment. <jpoiret>Kabouik: probably one of their dependencies is not supported <jpoiret>you can try to build them and guix should tell you what's not supported <Kabouik>Hum, sad. I know they can work on aarch64 because I already compiled them manually on device in the past, but I assume the dependencies already in Guix are not necessarily built for all architectures <jpoiret>it's not that they're not built, it's that they were flagged as not being supported on that architecture <jpoiret>did you find out which packages are responsible for this? <Kabouik>Not yet, I ran a guix build -L . nmail-login in it, so fat its working <jpoiret>looks quite simple. Did guix not print any warning? <Kabouik>(I submitted a patch for it by the way and I should nag core members to review it again, but the patch was for 3.62 while the package in my private channel is now 4.20, and I forgot totally how to submit commits to issues.guix.gnu.org, so it'll take time before I can upgrade it. <Kabouik>No warning, it's still building/fetching dependencies (it's quite slow on a phone) <Kabouik>But even though I added the private channel in my channels.scm, and guix pulled without any issue, the packages from my private channel are not visible in guix search/guix install, so I was assuming it was an architecture filter. <jpoiret>ah, that's a whole other problem then <Kabouik> /home/droidian/.config/guix/current/bin/guix <jpoiret>and does `guix describe` show your channel? <Kabouik>Yes, though it also throws an error first: ERROR: ld.so: object 'libtls-padding.so' from LD_PRELOAD cannot be preloaded: ignored. I guess it's minor because the rest works. <jpoiret>that's from your own configuration, Guix doesn't set LD_PRELOAD <Kabouik>What I was thinking yes, Droidian is hacky <Kabouik>The package built fine on the device (and therefore cyrus-sasl-login which it depends on too), both are from my private channel <Kabouik>But still not indexed in Guix search/install. <sepi>I'm trying to build django-select2. It is build using pyproject. It should be fairly straight forward but when I build it I get an error saying it can't find the build backend flit_scm:buildapi. I do have python-flit-scm as a native-input to the package through. <sepi>when I debug this using --keep-failed, I can import the needed backendc <jpoiret>civodul: did you test the test on 3.0.9? it's passing for me <Kabouik>Weirdly enough, the packages now show in guix search/install jpoiret. I haven't done anything but letthing the phone sit (with no guix action running) and ssh into it. <Kabouik>Unfortunately guix complains that cyrus-sasl-CVE-2019-19906.patch (required by cyrus-sasl-login) is not found. I find that surprising because building from the local .scm files worked just fine. <Kabouik>Maybe that patch no longer is needed. <jpoiret>civodul: disregard that, it does not pass, I was not checking the right thing <jpoiret>GNUtoo: there's no direct replacement <jpoiret>if you really need it, you can use `-e '(list (@ (gnu packages commencement) gcc-final) "lib"'` <apteryx>jpoiret: i'm trying your NetworkManager related patches, also re-instating a current NetworkManager version (1.42.6) <apteryx>any tip to test if it still works? just attempting to change my wifi (WPA2) would trigger it? <jpoiret>ah, good idea! For me, nm-applet crashed if I tried to modify a WPA2-Enterprise connection <jpoiret>otherwise, apart from checking that connecting does work in general, i don't know if there's a good general method to test nm <GNUtoo>jpoiret: thanks, I needed it to run a browser with guix sell <cbaines>(%current-system) doesn't seem to work in a package's source :( <otterz>Hi, I'm trying to build Guix in a guix shell environment, as described in the "Building from Git" section of the manual. I first run "guix shell -D guix --pure", then "./bootstrap", then "./configure --localstatedir=/var --sysconfdir=/etc", but I get the following error on the ./configure step: "configure: error: GNU libgcrypt not found; please <otterz>install it." Any ideas what may cause this error? <jpoiret>so eg. you can't use system-specific patches in the source <cbaines>well great, that explains why my attempts to stop the evil hack applying to the hurd haven't been working <jpoiret>aha, the evil hack is there exactly because of that <jpoiret>i really didn't want to write this monstruosity, trust me <cbaines>I'm talking about the evil hack in the gcc-cross-boot0 source <jpoiret>otterz: what guix version are you using (ie. `guix describe`) <civodul>cbaines: in general i think we should only go in the sexp->gexp direction, never backwards <cbaines>civodul, if you're talking about gcc-11, I don't think this is a general situation, things are a real mess <jpoiret>otterz: that's not enough for me to get the actual version, at least 10 chars are needed i think <cbaines>all I'm trying to do is damp down the fire a bit <PotentialUser-25>I think its because I havent specified the path to the patch correctly. Is there some resources how to specify it? <jpoiret>PotentialUser-25: (patches (search-patches "patch1.patch" "patch2.patch" ...)) <PotentialUser-25>If I put search-patches next to the filename like the cookbook says it fails with unbound variable <jpoiret>otterz: that's not enough to locate the commit, sorry. You'll probably need at least 10 characters <civodul>cbaines: yup, that's much appreciated! that was more of a general statement <PotentialUser-25>I thought search-patches was not used anymore due to the error message. But if they are used probably it cant find the file <otterz>jpoiret: ah, sorry about that. Here's the whole hash: "3efdc84bbd1819aeef6e2290aaf54bc88ba72dda". Hmm, when I run guix describe inside a guix shell session I get a different version "dc5430c9dc20ee53441995d9a89a90b0a86aeed3" <jpoiret>PotentialUser-25: it is used, but you need to specify the whole path starting at your channel's root <jpoiret>as opposed to patches which are in the Guix source <PotentialUser-25>what if I dont have a channel? I am running: guix install --install-from-file=something.scm <apteryx>i'll try editing a wpa enterprise connection as my test case <jpoiret>PotentialUser-25: then it just won't find the patch file unfortunately <apteryx>is anyone using Guix System on armhf ? <jpoiret>well, maybe if you just use (patches (list "file.patch")) but I'm not sure this will work <PotentialUser-25>jpoiret ah got it. so i need my own channel for any changes i do the pacakges <PotentialUser-25>i thought i could just change once without getting involved with channels :P but I will set one up <jpoiret>otterz: your shell might be messing with your env variables <jpoiret>can you try the same shell invocation but with `--check`? <jpoiret>yes, that's probably the reason. You should probably follow what the warning tells you at the bottom <otterz>From the "Invoking guix shell" section in the manual: "For example, if you are using Bash, make sure that environment variables are set or modified in ~/.bash_profile and not in ~/.bashrc—the former is sourced only by log-in shells." Yeah, I set my env. vars in .bashrc, i.e. not in the right place <otterz>jpoiret: yes, it works in a container! Thank you very much! <jpoiret>civodul: re elogind/PAM, wdyt of adding a shepherd service for PAM as a synchronization point for services needed by pam? <jpoiret>that way you can add pam as a requirement to all things that use it <civodul>jpoiret: that's an option, but i would first check if we modify pam_elogind to trigger dbus activation <jpoiret>we'd need to make dbus be able to trigger the shepherd service start as well <jpoiret>i'm not sure if it's a good idea to make PAM hang <jpoiret>esp. if dbus can't start shepherd for some reason <jpoiret>I'd rather be able to see the dependency failing to start at the shepherd level <jpoiret>but that would mean overloading the pam-service-type extensions even more, adding also symbols to represent shepherd pam requirements <civodul>we can make a <pam-extension> record to make things cleaner <civodul>(as is done for home-bash-service-type) <jpoiret>ah, that's right! i'll be doing this then <jpoiret>might solve the GDM issue that kept happening some time ago on slow hardware <civodul>re Shepherd 0.10, i guess we'll have rc2 hopefully this week-end and then release a few days after <efraim>i can test it a couple more times as needed <jpoiret>civodul: wouldn't it be possible to add shepherd-next by the way? <gabber>i run into "guix home: error: opening lock file `/gnu/store/HASH-mirrors.lock': Read-only file system" when i try to reconfigure (i'm still trying to test the generalized home-night-time-service). why/what does it mean? <civodul>jpoiret: i think using the shepherd channel is even better! <jpoiret>i just did a very low-quality semver check in my config.scm so that when the new shepherd ends up in guix i don't just end up running the rc instead <GNUtoo>jpoiret: do you know how to use '(list (@ (gnu packages commencement) gcc-final) "lib"' in guix shell? <jpoiret>there's a missing closing paren at the end though <podiki[m]>GNUtoo: there is a guix-devel/bug discussion about gcc:lib as well (regarding libstdc++ in particular, but in general making it available more easily now) <podiki[m]>GNUtoo: and thanks, was trying to figure out how to use -e and get a particular output of a package, that seems to work (thought I tried something similar but must have missed something) <mirai>other than a horrible chain of (if (eq? … <rekado>remove all the quotes from lines 6 through 8 <mirai>rekado: I don't have to quote them here? <mirai>does it mean that the comparison datum under 'case' are implicitly quoted? <sepi>I'm modifying a build phase and would like to access the final installation path of this package. Is this possible or an illegal self-reference? <ngz>How can I run "tests/texlive.scm" tests in my local checkout ? <sepi>duh, I can off course just use out <ngz>OK I read the fine manual and found the "make check" invocation. Duh. <PotentialUser-25>Is there a way to specify a local binary to be installed in the store? I thought file:// was that but it seems no <PotentialUser-25>my usecase is that the binary doesnt run because it doesnt see pthreads. so I was thinking of installing it in the store with a recipe <jpoiret>podiki[m]: maybe you tried with `guix build`, which doesn't support specifying outputs <podiki[m]>maybe, but was also trying for shell (since ultimately that's what I wanted) but now I can't be sure :) <jpoiret>sepi: you should use gexps, and in that case its #$output <ngz>Hmm now, how can I inspect a test failure… The ".log" file is not particularly helpful. <ngz>Can tests be run from a Guix REPL? <sepi>jpoiret: I don't explicitly use gexps but suie modify-phases and add-after. Then I extract the out from outputs passed to the lambda <jpoiret>you should use gexps around modify-phases, instead of it just being a sexp <jpoiret>sexps for #:phases are being phased out <sepi>are converted to something like gexps right now? <jpoiret>yes. Basically a gexp is similar to a sexp, but it has more bells and whistles to accomodate the build-side vs. host-side distinction that sexps don't have <mirai>at Line 68 it looks like it's confusing the field to match with a procedure call? <sepi>jpoiret: Ill check out the new style once I get this working as it should. Thanks for pointing it out though <jpoiret>mirai: isn't the name of the record wrong? <podiki[m]>speaking of guix shell, trying to make some scripts where the shebang limit is more than reached, any good tips? I found some wrappers but can't get the right escaping <mirai>I left out the outer one since it's not relevant <jpoiret>I would've expected <btrfs-file-system-scrub-configuration> <mirai>oddly if I handpick the imports it works? <mirai>so the inner (match-record … <…> (file-system)) third argument gets confused as a procedure call <mirai>it's missing #:use-module (guix records) <PotentialUser-25>hey. how can I "install" a local binary in the store? I have a go binary that needs to find glibc but it cant because guix doesnt follow fhs obviously. So I was thinking of installing it in the store <PotentialUser-25>jpoiret My thinking was that packages in the store can see the libraries and stuff. So if I add it there with a glibc depedency it would see it. Am I wrong? <civodul>mirai: looks like someone at the FSF made a mistake <jpoiret>PotentialUser-25: you'd need to use patchelf on the binary to change its RUNPATH, so that it finds glibc. <civodul> /guix and /hurd are normally redirects but they're 404 <jpoiret>PotentialUser-25: well, no, you'll have to patch it before it gets into the store, through a build phase <mirai>what are the arguments passed to the (start …) slot of a shepherd service <mirai>are they all that usually follows a “herd start foo …” or is the first argument special? <mirai>afaik a custom action, like “herd my-action foo 1 2 3 4” gets (<return value from the start slot> 1 2 3 4) as args to the procedure associated with it <ennoausberlin>Hello. I was loosely following the idea of teams some months ago. How can one join the python team? <jpoiret>ennoausberlin: you can send a patch for etc/teams.scm.in <ennoausberlin>jpoiret: That team is quite small. Only two members if I am not wrong. <podiki[m]>ennoausberlin: if you are looking for python stuff to review/test there's this series https://issues.guix.gnu.org/63139 which will cause a python world rebuild; I need help sorting out the bootstrapping/updates properly <TristanCottam[m]>Hi everyone! I'm trying to package Dgraph for Guix, which is installed using make install, which itself runs go install. <sepi>TristanCottam[m]: what's the issue? <sepi>TristanCottam[m]: you probably need to modify the makefile so that it can find the go binary <jpoiret>yeah, you'll most likely want to use the go-build-system <sepi>TristanCottam[m]: /homeless-shelter is the $HOME set by the build system. The build system tries to write into $HOME I guess. But yeah, follow jpoiret's advice. If there is a specific build system, it's probably a good idea to go for it <TristanCottam[m]>sepi: I was confused by the recommended installation method being `make install`, and couldn't tell if I should replace it. <sepi>Is it a common pattern to have functions modifying packages? I'm interested in having a function that takes a simple django application package and makes it into a package that runs the django application using gunicorn for example. <sepi>TristanCottam[m]: so this package is built not using the normal go built system? I'm not familiar with how go programs are built <dirtcastle>is there a way to start services in a container by declaring it. I know guix uses linux's LXC module to containerize apps. <jpoiret>TristanCottam[m]: yes, if the underlying makefile is just a synonym for go install then it's better to use the go build system, because it requires a lot of work-arounds to get go to work <TristanCottam[m]>sepi: Well I'm writing the package definition myself, just needed help about that. <jpoiret>guix's containers are just built on top of Linux namespaces <dirtcastle>is there a way to start services in a container by declaring it. <mirai>sepi: I'd consider packaging the django application as is and then define a service that uses gunicorn on it <mirai>I think I have an example for a scenario like this <ennoausberlin>podiki[m]: At the moment I added a dozen packages to my own channel. Before I add them to the official channel I'd like to learn more about fixing failing tests. At the moment I mostly set the tests? argument to #f, but this is not the way to go I guess <sepi>TristanCottam[m]: I think we understand what you're trying to achieve but unfortunately the build process is not clear to me. I'm trying to figure it out from the Makefile but honestly I'm not good with makefiles. <sepi>TristanCottam[m]: you should try to understand exactly what is happening under the <sepi>hood and then you compare it to the provided build-systems. You then choose the one most appropriate and customize it a bit. <podiki[m]>ennoausberlin: right, tests being disabled or skipped should always have a reason; with python often it is needing the right test modules, more general reasons to disable tests is for things like network access (not allowed in build environment) <ennoausberlin>podiki[m]: python-pytest 3.7.1 would be nice. I added it to my channel and it builds once, but somehow it causes problems to other packages (huge memory consumption on guix package -u) <ennoausberlin>podiki[m]: I am eager to contribute, but need more practice. <podiki[m]>an update to pytest, assuming it doesn't end up breaking everything :) would fit in that issue I linked earlier, since it will be rebuilding everything anyway <sepi>mirai: that was my first approach. The problem being that in order to run gunicorn, you need to know the PYTHONPATH of the application you're trying to run. This seemed tough at the time. <podiki[m]>ennoausberlin: my advice is always to read the guix code, pretty much everything you can think to do has been done, and of course ask here; submitting patches and getting review is also helpful, doesn't have to be perfect especially the first times <TristanCottam[m]>Can anyone help me understand what are #:import-path and #:unpack-path for the go-build-system? <ulfvonbelow>neither am I. You could probably find something out by reading in guix/build/go-build-system.scm or guix/build-system/go.scm <zacchae[m]>I compiled some code in a (--pure) guix shell. That code is failing to load /gnu/store/...gcc-11.3.0-lib/lib/....so. gcc-11.3.0-lib is not in my profile, so it must be referenced in one of the packages in my shell environment. <sepi>mirai: after spending countless hours on this, I managed to make a package combining my application with gunicorn and exposing a shell script to launch them. This works since I have access to the needed PYTHONPATH during the build of the package. I don't think I can have that info in a service available <zacchae[m]>How can I track down which package is finding tha .so file? <ulfvonbelow>TristanCottam[m]: you might especially like the long comment at the beginning of guix/build/go-build-system.scm <mirai>the package in this snippet was actually a flask app but it should work similarly <TristanCottam[m]>ulfvonbelow: Right, I didn't realize it could be more informative than the docs. <ennoausberlin>podiki[m]: At least the situation is better than a year ago, because most projects switch over to pyproject.toml and this is easier to build <sepi>mirai: damn, that looks simple :) I was missing package-transitive-propagated-inputs <jpoiret>`mumi send-email` worked on the first retry this time, quite impressive <sepi>mirai: well, not all my time was taken in order to get the service running. I also spend a decent amount of time to package all the python dependencies :) <jpoiret>zacchae[m]: gcc is adding this reference automatically <sepi>mirai: thanks for showing me! I'll see if I cant implement it this way. <jpoiret>you mentioned you compiled some code, what kind of code is that? <jpoiret>lots of languages actually rely on gcc one way or another <sepi>mirai: How is that service configured though? I'm always using records. You seem to use a different style. <mirai>sepi: that snippet in particular simply uses a local-file (or path as string) since I couldn't be assed to write a record-type definition for an unstable custom app of mine <sepi>mirai: maybe try call/cc? <apteryx>rekado: hi! any idea why we don't see the greeter message when SSH'ing to berlin anymore? <apteryx>it was useful, telling people how to take care of keeping the system up to date. <mirai>sepi: idk, there's call/cc, call with escape and other sorts of stuff I've never heard about <mirai>I'm also not too sure whether or not things like call/cc, etc. play well within shepherd (guile-fibers) <sepi>mirai: honestly, I have no real clue about them. To me that's all magic I don't necessarily want to touch. <rekado>apteryx: must be a regression in login-pam-service <rekado>that one uses unix-pam-service to set up the motd <rekado>…are we even using login-pam-service when we log in via ssh? <rekado>the message is still here: /gnu/store/rx05dwn90qaa0wmq872prq1mljvxy2lq-motd <rekado>perhaps /etc/pam.d/sshd should also get: session optional pam_motd.so motd=/gnu/store/rx05dwn90qaa0wmq872prq1mljvxy2lq-motd <apteryx>ACTION sees PAM, sticks head in sand <apteryx>pam is used by default with the ssh-service-type in guix, unless that changed <apteryx>is pam_motd.so a builtin PAM module? <TristanCottam[m]>Dgraph's Go files are in a subdirectory. Should this be reflected by appending the subdirectory to the import path? And how can I instruct go-build-system to use this subdirectory for building? <apteryx>what can I read to get a grasp of how PAM/PAM configuration works? <apteryx>unchanged but with environment-variables reinstated at the config level <evilsetg[m]>@apteryx thank you for helping me the other day. It turned out, that the gpg-agent service that comes with guix only d3f <jpoiret>apteryx: looks like openssh-pam-services doesn't include an #:motd <evilsetg[m]>*defines a shepherd service if the ssh-agent option is set. So i will be using the gpg-agent shepherd service you send me. <apteryx>evilsetg[m]: so a guix-home related quirk? <apteryx>it'd be nice to make this easy for all users, if that's the case :-) <apteryx>I guess rekado's suggestion should do it (add a 'session optional pam_motd.so motd=/gnu/store/rx05dwn90qaa0wmq872prq1mljvxy2lq-motd' line to sshd's pam configuration) <evilsetg[m]>apteryx: Yes, if you do not want gpg-agent to manage your ssh keys, it does not run as shepherd service and is instead launched whenever needed. For me it gets launched in the first shell I start after logging in. <evilsetg[m]>I don't know if running gpg-agent as a shepherd service does solve the problem of accessing it in emacs but I will find out. <vagrantc>it took me embarrasingly long to figure out why sometimes sneek greeted me and sometimes not <g_bor>and can you share this surely enlightening insight? <g_bor>finally I managed to get a working irc client on this phone <g_bor>it was not so trivial to find something, the last one I used an my mobile is just gone... <ade>hello, i hope it's okay to ask nooby questions here <ade>so im checking if linux kernel binaries are avalible with this command: <ade>but when i try to reconfigure linux using this subsitute like this: <ade>it still tires to build linux for me <ade>sorry, the previous command was wrong <ade>i think it worked this time <ade>building /gnu/store/0m3xfj98wvh12n3c5h6zccpf1kcr9v09-linux-6.2.14.drv... <ade>| 'patch-source-shebangs' phase <rekado>you likely need to authorize the substitute server’s key first <ade>@rekado thanks for info <g_bor>something looks strange, is the matrix irc bridge down? <apteryx>I doubt so, there are 425 users in the channel <janneke>hmm, any way to get something like this to work? --without-stests=m4-boot0 --without-tests='(@@ (gnu packages commencement) m4-boot0)' <janneke>guess i'll have to edit commencement and use ./pre-inst-env <lemos[m]><zacchae[m]> "lemos: I think it should work so..." <- i did try that, but actually couldn't find this pre-inst-env <zacchae[m]>lemos: ./pre-inst-env is generated when you run either ./bootstrab or ./configure I believe <zacchae[m]>What even is /gnu/store/...gcc-11.3.0-lib? guix install gcc@11.3.0:lib prints "gcc-toolchain@11.3.0 lacks outpu lib", yet one of my packages in this shell refrences (and crashes on) gcc-11.3.0-lib. <zacchae[m]>Wait. 'guix install gcc' installs 'gcc-toolchain@11.3.0', but 'guix install gcc-toolchain' installs 'gcc-toolchain@12.2.0'. This is a bug, right? <mfg[m]>Not sure, but gcc-11.3 is the GCC used to build all the packages, while gcc12 is the latest packaged gcc <zacchae[m]>mfg: Oh no. The program I'm tring to package needs a libstdc++.so.6 with support for GLIBCXX_3.4.30. (the one in gcc-11.3 has up to GLIBCXX_3.4.29) <mirai>apteryx: re mpd, thanks! While working on this guile zoo that is btrfs-scrub-service-type ^^ I got some new ideas regarding the new 'update' action <civodul>ACTION tries 'mumi send-email' for the first time <mirai>I'll CC you later today (or tomorrow) an alternate implementation of some actions <apteryx>civodul: is your patch supposed to CC team members? This would be the full test :-) <apteryx>it should produce multiple X-Debbugs-CC headers, one per person CC'd. <civodul>turns out "mumi send-email" didn't see the cover letter arrive <civodul>so i eventually interrupted it, ran "mumi current NNN", and re-ran "mumi send-email"