<leoprikler>(also compare between (resolve-module ...) and (resolve-interface ...))
<alextee[m]>packaging question: a program includes a git submodule at a specific version. assuming we package the submodule separately and made it a dependency instead, wouldn't it be wrong because the versions could differ?
<joshuaBPMan>I did get this: #<variable 7f9f188f7380 value: #<syntax-transformer guile-web-configuration>>
<peanutbutterandc>For eg: the temporary profiles created just to test things out, that I no longer need.
<alextee>even after reading the propagated-paths section in the manual, i don't get it. how are they different from normal inputs?
***jonsger1 is now known as jonsger
<peanutbutterandc>alextee, As I understand it, the propagated-inputs are added to the profile. Say, if a timelapse script package includes ffmpeg in it's propagated-input, ffmpeg will be installed alongside it in the profile but if it is just an input, it will not be in the profile but it's absolute path (/gnu/store/.........-ffmpeg) will be used
<peanutbutterandc>alextee, It seems that propagated-inputs is best avoided at all costs because it throws away the whole idea of guix: independent package upgrades. Should the timelapse script depend on a certain version of ffmpeg, and an upgrade comes for ffmpeg, it'll break it.
<peanutbutterandc>alextee, ... and it seems anyone who knows what they're doing with guix prefers (substitute*) and/or (wrap-program) over propagated-inputs any day. [I am trying to upgrade my own package definitions to not use propagated-inputs at all. 1 down. 2 more to go]
<alextee[m]>oh hmmmm i kinda understand it a bit better now, thanks
<alextee[m]>packaging question: is there a way to disable "-j 8" for a specific phase?
<alextee[m]>it's a gnu build system, so maybe just override the test phase with "make check"
<peanutbutterandc>alextee[m], I'm sorry. I don't really know much about the actual building/compiling process. Just a n00b here. But I do remember hearing that the phases can be removed, skipped, replaced, etc.
<peanutbutterandc>Question: For a package that uses cmake-build-system (or any system, for that matter), where would I have to put the debugging lines? I'd like for it to (display %build-inputs) etc for investigation
<reepca>peanutbutterandc: you could put that in any phase (it shouldn't change). Alternatively, you could look at it directly in the builder that guix generates (though it's not pretty by any means).
<reepca>regarding deleting profiles, I think just deleting the symbolic link should work. Guix treats them as what it calls "indirect roots" - there's a symbolic link somewhere in /var/roots/... or something like that that points to /my/link/location, which in turn points to whatever it is you don't want garbage collected (in this case a profile). So you can just delete the symlink and the profile will no longer be live and be able to be
<reepca>(above information may be not-quite-right, am investigating further)
<peanutbutterandc>reepca, Thank you. That makes sense. I am also trying the debug trick. However, I haven't yet managed to invoke ls successfully. So far I've been noting the directory and `ls dir`-ing on a separate terminal
<reepca>peanutbutterandc: well, you could use scandir. May have to (use-modules (ice-9 ftw)) though.
<reepca>I assume you're using trivial-build-system?
<peanutbutterandc>The `ls` one is for everything basically. Just trying to learn some debugging tricks. What is `ftw` supposed to stand for here?
<reepca>file-tree walk, I believe. For some reason scandir is in there.
<peanutbutterandc>ice-9 is some kind of fictional element, it seems. So basically ice-9 contains the gnu stuffs and because gnu stuffs are gpl3, they named it ice-9?
<reepca>IIRC there's an explanation of the name in the guile manual somewhere
<peanutbutterandc>I see. I haven't gotten that far into the manuals yet. I will be on the look out for it. Thank you
<reepca>hm, just tried finding it and can't seem to
<peanutbutterandc>I see. I would have liked to read it. Perhaps I should `git blame` sometime and email the author. :D
<reepca>peanutbutterandc: Actually my answer about deleting profiles depends a bit on how they were created. If you used "guix environment --root=myroot", deleting "myroot" should make it no longer live (assuming it's the only root). If you used "guix package -p", you can delete generations with "guix package -p myprofile --delete-generations", but this will always leave at least one generation, which you can manually remove from
<grumbel>Can two versions of a package installed at the same time? I am getting conflicts here between firstname.lastname@example.org and email@example.com, but as far as I can tell gtk2 and gtk3 shouldn't conflict with each other
<brendyyn>leoprikler: lec79; from my brief encounters with nix, i feel Guix's operatings are much slower than Nix too. like when uninstalling a package from a profile in Nix, it was instant. updating was much faster too and there are always substitutes
<olivuser>I have rsynced a ton of data, ~250gb, from an old (~5-7yr) ext4-formatted sata drive, to a new, btrfs-formatted sata. Since then, my system is so slow I cannot use xfce anymore, and even the TTY's are incredibly slow.
<grumbel>btrfs can get full even when df reports that it's still pretty empty.
<olivuser>grumbel: but what would I do if it says it is full while it isnt according to other measures? Offloading to other hdds?
<grumbel>olivuser: that's what 'btrfs balance' will fix, it's not that the drive is actually full, just some of btrfs data structures got full and need some reordering
<grumbel>What is the relation between /var/guix/profiles/per-user/root/current-guix and /var/guix/profiles/per-user/juser/current-guix? Both contain a pure profile with just guix tools. Do I need both? Or should ~/.config/guix/current really point to the root one?
<grumbel>The guix-daemon is still managed by the root profile, so I don't see why there would be a set of guix tools updated independently of the guix-daemon (maybe I just screwed up the install?!)
<peanutbutterandc>grumbel, I believe it allows for separate users to `guix pull` to separate commits of guix. i.e. One could `guix pull` from root (on a foreign distro) and have the updated version of guix and guix daemon running, but the user foo could still stick to guix 1.0.1 or any other thing to his own liking
<peanutbutterandc>the current-guix dir only exists after running `guix pull`. So, contrariwise, the root could be stuck with 1.0.1 whereas foo could be using the latest and greatest guix.
<grumbel>I see, so it's more an artifact of package database and guix software still being one git repository.
<peanutbutterandc>grumbel, I think it is not "still being one git repository" but "actually being one git repository": it seems to be a design decision made by the guix developers pretty early on that the gnu distribution and guix go together
<PurpleSym>leoprikler: Is it possible to extend session-environment’s config somehow? It’s not a base service, so I can’t modify-service it. But adding it to the list causes the image building to fail.
<olivuser>so, I installed my home partition as btrfs using the guix graphical installer. Since my computer has become TERRIBLY slow after a data transfer from an old hdd, I tried running 'btrfs balance' on said partition. When I do that, btrfs balance says said partition is not btrfs, even though 'df -T' confirms it is. Any idea whats going on?
<olivuser>I did not have btrfs-progs installed from the getgo, will do a guix system reconfigure with those added to my config file, hope that helps...
<raghavgururajan>I was trying build a package using node-build-system. When 'build phase' started, I got an error "command "gulp" failed with status 127".
<grumbel>raghavgururajan: I think 'error 127' is when the program in the shebang (#!/bin/sh) isn't found
<grumbel>Is there a quick&dirty way of integrating guix.scm files found in upstream git repositories into the local system? Installing with 'guix package -f guix.scm' works well enough, but guix complains on updates about the packages having gone missing
<smithras>The not quick&dirty way would be with channels
<smithras>but maybe you could use the profile system to create a profile just for that one package, then guix package -u wouldn't always try to update it?
<smithras>I don't know much about profiles though, I just skimmed the article that was written a while back about them
<truby>hi guix! I've got a few patches for the llvm packages that I'd like to try and upstream, I was just wondering what the protocol is on version bumps in packages like llvm? Currently the latest package version is 8.0.0 but there's a bugfix/security release for that upstream (8.0.1) as well as a new version (9.0.0).. I was thinking to bump 8.0.0 to 8.0.1 and add a new llvm-9, clang-9 etc with the new version since it's backwards
<ng0>in pkgsrc we build it with clang++, but that's not icecat there. nevermind then
<olivuser>Hello guix. After data transfer (ext4>btrfs), my guix system has become super slow. Now, when I try to 'btrfs balance /dev/sdbX/', I am told that said partition is not a btrfs filesystem, even though 'df -T' says so and I did format to btrfs using the guix installer. Any ideas?
<nckx>olivuser: Because ‘file system’ here means ‘/’ (or whatever), not block device.
<truby>ng0: upstream (as in, firefox) do recommend to build it with clang, and their prebuilt binaries are all clang built. But I do believe it still builds fine with gcc
<nckx>Let's build it with GCC so we can report bugs & keep it that way 😉 (Sigh…)
<nckx>truby: Are you familiar with grafts? They address the rebuilds vs. security updates issue in many cases (unless ‘vulnerable’ clang code is statically linked, which is possible but unlikely).
<truby>nckx: vaguely :) I would have no idea how to write one though
<nckx>truby: Have you read the ‘Security Updates’ section of the manual?
<roptat>I have an issue in my graphical terminals... I can't type non ascii characters in them after my last reconfigure (and guix pull && guix package -u)
<nckx>It's really quite easy: you (define …) an entirely separate ‘clang/fixed’ package (you could even copy & past the original clang but in practice we use ‘inherit’), then add (replacement clang/fixed) to the original clang.
<ng0>I have a bunch of packages, and I'm looking into maybe reasoning for more additions to the reproducible stuff in pkgsrc.
<ng0>getting both to run with pkgsrc is more like hacker curiosity at this point, i don't know if (with guix hat on) we'd add native netbsd support or if compatibility can be used, etc. and with this in pkgsrc we could hypothetical add support for more OS and architectures in guix, but in the end i know at guix we have other priorities than in pkgsrc, so it probably comes down to just guix on netbsd
<ng0>the guix package is stuck at me finding motivation to patch up gnutls so that I can build the pkgsrc gnutls with guile bindings as they currently assume too much about tripplets
<dongcarl>How to I indicate to `lookup-inferior-packages` that I want the `static` output of a package?
<leoprikler>you get the derivation, which should contain the path to the actual file
<fps>but also only if you change that part of the config :)
<fps>oh well, i think i figured out what was wrong with my config. trying something
***MinceR_ is now known as MinceR
<jonjitsu>I'm trying to find information on if my lenovo t480 is fully supported. I think it would just be the wireless card (AC8265) that might need a binary blob. Is there a list of supported devices somewhere?
<bavier>the build progress meter seems to be confused by the "ghc" package's build output...
<bavier>jonjitsu: guix generally supports hardware supported by linux-libre
<jonjitsu>bavier: ya I was looking through the linux-libre website for such a list. I guess I need to search through the repo...
<bavier>jonjitsu: is the t480 similar to the t400? The latter has a couple RYF-certified models
<jonjitsu>bavier: The T400 seems like an ancient ancestor of the T480. I'm pretty sure the wifi card in the T480 is replacable though...
<jonjitsu>Do the RYF-certified models + drivers support bluetooth?
<nckx>bavier: Not from a technical standpoint. The 8 means ‘8 full generations since 0’. (‘T4’ is the model/form factor i.e. ‘they look similar’; the last digit is a revision number for minor tweaks, almost always 0).
<jackhill>it would be neat to have the full tor-browser in guix, but I don't know what's required for that.
<vertigo_38>I'm rather new to guile -- does anyone know how to load multiple modules in a more character-saving manner than (use-modules (gnu) (gnu packages emacs-xyz) (gnu packages statistics) [...]))? I'm aiming at writing 'gnu packages' just once and pass a list to it in my config.scm. I've tried constructs like (gnu packages (append (list emacs-xyz statistics))) and (gnu packages '(emacs-xyz statistics)), but obviously did not succeed with
<nckx>raingloom: *Why* is your preference more user friendly?
<nckx>Arch isn't exactly known for not patching stuff.
<raingloom>nckx, without that option the volume settings get very weirdly glitchy with no obvious reason, eg. VLC volume controls start controlling the master volume, setting different volumes for stereo channels breaks as soon as I start mpv or vlc, etc
<nckx>Interesting. Can't say I've ever had that problem with VLC but I don't use it often.
<dustyweb>throwing weapons improved, sif muna a better god, very nice all around
<nckx>Yeah, I've heard that before, but it's like we're using two totally different systems. I'm not exactly Mr. Multimedia, but I watch ‘Internet videos’ and enjoy ‘music and film’ as much as anyone. Never noticed anything even remotely odd about volume.
<nckx>raingloom: If that's what the OOB experience is for some people, please submit all the patches. 🙂
<leoprikler>there's nothing odd if you only have one program running and adjust your speaker via hardware
<nckx>leoprikler: I think I use the MPV/VLC controls about 50% of the time, physical controls the other half, so it sounds like I'd be more likely to hear subtle (or soul-destroying) differences. Oh well.
<nckx>leoprikler: It can start out small, with just this knob (that's a better way to set a distro default than patching anyway).
<efraim>do we have an easy way to run modprobe at boot?
<raingloom>hmm, then i might have to write this later, because idk how to add new config records yet, and i have midterms this week.
<raingloom>or should i still send a patch until a proper solution is merged?
<nckx>raingloom: That's understandable. You can just open a bug report (with our without patch) for discussion.
<jonsger>that's bad. It's very cold outside and our heating is broken. So I could "heat with Guix", but it doesn't run on ppc64le :(
<raingloom>i think i might have asked this before, but what's the reason botting became so slow recently? my most up-to-date profiles take a while with populating /etc, whereas older ones boot in seconds. did i enable something in my config that made it so slow or is this about reinitalizing stateful directories?