<nckx>Guix doesn't look at packages' inputs to determine dependencies of store items, it looks only at embedded store references.
<alextee[m]>nckx: is this the command to check them? guix gc --references /gnu/store/....-mypackage ?
<nckx>So your ‘understanding’ above is correct, but your reasoning is not 🙂 git is a native-input because it runs at build time, and has to run on the host (say an x86 machine when you're compiling for an AVR chip). A static library contains compiled code that is embedded in the final resulting AVR binary, so it can't be ‘native’ (x86). Does that make sense?
<nckx>I chose AVR as example of an ‘exotic’ arch, but it coulde be anything.
<alextee[m]>nckx: ahh okay, i see what it means now and what the "native" stands for. thanks for clarifying it!
<nckx>Yay! I love this moment. I agree it can be confusing, but it does make sense.
<nckx>Once you realise that Guix doesn't trust packagers to say what needs to be kept around as a run-time dependency but figures it out itself, thank you very much, it starts to click.
<alextee[m]>yeah just not used to this way of describing packages. other distros are usually "these are the build requirements" and "these are the runtime requirements" so i thought it was the equivalent, but i see guix is much more elegant
<nckx>‘inputs’ just throws things into the build environment. Only what comes out is a dependency.
<mbakke>I suspect it's mostly confusing for people with experience packaging for other distributions, where 'inputs' typically equate to what Guix calls 'propagated-inputs'.
<alextee[m]>"‘inputs’ just throws things into the build environment. Only what comes out is a dependency." i should post this somewhere to remember it
<nckx>alextee[m]: Like all things it has its own gotchas and tradeoffs (references can be ‘hidden’ in e.g. compressed jars, which is why Guix installs uncompressed jars) but yes, on the whole it is much more elegant.
<alextee[m]>so basically propagated-inputs are for dependencies that are not referenced but must be installed manually along with the package ?
<nckx>To (very) roughly paraphrase the Nix thesis: ‘this sounds like it shouldn't work half as well as it does in practice—but it does.’
<User-77785>l have negative effects in the future. Should I follow those instructions? is there a long-term solution? will that cause issues if I update glibc and guix gc?
<User-77785>odd.. maybe I'm wrong about this. "ldd ./rustup-init" says "/lib64/ld-linux-x86-64.so.2 => /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2 (0x00007f7880f60000)", which makes it seem like it does know where glibc is
<User-77785>ahh, here's the culprit: "libgcc_s.so.1 => not found". Find finds it though: /gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib/libgcc_s.so.1
<User-77785>super strange. after `patchelf --set-rpath ...`, `ldd ./rustup-init` no longer says "not found" for any of the libraries... but I still get this error "zsh: no such file or directory: ./rustup-init"
<funfuna>The wireguard I use is loaded as a module.
<funfuna>GuixSD I haven't used wireguard yet, I have used other distributions
<guix-vits>funfuna: `guix search wireguard` --> "wireguard: This package provides the userspace tools for setting and retrieving configuration of WireGuard network tunnel interfaces, and a patch that can be applied to a Linux kernel source tree in order to build it with WireGuard support."
<funfuna>I think things like vpn or network are not what initrd should do. (Although these operations can be put in initrd).
<guix-vits>interesting, how to chech if Linux-Libre built with this support...
<Blackbeard>drakonis: oh maybe I should write an email like that one too
<drakonis>it did do wonders for uniting distros under a single flag
<raghavgururajan>It does gives opportunity to unite. But instead releasing it as some suite. They released init-system. That fired up things. Why would an init system comes before boot and manage this like dns etc.
<DamienCassou>I'm using `$(guix system vm ./current.scm)` to start a VM running Guix from Fedora. It works but I can't install anything for the guest user inside the VM because the store is mounted read-only. Is that normal?
<mroh>I try to use shepherd as a user. How can i generate a shepherd service file from a guix service? i tried something like "(shepherd-service-file (service bitlbee-service-type))" but that throws in shepherd-service-provision...
<guix-vits>DamienCassou: is `guix install emacs` not working? In manual that was said, that the store writable only by the guix-daemon, and somehow mounted read-only for the rest.
<DamienCassou>> guix install: error: changing ownership of path '/gnu/store': read-only file system
<DamienCassou>in Fedora, `/gnu/store` belongs to user `root` and group `guixbuild`. In the Guix VM, `/gnu/store` belongs to user `root` and group `964`. I guess I should play with the group number in the VM too, right?
<guix-vits>efraim: the manual: `guix system ...` --> "If you built your own image, you must copy it out of the store (see The Store) and give yourself permission to write to the copy before you can use it.". Maybe change it to `guix build ...` ?
<zzappie>I was experimenting with environments recently. I create .genv folder in repository I am working in for storing environments and then use "guix environmet" with "--link-profile --container --user=project-name --share=project/.genv/genvname=/home/project-name". This way I can install arbitrary things like python and npm packages and make this environment persist between invocations
<zzappie>Next step for me is to integrate it with emacs. I thought it would be very cool to use "-- python" for example to start repl with comint within an environment
<infertux>hi there, I've been playing with Guix for a few days after seeing your FOSDEM talk and it looks like it could be a great server distro - no more need for Ansible/Chef/Puppet as everything could be deployed and configured using Guile, is that a fair assumption?
<infertux>however, as a long-time Debian fanboy, I'm wondering whether using a rolling-release distro for a production server is a good idea? should I run 'guix pull && guix upgrade' hourly or similar?
<leoprikler>Running it regularly is a good idea, but you shouldn't spam savannah with requests either.
<mehlon>I'm not sure if it's been done before, but it should probably work
<alextee[m]>the use case is there's 43 separate repositories that share the exact same build/install procedure and dependencies, so i could write what's different in a hashtable and loop over it or something instead of inheriting 42 times
<alextee[m]>ah okay, well i'll see if i'm ever up for that. thanks!
<apteryx>bandali: answering to your comment above native-search-paths in emacs-next: We could use emacs's native extra ":" separator in the search path, and this would take care transparently of finding its own Lisp librairies. The problem is there's currently no way of telling a search-path-specification to include such extra separator.
<apteryx>leoprikler: I think I've found the problem; comparing a successful log to a failed one, I can see: WARNING: (guile-user): `%standard-phases' imported from both (guix build glib-or-gtk-build-system) and (guix build gnu-build-system)
<DamienCassou>I've created a qcow2 image with `guix system vm-image`. I can boot that image and get a nice XFCE desktop running Guix. However, in this guest, `/etc/` doesn't contain the config.scm for the system. How is it possible?
<leoprikler>/etc/config.scm is not actually required by Guix. You can name your config.scm anything you like and it only stays on your disk because guix does not make any efforts to bind or remove it.
<NieDzejkob>DamienCassou: /etc/config.scm is just an example path for the config
<NieDzejkob>if you want to get the configuration anyway, it might be in /run/current-system/configuration.scm
<apteryx>the doc under 8.16 Running Guix in a Virtual Machine refers to /etc/config.scm
<apteryx>it suggests the VM images available for download have this property. If you want to mimick it you could have a look at the operating system examples, perhaps you'll find a plain-file of the config to extend the etc-service-type service.
<DamienCassou>`/etc/current-system` doesn't have any scm file, only folders
<DamienCassou>apteryx: I confirm that this is where I usually found it in new installation
<DamienCassou>even though I have using Linux for 15 years, I feel that I lack to basic knowledge. For example, I would like to understand better what `sudo` exactly does, what is the initrd etc. Do you know where I could learn about these?
<leoprikler>Do you mean how sudo works philosophically or intricately?
<leoprikler>For the high level stuff, there's man pages, for the nitty gritty you'll have to read source code.
<leoprikler>For anything in-between you may find stuff from info-pages to papers and books.
<DamienCassou>I've always known I can execute commands with administrator privelegies by prefixing commands with `sudo` but I don't understand exactly what `sudo` does, especially regarding the shell. I would like to understand the result of `sudo whoami` for example
<DamienCassou>I understand this last sentence. But I would like to understand the impact of it exactly. For example, `sudo guix pull` probably changes the HOME environment variable otherwise we would have root-owned files in the user home directory
<apteryx>DamienCassou: you could look at sudo sh -c 'env' to have an idea of what is going on
<DamienCassou>does any of you know why /gnu/store is shared read-only in a VM?
<leoprikler>because otherwise you could modify the disk-image (probably)
<leoprikler>and that's a no-no when said image itself lives in /gnu/store
<DamienCassou>is it possible/recommended to copy the vm image to my home directory and then arrange for /gnu/store to be shared?
<NieDzejkob>I built an installer image with "./pre-inst-env guix system disk-image --file-system-type=iso9660 gnu/system/install.scm" and ran it with "qemu-system-x86_64 -m 3072M -cdrom /gnu/store/0wwsa2lsqrg7rfl46j5hh3vwfhxs1pcw-image.iso". The TUI installer does not start, it flashes the screen blue a few times and then stays black. Am I doing something wrong? When I use `sendkey ctrl-alt-f3` in the QEMU monitor, I can access the shell login normally
<leoprikler>"If you built your own image, you must copy it out of the store (*note The Store::) and give yourself permission to write to the copy before you can use it."
<NieDzejkob>huh, does it apply to ISOs? those are usually readonly anyway. I'll give it a go when I'm done testing cow-store stuff
<leoprikler>Not sure about your case. Effectively you have 3G of virtual RAM in your qemu system, so graphics should work.
<DamienCassou>leoprikler: I read that part of the manual. But it won't magically give write access to /gnu/store in the VM. I could do that by tweaking the parameters of qemu but I don't know if it is a good idea that the VM and host can both write to /gnu/store
<DamienCassou>also, /gnu/store isn't writeable by the HOST normal user, only by root. So I don't know if the VM running under QEMU can write to it anyway
<NieDzejkob>apart from /gnu/store there's also an sqlite db that tracks the stuff in the store
<leoprikler>/gnu/store in the VM should follow the same rules as /gnu/store on the host, provided that the disk itself is writable
<DamienCassou>I asked the same question on the mailing list. I hope I will learn even more stuff :-). Thank you very much for all your answers.
<DamienCassou>regarding my earlier question about not finding /run/current-system/config.scm in the VM, it seems to be due to the absence of the `--save-provenance` option when creating the VM
<NieDzejkob>Hmm, I'm looking for a way to make "guix system init" warn the user if they skipped "herd start cow-store". I tried using statfs to check the filesystem type, but it's overlayfs both before and after cow-store. Any ideas on how to best do this?
<nckx>There's an extra gotcha in that the ports on berlin got swapped somehow. 5552 is dmitri. ‘ssh -p 5552 sergei’ will connect to dmitri because it's the same IP (in case I need the flexibility some day).
<nckx>It doesn't really matter in practice since they tend to die together.