<str1ngs>hmm I would think figuring why there is such a huge conflict
<str1ngs>maybe remove from gtk-icon-themes that which provided by the other package?
<str1ngs>assuming the packages don't conflict completely
<leoprikler>it appears as though gtk-icon-themes pulls in all the icons from all the icon themes and then generates a cache (this cache is what we actually want)
<leoprikler>problem is, the files themselves are not discarded afterwards, even though they probably should
<str1ngs>I sometimes wonder if it would be feasible to run hooks more lazy. so as some background process. but I don't know if that is technically feasible. since I run into this same issue with mandb generation
<leoprikler>you're probably also thinking of parallelizing them, aren't you?
<str1ngs>guix has no notion of a user service which would be really nice. maybe slightly offtopic for your issue
<str1ngs>I think parallelizing them is overkill. more like make non blocking
<leoprikler>I mean parallelize in the sense of hook #1 and hook #2 can run in parallel
<pkill9>happy new year, i hope this year brings many new advancements to Guix :)
<leoprikler>for what other reason would you do non-blocking?
<pkill9>I am confident that such hope is not needed
<str1ngs>leoprikler that could work though and avoid the back ground process
<str1ngs>well in the case of mandb the probability of using the mandb right after creating the profile is slim next to nill. so your terminal is blocked but probably for good atomic and locking reasons.
<leoprikler>As far as conflicts are concerned: I think many of them can be ignored safely.
<leoprikler>E.g. consider a split, where you have info-reader in two profiles, because that's how you get INFOPATH set up.
<leoprikler>There's no harm in taking either info, as long as INFOPATH is set correctly, which it would be.
<leoprikler>sneek later tell raghav-gururajan I fixed the icon problem by adding hicolor-icon-theme to my local profile, but that's weird, because it even fixed system icons for me and should also not be required. How did we get here?
<str1ngs>leoprikler: also I think fast nvme hide some of these performance issues
<nckx>leoprikler: No harm, but would it be transparent to users how this choice is made and how/if they can affect it? And I mean intuitively, not ‘by retracing the code that’.
<leoprikler>Perhaps we can make it so by enforcing some ordering.
<leoprikler>We already have current/channels as "the last to be added" = "the first in PATH", so adding constraints on top of that should not be difficult on a philosophical level.
<leoprikler>It may be a pain to write the shell script that does that, though 🙂️
<str1ngs>I think this just skirts the real issue that environment variables do not scale well also trying to still maintain some an hence FHS is an uphill fight. guix and nix need a more top down solution to this problem
<sneek>Welcome back raghav-gururajan, you have 1 message.
<sneek>raghav-gururajan, leoprikler says: I fixed the icon problem by adding hicolor-icon-theme to my local profile, but that's weird, because it even fixed system icons for me and should also not be required. How did we get here?
<raghav-gururajan>sneek: later tell leoprikler: I think I found the issue. The package "adwaita-icon-theme" suppose to take care of icons. But the package definition has an argument not to create icon.cache. So we might need to remove that argument.
<sneek>Welcome back leoprikler, you have 1 message.
<sneek>leoprikler, raghav-gururajan says: I think I found the issue. The package "adwaita-icon-theme" suppose to take care of icons. But the package definition has an argument not to create icon.cache. So we might need to remove that argument.
<leoprikler>So I'm not sure whether adwaita-icon-theme is sufficient
<leoprikler>it also does not appear to work when i put hicolor in my system config, but maybe I would have to reboot for that, idk
<leoprikler>adwaita-icon-theme has Adwaita only (who would have thunk?) but XDG says hicolor must exist
<kirisime>I'm not sure how to work around software assuming such traditional stuff is present, but maybe you can pull your dependencies into a guix env and set LD_LIBRARY_PATH to $GUIX_ENVIRONMENT/lib
<brown121407>kirisime: problem seems to be that Haskell's stack calls ldconfig whenever I want to do something like install a package. I see stack has Nix integration. I don't know much about Nix but I know Guix is based on it. Therefore it should be possible to build a Guix integration for stack. I'm going to look a bit into it, though I don't think I'm capable of doing a such thing, so that may turn into a feature request for stack
<nckx>brown121407: Some Guix packages set LDCONFIG=true (as in, the ‘true’ command, doing nothing); can you tell Stack something similar?
<leoprikler>Last time I checked, we were still a bit unsure of what v2 should actually be. The problem it tries to solve is the (optional) dependency of both evolution-data-server and gnome-settings-daemon on gnome-online-accounts.
<leoprikler>well, maybe not gnome-settings-daemon, but the GNOME Settings, which appear to be a superset of it?
<raghav-gururajan>Yes, even I am not sure. I just need time. Currently, I am trying to finishing gnome core packages. I think it's better to have all the components and then analyse how they are linked/work.
<raghav-gururajan>As soon as I finish 4/5 more packages that I am currently on. Debugging those things we discussed going to be next work. :-)
<nckx>raghav-gururajan: By the way, the convention is ‘* foo.scm (bar): Blah.’, not ‘(bar). Blah.’
<nckx>Let's not discuss the grammaticality of capital letters after colons and blindly accept this dogma.
<nckx>gitlab.gnome.org is heavily overloaded or otherwise malfunctioning here so I'll be back later.
<oriansj>the only thing you need to remember about sshfs is: sudo sshfs user@server:/path/to/folder /mnt/path/ -o allow_other,IdentityFile=/home/user/file
<str1ngs>I need to update a patch in a series is it possible to auto format the changes? ie * gnu/packages/gnome.scm (gnome-themes-extra)[arguments]: Disable cache file from configure flags. looks auto generated but I'm not finding the yasnippet that does this
<nckx>raghav-gururajan: There are people who think that every GTK package with a 3.3x version number needs to be updated in one grand GNOME ta-da. I disagree with those people. Unless it breaks something, I'll upgrade ‘GNOME’ things I use (like simple-scan) without waiting on the rest.
<civodul>specifically, the output of "guix describe" and the "guix build" command to reproduce
<leoprikler>NieDzejkob: Well, I haven't had any problems with Arch either, so I probably should not joke like that. However, for some reason Arch has this image, probably because its wiki and forums are a source of every failure you will ever encounter on any other system.
<nckx>raghav-gururajan: Stating ‘DE's are supposed to be cross-platform’ as fact is flame bait, but I'm not biting 😉
<rekado_>I have a hard time paying *enough* attention to the few mails I get to read :-/
<ixlun>Specifically, the test that's failing on my machine: "Failed test 'Don't crash on partial pixmap data'"
<lispmacs>reading about guix challenge... does your local store somehow remember whether packages were built locally or downloaded from a certain substitute server?
<rekado_>in other news, Gnome broke on the T60 that I upgraded today. It crashed *while* I was using it, 20 mins after the upgrade, just after I decided that it worked fine and I could GC the old system…
<rekado_>tried to use MATE then, but it’s missing glib:bin at runtime as it uses gio-desktop-launch to run programs
<rekado_>then noticed that I have no idea how to use ibus with MATE
<rekado_>but we’re a good chunk into this century already
<nckx>pkill9: It's not the same generation, but the X230t I bought last year came with a perfect (vintage) battery and runs for ~6 hours of normal use. Just don't compile anything on the road, but then most ‘power efficiency’ improvements since then are of the ‘do nothing, better’ variety anyway.
<NieDzejkob>(ignoring the pedants that consider the decade to start in 2021)
*rekado_ moves all data from the T60 to the workstation that had a successful Gnome upgrade…
<ngz>Anyway, for something different, I have a question about Python packaging. I have a Python package who installs executable in "$out/share/bin/". If I create a symlink in $out/bin/, wrapping magic doesn't happen and the executable fails because it cannot find other libraries. If I copy the executable in $out/bin/, it cannot find its own data. I'm sure that's pretty trivial, but what would be a way out?
<str1ngs>personally I think guix build -l defined.scm -e "vim bash" is a better approach then -f
<kiwi_694>so how do you guys make changes to the packages in source and then test them?
<leoprikler>NieDzejkob: In your example, you could use a substitute* that matches either form, i.e. one line with single quotes and one line with double quotes
<NieDzejkob>Is there an equivalent to Debian's 'apt source'?
<pkill9>leoprikler: i mean that i wouldn't need to split packages up into separate profiles if i could manage different sets of packages from the default profile based on queries like 'which packages have x server in their dependency graph' or 'which packages are larger than 300mb'
<NieDzejkob>leoprikler: The problem is that one has to anticipate that this will change
<pkill9>at the moment i separate desktop packages intoa separate profile, so i can update all the small commandline packages without updating the larger desktop packages which will take a while to compile
<leoprikler>Well, now that it did change, you could keep the old version in case someone decides to revert that patch ;)
<NieDzejkob>I feel like making a policy of using /fail-hard in places like this would be more effective
<lekzikon>I'm trying to define a private package (guile-mar) in a private channel. Both, private channel repository and the repository of the packaged software are local git repositories. But "$ guix build guile-mar" fails with "fatal: '/home/lekzikon/repos/guile-mar' does not appear to be a git repository".
<NieDzejkob>that would've been easier to notice if you posted your whole config :D
<NieDzejkob>in general, prefer pasting too much than too little
<NieDzejkob>I think you actually want to construct a gst search path out of your gst-* inputs
<ngz>That's what I tried. However, wrapping GST_SYSTEM_PLUGIN_PATH, GST_PLUGIN_PATH (as suggested by the configure script), GST_SYSTEM_PLUGIN_PATH_1_0 (as done by Nix) fails in the same way.
<ngz>Oddly that the configure script suggest to use $out/lib/gstreamer-1.0 instead of $gstreamer-inputs/lib/gstreamer-1.0
<valignatev>Sup guix! I'm trying to import a crates package recursively and eventually it throws "X.509 certificate of 'crates.io' could not be verified". I've installed nss-certs, exported all needed environment variables and made sure nscd service is running. Here's a full paste: https://paste.debian.net/1123908/
<valignatev>Notice that after hitting wasm-bindgen-webidl it starts going circles. Maybe import can't handle some circullar dependencies?
<oriansj>It is one of the reasons why the axiomatic assumption of infinity might itself be flawed (also older IRC clients don't support emoji)
<mehlon>by finite number space you mean something like numbers mod n?
<ngz>bandali: I don't use emacs-master, so I didn't notice anything.
<oriansj>mehlon: well that is one of the possible subsets of number spaces that fit the requirements
<bandali>ngz, ah. so auto-fill-mode works just fine in message-mode with orgalist in emacs 26?
<ngz>bandali: I didn't check. What is the problem?
<bandali>ngz, here’s the error: orgalist--boundaries: Lisp nesting exceeds ‘max-lisp-eval-depth’
<bandali>that happens when the line reaches wrapping mode (by default >72 chars)
<bandali>and the paragraph isn’t filled. a manual M-q works tho
<PotentialUser-99>Hi all, I was looking for some help with Guix System 1.0.1 installation. I got confused over the manual. I have prepared a dedicated partition for Guix with GParted. I'm using reFind as boot manager/loader (having other OSs aside) and thus don't need/want to install GRUB. I think for this I need to revert to the manual installation procedure using
<PotentialUser-99>--no-bootloader option on the guix system init command. Where I'm confused is that apparently the bootloader settings in the config must be defined. Can I leave it just empty in my case or does it need at least some valid entries e.g. EFI bootloader? Thanks
<bandali>ngz, by “wrapping mode” i meant “wrapping point”
<ngz>bandali: I cannot reproduce this on Emacs 26. However, I get an error when trying to use M-q in Emacs-26 with orgalist-mode on (trying to funcall nil).