<nckx>vagrantc: Is there a theme to R irreproducibility?
<acrow>Ah, so all these mismatched checksums could be caused by changes in transitive inputs? Although when there are many builds and none match; well, the source emerges as the culprit because the inputs are relatively stable.
<vagrantc>acrow: no, those are for a given guix commit.
<nckx>acrow: Not quite, I think, although I'm not sure what you mean.
<vagrantc>does guix publish publish the public key used to sign it's packages, or do you have to publish that independently?
<acrow>Ok, I should've thought about it more. the derivation checksum is calculated from the checksums of the derivations of the inputs (so when an input changes, we have an entirely new deriviation to build from) .. So, we are building derivations and there should be no variation in the output checksums. I was thinking about how changes in the inputs affect things. IIUC, derivations are reproducible, no?
<maximed>foobarxyz: We usually just put them all in 'lib', without architecture-specific subdirectories.
<maximed>vagrantc: I would keep the narinfos signed (even if the authorised key is not authorised), to allow later for things like multisig systems -- e.g., client only accepts a substitute if signed by two different authorised keys or such
<maximed>* even if the authorised key -> even if the key
<foobarxyz>maximed I see, thanks. I suppose this is because there will be only one guix instance running at the time as far as archs are concerned, so we can't have both x86 and amd64 packages at the same time
<maximed>foobarxyz: You can have both i686 (as we name it in Guix) and x86_64 in the same ‘Guix instance’.
<maximed>so not necessarily a problem (although installing two variants in the same profile probably won't work).
<maximed>Also, Guix supports cross-compilation arbitrary packages to any (supported) architecture: "guix build hello --target=aarch64-linux-gnu", which implies that you can have multiple architecture variants of the same thing on your system.
<foobarxyz>maximed: thanks, I'll have a look at the --target option and see how it behaves exactly
***tox is now known as vier-littleme
<sammm>simple question I hope, how can I have a shepard service (using requirement array) depend on something like the docker-service-type (which isn't a shepard service AFAICT)
<sammm>in short, my shepard services which were running docker run failed to start as docker wasn't yet running.
<arjan>the home configuration is minimal and does build successfully, but cannot be applied apparently
<stampirl>Hi #guix. I have a problem with my Guix SD. Docker stopped working and is spitting out this error ` Unknown runtime specified`
<mbakke>emacs tramp is asking for username for a host defined in ~/.ssh/config, what gives? It manages to resolve the alias and ProxyJump from the same file, but not User
<lilyp>mbakke: Is this new or did you just now try tramp and notice it for the first time?
<mbakke>lilyp: I've used Tramp occasionally for years, but not since I reinstalled my machine due to fatal btrfs corruption a few weeks back, perhaps I missed something? Also migrated to Guix Home, so many moving parts :P
<lilyp>there's also Emacs 27→28, which already broke some tramp thing
***wielaard is now known as mjw
<rekado_>nckx: the rdb/rdx differences in the case of r-affycompatible are likely due to the order of classes.
<z20>lilyp: Running that, it says that the service is disabled. For context, running mpd on its own says that there is no config file. Same story whether it's user as user or mpd as user in the service declaration.
<dhruvin>What downsides are there to rely on language package managers (like npm or go get or cargo or cabal) to download/manage guix package dependencies? I can think of one is that users won't be able to patch/modify dependencies as they wish as easly. Am I mising something important here?
<fps>dhruvin: i guess not all of them offer the reproducibility that guix/nix offers
<nckx>jpoiret: It's close to being its own Godwin's law at this point.
<lilyp>Well, I prefer the modern counterpoint to ‘why don't we just defeat the dragon’, but that doesn't apply here.
<dhruvin>lilyp: I'm suggesting to use npm and others to download dependencies from internet in source step, just like guix git-download and others do. Language package managers can download those packages and put them in some known place, where they're later used in build phases.
<nckx>My metaphor was utterly horrible. I could at least have gone with ‘appease the dragon’ and ‘we'd have to learn dragontongue’, but I did worse.
<nckx>dhruvin: But it downloads tonnes of packages.
<lilyp>dhruvin: I think your time is better invested trying to write an importer
<jpoiret>dhruvin: but then you lose the advantages of a package manager: a vetted and coherent repository of packages, with sane version management for dependencies
<bjc>guix isn't invulnerable to supply chain attacks, but it is less vulnerable
<jpoiret>the supply chain argument isn't the best argument because we use importers in any case
<z20>lilyp: Since the file message was from running `mpd' as a command, I suppose the clue is the connection refused message. I worked on that for a bit without success, but a more basic problem is why it's disabled and stopped on reboot
<lilyp>z20: as I pointed out, your mpd races against the network service, thus it gets disabled
<dhruvin>jpoiret: I get about not vetted packages.
<nckx>dhruvin: Say we patch a bug in package a, for which no fix is publish upstream, how do we get it to affect all users of a without rewriting each user?
<jpoiret>the issue is that developers want their program to Just Work™, but they're not thinking about the whole lifecycle of their product, and their dependencies
<jpoiret>many people in those "new languages" don't even understand that they should update their dependencies and test with them
<jpoiret>the problem is that the tooling encourages such "frozen" behavior
<jpoiret>if they were using packages from a package manager, updates to the dependencies would force them to test with the newer dependencies
<lilyp>tbf guix time-machine encourages frozen behaviour too
<jpoiret>lilyp: i wouldn't say it encourages, since it's harder to use that just guix itself, but yes
<nckx>I don't enjoy these discussions because they always risk coming off (or simply do, even) as old men yelling at the cloud, but at the same time I feel like the cloud isn't sending its best. So we end up performing this ☝ exact dance each time.
<lilyp>I read that as old men yelling at the butt.
<nckx>I'd love for some compelling idea to come along that Guix just can't ignore.
<dhruvin>To give context: I'm looking for ways to ease the submission of lets say electron based apps to guix (ignoring their downsides). Since there are so many dependencies, and using an importer will yield that many guix packages.
<jpoiret>the issue is that you can't really avoid the dependency hell of those package managers, they have smaller libraries that do only one thing
<dhruvin>nckx: <ignoring downsides>: I didn't want to derail this conversation.
<lilyp>(after people have aleady moved on to the next horrible ide mixing rust, go and node just to spite us)
<nckx>I didn't mean to imply you were, dhruvin, but a good part of the conversation is people pointing out downsides.
<dhruvin>Alright. IIUC reproducibility, vetting, and seamless bug fixes done by guix favors `guix import`.
<nckx>You can take your npm directory with 1000 packages that form a ‘functioning’ whole, check it into my-electron-app-monorepo.git, and write a Guix ‘package’ that just extracts that, with a nice hash & everything, today.
<jpoiret>oh and don't take it personally either! I think we all at some point were eager to add something like you are, only to discover that it's just a bottomless pit of horror. Personally, I had that with the protonmail bridge
<nckx>If you say, ‘that's fine, I don't care about that’, that's fine. :)
<jpoiret>that made me reconsider which software I want to use, and now if a program is written in Rust/Go/npm it's highly unlikely i'll ever use it
<jpoiret>it's getting difficult though, with Rust infiltrating many projects
<lilyp>I still think GNOME folk embracing Rust with open arms was a mistake.
<dhruvin>The situation got worse as new language level package managers came that allowed developers to create their own mini-world of dependencies disregarding how downstream will take care of that mess.
<jpoiret>see Python also, I have friends that use it for scientific computing, and they've all been told to use Anaconda, which is an additional distribution that's not either PyPI or a system distribution. It also includes proprietary software, that is on the front page. Updates don't go well, you don't get the latest packages, and it all interacts
<jpoiret>terribly with your own system-wide python
<bjc>cpan has been around forever and somehow didn't cause this level of problem
<vagrantc>cpan evolved in a very different development culture
<bjc>so at least some of this is simply cultural. cpan isn't special
<jpoiret>right, i personally think that it's the tools and the type of language that influenced that kind of culture
<dhruvin>jpoiret: I believe that many ml researchers only want a declarattive reproducible environment. That they can share with peers (or downstream). Conda does that well I heard. Isn't that right?
<nckx>Perfect is a stretch, but ‘this thing that is *very* convenient, just ‘works’, and is enabled and sanctioned by the language & tools is actually bad and you should stop doing it’ is a very hard sell.
<singpolyma>Well, using multiple definitions of the same words doesn't help obviously
<nckx>Let's s/docker image/huge static binary/ (the difference is purely semantic, but static binaries are easier to understand), and your binary will still likely do different things on PCs 30 years apart.
<muradm>because every time you make VM even with same input, your will get different images
<trevdev>Hey guix, is there some reliable way to add a folder to the %load-path in the context of `guix-home`? I'm trying to use a module to configure an mcron job, the context is getting lost in the gexp and part of that seems to be the `(current-filename)`
<nckx>lilyp: I got… excited is not the right word, but I'd already cut a new piece of red string all the same.
<muradm>and there will not be a way to compare one with another
<lilyp>I'm also quite sure GNOME Builder allows you to easily build flatpaks, but I don't think it does publishing
<dhruvin>I think people interested in guix are often in it to see, and modify the "produce" part of reproducable. Whereas docker folks seem to be just interested in identical copies of zeros and ones able to be executed in a preconfigured environemnt.
<jpoiret>Docker is often not even consistent because you can configure containers in a bunch of different ways that can make them misbehave
<jackhill>I'm curious to understand more hwo the relationship between Haskell devs and Nix, Stack, and the new Cabal tooling went. Also how well all the messaging around more managable depedency graphs have gone for Go (and maybe Clojure?).
<dhruvin>One of the complaints I see is that system level package managers are too slow to update their dependencies. This may be a reasonable excuse to not rely on let's say guix or debian or others. Velocity is what these new language level package managers are about. And I see that.
<jackhill>My experience working outside of Guix for work is that it's not nessisarily that the problems aren't apparent, but our developers are more pragmatic there about focusing on their narrow scope of work and will work around problem even as they are experiencing them.
<dhruvin>I don't feel go devs are careful enough about minimal dependencies. They have decentralization, yes, but I still see too many packages with years old dependencies.
<lilyp>but that's a problem with *distributions*, not with package managers
<jackhill>I see non-free platforms playing a lot into it as well. As a language ecosystem designer I, naturally, want to reach folks on those systems as well, which means I must provide my own tooling
<dhruvin>lilyp: We do have vetting in place though. Everyone will have to create their own guix channel, or submit packages to an unvetted channel; to be able to publish packages as easily as with npm et al. Right?
<lilyp>jackhill: wouldn't pkg-config have solved that problem for most everyone though?
<jackhill>And Rust seems to have done a good job building a vibrant community around their fairly new language. I don't know how much cargo and practices around it made that possible, but I'd bet that Rust folks think it to be part of their success.
<lilyp>dhruvin: as a package maintainer, you just have to provide a guix.scm in which you can do whatever.
<lilyp>on a company level, you have to merge those definitions into something meaningful
<jackhill>lilyp: seems like there might need to be some tooling on top of pkg-config. I dunno, I don't really udnerstand the problems my colleagues have with their chosen systems or why they persist in that coice.
<lilyp>well, that's what we call a build system normally
<lilyp>speaking of it, why does every language and their mother need their own package file format?
<dhruvin>lilyp: I am unclear about the consumer part here. I get that as a software developer I have my own guix.scm with my package definition somewhere in repo, but how will my users get the exact dependency they need from my repo (or via some other means)?
<dhruvin>Knowing about what has been updated and reconciling is done by `npm update` seamlessly. The flow you mentioned requires all downstream projects to keep a track of said upstream project's channel(s) of communication where updates are conveyed. npm and others seem to centralize it making things convenient using `npm update`.
<dhruvin>Can something like this be done with guix?
<dhruvin>Ideally projects should have minimum dependencies and keeping track of dependencies is part of their work. But with newer software having countless dependencies makes it much harder to do. If not done automatically using tools like `npm update`
<mitchell>dhruvin: When a package is defined in guix these relationships are formed by the other package definitions in that commit. If your package builds with a given commit, it will always build (unless you do some weird transformations on it)
<dhruvin>Yes, I was describing how npm and others do this
<lilyp>In Guix, you specifiy "exactly" the package to build against.
<unmatched-paren>To be honest, if you need a complex solver for figuring out your dependencies, you probably have too many of them.
<lilyp>If there's a conflict, then boom, there goes your web page.
<vagrantc>admittedly, one of the theoretical appeals for me to guix's model was that it might actually be able to support multiple concurrent incompatible package versions as sanely as possible ... that seem to be the trend for many languages these days ... but it's still a *lot* of work
<dhruvin>lilyp: Right. I get that. I was wondering can we come up with exact dependencies of all dependencies that are compatible to each other or not.
<mitchell>right, usually the sources get patched at build time to refer directly to store paths and not rely on the caller PATH variable
<dhruvin>mitchell: Specifying what minimum version to support in a package file with a lock file that has exact versions of all of my dependencies is what these language pms do. I'm trying to draw a parallel here.
<mitchell>"However, such version specifications involve a high degree of wishful thinking, since we can never in general rely on the fact that any version in an open range works..." --- The Purely functional deployment model
<mitchell>Chapter 1 of Dolstra's thesis goes into great detail on why thats the wrong approach
<dhruvin>Alright. So functional package management focuses on specifying exact versions for reproducibility and other benefits. I get that. But is there a way for me to generate these exact versions and keep them updated as I develop my software over let's say some months to years.
<apteryx>the burden of maintaing your own fixed versions is on you
<mitchell>Yes, you do this by updating the package definition using git. If you need to go back you can guix pull --commit
<mitchell>druvin: What we mean by "exact" is different than the usual usage
<acrow>IIUC, the general case is that the guix commit you work from fixes the versions of your various package inputs. So, if we could go back to a guix commit from 20yrs ago for a package sheepherder that depends on perl it would be built with the most current perl from that time (say perl4). If you pull a current guix commit with the same sheepherder package it would build with the current perl (6?). Unless, the package pins the versions
<lilyp>acrow: sure, but you yourself specify which guix commit to use (inside the CI) and how much to import from guix vs. ship on your own
<dhruvin>mitchell: By exact I mean what's used to compile my software. By range I mean, I'm comfortable with a dependency set (and updates) as long as they all obey given range.
<mitchell>dhruvin: That kind of compromise is not required in guix though. You don't have to accept any kind of range, even if some other package uses a different version. Specify one that works and stick with it until you need to update it
<mitchell>They need to throw the whole thing out and start from scratch
<dhruvin>Lock file isn't consumed by humans. you're right about it getting extremely large
<unmatched-paren>mitchell: As in, throw the whole language out. V8, mozjs, Node, Deno, npm, the whole lot.
<jackhill>I understand part of the problem with npm isn't (only) the sive of the graph, but that it has cycles, and many packages can't be build from source. Tooling can solve some of those problems but not others
<jackhill>but there is much good free software implemented in it, which would be sad to loose. Language proliferation is probably a problem for free software (incompatible things, "wasted" effort), but the alternative is not good either.
<mitchell>if thats what it takes lol. It seems like this depency hell has wormed its way pretty deep into the culture of the language. Throwing out npm would mean throwing out a lot unless someone can unravel the yarn ball they call a depency graph
<mitchell>I use a manifest.scm to create a profile for each project that gets activated by direnv scripts
<apteryx>an alternative way if the software is already in Guix and you don't need to experiment with its inputs much is to simply setup the development environment via 'guix shell -D the-package-in-guix'
<dhruvin>I will also have to give a list of channels as well, right? If there are more than one source from which these packages come.
<dhruvin>apteryx: Yes, I used to use guix environment extensively.
<apteryx>dhruvin: channels are handled at the guix level, mainly ~/.config/guix/channels.scm. You can also specify a channel file checked in your repo
<mitchell>Oh is that how i'm supposed to replace guix environment
<unmatched-paren>e.g. there was a bug where the system hung at boot because of something to do with iwlwifi
<dhruvin>I think channel commits define snapshots of (possibly) compatible set of packages, whereas if my requirements get complex, I transform those packages in question using guix's programming interface.
<lilyp>that works, but if your requirements get "complex" it might be easier to just write out the graph on your own
<mitchell>They should all be compatible. If you need to do complicated things in your channels you should create new package variants through the scheme api. You can include arbitrary amounts of code in your channels to do the complex things so that you shouldn't need to do anything more complicated than swapping out sources at the command line
<dhruvin>Alright. We are depending on channel provider to make sure of compatibility. If it's not met, we make packages compatible, using the scheme api mitchell mentioned.
<dhruvin>Now about updates. We still rely on channel commits for majority of our dependencies.
<dhruvin>And we only update or pin packages that we want in manifest. Using inferiors that unmatched-paren mentioned.
<mitchell>You dont necessarily need to pin things in the manifest. If you want to freeze time, you can use the output of guix describe to guix --time-machine in order to recreate things as they are right now from a manifest. The manifest is defined by the guix used to evaluate it.
<dhruvin>time machine will cause every package to be from an older commit, right?
<dhruvin>Pinning is helpful when I need old definition of one package but new of others.
<dhruvin>Although I suspect I'll be needing this often.
<dhruvin>So the unit of distribution here is a package definition. And you have channels that host these definitions and keep them compatible and up to date. If your needs diverge from channels' definitions you use programming interface to specify what you want, or you can replace channel package with whatever you wish, locally in your manifest.
<dhruvin>I believe this summarized what I was trying to understand.
<dhruvin>Thanks everyone for your valuable inputs in clearing out my doubts. I hope others may have found something helpful from this. :)
<mitchell>libtsm is failing in the configure stage because it can't find XKBCommon when cross compiling to aarch64-linux-gnu. libxkbcommon is a native input, is this the reason? Should it actually be a regular input?
<apteryx>if I remove the static-netorking-service-type modification, the config builds fine
<maximed>ternary: You can use channels without channels. More concretely:
<maximed>You could remove the channel from your list of channels, and instead tell guix with each command where to look for extra stuff: "guix build -L /location/of/git/checkout/of/channel channel-package"
<maximed>"sudo guix system reconfigure -L /location/... configuration.scm"
<maximed>(Removing the channel is not necessary per se, e.g. I haven't needed to do it for antioxidant, but seems rather fragile to have it both in your list of channels and in -L w.r.t. which module ‘wins’ etc.)
<ternary>Oh I didn't realize a reconfigure worked with a local path. That removes some of the pain for sure
<ternary>I assume I can't test the service without doing a reconfigure though
<maximed>ternary: You can, to some degree, with VMs!
<maximed>"guix system -L$THE_DIRECTORY vm the-configuration-of-the-vm.scm"
<maximed>Unless I got the wrong subcommand, it will output the location of a shell script that you can run to automatically start a VM with the given system configuration.
<maximed>Warning: if it does anything graphical, chances are that the default memory limit is too low, so you might need to add a -m3G or such somewheere.
<ternary>Oh that's a cool idea. I'll have to give that a shot
<apteryx>does extending remove the requirement to set provision to some value?
<apteryx>I think it either should accept no provisioning or document that it's needed but be careful to not provide 'networking multiple times because that's the default, or something, as seems to have bitten here: https://issues.guix.gnu.org/52511
<apteryx>civodul: few, it works. thanks for saving my sanity