<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 email@example.com, and can install it, but then deeptrack is not satisfied with the old version. Installing the newest
<weidtn>firstname.lastname@example.org 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 126.96.36.199 release, then you shouldn't have this problem
<weidtn>cbaines pretty sure 188.8.131.52 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
<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>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>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>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.
<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
<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.
<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"))) ...
<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.