<ulfvonbelow>what would be the best way to run a gexp in an isolated container with just its dependencies? <ric342[m]>Is stuff like a desktop environment in xorg working? <dirtcastle>I just read that I can use shepherd in guix home. does that mean, I can use shepherd as the init system on a foreign distro. <acrow>dirtcastle: Shepherd allows you to run guix services as yourself but the init system of the foreign distro continues to do what it did before. So it extends but doesn't replace. <raghavgururajan>Can we still use `(search-input-file %build-inputs "/lib/foo.so")` method or only `(string-append (assoc-ref inputs "foo") "/lib/foo.so")` method is preferred? <roptat>but I'm not sure you can use %build-inputs <roptat>no, assoc-ref expects two arguments. just drop it, it's just inputs: (search-input-file inputs "foo.so") <weidtn>Hello. I try to create my own package definition. The package python-deeptrack depends on python-scikit-image==0.18.0 and python-deepimagej, which itself depends on python-scikit-image==0.17.2. I defined my own python-scikit-image@0.17.2, and can install it, but then deeptrack is not satisfied with the old version. Installing the newest <weidtn>scikit-image@0.19 from official sources also does not help. <weidtn>Can anybody give me a tip how to solve this? <efraim>put the definition for your other packages in the file with python-deeptrack and use it there as an input. Guix doesn't care if you plan to provide it later, it needs to actually be in the build environment. <cbaines>weidtn, those requirements do indeed look incompatible. I'd look at the latest deeptrack release though, as it doesn't have a versioned requirement on python-scikit-image <cbaines>so if you get your guix package of python-deeptrack to use the 2.1.0.0 release, then you shouldn't have this problem <weidtn>cbaines pretty sure 2.1.0.0 still needs >=0.18.0. Where do you see that? <weidtn>efraim what do you mean? I already have definitions of python-scikit-image (0.17.2) and python-deepimagej in the same scm file as my python-deeptrack definition. *jonsger[m] enjoys the rust dependency hell while trying to update rust-cbindgen :( <efraim>weidtn: you mentioned installing them which isn't necessary for building a package. if you define the package as python-scikit-image-0.17 then you can use that package label as an input. otherwise it'll default to probably the highest versioned one <efraim>jonsger[m]: I think the debian folks figured out that the rust-cbindgen packages are pretty much interchangeable, and you _should_ be able to use just about any version, not only that specific version requested, if you adjust the Cargo.toml <weidtn>efraim still not sure if i get what you mean. If i do it like this I still get errors because both versions conflict <efraim>is there an older version of deeptrack that will accept the older version of python-scikit-image? <weidtn>Ah I finally found that the version recently was added. The release on Pypi does need it, on github it doesnt. So maybe I can fix it this way. Thank you for the input <jonsger[m]>efraim: I think you destroyed my motivation to update rust-cbindgen :P <efraim>jonsger[m]: on one hand we can (probably) dump a bunch of old versions, on the other hand it's going to need to be updated someday ... ***Dynom_ is now known as Guest8965
<efraim>jonsger[m]: if it makes you feel better I might've been thinking of bindgen instead of cbindgen :/ <unmatched-paren>that way your program/whatever will be portable to all three of seatd, elogind, and systemd <ncbfg36>I'm having trouble getting fonts to display properly. I am after glyphs from Google material design fonts. I have the latest .otf files for the set in ~/.local/share/fonts/ and I've run fc-cache. When I run gucharmap, some of the glyphs show, some are still tofu. With the ones that do display in gucharmap, some display in other programs, some don't. For example, wifi signal glyphs, half display correctly, <ncbfg36>half just show a blank space (polybar). The ones that do show in emacs, some look right, others look mutated and washed out. I sent my config to polybar dev and the fonts all displayed as expected for them. So i'm wondering if i'm missing something specific to Guix <unmatched-paren>ncbfg: Maybe it'd work better if you made a package for it using font-build-system? <zamfofex>SAIHAZE[m]: What do you mean by “binary patch”? You mean a patch that makes use of pregenerated binaries? Because if so, then I don’t think so. <ncbfg36>unmatched-paren: yes I have tried that package. It seems to be missing just about every glyph I search for (using codes from googles page) <zamfofex>ric342[m]: I had little success using Guix with the Hurd (on a VM and otherwise) for anything graphical. The biggest issue I had were lack of substitutes and unsupported packages. I have since wanted to try to set up a substitute server for the Hurd, but I couldn’t manage to figure out how. <ncbfg36>unmatched-paren: reading the docs, all that font-build-system does is copy the font files to expected directories. Running fc-cache -v shows that it is finding the files in .local/share/fonts/ so i'm not sure that would help <ncbfg36>unmatched-paren: i'll try that. I thought that's what fc-cache does <ncbfg36>no that didn't help either. Many glyphs from the font show as tofu in gucharmap <ncbfg36>if NONE of them showed up that would be one thing, but some do, some don't. Some display correctly, others dpn't <ncbfg36>Currently i'm on minimal system config with %desktop-services, stumpwm and emacs. Maybe i'll try installing full gnome and see if it works then <zamfofex>ncbfg36: Maybe there are other fonts taking precedence over the icon one. <ncbfg36>zamfofex: possibly. But why would they all show up as tofu? And half the ones that do display are disfigured <baconicsynergy>hello friends. Rekado told me how to properly build the locales from glibc-locales, using the following command: guix build -e '(begin (import (gnu packages base)) (make-glibc-utf8-locales glibc #:locales (list "de_DE") #:name "my-locales"))' <baconicsynergy>Once the derivation is built, how do I install it to my profile? <zamfofex>baconicsynergy: Also, I’m not sure about how relevant it is to you, but you can pass in store paths to ‘guix install’ <zamfofex>I’ve recently decided to pick this back up again: <https://issues.guix.gnu.org/53414> (i.e. updating Node LTS), though I’m getting some test failures for some ‘parallel’ tests, which I assume might be nondeterministic. What should I do about this? <baconicsynergy>woah, I can just paste /gnu/store/asdf.drv at the end of guix install? sweet! thank you so much! <zamfofex>The failing tests are: “parallel/test-http-missing-header-separator-cr” “parallel/test-http-transfer-encoding-repeated-chunked”, “parallel/test-http-transfer-encoding-smuggling” and “parallel/test-release-npm” <zamfofex>In particular: Is it fine to simply patch those tests out? It is really frustrating to work on it, because building Node took multiple hours for me, so it’s really unfortunate to have to wait again. <zamfofex>I wish phases could be able to be cached, so that if a phase is unchanged and the files it is to operate on are also unchanged, then it could reuse a previous output. <zamfofex>But I ackonowledge that might be nontrivial. <zamfofex>baconicsynergy: I don’t think you can ‘guix install’ ‘.drv’ store files to your profile, but rather store directories. <zamfofex>baconicsynergy: With that command you shared, you should be able to pass the very last line to ‘guix install’. <zamfofex>The one below the green ‘successfully built /gnu/store/…-my-locales-2.33.drv’ <zamfofex>Conversely, you can generally just do: guix install $(guix build …) <baconicsynergy>It worked!! Thank you very much. I've learned a lot this morning already <zamfofex>You’re welcome! I’m glad you managed to get it workin in the end! 🎉 <baconicsynergy>No more locale problems with my installed software is a beautiful thing <baconicsynergy>I was having some problems with a couple ones for some reason. That was the last hurdle to using guix properly and effectively <baconicsynergy>I've never really known how just how important settings locale is. falling back to "C" doesn't always work <muradm>fgrep -r package-with-extra-patches * gave no out put <muradm>what should be the list of extra patches? <nckx>muradm: Your grep is faulty. <muradm>nckx: just for illustration purposes, i use ripgrep from emacs actually :) <nckx>Anyway, same as a (patches ...) field elsewhere: usually, the output of search-patches. <nckx>If it gave no output it's still faulty. <nckx>The definition is in (guix transformations), there seems to be a use in (gnu packages cross-base) which... uses search-patches, actually. <ric342[m]>zamfofex: I'm trying right now to make a vm, having trouble as well, do you have any examples I could look at? <ric342[m]>error: %desktop-services/hurd: unbound variable <ric342[m]>guix system: error: no target of type 'session-environment' for service 'network-manager' <nckx>muradm: search-patches seems to be a superfluous synonym for LIST here but otherwise looks OK? <nckx>search-patches turns relative file names in a search path into absolute ones; you're already giving it absolute ones, hence a no-op. <nckx>Patches should be a list of strings. <nckx>(patches (list "/foo/bar")), keep it simple. <muradm>nckx: i tried many things, none worked, i suppose it is because (inherit (package-with-extra-patches ...)) <muradm>some times it becomes to weird then too much inlining <nckx>Just because us humans are easily confused. <nckx>I don't have a REPL handy. <muradm>(local-file is needed by the way <nckx>I'm going to try this out when I do have a REPL. <nckx>Inheritance should work. <nckx>muradm: OK. I misread the 'error' then. Agreed it's too cryptic, most Guix 'errors' are. <parallelepiped[m>Hello! I am now getting an error when reconfiguring my Guix Home config even though I think my config should word: ERROR: 1. &message: "unsupported manifest format". <tissevert>hi ! what makes you say it should work ? has it been known to work before ? <parallelepiped[m>It's probably an error with my system (Trying updating Guix). Non of the Guix Home commands work <tissevert>ah, now that's a good clue there's something wrong ^^ <rekado_>parallelepiped[m: what does ‘type guix‘ reveal? <rekado_>do you have ~/.config/guix/current/bin/guix? <tissevert>so I suppose you could simply use the system's guix to repopulate that correctly ? <rekado_>parallelepiped[m: this means that you’re using an older guix (the one at /run/current-system/profile/bin/guix) to work with a newer type of Guix profile. <rekado_>you might still have the newer guix somehere in /gnu/store, or even in /var/guix/profiles/per-user/parallelepiped/current-guix <tribals>There is a `clang-toolchain`, but seems like it has `ld`. How to get one with `lld`? <tribals> ("ld-wrapper" ,(car (assoc-ref (%final-inputs) "ld-wrapper"))) <tribals>Particularly, from source, eg. manifest.scm <civodul>rekado_: the other day you mentioned M-q not working for synopses: i've been observing the same here since switching to Emacs 28 i think <sneek>civodul, you have 1 message! <rekado_>civodul: apteryx brought it up with the Emacs folks and they said the new behavior is not a bug ¯\_(ツ)_/¯ <rekado_>so apteryx changed our .dir-locals.el to bring the old behavior back. <civodul>actually M-q is paredit-reindent-defun, so maybe the bug's in paredit? <tribals>`$ guix build clang-toolchain@14 --with-input=ld-wrapper=lld-wrapper` doesn't work either: <tribals> /tmp/guix-build-file-5.39.drv-0/file-5.39/src/.libs/file: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory <muradm>guix deploy --dry-run ... => guix deploy: error: dry-run: unrecognized option => huh? <muradm>absence of dry-run is very upsetting.. <civodul>muradm: yeah we should do something about it <civodul>what would dry-run do exactly? display the list of machines? <muradm>civodul: i would expect it to build all things locally, and say that these and these things built, if not dry run would be sent to there and there <civodul>muradm: see, i wouldn't expect it to build anything (other commands don't build anything on --dry-run) <civodul>defining what "dry run" means is tricky in this case <rekado_>guix deploy also doesn’t necessarily builds systems on the local machine. It depends on settings. <efraim>I still haven't actually used guix deploy <efraim>I should backup my keys on my pine64 and experiment with it at some point <vagrantc>with guix deploy, you need to have enough guix already installed for it to run? *vagrantc also hasn't tried it yet <cwebber>muradm: "guix deploy" could use a lot more love :0 <cwebber>it could also use a champion, I think. <efraim>phase `strip' succeeded after 1239.2 seconds <muradm>i have few servers set with guix deploy may be a year or so .. :) <muradm>but when i come back to them always fall back to --dry-run trap :D <efraim>it might be time to champion my parallel strip patch again <muradm>civodul: i don't feel it very tricky.. as it says "deploy" it will connect and sideeffect somewhere. so not doing that would be good "dry-run" <muradm>by build i ment all derivations whatever is comming out of that list of machines <muradm>rekado_: definetly, but the point is in the end of the day it will do "guix deploy: sending 3 store items .." thing <muradm>rekado_: you mean build remotely on machine. <muradm>still after those "items" are ready to be "applied", this is the point where dry-run kicks in <muradm>on the other hand, after few deploys, dry-run does not seem necessary <muradm>or i just get used not scare a lot as it is missing anyway :D *raghavgururajan is back on XMPP <unmatched-paren>perhaps it could be called `--build` or `--local` or something instead of `--dry-run` <unmatched-paren>because it would be quite unlike other dry-runs, as civodul points out <vivien>I’m trying to fix bash cross-compilation failure but it’s a pain. It is so far in the dependency chain that if I change the package definition, guix has to recompile a lot before it can compile bash-minimal for real <efraim>Initial rust support for riscv64-linux is now in staging! Just need to see how the test suite fares on 1.57. <efraim>aarch64 is supposed to work, I think the blocker there is the 8+GB of ram during the build phase <efraim>x86 actually needs some tweaks now due to x86_64 optimizations <efraim>and probably needs the ram consumption brought down to the 3GB range <muradm>unmatched-paren: by that logic it could be a lot off options like --only-check-syntax, --no-send, --just-build :) <muradm>no options seems to be good enough also <efraim>we also now (in staging) bootstrap straight to 1.54 <efraim>new versions can be added straight to master, the rust variable used for building everything is pegged at 1.57 and can probably be bumped on staging <unmatched-paren>i wrote the patch for 1.57 and I would not like to go through that process again :) <efraim>it looks like our current commit for mrustc has debugging symbols enabled by default. turning those off should help with the RAM usage <zamfofex>ric342[m]: Could you share the file describing the OS you are trying to build? Here’s an example that seems to work well for me: <https://paste.debian.net/plainh/47d6ecba> (i.e. ‘guix system vm’ starts to run and build stuff, but I haven’t let it finish yet) <apteryx>civodul: hi! paredit (24) just calls lisp-fill-paragraph, so the bug is really in Emacs <apteryx>but in the latest commit of paredit, it at least honors the fill-paragraph-function *variable*, which means you can set that to something else, such as the lisp-fill-paragraph version that was shipped with Emacs 27. This is what commit a2397e0ecda6b07a05d911ee6a614c41c19d052f does. <apteryx>I meant, commit c9fb789fe9eaa5dc0694ef14fe36e5aa821a646c <storm>whic laptop vendors has supported guix and *apteryx tests building Guix with /bin/sh linked to dash and export SHELL=/bin/sh <storm>Lenovo thinkpad t 440 p which is I use this laptop <zamfofex>storm: You could try booting into the live image and seeing if it works, I think. <raingloom>storm: i doubt any vendor supports guix, but guix does run on laptops by some vendors. i run it on a Thinkpad T400 and an MSI Wind P100(?). <gabber>rekado_: i saw, thanks again! not yet, but i have some things in the pipeline.. :) <ric342[m]>zamfofex: I just tried the one you showed, unfortunately it failed at this point <ric342[m]>build of /gnu/store/cjl2vwcj1fscb5b54vid3hadbsmvjcly-hurd-0.9-1.91a5167.drv failed <ric342[m]>Haven't managed to get a service like slim login manager or a desktop environment to allow it to build <ric342[m]>Basically trying to get something with xorg going <ric342[m]>Actually it looks like slim and gdm are not available for hurd <ric342[m]>dwm apparently however it still fails to build <bdju>does anyone else have really high CPU usage from mpv just being open with any file? I think I mentioned it a couple weeks ago in here but no one else had run into it <bdju>like just opening something paused brings my CPU temp up into the 90s and my CPU usage graph spikes in bpytop <zamfofex>ric342[m]: Maybe you could try to build plain Xorg for it, then just see if you can use ‘startx’ or ‘xinit’. That’d be a good first step before trying other more complex packages. <bdju>I do remember I tested with ffplay on the same files and there weren't cpu issues there at all. and none of my mpv settings are too crazy. I believe it was an update that brought the issue <roptat>bdju, it does that for me too, but only when playing, the CPU goes down when I pause <roptat>probably because it's software decoding, it needs some power while playing <bdju>storm: everything on T440p should work besides the wifi, I am using a T440p <bdju>yeah the high usage when paused is a somewhat new issue. last couple months maybe <bdju>I did have problems before that with weirdly high usage and frames dropped while playing back hevc videos. people with older/weaker CPUs would tell me the videos played fine for them, but I never could figure out the problem <roptat>mh, I'm not completely up to date, maybe I haven't hit that yet <storm>oh I am going to try guix on my machine but first I need test on VM <civodul>apteryx: re paredit, thanks for explaining! <civodul>apteryx: re AC_SUBST_NOTMAKE([SHELL]), i think it's okay; another option would be to force use of Bash, with AC_PATH_PROG([BASH], [bash]) SHELL="$BASH" or some such <muradm>in simplified (inputs (list coreutils (bind "utils"))) how to get utils output of bind ? <muradm>or should i fallback to legacy way of specifiying dependencies? <muradm>and then how do i get it form (lambda* .... (let ((bind-utils (assoc-ref inputs "bind"))) ... <muradm>ah i see (inputs (list `(,bind "utils"))) <johnjaye>scheme feels like it has less of a "bootstrapping" problem than c or c++. like if i learn more scheme i feel i can read more code. <johnjaye>but with like c++ it's like you have to learn the entire language at once before you can read production code <zamfofex>johnjaye: I think that makes sense. I suppose it is related (though not quite the same) as a learning curve. <muradm>(substitute* some-file (("| tr") (string-append "| " coreutils "/bin/tr"))) produces very weird recursive output :) <zamfofex>civodul: Is there any chance you have recently had the time to look at my glibc patch? Also, do you perhaps feel like it makes sense to indeed wait until August for the next glibc update before taking a look? <johnjaye>zamfofex: like i've opened c programs like bash for example where page 1 like literally main() has some really obscure feature i have to stop and go look up <johnjaye>i suppose scheme could use continuations or something convoluted right out of the gate as well <zamfofex>Bash (and other GNU tools) are oftentimes not a good place to look at when trying to learn, I feel.