<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>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>
<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
<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.
<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.
<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
<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.
<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.
<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.
<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>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>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>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.
<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!
<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: 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>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.
<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
<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>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.
<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
<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)
<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 ;)
<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.
<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.