<ZombieChicken>Is hydra just incapable of keeping up with the more recent packages? It seems like every time I do anything with guix, I'm having to compile two packages (in fact, this list time is when I'm trying to /remove/ a package)
<civodul>efraim: does LO fail to build on hydra too?
<civodul>ZombieChicken: it has a hard time keeping up in general, yes, though currently it seems to be doing okay
<civodul>we compile all of Guix, including package recipes, and compilation with Guile 2.2 is slower than with 2.0
<civodul>(the resulting code is faster, but still)
<jsierles>perhaps this is naive, but wouldn't it make sense to split the guix package definitions from the core repo itself?
<jsierles>at least ones that have nothing to do with guix itself.
<civodul>there are pros and cons, but essentially it's very convenient to have both together
<civodul>for instance (guix packages) is what defines the meaning of package definitions
<jsierles>ok. so the intent is always to have to recompile guix to get an older package definition?
<civodul>yes, but the intent is not to make it slow :-)
<efraim>wouldn't GUIX_PACKAGE_PATH be a good choice for this also?
<jsierles>i'm guessing there would be conflicts if you pointed that at an older checkout
<civodul>efraim: it depends on the exact use case, but it could be an option, yes
<civodul>jsierles: there shouldn't be any conflict: each Guix commit is self-contained
<jsierles>if there are two packages with the same name, would GUIX_PACKAGE_PATH ones take precedence?
<civodul>yes, and you would get a message about the ambiguity, i think
<efraim>I have one like that, GUIX_PACKAGE_PATH is rated higher
<ng0>civodul: has the upstream unversioned release of noto-sans been a problem in the past? If we split it up in the other hinted variants which exists by now (last emails I've sent just now on the question tumashu has) we have to find out if there's a regular cycle of individual tarball updates
<civodul>ng0: no idea, i'm quite ignorant about all this :-)
<ng0>At which point is Chromium to be considered for inclusion? I'm using it daily now and I am wondering what's missing that it could be considered for inclusion. it is stable enough and for myself far more usable than Icecat.
<ng0>I would guess some patches similar to Icecat would have to be applied on top of it
<chewzerita>Hi everyone! I want to package the ufw and gufw firewalls for guix, but I was having some issues. Can anyone help out?
<ng0>I think I'll look at parabola and others for what they do with Chromium or Chromium-like browsers
<civodul>hi chewzerita! sure, tell us what the problems are and we'll see
<chewzerita>civodul: thanks, I think I got ufw packaged properly, but gufw is where I'm having difficulty. I could hard-encode the url for the download for each version, but that would be hard to maintain.
<ng0>chewzerita: oO okayy.. so this is how the qtwebengine discussion ended. great. so what about KDE? I think the whole discussion was about KDE in the first place..
<jsierles>civodul: so i updated guix to see if your nar caching fix would fix issues I had with my substitute server. alas, I still see the same problems. Do you have any insight for another debugging route?
<efraim>if its of interest to you, I don't have caching turned on for my aarch64 substitute server
<ng0>catonano_on_mobi: it's not about gnome browsers
<magnicida>i am trying to use it set up development environments
<magnicida>but i am having trouble understanding how guix environment works
<rekado>magnicida: it builds a profile and then starts a sub-shell in which the environment variables needed to use that profile are set.
<magnicida>if I do "guix environment guile", i seem to get guile dependencies in the environment, but not guile itself, in particular, i don't get guile-2.2.pc in the /gnu/store/asdasdasd-profile/lib/pkgconfig
<Apteryx>civodul: I'm about to leave for work. Any suggestion to test libreoffice build as much as possible while I'm away? I was going to run: ./pre-inst-env guix build --rounds=2 libreoffice -c 1 -M 1, to try to get the compiler bug again.
<civodul>jsierles: oh but i guess the area that we're the most interested in from a package management perspective is the backend :-)
<jsierles>civodul: yeah, just will take some time :) we'd like to find things we could usefully open source of course
<ng0>is there solution for having a patches subdirectory in a GUIX_PACKAGE_PATH? (patches (search-patches "patches/foo.patch")) doesn't work, it works with leaving out the subdir and moving its content to the root of the GPP
<civodul>ng0: it's relative to the top directory, if you see what i mean
<civodul>or you can do (patches (list (local-file "patches/foo.patch")))
<jsierles>civodul: alright, that helps. the goal here is just to be able to present a list of software that's already been built and available in the store. for now, we'll be controlling what gets put into the store
<rekado>civodul: yes, I’m talking to the local daemon that I’m running with “sudo -E ./pre-inst-env guix-daemon …”
<rekado>strace shows me “write(4, "stla\\0\\0\\0\\0G\\0\\0\\0\\0\\0\\0\\0/gnu/store/lsfjq"..., 88”
<chewzerita>when I try to start a guix environment I get a backtrace and an error: guix/scripts/environment.scm:283:4: Throw to key `match-error' with args `("match" "no matching pattern" #<unspecified>)'
<vaeringjar>Anyone here know of a build tool that has compatible members to a guix package, for written in sh or python (for my non-scheme coworkers)? I want to use the same data source to define the packages for software builds and then wrap all that in a makefile for ease.
<nicorikken[m]>efraim: I've been fiddling a bit with glib-or-gtk build system to resolve my Zim desktop wiki port. However I'm not sure how best to combine multiple build-systems in this regard. I was thinking of using #:phases (modify-phases %standard-phases (add-after 'install 'glib-or-gtk-wrap glib-or-gtk-wrap))) but that does not work. Am I right to keep the python-build-system? and is there a better way to combine/replace build
<nicorikken[m]>efraim: I was thinking of refering the 2 steps as definined in %standard-phases in glib-or-gtk-build-system.scm. Like: (add-after 'install 'glib-or-gtk-wrap wrap-all-programs) However I get the 'unbound variable' error, so perhaps I'm importing it right. Could it be that I'm doing something wrong with use-module?
<divansantana>But if I ssh into the system and run =guile -c "'(use-modules (guix config))'"= the exit status is 0. I noticed GUILE_LOAD_PATH is not set. Though not sure what it's supposed to be set to. The build machine is on arch linux. I followed the build and application setup as per machine (I think).
<civodul>divansantana: that's because in the second case, your shell sources its login startup files, whereas in the first case, the shell does not
<civodul>the result is that different environment variables end up being defined
<civodul>you may need to define GUILE_LOAD_PATH & co. in ~/.bashrc
<lfam>civodul: It didn't show OOM while building the disk-image, but it did while building a vm-image: init invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
<civodul>ah okay, so that definitely suggests a Guile issue
<jlicht>What is the best way to include a copy of a built package in a different package? Can I just create a hard link, or is a symbolic link more appropriate?
<jlicht>context: I am currently reworking some npm related things, and decided to try to go with something between npm2nix´ and node2nix´ models, where I need to link all dependencies of a package in the same directory tree
<civodul>should we commit (part of) your importer BTW? :-)
<jlicht>symlinks work properly with grafting as well?
<divansantana>civodul: I though of that but when logging in via shell GUILE_LOAD_PATH is still not being set. I'm not sure what to set it too, and what else is missing. Which part of the manual shows what to set GUILE_LOAD_PATH to? Doing an env|grep -i guix when logged in and ssh user@host env|grep -i guix returns same.
<jlicht>civodul: we could, as I saw janneke is already starting pushing some small parts ;-). I´d just really like to still get the fundamentals right first, so we have a proper way forward. NODE_PATH is nice for commands like `guix environment´, but not usable for actual package deployments
<janneke>jlicht: not usable, what makes you say that?
<civodul>jlicht: symlinks work properly with grafting
<janneke>ACTION has been using NODE_PATH with much success, apparently
<wigust>divansantana: you grep guix but writing about GUILE_LOAD_PATH
<jlicht>NODE_PATH afaik will lead into problems if we ¨want¨ two versions of the same package to be available
<divansantana>wigust: True. Urgh. Woops. Ok but same is true for grep -i guile. Searching manual.
<reepca>divansantana: are you on GuixSD or running inside another distribution?
<janneke>jlicht: i have been using NODE_PATH only for `toplevel' packages
<divansantana>reepca: Trying to use guix on parabola linux as my build host.
<chewzerita>does anyone know the default username and password for the guixsd qemu vm image?
<lfam>I think 'Web' is a great name for the GNOME browser. On systems that are really popular like Android or iOS, most users don't know the name of the browser, and they don't want to learn it. It's best to keep the names simple when building an integrated system like that, IMO
<jlicht>janneke: no clue what that is about. Did you try npm install -g or something?