<marusich>Apteryx, installing udev rules from a pacakge is possible. <marusich>See commit 3547a5effecfa19f73af29f0d503f5a231025672 for an example. <marusich>Conceptually, as I recall, that commit adds a service (created by the simple-service procedure) to the list of desktop services. <marusich>I believe the "service" extends the udev-service-type and provides a singleton list containing the libmtp package as its "parameters" for the service... <Apteryx>Interesting! So by passing the package to a simple-service of udev-service-type, we can extend <marusich>Not the package, but the service parameters, I think. <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>udev is a system-level service. It makes sense that to add rules, you must take action at the system level. For example, an administrator must run "guix system reconfigure." <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. <marusich>I am not aware of any per-user features of udev] <marusich>As far as I know, it's a system-wide service. <Apteryx>I guess it wouldn't work very well as a user service since it's role is giving users access to privileged devices :) <marusich>Most users who want to do this are already administrators of their own systems, so requiring them to run "guix system reconfigure" (as root) is not a problem. <Apteryx>Should we have 'ready-to-consume' service extensions to copy paste to an operating-system definition? <marusich>I think that would be a useful contribution. <marusich>I mean, that applies to most anything in the operating system configuration file, since so much of it is custom. <marusich>There are various tricks you can do to customize things...just like with ~/.emacs <marusich>I think it would be great to have people sharing the neat ways they customize their systems, if they're comfortable doing so. <Apteryx>I'm not sure where they'd fit in the current picture though, it would be a first I think. <ng0>well... damn. I think there's no issue with guix, there's an issue with my config or system. stillpre-mount actions failing. <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>How are you running guix-daemon? <ng0>don't we install 'testcurl.1' with curl? <ng0>… does any system do that actually? because if no one does it, that's one collision less I need to worry about <ng0>$out/curl/share/man/man1/ says no <ng0>and so does $doc/curl… <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>How do I modify the daemon's environment? Where's the OS configuration file for the virtual machine image? <ng0>last time I tried it with guix + socks5 tor I failed.. I should try it again to test if anything has changed. <Saone>I was looking at building my own image and the configuration file seems more straightforward in that case, but the prebuilt VM image I'm a little lost on <mange>Yeah, I don't think you can modify the VM image, I think you'd have to build your own image (maybe using the VM image as a base: I assume the config is in the source tree). <mange>The other option is to stop guix-daemon through shepherd and run it yourself, with the environment you want. <mange>So, something like: `sudo herd stop guix-daemon` followed by starting guix-daemon in the correct environment. <Saone>Any idea if I can supply environment variables in herd? <mange>I don't know exactly how guix-daemon is run, though, so I'm not confident enough to tell you what flags to run it with. <mange>Shepherd can definitely set environment variables, but I don't know how to tell a running instance to add environment variables. <Saone>lol, "guix perform-download: error: refusing to run with elevated privileges (UID 0)" <Saone>is there a user I should run it as? I dunno the system users in guix <marusich>Saone, I think this might be the operating system configuration file that was used to generate the vm image: guix/gnu/system/examples/vm-image.tmpl <mange>I don't know what user you're meant to run with. Unfortunately I'm not running GuixSD, so I can't easily check. <Saone>Oh interesting, found the file <marusich>I'm pretty sure guix-daemon is intended to be run as root. <marusich>Primarily so that it can create chroots and all that <Saone>It wasn't happy with that? lol <marusich>I can tell you that my guix-daemon in GuixSD is happily running as root, so running it as root is probably not the problem. <Saone>I got that when running `guix package --install vim`, it appears to be guix output rather than guix-daemon <marusich>Well, you ought to be able to run "guix" as root, also, in order to manage root's installed packages if you really want. But I realize that isn't very helpful information. <marusich>If truly you are unable to run "guix" as root due to an error like that, I would be surprised. Maybe it's a bug. <marusich>FWIW, I was able to run that command "sudo guix package --install vim" without issue. <Saone>Hmmm, if I unset my proxy environment vars it still gives me that error instead of the usual "could not connect" so something else seems to be going on <marusich>I am using a version of guix from a few weeks ago <Saone>Yeah, I have a guix VM running outside our proxy and was able to run it as well <marusich>Weird. I wonder if perhaps it's a VM limitation...? It seems unexpected; you might consider filing a bug report with steps to reproduce. <Saone>(also, if I have an https_proxy env var it spams "substitute: warning: `https_proxy` is ignored" at me like crazy) <marusich>I'm afraid I have to step aside for a bit, but perhaps someone else can help you troubleshoot further. It sounds frustrating :( <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? <marusich>I believe there is a "utils" output, so so you'd install it with something like "guix package -i bind:utils" <sadiq[m]>hm.. installing 'bind:utils' installs bind too. Can I avoid that and install only 'bind:utils'? <marusich>guix package --list-installed | grep bind <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 <somebodyelsemayb>marusich: to be fair, I didn't mean the two questions to be directly related. mostly, I've just never seen a verify command specify a server <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 <ludo@gnu.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>If that's the case, though, I think you've got bigger problems. <somebodyelsemayb>well, the server log agrees with my interpretation of reality, so today's looking pretty good <marusich>I think that depends on what you want to do <happy_gnu[m]>I haven't had the time to read the articles of NixOS but I will read them <marusich>I haven't read all of it, myself, but it's on my to-do list. :) <marusich>Reading is all well and good, but it's also necessary to play around and try to code some stuff yourself. <happy_gnu[m]>:/ that's probably my problem I am not creative to know what to do <marusich>One thing that I did when I was learning about scheme and data structures was to try to implement a simple data structure in scheme. <marusich>It doesn't take much creativity to implement a known data structure or algorithm, but it's a decent way to get used to writing in a language. <marusich>Maybe you could try doing some of the SICP exercises in Guile scheme? <marusich>A heap is a type of data structure; you can read about it in many textbooks on data structures, and online, too. <marusich>They're not too complex, and they're pretty useful. <marusich>Another common one that can be fun is a hash table. <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. <marusich>It's not very technical, so it's pretty easy to ead compared to the rest <happy_gnu[m]>But with the earthquake (mexico) I just didn't had the mind to do it <marusich>That's totally understandable :) When you get around to packaging it, if you have any questions, I'm sure people here or on the email list will be happy to help. <brendyn>on guixsd, when i try to a site it says content encoding error... page uses an invalid or unsupported form of compression <brendyn>looks like it fixed it's self when i 'refreshed' icecat <ng0>what's wrong about this sed if its expression matches the /gnu/store/foo-… part of the shebang? sed 's/\\/gnu\\/store\\/[a-z0-9]{32}-bash-minimal-4.4.12//' ltmain.sh <ng0>is sed picky and wants the #! infront of it? <ng0>plus the rest afterwards (/bin/sh) ? <ng0>the iuntention is a quick un-patchshebang so that I can forget about ltmain.sh for a while <roptat>you need sed -i 's/...//' ltmain.sh to transform a file directly <ng0>but it doesn't even work on standard output <ng0>or is my understanding of the output of sed wrong? <roptat>ah, sed 's|/gnu/store/[a-z0-9]\\{32\\}-bash-minimal-4.4.12||' should work <ng0>that || at the end is intentional or a typo? <roptat>and I use | as the separation character so I don't have to escape / <roptat>is a convention, but you can use anything, try "echo ab | sed 'sbabcb'" ;) <ng0>I hope to learn more sed and awk.. useful, but stil a bit cryptic to me <ng0>correction: I will learn more. it just takes some time <ng0>got to go. many thanks! <ggarrmmoo>ERROR: In procedure connect*: Connection time out <ggarrmmoo>guix pull: error: failed to download up-to-date source, exiting <Apteryx>Trying to build latest master, I get: gnu/services/avahi.scm:119:4: gnu/services/avahi.scm:119:4: In procedure allocate-struct: Wrong type argument in position 2: 5 <Apteryx>It seems nothing changed in that file, so I'm a bit loss. <rekado_>Apteryx: did you run “make clean-go”? <Apteryx>oh, I didn't. I can't seem to learn that one ;) <Apteryx>abi breakages are quite frequent in Guile it seems. <Apteryx>(I remember this has to do with changes in the number of fields of records or something along that) <sadiq[m]>anyone I can talk about fixing glib compiled schemas issue of gnome-control-center and gnome-tweak-tool? (I wish to propose a fix for guixSD) <mekeor>maybe just ask? or just mail to a mailing-list? :) <sadiq[m]>hm.. which mailing list should I ask? report a bug? or dev list? can you please provide the link to the list? thanks <rekado_>sadiq[m]: is it a bug? Then please send email to bug-guix@gnu.org <sadiq[m]>I'm sure someone has filed this bug, let me search the database <rekado_>sadiq[m]: in that case please send email to 26215@debbugs.gnu.org or 28167@debbugs.gnu.org. <sadiq[m]>yeah. I'm trying to decide which one should I mail (or should I mail ever). :) <sadiq[m]>won't guix lint find licensing mistakes in package definitions? <sadiq[m]>How can I run gnome-calendar? It doesn't find evoluion-data-server (probably not running) <mray[m]>Do I get this right: GUIx has no plans for a GUI software manager? <ng0>no one will stop anyone for taking on this task though <sadiq[m]>mray: may be someday packagekit will support guix, and we will have gnome-software :) <mray[m]>sadiq[m]: wow! awesome. I didn't know this was a thing! Somebody absolutely should get guix under the hood there! <mray[m]>having installed guix on ubuntu - how do i know what binary is firing up when i start one of my inkscapes? (ubuntu and guix seem to have the exact same build in their repos) <jonsger>mray[m]: "which inkscape" in your terminal <hooverville>mray[m]: also can do 'ps aux | grep inkscape' and check the path of the inkscape that is running <mray[m]>hooverville: jonsger tahnks for the hints! <mray[m]>hooverville: ps aux | grep inkscape does not seem to provide hints though <mray[m]>jonsger: which inkscape only shows one path (the guix one) o_0 <jonsger>mray[m]: yeah, so the guix one seems to be "active" <mray[m]>hmm. how would i go about starting both next to each other?! <hooverville>mray[m]: maybe try just 'ps aux' and look for it manually <hooverville>nm that doesn't work either, weird because emacs will show path <ggarrmmoo>When run "guix pull", I got this error message: <catonano>has the manual a section/chapter about system tests ? I was suggested to rely on system tests in order to write a service <catonano>ggarrmmoo: I saw a thread about a weird behavior with cgit on the mailing list <civodul>you're pulling from which version of Guix? <ggarrmmoo>Hi. Fresh installation, from usb install. Version 0.13.0 <civodul>ACTION .oO ( why am i compiling Vim? ) <jonsger>civodul: maybe you need an editor :P <civodul>it seems to be a depdendency of GuixSD somehow ***abbe_ is now known as abbe
<mray[m]>ok i have blender installed through apt and through guix - how do i fire up the guix one? (seems like GNOME only links to the apt) <civodul`>mray[m]: make sure to have ~/.guix-profile/bin in $PATH <civodul`>yes you can, just specify the absolute file name of the executable <mray[m]>how do i find out the absolute filename of guix's blender?