<roscap>hai! i just booted into my first native guixsd install, but im stuck at the bootloader-installer phase. i'd appreciate any help. i have an "efi system" partition with the necessary boot flags, mounted at /boot/efi, but it keeps failing: "failed to get canonical path of '/boot/efi'"
<roscap>what could i do to debug this? ive been following the guixsd 0.14 manual
<buenouanq>I've had this happen and I don't exactly remember what the cause/fix was.
<civodul>mbakke: did you try switching to gcc@6 in core-updates?
<civodul>well indeed, the C_INCLUDE_PATH issue bites
<civodul>rekado: i'm testing a patch for the prlimit64 story
<thomassgn>the result of guix pull is another store item -latest ? is there a reason why we can't have guix pull --roll-back ?
<civodul>thomassgn: no good reason, that'll come in due time :-)
<thomassgn>Cause it seems like one of the few problems that have been around since I became a user - that possibly breaks a system... Do you think it is similar enough to one of the other roll-back's that I could have a look at it?
<civodul>good question, that would need to be discussed
<rekado>it would likely be a little different from profiles.
<rekado>for guix pull we may want to record more than just a number but a timestamp or upstream version.
<ng0>so without linking to code: I used to have a kernel which simply inherited from linux-libre and changed what I wanted (search for "inherit" in the gnu/packages/ in the guix source). Later on I changed it to rewrite the gnu/packages/linux.scm to not depend on changes in linux-libre. The module is in my GUIX_PAKCAGE_PATH and I import it i nthe config.scm for the operating-system at the moment with something that
<ng0>would translate to (use-module path to module)
<ng0>I hope my inaccuracy was still alright for you to understand the general idea
<ng0>so (path to module) includes the public definition for FOO. and then you'd write (kernel FOO) in the operating-system declaration
<thomassgn>haha, I love this, I just realized I've started doing like 3 new mini projects the last hour or so. Starting from wanting a notification of battery-low; to reading dbus and upowerd documentation, to adding documentation for the dbus package, to trying to get the guix source hacking env working with direnv++ to trying to understand and use yasnippet - which I just finished. And I'm like - where was I? where does
<thomassgn>hmm, looking at gstreamer to understand how outputs work: 'guix build gstreamer' gives both doc and out, but 'guix build gstreamer:out' and gstreamer:doc gives me "unknown package"
<thomassgn>maybe I should look at another package with outputs...
<bavier`>thomassgn: 'guix build' cannot build individual outputs, and thus does not understand the output suffix
<zybell_>Here is something I thought about since I read about guix: Why does guix need a package manager? Let me explain: I have a store indexed by the hash of a unique file. Or as long as that does not exist a provisional identifier derived from the PID of the process creating that file. That file contains the commands to symlink the installed files/binarys into a rootfs. The binaries are named after their content, so the file differs for every
<zybell_>version. Each package unpacks into its own rootfs, where it uses the scripts of its dependencies to link them in. One of these dependencies provides an install program (literally called 'install') that renames/hardlinks files according to their content, symlinks them into place and records that symlink into the unique file. That would make all package management distributed to these linkfiles. Therefore no need for a package manager except for
<zybell_>convenient interface. Or do I miss something?
<thomassgn>bavier`: aha. it's only for guix package -i and similar declarative expressions then?
<bavier`>zybell_: in what you describe, the package manager would be responsible for creating those "linkfiles"
<roptat>for instance, most ocaml packages expect to be installed in the same directory as the ocaml compiler
<thomassgn>zybell_: I'm not sure, but I think a lot of the remaining work (if we assume that all packages use wellformed autotools) is on the part of hacking the user env. to go around the lack of FHS support, choice of which file is "current" (e.g. if you have several coreutils installed) and such things.
<roptat>so they would call `install META /gnu/store/...-ocaml/lib/ocaml/site-lib/my-lib`
<thomassgn>These things sounds so simple often, but I know I'm not smart enough to start to solve all the problems that would start arising, and that is just for me. I mean read the source for ls to get a little peak into edgecases and weird shit you have to take care of... :P
<thomassgn>sorry if that came over as a hostile/negative response zybell_. It was meant as critical input - not to shut down you inquiry, but I see it came out differently than I wanted. Language is hard :P
<zybell_>roptat: thats fine with me. Pls note that I provide an entire FHS where the program can install anywhere. Only its recorded. And will be replicated in any pkgs that *depend* on that behavior.
<thomassgn>I guess the real question is, how much of this do users need to understand to use it?
<amz3>I have an issue with my locale using guile, I installed glibc-utf8-locales and set GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
<zybell_>thomassgn: In the first it came over absolutely unclear. I would like to understand which problem you forsee.
<amz3>when I call (setlocale LC_ALL "") it errors with the following message: In procedure setlocale: Invalid argument
<thomassgn>zybell_: oh, right. I might not be understanding your proposal all that well, but I see that guix does a lot of work to keep environments (like a users PATH and so on) pointing at the correct thing. And as I understand your proposition there would be a lack of roll-back possibility for instance (which is one of 2 major reasons I use guix). I've also followed a bit of the discussions that happened when (or one
<thomassgn>of the times?) gentoo looked into moving some of their FHS related files (I think they wanted everything in /usr/(s)bin instead of /(s)bin to save space in initramfs or something) and the amount of technical problems arising from those efforts (there was of course a hole lot of bikeshedding and other non-tech arguments).
<thomassgn>So I what I may be trying to say is that I think guixsd is awesome, and I don't see much reason to simplify it. It could ofcourse be an interesting project for people into slackware or similar, but I think it would demand a whole load of work, most of which is impossible to foresee.
<amz3>seems like host glibc and guix glibc must match.
<zybell_>thomassgn: I did not mention it explicitly, but of course I would write the 'linkfiles' in a way that a special argument turns it into remove-what-you-created.
<zybell_>And no a real rollback is not possible because you cant 'uncompile' a pkg. But garbage collection is, if the 'linkfile' marks the linked-to dir as used, which is easy with a special patch-file.
<thomassgn>huh, and './pre-inst-env guix package -i dbus:doc' says it cannot connect to `/gnu/store/guix/daemon-socket/socket': No such file or directory, ofc. that doesn't exist, but how can I tell it to look for th daemon socket in guixsd's socket dir? I can't see sockets mentioned in the pre-inst-env script either
<zybell_>thomassgn: it can be as declarative as you want to define 'declarative'. Granted it is a shellscript, which means imperative if you look at the way it is executed. But on the other side it is a textfile mentioning pkgs to import one line after the other. Its a matter of definition.
<zybell_>rollback: Granted you can't take back all changes, so its no rollback. But you can take back all 'observable' changes (for an appropriate definition of observable), so its a matter of definition too.
<ng0>aw crap. I broke downloads through my recent crashed server and its restore. Sending patches to fix it :/