<amz3>ConfusedLizzard: send a mail to bug-guix@gnu.org with a proper subject <apteryx_>Do we have a docker container service in Guix? <str1ngs>apteryx_: docker is not even a package <nekroze>how does guix manage secrets in the store? are they plain text? I am thinking of switching from nixos and it seems `guix system vm` mounts the guix store, I know in nixos this can be a security problem as secrets are currently stored in plain text when they are used in nixos config files for services and am hoping guix avoided this issue. ***zero is now known as Guest12408
<Guest12408>the web irc client at guix website doesnt work from default web browser and icecat, do you have same problem? <Guest12408>how to use os-prober? and where to find emacs init file? ***Piece_Maker is now known as Acou_Bass
<g_bor>When bootstrapping, what is the accepted way to go? Inherit the default package from the bootstrap one, inherit the bootsrap package from the default one, or to have two independent definitions? ***contrapumpkin is now known as {-_-}
***{-_-} is now known as contrapumpkin
<ng0>hey, does this sound familar to anyone on a recent HEAD of guix: guix/packages.scm:723:2: guix/packages.scm:723:2: In procedure private-lookup: No variable bound to %make-hash-table* in module (guix memoization) <ng0>and if so, just run make clean to fix it? I'm not always near a power plug here :) <ng0>recent: aa5c206348b5606cc82bb1436aca5c9675332993 <ng0>well damn that's old, I didn't rebase the branch <ng0>I guess I can fix it. I'll be back if not. <kmicu>ACTION assumes it is trolling, b/c that user wants a working GNOME and proprietary nVidia drivers. <pkill9>that's posted to the nix ppl tho <pkill9>nix provides proprietary nvidia drivers i think <kmicu>Title suggests Guix has all of that. Pure antagonizing. <pkill9>i think they're referring to the quality of the package definitions <kmicu>Which in case of GNOME is terrible in both? :) <kmicu>Nixpkgs is order of magnitute bigger than Guix so they have terrible and excellent package definitions. <kmicu>(It is all about reproducible builds. Debian/Nix/Guix help each other. It sucks to see such clickbait-level issue title.) <boegel>is there an easy way to tell how many packages are currently supported by Guix? <ng0>compiling the checkout again fixed it :) <boegel>alezost: that makes sense, thanks <alezost>boegel: np; or if you use guix, you may use "guix package --list-available | wc -l" <boegel>kmicu: what makes you say Nixpkgs is order of magnitude bigger than Guix? I'm getting a count of 6.7k for Guix & for Nix about 8k <boegel>alezost: so, what does that spit out for you (I don't have Guix installed anywhere, but I'm planning to play around with it since I <kmicu>boegel: how did you measure both? I am familiar with both system, I have both. Please, do not tell me that you have counted packages from Nix web page :) <kmicu>(Nix(pkgs) hides haskell/tex and so on packages, b/c there is too much of them. What is on Nix web page is limited set from Stable channel.) <boegel>kmicu: nix-instantiate --eval -E 'with builtins; length (attrNames (import (fetchTarball "github.com/NixOS/nixpkgs-channels/archive/nixos-17.09.tar.gz") {}))' <kmicu>Exactly. You are missing ~20k packages with that command :P <boegel>kmicu: well, excluding TeX makes a lot of sense to me, that's really one big +1 <kmicu>This is why users should not jump to conclusion if they are not familiar with both systems. <ng0>is this packages OR outputs in Nix and Guix though? The numbers differ for both on both sides <boegel>kmicu: I'm not, I'm asking questions (and will let people familiar with the projects review my comparison) <boegel>kmicu: up for reviewing my talk, since you're familiar with both Nix & Guix? ;) <kmicu>boegel: ah, that was not direct at you, but at that issue linked by me. <boegel>kmicu: sure, but it's a valid statement in general too... making a comparison like this is very difficult when not being intimately familiar with these tools <boegel>kmicu: ok, so do you know of a better way to compare counts in Nix & Guix? <ng0>oh, on topic: just a couple of moments someone came to the booth here nad they were familiar with Nix but not with Guix. I should have Guix and GNUnet signs in addition to secushare :D Maybe we should have had someone at chaos congress for an official booth other than my meta-booth :) <kmicu>I am not sure. There are many issues like e.g. Guix bundles whole TexLive. How should we count Nixpkgs packages which are packaged blobs? What about proprietary packages. What about quality? What about autogenerated packages? <boegel>TexLive should be counted as one imho <ng0>guix bundles texlive? what do you mean? <ng0>we went through some effort to split it up <kmicu>boegel: E.g. I do not care about proprietary packages in Nixpkgs. Those give me no value. So the measuring contest could be misleading for users like me. <boegel>kmicu: quality is hard to judge, you'd have to pretend all packages are equal there <boegel>and I don't care much whether it's proprietary software or not in this context <ng0>you can get a lagging external counter via this repology thing <kmicu>ng0: in Nixpkgs TexLive is granular. I can install only arbitary 10 packages from CTAN. <ng0>how is this related to my question? I don't fully understand your reply <ng0>what has CTAN to do with the state of Texlive in Guix? <kmicu>How to install 5MB big closure of some Tex packages on Guix? <kmicu>How to install ONLY 'ulem zapfchan zapfding'. <ng0>sorry, it might be a language barrier, but I don't understand what you're getting at <ng0>well you import the package and make a package from it <ng0>or you install it if it's available <ng0>we don't have all of ctan at the moment, but a good part <kmicu>I am saying that with Nixpkgs I can install only those Tex packages that I need. They are not bundled in a big meta-package. <ng0>you still have the meta-package but you also have inidiviual small packages of Tex <ng0>this happened in the last 6 months <kmicu>How to install now 'ulem' from Guix? <kmicu>I am not talking what is possible. Of cource, I can package it for myself. <ng0>guix package --search ulem spits out nothing, so you have 2 choices: 1) create a package for it via help of the import function. 2) use ctan however you'd use it anywhere else <ng0>there isn't even an 'ulem' package on ctan <kmicu>Yes, that's the issue. In Nixpkgs I do not have to do any of that. <ng0>ACTION doesn't get the issue <ng0>it's not even a 'works for me' thing.. I don't understand how all of this relates to the original claim that Texlive is bundled in Guix <ng0>and Ulem or ulem is not existing package at Ctan upstream <kmicu>Are there seperate definitions for TexLive packages in Guix? :) <ng0>user@abyayala ~$ guix package -A texlive-* | wc <kmicu>And that's the problem. TexLive in Nixpkgs has couple thousad packages. How should we count that? <ng0>i don't know the upstream numbers of ctan, but as a team as small as 20 regular contributors and around 70+ contributors to every release one can hardly expect that we have all of ctan <ng0>if someone wnats to have ctan, they'll work on it <kmicu>Oh my, I am not attacking Guix. I use Guix as my primary system. <ng0>I didn't understand it as this <ng0>I was just generally saying: if there are no more ctan packages in Guix, people can add them. The issue is that Nix has more contributors than Guix <kmicu>And I am not talking what is possible, but what is available for users right now w/o any additional work. <ng0>so they have the people power to maintain this. we could have an recursive importer for ctan... <kmicu>I assume this is what boegel wants to show. What is available today. W/o any additional work. <ng0>we have 0.2% of Debian stable :) <ng0>I think Nix is half the size of Debian <ng0>what's available today is difficult.. depends on what someone wants today <pkill9>when the Guix websiet says it's compatible with the nix store, does that mean it is able to use the Nix packages as well or are the builds vastly different but it's able to store them in the same store? <pkill9>debian stable is so out of date though i think <ng0>nevertheless it has a well maintained good number of packages used by a large community <ng0>idk about nix compatiblity, someone else has to answer that, wasn't my field of interest so far. <kmicu>pkill9: iirc that paragraph is not valid anymore. <ng0>are you sure or are you just guessing? <kmicu>That was already discussed in the past here. I am sure you will not find even one user doing that. I will be happy to be proven wrong :) <kmicu>pkill9: could you link to that page please? <kmicu>Yep 2016-11-28 civodul spacekitteh: they've become slightly incompatible lately <kmicu>2016-11-28 civodul namely, the daemon protocol is a bit different <boegel>kmicu: that's exactly what I'm after: what is available today, w/o extra work <boegel>kmicu: so, the count I have now for Guix includes about 100 texlive pkgs, while the full count for Nix would include many more? <boegel>still a fair comparison then, imho, if more stuff is packaged up ready to go in Nix <kmicu>boegel: in case of TexLive: Guix and Nix has the same number of packages, but Nixpkgs let us install them granulary. So numbers are differnt, but result the same for both :) <boegel>that's a good way of messing up the count, but as long as the numbers I use reflect the difference in scope, I'm happy :) <kmicu>The joys of TexLive Tex distribution. My point is that there is a lot of exceptions from the rule. <boegel>yeah, it's very hard to come up with an exact number, but a reasonably fair number that can be used to compare scope is basically what I'm after <kmicu>Another example: 'NIXPKGS_ALLOW_UNFREE=1 nix-env -qaP '.*' -f '<nixpkgs>' -A haskellPackages | wc -l' → 12406 :) <boegel>EasyBuild has about 2k, but is heavily biased towards (only) scientific software & its deps <boegel>kmicu: someone in #nixos is showing me how they come up with a count of 25k :) <kmicu>So we are in an area of creative accounting. <boegel>well, maybe, but I'd still like to come up with an somewhat objective number, I'm not trying to favor a particular projec <boegel>how wrong does a count of 6.5k for Guix vs 25k for Nix sound to you? <kmicu>This is why I do not like those numbers; people tend to misinterpret them. Those 12k Haskell packages gives nothing for users not using Haskell. They are not only programs, but majority are libraries. <kmicu>boegel: heh, my answer is: It's complicated, but a user will find order of magnitude more packages in Nixpkgs including binary blobs installed by firmware-linux-nonfree :). <boegel>kmicu: well, I'm still getting that message across I think <boegel>I can easily come up with examples of "big" applications supported in EasyBuild that are not available through Guix or Nix :) <kmicu>Choo choo! New Emacs-Guix 0.3.4 goodies. ヽ(*＾▽＾)／ <vagrantc>boegel: would it be easier to count sources of packages, rather than "installed" packages ... <vagrantc>boegel: e.g. u-boot in guix can build multiple u-boot variants for specific hardware, but the source is from the same codebase <vagrantc>not sure if that information is easy to get with guix, nix, etc. <shiranaihito>is there a "working directory" setting for calling guix on the command line? <lfam>shiranaihito: Can you clarify what you mean? <shiranaihito>lfam well, i realized i don't need to do it after all, but i meant setting the path that guix uses as the basis for "local-file" paths <lfam>I'm not sure. Maybe somebody else knows? Otherwise I'd guess it's relative to the source file <shiranaihito>it seems to be relative to the system config being applied <shiranaihito>when a system config has some "related assets", you might want to keep them somewhere other than right under the directory where the system config itself is <wigust>shiranaihito: Do you mean absolute path? <shiranaihito>but if you were to set a base path for the guix command, you might well use an absolute path :p <wigust>shiranaihito: I don't understand what is base path. As I know there exist only relative and absolute paths. <shiranaihito>i meant "base path" like a path that serves as a basis for another path :) ok.. let's get this over with :p. so if you have a (local-file "path/to/file.scm"), then if you could set a "base path" for lookups like that, then guix would try reading: "<base path>/path/to/file.scm" <shiranaihito>now it reads "<directory-that-contains-system-config-being-applied>/path/to/file.scm" <wigust>shiranaihito: so the "<base path>/path/to/file.scm" path is absolute actually, no? <wigust>shiranaihito: you could (define %base-path) and then (local-file (string-append %base-path "/file.scm")) <wigust>(define %base-path "/src/git") for example <shiranaihito>wigust yes but i want to give "base-path" as a command line argument, depending on the situation <wigust>shiranaihito: ah, so you want a Guile script which reads command line arguments and then evaluate building a system definition <shiranaihito>wigust well, if i insisted on being able to give guix a base path, then i guess i would :P <ng0>lfam: do you know anything about the decision not to include #:log-file to the mcron service or if it was just forgotten? we've been looking at an mcron definition and a friend wondered why there are no standard logs for mcron like for other crons on ther systems. <lfam>ng0: Why me? :) Was I involved in a discussion of that feature? <ng0>no, I just don't know all the names of the people longer involved than I am :) you're at least around as long as I am <ng0>and I saw your name a couple of lines back <ng0>git böame gnu/services/mcron.scm I guess :) <ng0>oh. log says civodul is to blame for all of it :) <ng0>sneek: later ask civodul: why was there no #:log-file for the mcron service provided? are there any reasons at all or just because it didn't make sense to you at the moment you were writing it? <ng0>I hope ask works as well as tell <lfam>Yeah, they seem to be equivalent <jrandall_>does GuixSD support some mechanism for instances to be configured at boot time (something like cloud-init) in order to configure root device, network settings, and ssh authorized keys? <lfam>jrandall_: On GuixSD we use something called Shepherd which does init / service supervision / configuration in Guile. I'm not sure how it compares to cloud-init <jrandall_>On openstack we can provide instance-specific configuration via either a metadata service (i.e. a document accessible via link-local networking, something at the URL prefix http://169.254.169.254/) or on an ISO volume available via a block device, both of which can provide cloud-config and user data, which contains instance-specific metadata. Is there a GuixSD way of making use of this run-time contextual information without having to generat <lfam>I haven't heard of anybody doing that yet, but the sky is the limit <jrandall_>AFAIK, cloud-init is a package which is configured to run at boot and which on the one hand has support for the cloud-config formats and distribution mechanisms supported by various cloud providers and on the other has some rules for how to apply that information on a particular OS (e.g. by setting up network interfaces and adding an ssh public key to the default user) <jrandall_>So, presumably cloud-init itself could be packaged for guix and support added to it for setting up GuixSD. <lfam>We have tools in GuixSD for generating various types of virtualized OS instances and disk images from Guile code. So I guess the interested parties would need to get familiar with that and decide whether to extend that or build a layer between cloud-init and our tools <lfam>The relevant commands are `guix system vm`, `guix system vm-image`, and `guix system disk-image` <lfam>Not being familiar with cloud-init, it's hard for me to give specific advice, though <jrandall_>Thanks. Is `guix system vm-image` what was used to generate the qcow2 image available for download? <lfam>I'm sure someone else here could do that <lfam>The GuixSD installer image is created with `guix system disk-image`, and configured with the file 'gnu/system/install.scm' from our source tree <lfam>Hm, I'm sorry, my answer was wrong. I think your hunch was right <lfam>I forgot we offered the qcow2 image <jrandall_>It seems I will need to change the root device from /dev/sda1 to /dev/vda1 <jrandall_>To get it working on openstack with a virtio device <lfam>I think that the qcow2 image we distribute was created based on 'gnu/system/examples/vm-image.tmpl' <lfam>Currently it targets VPS hosters that accept raw qcow2 images, which I think is unusual. We recently got support for so-called "ISO" images which are more commonly accepted by VPS hosters <lfam>You can see it's very primitive, requiring the network to be configured after booting for the first time, etc. <jrandall_>I've gotten the qcow2 raw image to boot on our openstack private cloud, but it boots into "bournish@(guile-user)>" (a rescue shell?), because it doesn't have the right block device for the root device, so I guess I'll try building an image of my own. I guess I'll make a new qcow2 image myself with the correct block device, and then figure out how to get the network and such setup after boot - I assume if there is a way to do that manually, th <lfam>jrandall_: Your messages are getting truncated <jrandall_>Oh, huh - not sure what the limit is. The last one ended with: <jrandall_>I guess I'll make a new qcow2 image myself with the correct block device, and then figure out how to get the network and such setup after boot <jrandall_>I assume if there is a way to do that manually, then there will be some way to script it on startup! <lfam>I think the best thing to do is figure out if the network interfaces will be consistent across VM instances, and then just set it up when creating the VM image so that it works out of the box <amz31>Hello, I have an old guixsd that I can't update, when I guix pull, it fails the tests for 'tar' <jrandall_>oh, but we don't have DHCP - the IP address as well is provided by cloud-config <amz31>Can I do a binary installation on top of the current installation and relaunch guix reconfigure to update? <lfam>amz31: I worry that would involve overwriting /gnu/store which could get really messy <wigust>amz31: you could try to get a local guix checkout working <amz31>actually I can try to do an install from scratch