<marusich>The fact that in this case the parameters to the service are a list containing a single package is, I think, a detail of the contract defined by udev-service-type.
<Apteryx>yes, it must always take a list as argument
<marusich>Generally speaking, services have a contract that says something like, "you tell me what your parameters are and what service type you extend, and I will pass them off to the mechanism for extending services of that type"
<Apteryx>This doesn't make the rules 'installable' but rather always on, though.
<marusich>But the details of what the parameters must be, and how they will be used, is totally up to the various service types to define.
<marusich>I suppose it might be intuitive to want to allow the administrator to run "guix package -i my-rules", but that is basically the same thing as having the administrator run "guix system reconfigure" with an updated system definition.
<marusich>Is it possible to install that as a non-privileged user?
<Apteryx>When such udev rules are installed, nearly all android phones can be used with adb/fastboot without requiring to be root (as long as the user is part of the right group).
<marusich>To put this another way...does installing that package cause udev rules to be created in system-level (i.e., not user-specific) directories?
<marusich>The installation instructions suggest putting the rules into /etc/udev/rules.d/
<Apteryx>oh, good point. On these other distributions it would add the rules to /etc/udev/rules.d or something like that, and these would be picked up by the system udev service.
<marusich>so, that is definitely an 'entire system' level thing
<marusich>So, it's appropriate to require an administrator to install these rules by updating the operating system configuration file and then running "guix system reconfigure"
<Apteryx>Hmm. So it seems what we have right now to accomplish this would be a custom service at the operating-system level, yes.
<marusich>Unless there is a way to install udev rules on a per-user basis, which are not shared system wide, I think this is fine.
<Apteryx>marusich: thanks for your help, it cleared my thoughts!
<marusich>Sure thing. Udev and services in Guix are not quite as simple as I would like, but they're great nonetheless.
<ng0>*still pre-mount issue with something I can't paste because it's before I have any access to anything (sorry for confused grammar style, long day + been staring at cURL for the past 2 hours).. anyway I'll just setup the system new and use a config from my git.
<marusich>Oh, I see. pre-boot issues are tough. :(
<marusich>So much of that stuff must be configured outside of Guix...
<marusich>Having to ensure that it all matches what you told Guix to expect, in your operating system config file, is sometimes a bit of a challenge.
<ng0>it worked. and at some point I did a thing but I'm not sure anymore which of the configs both outside of the git I used ;) so git is better
<Saone>I have a question that someone might be able to help me with, anyone around? :>
<mange>I'd suggest just asking, and you'll be able to tell if people are around based on whether you get an answer.
<Saone>I'm trying to run guix behind a proxy, and I'm having trouble getting guix-daemon to pick up my http_proxy (etc) environment variables, do I need to do something special to give the daemon proxy environment variables?
<mange>The trick is that you need to set http_proxy in the daemon's environment, not in your environment. You need to modify your OS configuration file to specify http_proxy in the daemon's environment.
<Saone>Upon further inspection, it seems that guix-daemon doesn't like something about my root environment, and refuses with that UID 0 message? it also doesn't look like guix-daemon has any options to provide env vars in initialization. ¯\\_(ツ)_/¯
<Saone>(which would have been nice if I was just restarting it through herd)
<Saone>I gotta step away too, thanks for the help all
<sadiq[m]>Hi. which package includes dig and nslookup binaries?
<sadiq[m]>marusich: not yet installed, but bind-9.11.2 and bind-9.11.2-utils where going to be downloaded, and the former is around 20 MiB
<marusich>I'm not surprised that bind would be downloaded; to build the tools, you probably need to build bind.
<marusich>Let the command run; I think you will find that in the end, you will only get one output installed into your profile, and you will only see the "dig", "nslookup", "nsupdate", "delv", and "host" commands show up in your ~/.guix-profile/bin directory.
<marusich>More specifically, /gnu/store/...-bind-9.11.2-utils retains a reference to /gnu/store/...-bind-9.11.2. Specifically, nsupdate and delv refer to it.
<sadiq[m]>hm.. can I run guix package -i parallel in different terminals? (with out any custom build daemon)?
<marusich>So, even though you will only wind up installing the "utils" output, the "out" (i.e., the usual) output of the "bind" package is still required in order to run the tools.
<marusich>You shouldn't do that. It will not result in a "merged" profile.
<marusich>The problem is, I don't know what will happen if the two "guix" processes try to update the profile symlink at the same time.
<marusich>Probably, one will succeed, and the other will either (1) fail or (2) overwrite what the other did.
<marusich>either way, you wouldn't get the results of both commands in your final profile.
<marusich>There is no reason to run it in parallel to improve performance, though. If you forgot that you wanted to install something, you should just ctrl+c the process to stop it, and re-run the command.
<marusich>Since build outputs are stored in the store, your progress is mostly "saved" between invocations.
<marusich>Those are probably benign; they are inevitable in any system, like Guix and Nix, which creates a tree of symlinks pointing to components, and some of those components share common files.
<marusich>If foo and bar both provide a file at path foo/a and bar/b, and you try to make a tree of symlinks rooted at baz, you can only choose one "a" to put at baz/a.
<marusich>It's only a problem if the choice matters.
<marusich>Frequently, the choice doesn't matter. Those icon themes are probably benign. For what it's worth, I also see the gschemas.compiled message a lot, too, and it doesn't seem to cause any apparent problem.
<marusich>Your profile (pointed to by ~/.guix-profile) is a tree of symlinks, so Guix needs to deal with conflicts that arise. It does that by arbitrarily choosing one.
<sadiq[m]>I have got problems of that. When I tried to open keyboard settings in gnome-control-center, it segfaulted. it wasn't finding gnome-shell gsettings key. reinstalling gnome-shell fixed the issue.
<marusich>Hm. If there is a problem like that, and you can reproduce it, it would be worth submitting a bug report.
<sadiq[m]>there should be atmost one gsettings compiled schemas if possible. it is created from all the avaialable schemas
<marusich>We probably aren't the first to observe the collision with the gsettings.schemas file...perhaps if you search the bug reports or the mailing list, you'll find some discussion about it already?
<sadiq[m]>overall, the OS is pretty good, except the minor issues like this (and a huge bandwidth usage)
<marusich>I'm happily using GuixSD for personal use... I like it. The minor issues can be fixed, if you help us to do so. :) As for the bandwidth, they're working on improving the build farm, and in the meantime, you always have the option of setting up your own, since Hydra and Cuirass are free software, too.
<marusich>But yeah, it's a bit slow sometimes... I prefer to let operations run overnight, since it's really frustrating to wait minutes or hours for the build/download to finish.
<sadiq[m]>I was unlucky to install guixSD the same day webkitgtk was updated. :)
<somebodyelsemayb>last I checked (several years ago), I'd heard that server was administered poorly, but now that pgp actually checks the sigs it receives, that's probably less of an issue.
<marusich>If you are truly concerned about somebody putting a bad key in there *and also* managing to deliver to you a bad image, then I would expect you to rely on the web of trust to validate the binding between the key you downloaded and the identity it claims to represent.
<marusich>If you are not relying on the web of trust to do that, then I'm not personally convinced that you'll be safer just because you decided to use a different key server.
<marusich>Alternatively, if you're that concerned, but you don't use the web of trust (e.g., because you rely on the tofu model), I would expect you to take additional steps to verify the authenticity of the received key before relying on it for validating signatures. For example, you could download the same key from another key server and compare them to make sure they're identical. Or you could obtain the fingerprint of the key from some other trusted
<marusich>If the pgp.mit.edu servers are known to be mis-managed, then I suppose it might be reasonable to suggest a server (or collection of servers) to use instead which do not have a bad reputation. I don't know much about the reputation of the various key servers, and in general if you're using the web of trust, it shouldn't matter where the public key originates from.
<somebodyelsemayb>marusich: well, the page includes the longform key ID, which is harder to duplicate than the 8-digit ID
<marusich>I don't personally think it's a big deal, but perhaps the maintainers have a different opinion. What is safe and what is not depends very much on a person's situation and their own threat model...for the average user, I think it's fine to recommend the MIT site.
<marusich>Oh, well yeah, if we didn't put the full key in there, then it would be a problem, but it would be a problem because the key ID is ambiguous, not because it's sitting on the MIT servers.
<somebodyelsemayb>I think gpg uses the sks keyservers if you don't specify anything, but I don't remember whether that required configuration. It's been too long since I've dug into configuring GPG from scratch.
<marusich>Anyway, if people are using the web of trust or some other kind of validation (e.g., double checking the key fingerptint with other sources) to verify the authenticity of a key before relying on it to validate signatures, I don't think it much matters where the public key comes from.
<somebodyelsemayb>anyway, they key ID I see on the website is 3CE464558A84FDC69DB40CFB090B11993D9AEBB5, which appears to belong to Ludovic Courtès <firstname.lastname@example.org>, though I don't have countersignatures to verify it.
<marusich>And I would expect that any security-conscious user would do such a thing, regardless of whether the MIT servers are being used.
<somebodyelsemayb>marusich: yeah, I think GPG fixed the unverified-signature bug two years ago? the server hasn't mattered much since then.
<marusich>For what it's worth, that ID is the same as the one I have for Ludo in my keyring.
<somebodyelsemayb>marusich: coolness. I'll try to check further, but that's pretty good verification. I expect the entire channel would get mad if we got Ludo's key wrong :)
<marusich>Unless they've hacked your router and you're talking to a pretend marusich! ;)
<marusich>In my opinion, if you want to learn about the common data structures, you should get your hands on a textbook dedicated to the topic. They will be more informative and helpful than Internet articles.
<marusich>As for Guix and Nix, happy_gnu[m], if you read anything, I think you should read the first chapter of Eelco's thesis. It's very useful for understanding the problem that Guix and Nix solve. It's good to know the motivation in more details.