<bluekeys>I've installed guix onto a debian vm (hosted by xen on qubesos) using the script on the site. The hello package is installed successfully. Step 8 states: "The binary installation tarball can be (re)produced and verified simply by running the following command in the Guix source tree". Where is the source tree?
<sneek>Welcome back bluekeys, you have 2 messages!
<sneek>bluekeys, nckx says: You're passing a nested list (nss stump (%base) as packages. %base-packages is already a list, so move it one line down outside of the (list …) call.
<sneek>bluekeys, nckx says: Typo, forgot a ) in my first sentence.
<sneek>johnmd, nckx says: Filmic Blender isn't part of Blender. A package for it would be very welcome!
<leoprikler>I goofed anyway. I think apteryx noted an embedded OS taking 1h30m (i.e. 90m), not 130m, tehepero
***jonsger1 is now known as jonsger
<johnmd>The version of Blender compiled by Guix doesn't have a colormanagement folder. I get this error: "Color management: using fallback mode for management" and I don't see Filmic Blender in the settings (unlike Blender on Ubuntu, Arch, Windows, Mac, etc.).
<johnmd>Also, Filmic Blender is included in the settings of Blender 2.8x on Guix.
<johnmd>it's using files in the colormanagement folder (which is currently missing in Guix's firstname.lastname@example.org). Usually (other GNU+Linux distros), this folder is located at /usr/share/blender/2.79/datafiles/colormanagement.
<terpri>hm, yeah, with 2.83.3 there's no colormanagement folder under datafiles, odd
<Kimapr[m]>does guix use curl, wget or something else for downloading?
<fnstudio>now, this may very well be OT, but i'm familiarising with the packaging process and was pondering what the options are in terms of uploading a signed tarball to gitlab
<terpri>CMakeLists.txt mentions "OpenColorIO" which could be required for that to work properly, maybe
<fnstudio>wait, forget that, i might be mixing things up
***jonsger1 is now known as jonsger
<leoprikler>Kimapr[m]: Guix uses Guile ports for downloading.
<terpri>lol opencolorio requires git to build...not to download a repo but to apply a diff
<atw>when attempting to sudo guix pull I'm encountering an odd error: "guix pull: error: Git error: could not open '/root/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/nix/.gitignore' for writing: Structure needs cleaning". What can I do about that?
<leoprikler>why do you want to "sudo guix pull" in the first place?
<terpri>atw, that seems to be a filesystem error rather that a git-specific error...fsck?
<terpri>failing that, nuke /root/.cache/guix maybe (*hopefully* it's only a cache...)
<terpri>it seems to happen with multiple FSes (xfs, ext4 at least)
<fnstudio>is `guix download` supposed to be used against the tarball of the final binary? i suppose so?
<atw>leoprikler: to, uh, update the root user's guix? should I be doing that?
<fnstudio>in particular `guix download` doesn't seem to support ssh-agent based connections?
<terpri>fnstudio, i don't understand what you want to use "guix download" for. typically, it's used to get the hash of a *source* tarball, to help with writing package definitions
<fnstudio>terpri: yep, but suppose the final source tarball is not publicly available, eg when it is kept as part of a private repository
<terpri>fnstudio, then the simplest method would be to get a local copy via scp or something, and use file:/// uris for package definitions
<fnstudio>i understand guix provide some support for downloading from "private" channels but that mechanism doesn't seem to be available for guix download (i'm experimenting with this for the first time, i may very well be wrong)
<fnstudio>terpri: ok, cool, i'll try that - thanks!
<raghavgururajan>nckx: Is it possible to dependency between service-types? Like, foo-service-type and bar-service-type are two different service, but adding the bar-service-type will also add/includes foo-service-type.
<kkebreau>mbakke: In commit a749caa74e2, you removed git as an input to the elixir package. Did it just not show up in the requisites of elixir? Because one of the phases looks for git... :-/
<kkebreau>Perhaps git-minimal is enough? I'll find out once I'm done building these wxwidgets dependents.
*terpri compiles blender with OpenColorIO as an input
<terpri>maybe this will fix the colorspace problem, maybe not
<efraim>i never realized how complex the network-manager service is
<efraim>the network-manager shepherd service has a requirement on '(user-processes dbus-system wpa-supplicant loopback), and the network-manager-service-type extends several service types, most importantly the shepherd-root-service-type where it registers itself as a service
<terpri>nckx, i'm not particularly familiar with mesa but it seems like it might just be duplicating includes? like maybe it's not supposed to #include <GL/gl.h> when alse #include'ing <GL/glew.h> or something
<terpri>"As with most other loaders, you should not include gl.h, glext.h, or any other gl related header file before glew.h, otherwise you'll get an error message that you have included gl.h before glew.h. In fact, you shouldn't be including gl.h at all; glew.h replaces it."
<NieDzejkob>leoprikler: oh, so taking it into account for function overloading. Rust and Haskell kinda do that. The caveat is that they don't have free-form overloading, you need to use traits/typeclasses.
<NieDzejkob>For example, in Haskell, foo <- readLn will infer the type of foo from its usage and then parse the input into that type
<leoprikler>so Haskell has a readLn : IO -> String and IO -> Int?
<leoprikler>Or is there an implicit String -> Int converter, that the compiler always considers?
<PurpleSym>It’s actually a generic, i.e. readLn :: Read a => IO a
<PurpleSym>So it can return anything that implements Read.
<apteryx>ah, --compose is just a message, --cover-letter pulls in more details such as the branch description, shortlog and overall diffstat.
<nckx>apteryx: I wouldn't call it undocumented but it's not very discoverable: ‘any format accepted by git-format-patch(1) can be passed to git send-email’, and the man page for g-f-m does mention it. But plenty of people (well, me) just ‘/ -v’ in less and won't find that.
<pkill9>is there any work on packaging jitsi desktop client?
<apteryx>nckx: ah I see, yes, that's where I could learn more about --cover-letter
<leoprikler>bluekeys: you need `guix environment --ad-hoc guix gwl`
<simbaclaws>hi, I would like to try guix on my laptop using the same configuration that I've currently setup on my gentoo system but without any of the non-fsf approved software. Is it possible to use suckless software with guix? And start the installation with something like dwm?
<simbaclaws>I've made my own c patches that I would like to port
<malaclyps>does anyone know if `guix weather` with no arguments calculates the weather for the entire guix distribution, or the default profile? It's telling me it's looking at 14,711 package derivations which seems a lot!
<OriansJ`>everything not written in Assembly is "bloated" but who cares? You can buy a chromebook with 4GB for under $50
<malaclyps>okay, i have hacked together something which looks at my profile, converts it into a manifest, feeds that to guix weather to find out what is lacking a substitute, and then feeds those as --do-not-upgrade arguments to `guix upgrade`
<malaclyps>i assume there's a far far better way of doing this and maybe it is just an option to guix upgrade