<mark_weaver>suitsmeveryfine, petter: xts is already included in and loaded by our initramfs, by default. <suitsmeveryfine>mark_weaver: thanks. So this probably means that my current desktop install will not help me boot this time either <mark_weaver>suitsmeveryfine: it might be that you need the "serpent_generic" and "wp512" modules. <mark_weaver>wp512 is the module for the Whirlpool hash algorithm <suitsmeveryfine>it's a pity that I can't easily add them after having done the desktop installation <mark_weaver>yes, I agree that problems during the initial install are a pain to deal with. we need to find a way to improve this. <suitsmeveryfine>Are you pretty certain that adding those two modules is going to work this time? <mark_weaver>the good news is that once you have a working install, you can experiment easily and fearlessly with new configs, and always be able to boot to an older system if the new one doesn't work. <mark_weaver>suitsmeveryfine: I'm quite certain that those two modules are needed, but I won't go so far as to say that I'm certain it will work. <mark_weaver>I'm assuming that you created the encrypted partition with this command, from petter's guide: cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --use-random --verify-passphrase luksFormat /dev/<your-partition> <mark_weaver>i guess that needs serpent and whirlpool, and you were lacking the modules that contains those things. <mark_weaver>if it fails again after adding "serpent_generic" and "wp512", then a picture of the error would be appreciated. <mark_weaver>I have to go afk, probably for the rest of the night. good luck! <codemac>trying to build guix in nixos -- anyone had failures in loading the json module? <codemac>seems that the make system finds json, but then later can't? hm. <codemac>hm, the configure script prints out that it can't find json.. then somehow it still gets compiled anyways <codemac>ok, wrote a quick guile-json package for nix :) I'm building this on an 8 core xeon, ... it's still very slow. I wish I understood more about lisp compilation to know even hypothetically what the bottle neck is <Steap>codemac: yeah, I think guile-json is optional <calher>Do I have to enter GRUB commands to boot GuixSD on Libreboot? <codemac>Steap: it's supposed to be, but looks like there is a make bug in 0.9.0 <suitsmeveryfine>mark_weaver: you were right: I only needed to add "serpent_generic" and "wp512" <davexunit>codemac: yes that's a well-known bug from 0.9 <davexunit>it's probably not worth building 0.9 at this point. <mark_weaver>sneek: later tell calher: if you make /boot/grub/libreboot_grub.cfg a symlink to grub.cfg, then the first (default) entry in Libreboot's GRUB configuration should automatically load GrubSD's grub menu, and so then you shouldn't need to type anything to boot into Libreboot. <suitsmeveryfine>but I've accidentally ended up in ratpoison and didn't know any way to exit but doing a hard shutdown :) <mark_weaver>suitsmeveryfine: ratpoison has a keyboard interface similar to GNU screen (in case you're familiar with it) except that the default prefix key is Ctrl-T instead of Ctrl-A. "Ctrl-T ?" will print help, and iirc, to exit you type "Ctrl-T :quit RET" <mark_weaver>that's 6 keypresses after the Ctrl-T, in case it's not clear. <mark_weaver>another way is to switch to a text console, log in, and kill the ratpoison process from there. <mark_weaver>although maybe that's challenging on a MacBook keyboard; I don't know the mapping. <mark_weaver>on non-Mac keyboards, you type Ctrl-Alt-F1 (or F2, F3, etc). <mark_weaver>and Ctrl-Alt-F7 is usually the one where the X server is running on. <mark_weaver>but I don't know how to type that on a Mac keyboard. <mark_weaver>hmm, that's strange. what's the last thing it printed before hanging? <mark_weaver>hydra.gnu.org might be overloaded again. let me check. we are preparing to replace it with a far more powerful machine. <mark_weaver>no, hydra is doing alright. are you doing this from the command line? ("guix package -i icecat"), or something else? <suitsmeveryfine>I just intalled a different package in another terminal emulator and that worked fine <mark_weaver>it's probably a networking issue. we don't yet handle network problems very robustly yet. I would Ctrl-C and rerun the command. <suitsmeveryfine>had to reinstall the system maybe five times just because of that issue <mark_weaver>also, if you run two or more "guix package" commands that modify the same profile at the same time, some of them will not actually take effect. <mark_weaver>suitsmeveryfine: it's partly that hydra.gnu.org is a very underprovisioned virtual machine, with not nearly enough RAM or disk bandwidth. we will be replacing it in the next month or two. <mark_weaver>hydra.gnu.org will most likely be located in a place where multiple Guix hackers live, probably either the FSF in Boston or Bordeaux, France. <mark_weaver>but we may want to have more caching proxy servers in various places, to spread the load. <mark_weaver>the longer term goal is to distribute binary substitutes in a decentralized way over gnunet.. <mark_weaver>but in the medium term, caching proxy servers would probably be a good thing. <mark_weaver>anyway, I have to go afk again. thanks again for working through the problems with the keyboard and encrypted root. you've done us a great service to work through the problems. <mark_weaver>I have commits in my local git repo to add the missing modules, and will push them after we've tested them on other machines. <fhmgufs>What I don't like is the behavior of guix pull to just get new package definitions. <fhmgufs>I think that package defintions should either be seperated from the guix package and moved to another package (e.g. guix-packages). <fhmgufs>The reason is that "normal" users don't need a development version of the whole guix program. They only want to get the most recent package definitions. <lfam>You could end up with Guix packages exposing some new feature being handled by an old Guix that didn't know those features. <fhmgufs>In this guix-packages package there shouldn't be feature changes. If there's a new guix release it would be updated normally. After that the user you could run "guix update" or something like this to get the newest package definitions with the version number equal to the guix release. <fhmgufs>And a minor number to label the updated definitions. <fhmgufs>This new guix-packages package would then make use of the new features. <fhmgufs>For example: I run guix 1.0 :) I get the package guix-packages-1.0-1, update it to guix-packages-1.0-2 including the new guix 1.1 release. Then I install guix 1.1 in the usual way. <fhmgufs>After that I fetch guix-packages-1.1-0 - maybe with the use of new features. <fhmgufs>And between the guix releases I just need to fetch guix-packages to get the new definitions. <lfam>This way users never have to worry about compatibility between the package definitions and the implementation of packages <fhmgufs>It seems to be a download error. Try again. <ugodayn>same result with same unexpected sha256 hash <a_e>ugoday: I just read the channel logs. <a_e>Your problem is probably related to the recent dmd->shepherd name change. <a_e>Could you report it on the bug tracker? <sneek>Welcome back calher, you have 2 messages. <sneek>calher, mark_weaver says: if you make /boot/grub/libreboot_grub.cfg a symlink to grub.cfg, then the first (default) entry in Libreboot's GRUB configuration should automatically load GrubSD's grub menu, and so then you shouldn't need to type anything to boot into Libreboot. <sneek>calher, mark_weaver says: s/GrubSD/GuixSD/ <calher>piyo: I didn't know Xzibit used GNU. <calher>The rapper that did Pimp My Ride. <piyo>I only know it from the "we put xxx in yyy so you can xxx while in yyy" meme <calher>I like GNU Screen better than tmux now. <piyo>Huh tell me more, I only use gnuscreen and I am wondering about the other side <calher>piyo: For one thing, it doesn't always have to have a friggin bar at the bottom, glaring at you all day. <calher>irssi takes up the whole screen. <piyo>uh I turn that on in GNU screen... ._. <calher>Well, in tmux, you have no choice, and I get tired of it. <piyo>How do you know you're inside gnu screen tho? <calher>I know configuring the bar in Screen is a pain, but maybe an abstraction can be made for it. <calher>piyo: I type C-a c tmux RET C-a c <calher>tmux is made my nasty BSD people. <piyo>I am in #emacs and I am fully agree at least for fist-bumping sake. <calher>Perhaps in the future Screen could be configured in Scheme, with good abstractions for things like the bar at the bottom (if you choose to have one). <calher>Oh, how do I copy and paste in screen? <piyo>Sometimes I use gnu screen host1 inside gnu screen host2, so the bottom line is helpful for reminding me how many times to press my screen leeder key (which is C-t) <calher>Whoa, I can't send messages to #screen... <piyo>yeah we should talk in #screen <piyo>its fine if we talk here? there is a copy and paste in screen <calher>How do I copy and paste in Screen? <piyo>I have set it to a non-default, though, C-t c and C-t v cuz I'm a window/cua nerd <piyo>ACTION looks at his config <calher>I stopped using Losedows when I was 11. <piyo>for me it brings home the bacon so ... <piyo>uh it's "copy" and "paste ." <calher>(1) doing things just for bacon is bad; (2) bacon is unnecessary to live a full life. <piyo>In any case I am using Linux and trying to help you. <piyo>Try typing C-a : copy RET <piyo>you have to press space to start and stop the select copy region action. <piyo>If my config comments are correct C-a [ is bound to copy already <piyo>and C-a ] is paste . very nice and symetric <calher>Whoa,,, I accidentally did C-a Z because Dvorak->QWERTY. <calher>Huh? C-w doesn't copy; it just exists copy mode! This goes against both Emacs and tmux behavior. <piyo>btw you can make a sub keymap in GNU screen. Cuz I can't remember that many keybinds <calher>Also, I can't do C-f to move forward, but I can still do C-n and C-p. This also goes against Emacs/tmux behavior. <piyo>i.e. bind -c emacsx "1" only ;; bind -c emacsx "2" split ;; bind -c emacs x "3" split -v <piyo>and then "bind "x" command -c emacsx" <piyo>wat, C-f does move forward in gnu screen's copy mode... mabye I have emacs keybindings on? <piyo>oh I have "bind "^f" next" so maybe It Works For Me. <piyo>oh man, its not that... (setq helm-split-window-in-side-p t ; open helm buffer inside current window, not occupy whole other window <piyo> helm-move-to-line-cycle-in-source t ; move to end or beginning of source when reaching top or bottom of source. <piyo> helm-ff-search-library-in-sexp t ; search for library in `require' and `declare-function' sexp. <piyo> helm-scroll-amount 8 ; scroll 8 lines other window using M-<next>/M-<prior> <piyo>take a look at this: (setq helm-split-window-in-side-p t ; open helm buffer inside current window, not occupy whole other window <piyo> helm-move-to-line-cycle-in-source t ; move to end or beginning of source when reaching top or bottom of source. <piyo> helm-ff-search-library-in-sexp t ; search for library in `require' and `declare-function' sexp. <piyo> helm-scroll-amount 8 ; scroll 8 lines other window using M-<next>/M-<prior> <piyo> helm-ff-file-name-history-use-recentf t) <piyo>oh man Id did again sorry. I mean this: #01# Emacs keys in copy-scrollback mode <piyo>this channel is logged as well, not good not good. <piyo>I added that to my config in 2006. Still works good! <calher>piyo: Are you the guy who installed Guix on Libreboot with FDE? <calher>Crap, I need to get Dvorak keybaord layout on here; QWERTY is getting uncomfortable. <piyo>no, I am just foreign Guix for now <piyo>calher: there's a new melpa package called fix-input that attempts to help you use dvorak in emacs <piyo>I am qwerty pleb tho, so don't ask me about dvorak <calher>piyo: Cool; so I don't have to fix the MULE input methods like russian-computer! <calher>I've had to do that before and it's a pain. <piyo>yeah it just came out today <sneek>Welcome back suitsmeveryfine, you have 1 message. <piyo>I forgot to mention, calher. Linux also brings home the bacon. ;-) <fhmgufs>civodul: When will there finally be a shepherd release? :) <CompanionCube>ACTION thinks 'dmd' sounded nicer/better/shorter than 'sheperd' <fhmgufs>ACTION thinks 'shepherd' sounds nicer/better/longer than 'dmd' <piyo>shepherd looks better to me with two "h"s but what do I (and ispell) know <piyo>sheper-d : a daemon for sheper <civodul>it's just my gut reaction when i saw dependencies.sh <fhmgufs>piyo: Wow, how did you know that I was about to ask for that? <piyo>uh emacs is the standard editor for #guix amirite? <mthl>piyo: Emacs is part of the code of conduct ;) <piyo>I was hoping for a clarifying link... <davexunit>civodul: it looks like we have almost all of those dependencies <mthl>piyo: I don't promote it so I don't link it. <civodul>sounds like the comments on LWN about Stallman or Sandler being Marxists and the GPL being the text to ban <piyo>mthl: emacs is not literally mentioned in that link but maybe the joke is flying over my head ;-) <mthl>civodul: pardon my ignorance, but who is Sandler? <civodul>np :-) Karen Sandler, of the SFC (and formerly GNOME Foundation) <davexunit>civodul: the discussion around Karen on LWN right now is horrible. <suitsmeveryfine>What is the correct procedure for installing and running programs with privileges? <civodul>davexunit: yes, it almost made me puke <petter>suitsmeveryfine: you usually run 'guix package' as a normal user. <mthl>suitsmeveryfine: <joke>It is a feature! Free software empowers users not root!</joke> <civodul>it's all about disempowering sysadmins <civodul>the 'guix' command is available to every user there <piyo>I thought it was recommended that root also use guix package even on foreign Guix? <civodul>piyo: yes, Guix is good for everyone, even for root :-) <davexunit>suitsmeveryfine: do you know what environment variables are? <davexunit>you'll have a tough time getting by if you don't. <davexunit>what is the output of 'echo $PATH' as the root user? <alezost>suitsmeveryfine: when I need to run guix (or anything) from root with the current env, I usually do "sudo -E guix ..." <davexunit>suitsmeveryfine: looks like whatever you've done doesn't create a login shell that loads root's bash profile <civodul>we'll have to do the dmd->shepherd rename in Guix as well <davexunit>civodul: re: "design decision behind inputs ..." on guix-devel: we *do* scan store items for references to form the store items closure, correct? <davexunit>Steven is concerned that this is bad magic because it's foiled by compressed files and such, which I get but at the same time I don't see a problem with it. <mark_weaver>davexunit: the problem that suitsmeveryfine ran into is this: that "su" ends up spawning a shell with PATH set to what he pasted. <mark_weaver>and fwiw, suitsmeveryfine was quite helpful to us by perservering through a difficult install of GuixSD on a MacBook2,1 running Libreboot with an encrypted root partition, where there were problems on both the MacBook side (keyboard drivers) and on the encrypted root partition. <mark_weaver>and thanks to his reports I have some patches that should address the problems. <mark_weaver>civodul: this is just a guess, but I suspect that the toxic comments about Sandler on LWN were done by a Public Relations firm. "discrediting" opponents is one of the things that the PR industry does. <petter>i was just about to say to suitsmeveryfine when they left that this run "guix package" as root isn't necessary. Because they're installing flashrom, which is included in libreboot_util <petter>(it would be nice to fix the problems there obviously, but not necessary at this point) <CompanionCube>hm, if I install a GUI program with guix, would it be included in the XDG menus? <fhmgufs>If there is a menu file included in the programs sources, yes. <fhmgufs>I don't know, sorry. Couldn't you test it? <mark_weaver>CompanionCube: no, the host GUI will not look in the places where Guix installs things. <mark_weaver>there may be a way to persuade the host OS GUI to look in the places where Guix installs things, but I don't know off hand how to do it. <mark_weaver>iirc, that info is normally in the .desktop files in /usr/share/applications <parabool>someone on here gave a talk about guix @ MIT couple of days ago. he said something about a recording of that. i forgot who it was, though. <mark_weaver>and for programs installed using Guix, they are in ~/.guix-profile/usr/share/applications <efraim>i've considered symlinking from ~/.guix-profile to /usr/efraim but it seemed like a bad idea <petter>parabool: it was davexunit, haven't heard anything about the video being available though <mark_weaver>if I were to make a wild guess, it might be that XDG_DATA_DIRS needs to include /home/<user>/.guix-profile/share <mark_weaver>(sorry, I meant to write ~/.guix-profile/share/applications above) <mark_weaver>and that environment variable would need to be set before launching your GUI environment, so that it would be accessible to the code that creates the applications menu. <mark_weaver>CompanionCube: that document mentions $XDG_DATA_DIRS/applications, so I guess XDG_DATA_DIRS is indeed the thing to set. <mark_weaver>most of us devs are running GuixSD, so those of you running Guix on top of another OS will have to take the lead on this. <mark_weaver>arranging to set the environment variable before your gnome-session (or whatever) is launched might be a bit tricky. you'll probably need to create an ~/.xsession script or similar, which also launches your DE. <efraim>for DE that sounds better than my idea of uninstalling lightdm and calling enlightenment_start from tty7 <mark_weaver>looks like PATH will also need to be set before the DE is loaded, because the "Exec" fields of our *.desktop files don't use absolute pathnames for the executables. <efraim>it was enlightenment's lack up updates on debian that made me start looking when I found guix <efraim>it looks like it runs well, i've only tried it in a VM so far <efraim>haven't converted my laptop over yet <CompanionCube>I'm using arch's -git package so outdatedness is not a problem for me <mark_weaver>I'm not sure what the right answer is -- this is not my area -- but what you wrote makes sense to me, and it also seems to me that you're in a better position to judge these things than I am. <davexunit>paroneayea: services can already extend other services. <davexunit>in the case of mediagoblin, the mediagoblin-service would extend nginx with additional configuration. <davexunit>our nginx-service is already extensible in this manner. <mark_weaver>I think the issue paroneayea raises is that it might be useful for services to look at the configurations of other services. <paroneayea>well it sounded to me like davexunit was saying that a service would effectively accept a file-like object but the procedure would build that for it <mark_weaver>and that would be a lot easier/nicer if the configuration was in a nice schemey form <paroneayea>so, it seems like we want to have schemey definitions <paroneayea>and we also want to provide a "trapdoor" for raw config things <paroneayea>though maybe the schemey procedure builds the raw config <paroneayea>but I don't want the service to "forget" its schemey config *if* it has one <davexunit>the idea behind my proposal was that we'd provide configuration DSLs as a higher level thing. <davexunit>paroneayea: with my proposal, it would forget it. <paroneayea>davexunit: right, that's my concern... how could mediagoblin add stuff to the nginx service? <paroneayea>hence me suggesting we have a lossy service built *from* a non-lossy service <paroneayea>I still want mediagoblin to slurp MTA information, and mediagoblin to provide info to nginx, etc <davexunit>you can already provide additional config to nginx. <mark_weaver>davexunit: but if the nginx-service only remembers the raw text, that's not a very nice thing to inspect or add bits to. <mark_weaver>so it might be better for nginx-service to remember the scheme representation of the config, and then allow that to include raw text bits within, kind of like "asm" in GNU C allows raw bits to be inserted within a larger C program. <paroneayea>well that's also my reason for suggesting a higher level service that builds a lower level one <paroneayea>because if people just want to dump in raw text, whatever, they can, but they lose the ability to work with the rest of the system's config introspection <davexunit>I think we're confusing 2 orthogonal things. <paroneayea>and theoretically the higher level config stuff will get built into the raw text config anyway <davexunit>the nginx-service, as it stands now, has no Scheme configuration API because it's highly impractical to do so. <davexunit>yet, you can extend the nginx-service-type with additional configuration files. <davexunit>mark_weaver: the problem is that the set of available configuration directives is unknown. it depends on what extensions nginx was compiled with. <paroneayea>ACTION anticipates that configuring services is going to be something we're going to struggle with getting right for some time to come... <mark_weaver>davexunit: that could be solved with a mechanism to introduce raw text snippets within the schemey config, in a way analogous to how 'asm' allows arbitrary asm to be inserted within a GNU C program. <Gallomimia>well, i suppose given your goals, it could be possible to know which extensions nginx were compiled with. <Gallomimia>you could stow that list someplace, if nginx was installed/config'd/setup by the distro system <mark_weaver>davexunit: I'll acknowledge that the traditional approach of having the master config include all files from some directory, where that directory can be populated by things like mediagoblin, is a feasible and time-honored approach to this problem. <mark_weaver>those who've worked with SXML are (hopefully) aware of the advantages of working with that representation. That happens to be a sweet spot because of the uniformity of XML, so it's a one-time and fairly easy job to write sxml->xml. <mark_weaver>writing and maintaining code that generates text config files from an S-expression-based representation would be more work <mark_weaver>whether that work would be worth the effort, I don't know. but it seems to me a worthwhile question to investigate. <mark_weaver>but I certainly found wingo's work on dovecot configuration quite inspiring :) <mark_weaver>the other thing is that some users will be put off by the prospect of learning our S-expression representation, when they are already familiar with the text-based configuration of the various tools. <mark_weaver>but on the other hand, others may prefer the S-expression based representation, whose syntactic details only have to be learned once. so, if I want to introduce a special character into some config file, I won't have to look up how to escape it for that particular configuration file type. the uniformity of S-expressions will be considered a benefit for some of us. <mark_weaver>petter: one thing: I'm not sure that texinfo supports more than 4 levels of hierarchy. <mark_weaver>also, I'm unsure whether the Libreboot-specific docs should be in here, since many (most?) of the details may depend more on the version of Libreboot in use than the version of GuixSD. <mark_weaver>of course, I would like to promote Libreboot, so I'm of mixed feelings about it. <mark_weaver>anyway, it's probably better to discuss on guix-devel@gnu.org <petter>what do you consider Libreboot-specific? <mark_weaver>well, I guess the boot process from within Libreboot's GRUB is what I was thinking of. I don't know of a future version of Libreboot may be able to make that nicer with some changes to its default grub.cfg. but maybe it's not feasible to make it nicer, dunno. <mark_weaver>petter: let me ask you this: what would be the differences between the text in "7.1.3.3.1 Encrypted / (incl. /boot)" and "7.1.3.3.2 Encrypted / (excl. /boot)" <petter>we could move those parts to libreboot.org in case. But still have steps for setting up a encrypted root in general <petter>mark_weaver: you'd need two partitions and extra things in the config <mark_weaver>sure, I'm definitely in favor of adding instructions for installing with encrypted root to our manual :) <petter>let me just work through it (i'm in the mood), and then we can maybe dissect it and such later <mark_weaver>btw, you might be right that we should include the libreboot-specific docs in here as well. <petter>i think coreboot will be exactly the same <mark_weaver>I was "thinking out loud" without clear thoughts on it. <paroneayea>mark_weaver: an even more important thing to me: I would like to be able to build interfaces on top of guix <paroneayea>maybe that needs to be another layer of its own though <petter>mark_weaver: by all means, i'm happy to be able to contribute something :) <mark_weaver>paroneayea: I don't know either, but I appreciate your thoughts on the matter, and the experience you can bring to the table here :) <paroneayea>but I'm surprised to see we have no other common lisp libraries packaged! <mark_weaver>petter: maybe the Libreboot/coreboot bits could be added as a sort of addendum to the encrypted-root section, or something. <mark_weaver>paroneayea: yeah, I think that's uncharted territory so far. maybe we need an asdf-build-system or something, dunno. <petter>i'm sure francis would set us up with a page on libreboot.org, and we could have these things there, and link there from the GuixSD manual <petter>suitsmeveryfine: regarding your issues before. libreboot_util comes with flashrom, so you can use this instead <suitsmeveryfine>I'm typing this from the macbook :) No touchpad, media keys and other stuff but it works <suitsmeveryfine>petter: yes, I thought about that. Maybe I should just use his binaries <mark_weaver>suitsmeveryfine: regarding your question earlier: unfortunately, 'su' sets the PATH in the root-shell to a fixed value that doesn't work at all on GuixSD. we should probably fix that at some point. in the meantime, "su -" works better. <petter>suitsmeveryfine: it's what i did at least, worked great! <suitsmeveryfine>But I would like to learn the proper way of doing things on guixsd. I have only experience with apt-get distros <mark_weaver>paroneayea: the 'maxima' package is written in common lisp. maybe worth looking at. <paroneayea>mark_weaver: I found the secret lisperati cabal here at the stripe offices and have been hanging out with them a bit. One of them opined that he left common lisp becuase packaging was so bad <paroneayea>similarly, ledger was rewritten by john wiegley into common lisp, and then it was so hard for users to install, he rewrote it again back into C++! <paroneayea>maybe Guix could be an appealing direction for those sad lispers <suitsmeveryfine>regarding the touchpad I installed the necessary package, as user, but when I try to run synclient I get told that maybe the driver isn't installed <suitsmeveryfine>Is it the case that some packages should be installed by the user, others by root or is there a secret permissions section that I have missed. <mark_weaver>paroneayea: I confess that my only experience with CL is Maxima, which I did some development on many years ago. but I never learned about asdf for the build systems, so I won't be much help here. <mark_weaver>suitsmeveryfine: "guix package" can be run by any user, and it only affects the ~/.guix-profile for that user. <mark_weaver>suitsmeveryfine: another thing to be aware of: "guix pull" only updates the package database for the user who ran it. so each user has his/her own set of package descriptions. <fhmgufs>davexunit: Thanks, after I've thought about it, I also think it's not needed. But "guix pull" is so slow! :( <mark_weaver>suitsmeveryfine: actually, if you want root to always use the same package descriptions as your normal user does, you can arrange it by making ~root/.config/guix/latest a symlink pointing to ~USER/.config/guix/latest <mark_weaver>("guix pull" compiles a fresh guix from current git master, and sets the ~/.config/guix/latest symlink to point to it) <suitsmeveryfine>That sounds like a good idea, but how do I know which packages must be installed by root? <mark_weaver>suitsmeveryfine: regarding 'flashrom', for now I would recommend using the one from Libreboot. Our 'flashrom' package is a bit old, and the last time I tried to update it I ran into complications and then got distracted by other things. <suitsmeveryfine>ok, so flashrom is a particular case, but what about all the programs that interact with X? <mark_weaver>suitsmeveryfine: no package needs to be installed by root. any user can run any program. it's just a matter of what's available in their PATH. by default, each user only has the system-wide packages and their user's packages in their PATH. <mark_weaver>some programs need to be *run* by root, however, and flashrom is one of them. <suitsmeveryfine>I think that should be included in the package description in that case <mark_weaver>suitsmeveryfine: well, to be more precise, flashrom only needs to be run as root for certain target devices, and that's mentioned in the 'flashrom' man page. <mark_weaver>these are not Guix-specific issues, and so IMO they belong in the program's own documentation. <mark_weaver>our package descriptions are not intended to be documentation on how to use the program. <suitsmeveryfine>yes, somewhat. I like the idea that the documentation is with the single packages <suitsmeveryfine>and there people say, do apt-get install X, Y, Z and you'll fix that particular issue <mark_weaver>well, how to map that advice to GuixSD depends on the specific case, I'm afraid. <mark_weaver>the special features provided by GuixSD requires some radical changes to the system, and necessarily that means that advice from other fora are not always directly applicable to Guix. <suitsmeveryfine>Yes, I understand that. I just need to learn where to start reading instead <davexunit>sneek: later tell fhmgufs I agree that 'guix pull' is too slow. we need to find ways to make it faster. <mark_weaver>suitsmeveryfine: well, feel free to ask questions here. more specific questions are probably easier for us to address. <mark_weaver>suitsmeveryfine: which package did you install for your touchpad? <mark_weaver>ah, so that needs to be included in the X configuration, which on GuixSD means that it needs to be included in the xorg-service <davexunit>synaptics should be included by default, probably, if it's not already. <mark_weaver>suitsmeveryfine: x86-input-synaptics is already included in our X configuration. <suitsmeveryfine>it's not that I don't no response from it, but I can only move the cursor in a vertical line <mark_weaver>suitsmeveryfine: can you look in /var/log/Xorg.0.log for clues regarding synaptics? maybe one of the other input drivers decided that it could handle your device, so the synaptics driver didn't get chosen, or something. <civodul>davexunit: yes, we the daemon scans build results for occurrences of store file name <civodul>mark_weaver: re the LWN comments, yeah, that's possible <civodul>OTOH, i don't think there's a conspiracy, rather a bunch of isolated silly people plus a community of interests <suitsmeveryfine>mark_weaver: I found this: Using input driver 'evdev' for 'Apple Computer Apple Internal Keyboard / Trackpad <mthl>Does anyone have a link for the actual LWN thing? <lfam>efraim: Does your claws-mail update address the recent CVE? <paroneayea>I'm annoyed by how zemmlin wrote that in the article <mark_weaver>suitsmeveryfine: okay, so I guess 'evdev' declared that it could handle your device, but failed to do so. hmm. <paroneayea>and brought up the trolling against karen as what felt like a sidestep <paroneayea>calling out trolling is good, and should be done <paroneayea>but I feel like it was not handled right here and just lead to more of it. And it felt tactical :\\ <suitsmeveryfine>mark_weaver: maybe this is because we included too many modules earlier in initramfs? <mark_weaver>suitsmeveryfine: no, it has nothing to do with that. <mark_weaver>suitsmeveryfine: the evdev and synaptics modules are X server modules, not kernel modules. the initramfs only deals with kernel modules. <mark_weaver>you might be able to work around this problem by removing the xf86-input-evdev from your X configuration <mark_weaver>suitsmeveryfine: unfortunately, I don't see an easy way to remove it. we didn't anticipate that removing these modules would be needed. <mark_weaver>well, there is a way, and it's a good thing to do anyway if you might be interested in contributing to guix: compile guix from source code, from our git repo. <mark_weaver>and then you can easily make arbitrary changes to guix, such as this one. <mark_weaver>once you have guix compiled from git, then making this change is literally just removing one line from the source code and reconfiguring. <mark_weaver>from now on, you'll always just "guix system reconfigure", and if the resulting system fails to work in some way, you can just select an older generation of the system from the GRUB menu. <mark_weaver>the last time I ran "guix system init" from a few years ago :) <suitsmeveryfine>alright, but how do I choose to install from git instead of fetching the substitutes? <mark_weaver>suitsmeveryfine: not even that. just building 'guix' from a git checkout and running that one. <mark_weaver>so, that involves first installing 'git', and then running "git clone git://git.sv.gnu.org/guix.git" <mark_weaver>and then following the instructions in the "Building from Git" section of the Guix manual. in the "Contributing" chapter. <mark_weaver>suitsmeveryfine: running the 'guix' command that you compiled from source, instead of the one that's in /run/current-system/profile/bin/ <mark_weaver>this will allow you to experiment with modifications to guix that are needed for your unusual hardware <mark_weaver>the steps I outlined above are all to be run as your normal user. <suitsmeveryfine>are there others than me that have issues with their unusual hardware? <mark_weaver>I suspect that every distribution has to go through these growing pains :) <suitsmeveryfine>Well I like to think that libreboot-compatible machines should have priority in getting fixed :) <mark_weaver>suitsmeveryfine: often with help from us, yes. and then we modify guix as needed to fix it. <lfam>suitsmeveryfine: Indeed. <suitsmeveryfine>it's a bit frustrating having to work at a machine that needs fixing <lfam>You can do it another way, but if you want to contribute that package to Guix it's best to do it as mark_weaver described earlier. Cloning the git repo and integrating your package into the source code <mark_weaver>suitsmeveryfine: one thing that's not mentioned in the "Building from Git" section, but probably should be, is that you must pass --localstatedir=/var to ./configure <lfam>I'm not civodul but I think so. What percentage of users change the default? And those users are the ones that know about --localstatdir <mark_weaver>(I often think that /var should be the default localstatedir for us) <lfam>Does anyone else thing that Contributing is not clear enough for new users? <mark_weaver>suitsmeveryfine: after ./bootstrap run "./configure --localstatedir=/var" and then "make" <lfam>suitsmeveryfine: It helps to have first entered the right guix environment: `guix environment guix` <lfam>That makes all the dependencies of Guix available for you to use. Libraries and build tools, etc <suitsmeveryfine>I'm glad that you included XFCE aside from Ratpoison. This should help new users contribute <suitsmeveryfine>even if ratpoison is the default and you acidentally log in there three times a day ;) <petter>suitsmeveryfine: you can remove Ratpoison if you want (i have) <mark_weaver>suitsmeveryfine: you can avoid that by creating ~/.xsession that contains: <mark_weaver>and making sure it's executable (chmod +x ~/.xsession) <mark_weaver>then, you'll get XFCE regardless of which session is selected in the login screen. <mark_weaver>and, as a bonus, you can put more customizations in there between those two lines, e.g. I have: "setxkbmap -layout us -option ctrl:nocaps" to set my keyboard layout the way I like, and "xset b off" to disable the harsh beeps. <mark_weaver>suitsmeveryfine: sounds like you didn't do this within the shell spawned by "guix environment guix" <mark_weaver>do you understand the concept of how environment variables work? <mark_weaver>each process in the system has its own copy of "environment variables", and they are typically inherited by newly spawned processes from the parent process. <mark_weaver>so, e.g. there's the PATH environment variable that specifies a list of directories to search for commands that you type. <mark_weaver>and if you set PATH in one shell, that does not affect its setting in other shells. <mark_weaver>but for now, the important thing to know is the "guix environment guix" launches a new shell process with the environment variables set so that you have access to everything you need to build guix. <mark_weaver>suitsmeveryfine: you'll need to rerun "./bootstrap" from within the shell created by "guix environment guix" and then proceed from there. <lfam>I think the manual should suggest `guix environment guix` in "Building from Git". I keep forgetting about doing this so I'm doing it now unless somebody objects <lfam>Oh, just not live on the web? <mark_weaver>maybe people are looking at an old copy of the manual? <lfam>The web copy is from 0.9.0 <efraim>lfam: I didn't check the commits too closely, but it should take care of the CVE <lfam>efraim: Okay. I'm having trouble figuring out what's what with that CVE. The mitre and nist pages are still unhelpful and there was a "partial-fix of CVE" CVE related to it was well <mark_weaver>okay, viewing it in emacs is probably best. from within emacs, "C-h i" to enter info mode, and then select guix from the menu of manuals. <suitsmeveryfine>Almost everytime I install a package I get a message that an environment variable might be needed <efraim>the email only lists fixing oldstable and stable, the debian website lists claws-mail as fixed, with version 3.13.1-1.1, so the .1 at the end means something <mark_weaver>suitsmeveryfine: some programs might not work quite right on GuixSD without certain environment variables being set. <mark_weaver>on GuixSD, by default, when you log in the environment variables are set appropriately for the set of programs you have at that time. <mark_weaver>but there's no way to change the environment variable settings for arbitrary programs that are already running. <mark_weaver>however, in shells you can set environment variables like this: export FOO=bar <mark_weaver>ratpoison can do it with its setenv command as well. <suitsmeveryfine>If I were using ratpoison I wouldn't have an issue with the trackpad :) <mark_weaver>it's not ideal, but once you have your system mostly set up, it's fairly rare for new environment variable settings to be needed. <efraim>so i think cve-2015-8708 is that cve-2015-8614 didn't have a complete fix ***lambda is now known as Guest44725
<lfam>Yes, and that git log shows that they address CVE-2015-8708 and then released 3.13.2. <petter>ACTION is now confused whether XFCE and Xfce is the same spelling and that the keyword is something else <civodul>my understanding is that nowadays the correct spelling is "Xfce" <petter>i'm confused whether spelling takes capitalization into account or not <CompanionCube>I know that Enlightenment has a configuration dialog for environment variables <civodul>mthl: oh, just read about "dog", fun :-) <mark_weaver>petter: I'm not sure either. I think it depends on context. <mark_weaver>but for proper names like this, I think it's reasonable to consider capitalization part of the spelling. <lfam>Would it make sense to be able to do this? $(./pre-inst-env guix refresh -u $(./pre-inst-env guix refresh foo --first-level-dependencies)) <helsingoer>hi, my company is buying me a new laptop, which i'd like to run guix on. What hardware do you recommend? Perhaps a Rockchip Chromebook? <mark_weaver>helsingoer: GuixSD is not yet supported on ARM, although Guix can be run on top of another system. <mark_weaver>helsingoer: but I suppose it depends on what you will be doing with the laptop. <Jookia>helsingoer: Can't go wrong with a Libreboot <petter>in general i think we'd recommend as free hardware as possible <helsingoer>mark_weaver: basically webbrowsing and sshing to my servers <mark_weaver>at present, my recommendation for most purposes would be to get a Libreboot X200 laptpo. <helsingoer>mark_weaver: sadly my company won't get me a X200 as it has to come through certain suppliers <helsingoer>perhaps a cheap intel then, but i guess i will have a bit of trouble with linux-libre? <Jookia>Doesn't sound like your company likes free software enough ;) <helsingoer>well, i can at least install my own stuff :D, definitely an upgrade from previous workplaces <helsingoer>so a compromise solution would be an all intel machine, or what would you recommend? what are you running guix on? <mark_weaver>hardware that doesn't require non-free software is becoming increasingly difficult to choose, I'm afraid. <mark_weaver>The Libreboot X200 is by far the best option right now. <helsingoer>petter: i can get a c201 as it's the only one my stupid company suppliers will get me because its brand new <helsingoer>mark_weaver: yes, i know well but they will refuse to purchase from them :( <petter>helsingoer: unfortunate that this is the one ARM computer :( <mark_weaver>the C201 is an interesting one, but there are two serious flaws: it has a wireless adapter that requires a non-free blob to be uploaded to get it working. and there's no free driver for the graphics acceleratoin. <helsingoer>mark_weaver: yes, i can ignore graphics acceleration i think and use an alternative wifi adapter <mark_weaver>GuixSD might support the C201 in the future, if someone does the work. <Jookia>helsingoer: No GRUB on ARM, no u-boot port on Guix <mark_weaver>helsingoer: there's a GRUB for u-boot ARM systems, but the C201 doesn't use u-boot, so that's one difficult issue. <mark_weaver>GRUB is somewhat important for GuixSD because it enables the system-wide rollback functionality. <Jookia>mark_weaver: You can get system-wide rollback functionality on u-boot <petter>helsingoer: have you actually asked your company if you can get a Libreboot computer? <mark_weaver>less difficult issues are that we lack a linux-libre config for ARM systems, and also some packages are currently broken on armhf that need to be fixed before you have things like a modern desktop environment and modern web browser, etc. <mark_weaver>helsingoer: I wonder if you could try to persuade your company to buy an X200 from one of the above suppliers. <helsingoer>i did try as i'd like to run libreboot, but didn't succeed. <mark_weaver>failing that, I guess I would hunt around on https://h-node.org/notebooks/ to find something that at least can run Trisquel well, and if Trisquel works then GuixSD probably also works on it (or could be fixed to do so) <Jookia>mark_weaver: By the way: Any plans for a 'stable' GuixSD set of packages? <mark_weaver>I would recommend making sure that the graphics accelerator is from Intel. <mark_weaver>and ideally the wireless would be ath9k, but that's less important since you could use an external wireless adapter. <Jookia>mark_weaver: It's ... difficult to follow rolling release when you're compiling everything yourself on ARM <mark_weaver>helsingoer: another problem with the C201 that I forgot to mention: it has very limited storage that cannot be upgraded. <mark_weaver>and GuixSD tends to require more storage than other distros. <mark_weaver>since when you update things, the old versions stay around, which is what enables rollback. <aeva>anyone here use enlightenment and mind if I ask some super basic questions on how to get started with that on guixsd? :) <Jookia>Also if you're like me and compile everything source archives are pretty big <lfam>The chip in the C201 (cortex-A17 quad) should be much faster than the Allwinner A20 (cortex-A7-dual). But my experience with the Allwinner led me to realize that having source code and copyleft licensing is not the same as being able to actually build from source and have a working software system. Hopefully the C201's Rockchip CPU is better than the Allwinner stuff <mark_weaver>and also, we haven't yet done as much work to split packages into pieces (e.g. separate dev packages) to minimize package sizes. <Jookia>lfam: Let's not pretend Allwinner complies with copyleft ;) <lfam>Jookia: I'm not even talking about that level. The SOC is too slow and the thermal dissipation too poor to actually do long-running compilation <efraim>I'm actually about to go to bed, sorry <Jookia>Yikes, I'm on a Cortex-A9 and got along fine. Maybe I'm doing it wrong? :P <lfam>The A20 is basically totally supported in mainline linux. But good luck actually compiling the system on it. <mark_weaver>Jookia: I sympathize with that problem, as I've attempted in the past to run GuixSD on my Lemote Yeeloong without using binary substitutes. <mark_weaver>Jookia: one or more stable branches would be nice, but it would also be a lot of work. someone would need to do that work :) <lfam>I expect Freescale to do a much better job of building stable hardware systems <mark_weaver>but also, for security updates to core libraries, we need working grafts, which we don't yet have. <lfam>The Cortex-A9 is the "first" ARM out-of-order ARM core, so that gives it a big advantage over the A7 <Jookia>lfam: I figured it was something along those lines- The Cortex-A* line is confusing to figure out what's useful and what's not <lfam>We'll see if Rockchip is any better than Allwinner. <lfam>Jookia: It's worth reading. The manufacturer model numbers are way less important than the Cortex versions IMO since that's where all the actual CPU features are determined <Jookia>lfam: Oh I've done a lot of reading on it but it's not something that is easy to remember, or makes sense when the number in the Cortex series doesn't represent something measurable, though perhaps it's power consumption? I'm unsure <mark_weaver>Jookia: setting aside the grafts issue for the moment (which is needed to allow security updates to core libs without rebuilding much), one thing I did to minimize the problem was to run guix from my own private git branch (which I always do anyway), and then to just cherry-pick commits from master that I care about. <Jookia>mark_weaver: Yeah, that's how I've handled NixOS but it's been troublesome with regressions. Develop fast, crash hard <mark_weaver><Jookia> mark_weaver: You can get system-wide rollback functionality on u-boot <mark_weaver>Jookia: I guess so, but since GRUB for u-boot exists, I think that's probably the better way to go. <mark_weaver>right now, GuixSD assumes GRUB, and has no framework for alternative bootloaders. <mark_weaver>changing that would also be some work, and I suspect more work than packaging GRUB-for-u-boot. <mark_weaver>but also, I'm not sure that supporting other bootloaders is desirable. I would prefer to get GRUB working on the systems we care about. <mark_weaver>We are building the GNU system, and GRUB is the GNU bootloader. <Jookia>I'd rather have u-boot now than GRUB later <Jookia>If that's even what we're choosing <mark_weaver>"I'd rather have u-boot now than GRUB later" seems to assume that it's less work to generalize GuixSD to support other bootloaders than to package GRUB-for-u-boot. <Jookia>You speak of packaging, but what about testing? <Jookia>What use is a packaged GRUB-for-u-boot if it doesn't work <Jookia>Sure, but it's a lot easier to test with tools that work <mark_weaver>have you looked seriously at what would be needed to generalize GuixSD to support other bootloaders? <mark_weaver>why don't you work on it and come back with a proposed patch <Jookia>mark_weaver: I was going to but you're giving me second thoughts <mark_weaver>given that GRUB for u-boot already exists, I'm not sure why you're so against it. <Jookia>Grub for u-boot does not work on the Novena <Jookia>Have you gotten it to work on the Novena or i.MX6? <Jookia>I'm sure I didn't make a mistake as it gave errors consistent with unimplemented or buggy features <Jookia>The errors I think were consistent with u-boot interfaces which GRUB uses being unimplemented <mark_weaver>Jookia: if you want to propose supporting non-GRUB bootloaders, please raise it on guix-devel <Jookia>I talked about it a bit on another list <mark_weaver>Jookia: so, another thing: GRUB supports mounting encrypted partitions from the bootloader. does u-boot support that? <Jookia>Does Guix's initramfs not support decryption? <mark_weaver>it does, but the initramfs's and kernels (one for each system generation) are on the root partition. <Jookia>NixOS has a /boot partition for that kind of stuff <mark_weaver>in theory, copies of the kernels and initramfs could be put onto /boot, but this all sounds very suboptimal to me. <Jookia>However, I want GuixSD to run on ARM sooner than later <lfam>Steap: Your kernel may not support user namespaces <mark_weaver>Jookia: if you want to implement support for other bootloaders, and civodul is okay with it, then I won't block it. <lfam>Or perhaps you need to be root <Steap>it also fails as root, weird <Jookia>mark_weaver: It's not that I don't like GRUB, it's that it's not working and I'm kind of in a hard place when it comes to running Guix or NixOS on my system <lfam>I remember there being a problem with the Debian kernel (which I'm using). I think they compiled it without support for that feature. Maybe that's what's going on <Jookia>mark_weaver: Once I'm somewhat settled I'll probably devote some time to getting GRUB working better if I can :) <lfam>Steap: That was a few months ago, I don't know if it's still true. Or if it's relevant to your situation. <mark_weaver>Jookia: fair enough, and that would be much appreciated :) <Jookia>Arch Linux/Parabola doesn't enable user namespaces from what I know either- something to do with security <Steap>lfam: do you know how I can check that ? <lfam>I'm trying to find the bug-guix thread because I don't remember how to check it <Jookia>I wasn't aware people used containers for security <aeva>I'm running into a thing where I can't start enlightenment because it says it can't find locale en_us <mark_weaver>lfam: on Debian derivatives, /boot/config-* contains the kernel configurations. <Jookia>aeva: Do you have glibc-locales installed? <aeva>yes, just installed it actually :/ <helsingoer>Jookia: yep, containers will evolve to be quite useful to sandbox software, like android or ios do <Jookia>mark_weaver: I posted to guix-devel about it, so it'll probably appear sometime today :) <mark_weaver>aeva: it should be en_US.utf8 I think. "locale -a" will show you the available ones. <mark_weaver>aeva: it may be that other distros create more locale aliases. <Steap># grep CONFIG_USER_NS /boot/config-4.2.0-1-amd64 <mark_weaver>aeva: 'locale' is in the gcc-toolchain package, a necessity for any developer :) <aeva>will installing that make enlightenment work? :D <mark_weaver>aeva: no, sorry if that sounded snarky, it was not intended. <Steap>mark_weaver: seems like Guix reads "1\\n" from /proc/sys/kernel/unprivileged_userns_clone <mark_weaver>aeva: the "en_us" with lowercase "us" is not the right capitalization for the locale we have in GuixSD. it's "en_US". I'm not sure whether the lowercase "us" is due to a problem in your OS configuration, or if enlightenment is doing something odd. <mark_weaver>hence my question about the 'locale' field in your OS config. <aeva>I'm not sure what my os config is? <mark_weaver>aeva: the OS configuration is the file that you passed to "guix system init" or "guix system reconfigure" to instantiate your system. <mark_weaver>aeva: okay, nevermind everything I wrote about this. it was all based on the lowercase "us". <paroneayea>ACTION just explained guix to someone and they said "Does it have static typing? Because if it doesn't have static typing how can you trust your system, who knows what will happen." <mark_weaver>aeva: do you set any locale environment variables in your dot files or scripts? <mark_weaver>if you set anything to "en_US" without the ".UTF-8", that might be the problem. <paroneayea>and I'm like "well no but you can roll back if something goes wrong" and they say "are you sureeee?" <aeva>mark_weaver: I don't think so? I don't think I've explicitly set anything about this anywhere <mark_weaver>aeva: okay, in that case I'm out of ideas for the moment. sorry. I guess you should ask efraim when he's awake. <petter>maybe set "LANG=C" and start enlightenment.. <mark_weaver>petter: well, then any programs spawned from enlightenment will be i18n-impaired. <petter>yeah, but just to see if it works. Maybe it helps tracking down the issue <aeva>I'll give that a try in a sec <mark_weaver>aeva: or if you want to investigate sooner, running enlightenment within 'strace' and seeing how it looks for locales might be worthwhile. <petter>though i think i'd start with figuring out where the locale command is <aeva>I'm gonna try the LANG=C bit, brb <mark_weaver>petter: 'locale' is in the glibc package, and glibc (along with gcc, binutils, and ld-wrapper) are included in 'gcc-toolchain' <petter>mark_weaver: it was said "command not found" when you suggested to run "locale -a" <mark_weaver>programs don't typically need the 'locale' command, but maybe enlightenment does, who knows? <petter>maybe the LANG and LC_* environment variables aren't set <aeva_>no dice - "could not request bus name" now <CompanionCube>iirc there are certain environment variables that can be used to obtain more detailed logs from Enlightenment <aeva_>well, it doesn't work, rather -.- <petter>though hard to say if it the process came further or stopped earlier i guess <mark_weaver>aeva_: my guess is that our enlightenment package requires other packages to be installed in order to work, which we try to avoid. it indicates a problem with our enlightenment package. <CompanionCube>to crank up the logging of Enlightenment, set INA_LOG_LEVEL=5 <mark_weaver>aeva_: running enlightenment within "strace -f" would allow us to see what it's trying to do before printing the errors. <mark_weaver>it's a common method for us to debug problems like this. <aeva_>do you think it would be meaningful to do that without closing X first? I think this might be a tedious thing for another time :/ <aeva_>thanks for trying to help :) <mark_weaver>aeva_: if you could send an email to bug-guix@gnu.org about this, that would ensure that we won't forget about it. <aeva_>I might try again a sec - gonna make some tea and sign into irc on a different computer >_>