IRC channel logs


back to list of logs

<OriansJ`>lfam: whenever I think about time in software, this is always first
<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.
<buenouanq>how is the drive formatted?
<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>What is a form in the following context? ...
<jorgesumle>If you get the line @code{location: gnu/services/foo.scm:188:2},\\nadd @code{foo} to the @code{use-service-modules} form.
<jorgesumle>I'm translating Guix into Spanish
<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?
<wxie>Did miss the answer?
<grillon>hi there
<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
<roscap>i see, ok.
<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>Hello Guix!
<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
<civodul>like you write rekado
<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.
<IntoxicatedHippo>What's the best way to load intel microcode updates?
<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
<thomassgn>wxie: see menu-entries here:
<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
<thomassgn>or I mean writing to your boot partition
<thomassgn>mbr or uefi whatever it is called
<wxie>ok. I will read the manual first.
<wxie>How should I make guixSD control grub if it is not?
<thomassgn>are you on uefi?
<thomassgn>I think you just need to mount your boot partition under /boot for bios and /boot/efi for uefi.
<thomassgn>and then run system reconfigure
<thomassgn>I mean 'guix system reconfigure /path/to/config/file.scm'
<thomassgn>I'm not dual booting, but here is my config for a uefi machine:
<thomassgn>wxie: ^^
<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?
<thomassgn>with like notify or something else?
<mbakke>thomassgn: The 'i3status' bar turns red when the battery is low FWIW.
<thomassgn>aye, but I have it autohide
<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 :-)
<mbakke>That diff looks familiar :-)
<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>my backtracing lead to next :P
<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?
<thomassgn>ACTION runs to the info room of emacs
<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>ACTION learned
<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"
<bavier`>thomassgn: right
<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>s/read/take a look at/
<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
<amz3>how can I debug this?
<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
<amz3>tx pjotr!
<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>(which is declarative OS declarations)
<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 :/
<IntoxicatedHippo>Is there a way to enable trim for a luks device?
<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?
<bavier`>davidl: the "bc" package
<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>oh, I’m sorry!
<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)
<civodul>the editor is Geiser-like, right?