IRC channel logs
2024-10-05.log
back to list of logs
<weary-traveler>what's the correct way to ensure that at the runtime for a package SSL_CERT_DIR and SSL_CERT_FILE are correctly set? IIUC, adding nss-certs to propagated inputs isn't enough. is my understanding correct? <meaty>If you set your source for the guix channel to a git checkout, will "guix pull" also pull down changes into the local git repo? will it clone it to the store and then pull? what happens <podiki>meaty: no, guix pull just updates the local guix (program and package definitions) from the repository specified then, ignoring upstream guix <podiki>in other words, it replaces completely the default guix repo <podiki>though there is always a local checkout of guix tree <tomato28>so native-inputs is packages needed at build time, inputs is packages installed in store and available at build but not in profile. How do I get packages into the packages profile? <podiki>all inputs are available at build <podiki>native-inputs are for ones that need to match the building architecture as opposed to the target one (e.g. cross compiling, if i got my terminology right) <tomato28>im uhhhhh, struggling with syntax atm (propagated-inputs (list `((openjdk17 "jdk") ("jdk" ,icedtea "jdk")))) <podiki>(list "(,openjdk17 "jdk") "(,icedtea "jdk")) i believe <podiki>` is saying to quote (not evaluate as variable) so you need , to tell it that this next thing should be evaluated (to get the package variable) <podiki>while the "jdk" is to specify the output, as a string (don't evaluate) <podiki>or, (list (list openjdk "jdk") (list icedtea "jdk")) i believe <podiki>(the comma after or is not part of the code) <tomato28>I feel like typing out list like you just did is so much better for noobs trying to read packages <tomato28>I get that its a simple language feature you get used to <podiki>until you do it like 3 times and then you'll be tired of it :-P though you don't need it much usually <podiki>so i haveta think every time i do it <tomato28>still, its the difference between a noob making perfect sense of something and having to google something thats hard to google <podiki>i guess the thing to remember is that inputs are a list of either a package variable or a list with a package variable and string for which output <podiki>probably complicated by the fact that it all used to be different (and more repetitive) <podiki>so you'll see the old style ("somepackage" ,somepackage) <podiki>maybe more confusing if you're not coming from the previous style, but still maybe helpful to see some explanation <tomato28>also, how can I see which version of the package in my store is the one that was added to the packages profiel <tomato28>okay, I was able to patch the application to include the other java, and if I manually browse to the store java bin I can successfully use it now! <tomato28>so, is there a way to put the binary somewhere manually? <tomato28>I have the odd edge case of using a java21 application that needs to run java8 and other versions <tomato28>I got java.io.IOException: Too many open files <tomato28>how do I change ulimit in a guix package :o <meaty>what is the guix equivalent to the 'gtk3' package? <nutcase>Hi. I'd like to modify extending files in /etc/pam.d/. How are these files created? <gerogaga>Hello, I was wondering, is there a module which would allow me to hook into guix shell? <nutcase>lilyp: you mean the pam-root-service-type, right? thank, I need to figure out, how to use this / the pam-root-service or its transfomers, probably <Rutherther>nutcase: btw if you are after a working pam screen locker, there is screen-locker-service-type. If not, you could also use that as an example at least. <nutcase>Rutherther: thanks, I think I'm not working directly on a screen-locker (but want to modify it), my swaylock works generally. I'm working on a first-world-problem, my fingerprint reader. Thanks to your hint, I now got that far :https://paste.debian.net/1331369/ <nutcase>However, I'm not a guix/guile/scheme expert and don't expect that this works. Maybe someone can give feedback? <dariqq>is there someone i should ping for a llvm@15 build failure on i686? It is blocking a lot of qt/kde stuff <civodul>probably we should just do #:validate-runpath? (not (target-32bit?)) for now <dariqq>civodul: Ah didnt see that and I created a duplicate issue the other day (how would i mark it as duplicate?). I encountered it because i wanted to switch back to %desktop-services which includes sddm . The llvm@{16,17,18} packages remove the make-dynamic-linker-cache entirely already <civodul>dariqq: oh, well i guess we could do the same for llvm@15, just make sure there’s a link to the issue above <civodul>so we eventually come up with a proper fix <dariqq>I think all llvm packages are inheriting from the llvm-15 package , so should be enough to do it only there <dariqq>(and i just noticed that the qt5 version of sddm is available) <apoorv569>not sure why its not showing inline.. I sent the patch as attachment. <ekaitz>apoorv569: i think that's how our issue system works <apoorv569>ekaitz: What do you mean? I have sent patches before they show up inline always. <ekaitz>nah forget it i didn't understand well what you meant <ekaitz>sometimes it is shown inline when you attach it, yes <apoorv569>Well, I guess people have to download the patch in this case. <apoorv569>I can make any adjustments needed, I would like the 2 patches and others possible to be merged as soon as possible. <dariqq>hmmm even after setting sddm to sddm-qt5 something else is still dependending on the qt6 version <dariqq>there are a bunch of other fields that use the sddm packe (for the config file). After replacing all of these with the sddm-qt5 version things are happening now <apteryx>was there nota commit that made (guix build utils) always part of the origin's snippet environment? <apteryx>civodul: hi! perhaps you remember some change about (guix build utils) becoming always available for source snippets? <apteryx>lilyp: I've addressed most of your comments for the jgrf (jollygood) + emulators series; is it good to go? <apteryx>I'll push it now, if there's anything else, I'm happy to fix it. <lilyp>haven't seen v4, but I assume it's good to go <panosalevro>Hi, any idea what causes this error when I do a system reconfigure? -> guix system: error: symlink: Permission denied: "/var/guix/profiles/system-28-link.new" <panosalevro>(that's what happens when you do a system reconfigure after 3 months) <weary-traveler>package $foo that uses copy-build-system, installs a script that depends on git. ensuring that the git reference points to the store during a build phase seems to work. however, at run time the script fails because it's unable to find the ssl certs. adding both git and nss-certs to propagated inputs is sufficient to resolve, but seems like overkill. what's a better way? <weary-traveler>specifically, it seems that it shouldn't be necessary to have to include git in propagated-inputs <nckx>weary-traveler: How are you testing this package? In a guix shell? <weary-traveler>nckx: pure shell, loading a profile with package installed. well that and bash <nckx>Right, good, I wouldn't have expected it to fail outside of one. Does adding nss-certs to the shell command line fix the issue? <nckx>Certificates shouldn't be 'bundled' with packages as inputs, they are OS-provided. If adding them to the shell doesn't work, you'll need to add $SSL_CERT_FILE and/or $SSL_CERT_DIR (I'm not 100% on what exactly is the most korrekt) search-paths. <weary-traveler>nckx: let me test what happens when i remove nss-certs and git from propagated-inputs, and add them to the profile when testing. back in a moment <nckx>Patching git to point to the store (NOT propagating it) was a good move. <nckx>See cmake-bootstrap for a search-path example. <nckx>Yes, the Scheme variables have an $ in them, it's cute. But they are just convenience variables pointing to a search-path record. <weary-traveler>adding simply nss-certs in profile isn't sufficient. seems either one of the SSL_CERT_DIR SSL_CERT_FILE or GIT_SSL_CAINFO is what i need to set <weary-traveler>hm it's adding those entries to native-search-paths. i'm not sure i understand what that's supposed to be doing <nckx><what that's supposed to be doing> Declaring to Guix that it should set those environment variables when a package, here nss-certs, contains directories 'claimed' by those records (which you can find in (guix search-paths) if you care). <nckx>ACTION still technically away. <nckx>But the package has to be present in the profile, e.g., by adding it to the command line, it is (by design) not an 'input' or 'dependency' or whatever. <weary-traveler>nckx: okay for some reason we don't want nss-certs to be in the inputs. i don't understand why, but we can come back to that later. first, it seems adding those variables to native-search-paths does the trick, but if they are added to search-paths it doesn't work. could you please help me understand what the distinction is? <Rutherther>weary-traveler: because it's up to the user of the package / system administrator to choose which CA's to trust, not up to the packager, so it should be selected system-wide / by configuration, not by package itself <weary-traveler>and the native in native-search-paths is making me wonder if that has the right behavior when cross-compiling <weary-traveler>Rutherther: okay, fair. that answers the "for later" question. any insights to the other? <Rutherther>I am not completely sure. I think that if you do guix shell it implies to be a native, so that's why native search paths are needed here. As for cross compilation, I think native-search-paths won't be used anymore, and you might have to put the same search paths also to search-paths. But as saying, I am not completely sure, I haven't grasped the native vs non-native search inputs fully yet. <weary-traveler>seems the difference in the two is precisely the directory argument that gets passed to set-path-environment-variable <weary-traveler>and cmake-minimal-cross explicitly sets native-search-paths to nil and sets search-paths to the native-search-paths of cmake-minimal. i didn't realize one needed to define distinct packages to support cross-compilation <nckx>That is not something you should take away from this. Anyway, I never remember the difference between {native-,}search-paths either. <weary-traveler>nckx: at least in gnu-build-system (which copy-build-system inherits) the difference seems to be whether set-path-environment-variable is receiving input-directories or native-input-directories. the code seems straightforward, but what's unclear is why input-directories don't work as intended <weary-traveler>or is it as Rutherther implied, and the variables need to be added to both native-search-paths and search-paths to cover the guix shell situation as well as others <ieure>Does anyone have a reasonable Xorg setup without video tearing on an Intel GPU? I have this in my xorg-configurations extra-config, but the video still tears: http://paste.debian.net/1331429/ <ieure>I don't want to use a compositor to fix this, both compton and picom have been extremely buggy in my experience and are worse than the tearing video. <ieure>I see in my Xorg log that it's loading the intel module and picking up the TearFree option, but the video still tears. <fnat>In a nutshell: 'Using 'hatchling.build' to build wheels ... fatal: not a git repository'. <fnat>If I use '--keep-failed' and explore the build folder, I can see there's no '.git' directory. <fnat>Could that be the issue? Am I supposed to download the source differently? <fnat>I might have to use 'git-fetch' instead of 'url-fetch'? <luca>Is this a way to return a list? Like (list ("" ,sway-like) ("" ,object)) ? <fnat>Hi Luca, yes, that's correct. It's like '(list (list "" sway-like) (list "" object))'. <fnat>Hm, 'git-fetch' also fails, for the same reason: no '.git' folder. <luca>I tried adding a bunch of config files using local-file with a map, but I am getting a `guix home: error: duplicate 'name' entry for files/`. As far as I can tell there are no duplicate files, so I am not sure why this is <fnat>In other words, '`((,name ,(local-file ...)))'. <fnat>Or, '(list (list name (local-file ...)))'. <luca>maybe one too many parantheses? <fnat>luca: I'd try a simplified version, with a single config file. I'd double-check the (relative?) path too. <fnat>luca: I have something like '(service home-xdg-configuration-files-service-type `(("emacs/init.el" ,(local-file "emacs.el"))))'. 'emacs.el' is in the same folder as the 'home-environment.scm' file (hence the relative path). <fnat>Anyone familiar with the pyproject Python build system and 'hatchling.build'? I'm getting this error about a missing '.git' folder, is that expected by hatchling? Any common way of approaching this? <fnat>luca: Could it be because of a wrong relative path? <fnat>Wait, let me have a closer look. <luca>For what is worth I am using `guix home container home-configuration.scm`, so I hope that isn't having weird side effects <fnat>luca: I think you might have to get rid of 'string-replace-substring name'? <fnat>And simply use 'name', which is the config file's relative path. <luca>If an object store name has a "." in it then it is considered invalid. So for example `error: invalid name: `.xinitrc' for `((".xinitrc" ,(local-file ".xinitrc"))) <fnat>I didn't know about 'assume-source-relative-file-name', but it seems you may just need that, with no second argument at all? <luca>I can actually remove the whole assume-source-relative-file-name and the error stays the same, just with a bunch of warning: resolving './.config/xresources' relative to current directory <luca>(I am lowkey considering writing a shell script to write me the lisp code for this instead of learning map) <nckx>As you're probably aware, all MAP does is call your procedure on each element in the list, in turn. Test your lambda first, ideally in a Guix REPL, to remove at least the outer brackets and to reduce the pointless verbosity of error messages. Once the output looks good for a single input, you can add back the map. <nckx>And then, I dunno, maybe add each element back one at a time, in case the problem really isn't your lambda but a single bad apple of an input. <luca>A mix of `/` not being allowed in store names as well as find-files picking up symlinks <luca>(also an extra paranthesis somewhere of course :P) <bigbookofbug>hi all, i submitted a bug report but wanted to report it here as well, the lsof update is causing the check phase to fail on my system <luca>What home service provides the .profile file? <bigbookofbug>reverting to eff3ff9878c7225351650bf967c9a8de3869e919 allows me to update, so i know its one of the most recent 3 commits <PotentialUser-58>Can anyone recommend a way to synchronize dotfiles? The chezmoi package is terribly outdated. <luca>At least that's what I am trying to use right now and it seems like the right tool for the job <ekaitz>PotentialUser-58: i use stow but in guix, guix-home should be the way to go <ekaitz>but i guess you need chezmoi because of the encryption features <ekaitz>which you don't have with stow, of course <PotentialUser-58>luca I am still to new to Guix. Guix home seems a bit scary to me. Is it as complex as it looks? <luca>I am also very very new and uhhh, yes. <nckx>bigbookofbug: Hmm. I can't reproduce this at all, on 2 different systems. <nckx>But ‘LTlock’ sounds very familiar, I think it (consistently) failed for me when trying to update lsof, in the past. <PotentialUser-58>ekaitz I don't expect to store the files outside my home. But chezmoi is a tool built for this purpose. <sepeth>PotentialUser-58: depends on how you look at it I think. I am also new and I find it simpler than any other distro I tried. But programming is my day job, so I like to look at the source. Guix is simpler to me than Nix or Debian or Gentoo. One of my favourite thing is that guix is everything mainly in one repo and in Scheme and I can look at how things work easily, or bend it to my will when things doesn't work for me. <sepeth>I chose the word *simpler* deliberately. <luca>I'm not sure how relevant that is for dotfiles <sepeth>Oh true, I was commenting generally, but syncing home wouldn't differ much between distro I would guess. <sepeth>It may even be simpler on guix perhaps due to guix home. <nckx>bigbookofbug: I'm heading off to bed now, but which file system is your /tmp? And why aren't you getting a substitute from ci.guix.gnu.org? (If you disabled it on purpose, that's fine, but otherwise you shouldn't have needed to build it at all.) <sepeth>My bad, I read "Guix home seems a bit scary to me" as "Guix seems ...". Late night here in Cape Town ^-^