IRC channel logs
2018-03-30.log
back to list of logs
<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. <mbakke>roscap: Try mounting the EFI System Partition at /boot/efi instead of /mnt/boot/efi. There is a bug in the 0.14 installer. <roscap>gosh darn - that did it. thank you so much mbakke. buenouanq, i had formatted it as fat32. in any case mbakke's suggestion solved it, i was mounting relative to /mnt <mbakke>roscap: Glad it worked! It's a surprise to everyone. <roscap>:-))) you dont know how grateful i am. finally ready to plunge into guix <jorgesumle>If you get the line @code{location: gnu/services/foo.scm:188:2},\\nadd @code{foo} to the @code{use-service-modules} form. <efraim>line? grouping? portion? segment? <wxie>In the guix installation page, it says if you have /boot on a separate partition, mount it at /mnt/boot. Is this for detecting another os? <wxie>Won,t update-grub do it? <roscap>how does one revert a "guix pull"? the docs tell me to manually switch the link, but i just installed guixsd and see no other /gnu/store*-latest. <buenouanq>would that mean you have nothing to revert to? so you can't <buenouanq>and guix pull is different from upgrading packages you understand <roscap>yes i think i do. the reason im trying to revert the pull is that system reconfigure is breaking due to a bug in the "pull"ed kernel <roscap>trying to figure out how i can "checkout" the previous version of the kernel <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. <civodul>i'm thinking more of a reflog-like thing <rekado>users could also have multiple versions of Guix and switch between them with an extra option to guix, instead of just using the latest. <civodul>IntoxicatedHippo: GuixSD doesn't help with that, so it's up to the user to decide what to do <thomassgn>haha, sounds difficult :) but I'll have a look. It's a good reason to try and set up a proper working environment for guix anyway. I'll learn :) <wxie>How should I get dual boot with guixSD? <wxie>I installed guixSD, but it is not listed in my grub. <thomassgn>someone correct me if I'm wrong, but I would install guixsd as normal and then add an entry in my guixsd config.scm for the bootloader. I'll find the doc section for you. <thomassgn>currently I think guixsd needs to control grub to be able to give you the choice of system generations when you boot <wxie>thomassgn: Thanks. Do you mean guixSD should be the first system on a machine? <thomassgn>not first necesarily, but it needs to be the system writing your bootloader <wxie>ok. I will read the manual first. <wxie>How should I make guixSD control grub if it is not? <thomassgn>I think you just need to mount your boot partition under /boot for bios and /boot/efi for uefi. <thomassgn>I mean 'guix system reconfigure /path/to/config/file.scm' <mbakke>civodul: did you check if going back to CPATH made a difference for gcc@6? <efraim>Would it be better to just add an extra bootstrap round and use gcc5 to build gcc7 <thomassgn>Anyone have their laptops tell them when battery is low? <mbakke>thomassgn: The 'i3status' bar turns red when the battery is low FWIW. <thomassgn>:) But I could possibly have some acpi or other tool that already deals with this bother me with a message or something <thomassgn>was just hoping someone had something like this running so I wouldn't have to do anything :P <mbakke>I've been dreaming of a "Tasker"-like (of Android fame) framework for GNU/Linux. But don't know any "out of the box" solution. <civodul>mbakke: no, i just wanted to see by myself that it didn't work :-) <thomassgn>is dbus documentation not present in the package output? <thomassgn>or I mean, it doesn't show up in man or info after installing the package to my profile <mbakke>thomassgn: Looks like dbus doesn't build documentation currently. Would you like to try adding it? <PotentialUser-76>Hi,everyone. What should I do if I want to add an extra kernel module on guixsd? <roscap>PotentialUser-76: have you seen the initial ramdisk page in the manual? but i'd also like to know how to integrate a custom kernel. <ng0>you use (linux somethingelse) where somethingelse is the definition you imported in a modle <ng0>I can not link the way I do it here for policy reasons. <ng0>info guix operating-system will have more <ng0>I was wrong. (kernel FOO) <ng0>haven't edited my files in a while <roscap>ah i see. so one would package their own kernel, install it, then reference it in operating-system? <ng0>no, simply reference it <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 <ng0>basically what you wrote :) <ng0>sorry for the bverbosity <roscap>thanks for the info. im still really new to guix - this will help a lot <ng0>could be that pjotr's extension to the Manual has more. <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>Let's see if we can get this env going and add documentation outputs to dbus... :) <civodul>thomassgn: heheh, i know that feeling :-) <thomassgn>huh, dbus is not a define-public? and it is in glib.scm not freedesktop.. Is this ('define dbus' vs 'define-public dbus') significant? <lfam>thomassgn: I think it's done that way to avoid some circular reference <civodul>though actually it doesn't make any difference <thomassgn>right, what is the difference between define and define-public anyway? <bavier`>thomassgn: define-public automatically exports the symbol from the module <thomassgn>it does actually say "Export variables up-front to allow circular dependency with the 'xorg' modul." in glib.scm <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" <zybell_>bavier: that will be the task of 'install' which is called from the makefile in compiling the package. <zybell_>The 'linkfiles' are only another binary output of compiling. <bavier`>sure, I suppose if such ideal packages existed <zybell_>Nowadays every Makefile expects an programm called 'install' to move the binarys into place. That was it what gave me the idea. <roptat>zybell_: not every Makefile is friendly <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 <zybell_>amz3: I think you mean (setlocale LC_ALL "C"). <amz3>zybell_: no, it used to work with "", it's the what is recommended by guile manual <amz3>I think the issue is that I use a different libc <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). <amz3>I forgot to say, I am on Ubuntu/Guix <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. <amz3>so updating the whole thing did the trick <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>what do you do to get emacs working with the src checkout of guix? I mean, do you somehow make C-c . b in guix devel mode use ./pre-inst-env ? <thomassgn>zybell_: ok. then it's missing my major feature #.2 and looks like major feature #.1 also <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 :/ <mbakke>thomassgn: You have to run "./configure --localstatedir=/var" to make your git checkout find the Guix daemon. <davidl>is there any package that contains gnu bc? <davidl>bavier` yeah, thanks. it's getting late now. <efraim>building ovmf for x86_64 from aarch64 is harder than it should be <civodul>rekado: re ao/libfive, i think you forgot a 'define' for the deprecated package <civodul>i didn't know about the rename, but it still looks very cool <rekado>they no longer offer a REPL; instead there’s “Studio” a special editor with a preview pane. <rekado>I updated it because the old ao-cad package crashed for me when I installed it just now. <rekado>(probably related to the fact that it was using Guile 2.0 and that conflicted with my Guile 2.2 packages)