IRC channel logs
2018-09-30.log
back to list of logs
<ng0>georges-duperon: context would help <ng0>I'm off soon, head's not in the right place, wrestling python the night.. *rekado tries to fix git-annex on wip-haskell *rekado fixed the agda build *georges-duperon had an Agda course a while back and should try to use it again (or Idris maybe). <georges-duperon>ng0: My project is generating a disk image, and the partitioning tool needs a UUID. <georges-duperon>ng0: Until now I was using `git log --format=%H -1', cutting that hash the right length, and inserting dashes in the right positions, which gave me a nice UUID. <georges-duperon>ng0: With (source (local-file …)), I'm not copying the .git (for obvious reasons), so my build can't do that anymore. <georges-duperon>ng0: so I was trying to inject the hash of the inputs in some way into the build. <georges-duperon>I think in the end I'll generate a temporary disk image using 00000000-0000-0000-0000-000000000000 as the GUID, hash the resulting (deterministic) image, and then modify the GUID using that hash as a basis. <georges-duperon>That way the build process will be deterministic, but will not actually require git nor guix (the latter being used "only" to ensure the build tools en environment are fixed) <snape>Is there a way for guix publish to provide plain text logs? (Instead of bzip2ed) <snape>Maybe the solution is to tell NGINX to uncompress them on the fly. <efraim>maybe 0 compression together with uncompress on the fly to not require too much cpu <snape>efraim: Thank you! I'll try that. <snape>The plan is to be able to click on logs in the Cuirass web interface, and see them display in the browser. <snape>Actually, just changing log compression to gzip works <`ani`>hi, give me a few reasons to migrate from Parabola GNU/Linux onto GuixSD. <efraim>'g' comes before 'p' alphabetically <pkill9>ability to load previous system configuration and kernel at boot time, so if an upgrade goes wrong, e.g. kernel is misconfigured, you don't have to boot from memory stick to fix it <pkill9>by 'boot time' i mean from a GRUB entry <pkill9>and also being able to configure the system using a single configuration file, so when you need to do tweaks like adding kernel parameters, they are all recorded into that configuration file, so in the future if you for example need to reformat, you won't lose/forget about those tweaks <`ani`>what is your stance on kernel JIT updates? such that a reboot won't be necessary to get the new fixes. <`ani`>can I install a set of packages based on a configuration stored in my home dir? <pkill9>also, not having to use LD_LIBRARY_PATH to run software from the guix repos on the foreign distro (usually grpahical software, also I couldn't get a guix-packaged window manager to work with my foreign distro's xorg) <`ani`>makes reinstalling a lot easier. <`ani`>how about packages that are not in the official repos but are very much candidates for it? <`ani`>can I build those with a simple helping system? <`ani`>can I use a tool to collect all licensing information in a software package? <pkill9>there isn't such a tool with guix (aside from the importers, which don't always work), but those are things you cna write yourself <pkill9>i've writtena tool that generates a package definition <pkill9>well, it uses guix's json importer <pkill9>but creates the json for it, so you can give it inputs on the commandline <pkill9>actually that sort of thing would be accepted into guix, but mine is written in python since I didn't know enough Guile to write it in Guile <`ani`>it's a planned feature then I take it? <pkill9>well, it's not planned, but if it works well then I assume it would be accepted if you posted a patch, because there's a `guix import json` which basically takes the package definition as fields and outputs a package definition in Guile <pkill9>so since that's been accepted, i would assume tools that make it easier to generate package definitions in general would be accepted <`ani`>how does one push a definition in without being in the official team? <`ani`>for instance, a foreign package which fits into the freedom definition. <`ani`>pkill9: so I take it that I can not. <pkill9>do you mean install your own written package definition that isn't part of the guix repository? <pkill9>i assume that's what you mean if you look at that and say you can't <georges-duperon>`ani`: True story: a couple of days ago, a relative installed the updates on an ubuntu machine, using the GUI (so nothing fancy). The updates managed to silently crash mid-way, and left /boot/grub damaged, with only half of the files in there. <`ani`>yeah I can see the use in that. <georges-duperon>(although I don't know whether the updates for grub itself are atomic in Guix, for the rest it should be the case). <`ani`>the only thing that keeps me anxious when hitting the power off button (soft powerdown) is whether pacman is running in sudo mode. <`ani`>however one question is unanswered. what is your stance on kernel JIT updates such that would make a reboot redundant in order to get the kernel patches running? <georges-duperon>`ani`: I heard about that a few years back, but it was meant for servers, no? <`ani`>doesn't matter how you use the computer. <georges-duperon>`ani`: I'd feel safer rebooting the machine if I can. C code is already an unsafe mess of pointers and segfaults, patching things in-memory without any formal guarantee that you did it right is something that I'd do only if I really have no other option. <georges-duperon>(unless we're talking about unloading/reloading modules, but the JIT patching I had read about was assembler-level patching of the kernel in the RAM). <georges-duperon>Is it normal that `guix environment perl-archive-zip -- crc32 somefile' works, but in a package definition I need both ("perl" ,perl) ("crc32" ,perl-archive-zip) in my native-inputs? <georges-duperon>Can't locate Archive/Zip.pm in @INC (you may need to install the Archive::Zip module) (@INC contains: …) at /gnu/store/…-perl-archive-zip-1.60/bin/crc32 line 8. <Laalf>could i have an example of a cron service that works? i cant get it to run because In procedure append: Wrong type argument in position 1 which makes no sense to me <iyzsong>georges-duperon: yes, the crc32 doesn't get its Archive::Zip module. Wrap it with PERL5LIB with the 'site_perl' directory of perl-archive-zip would help. See 'perl-file-mimeinfo' for an example (using wrap-program). <georges-duperon>Laalf: that error message usually indicates that you gave e.g. a string where a list of strings was expected. <georges-duperon>iyzsong: so you mean that the same trick with (wrap-program …) should be applied in the package definition for crc32 ? <Laalf>georges-duperon: i copied the exact thing after the use-modules in my (operating-system and i still get the same error <georges-duperon>Laalf: when do you see the error? When running guix system vm myconfig.scm, or something like that? Or at run-time? In a log file? <Laalf>georges-duperon: guix system reconfigure <georges-duperon>Laalf: I can't test with reconfigure as I'm not using GuixSD (I have another distro) <Laalf>georges-duperon: seems to work now. idk what i did wrong. i will get my other cronjobs in there and see if they work. thanks! <snape>I can't upgrade Shepherd services anymore with the Shepherd update. Is that normal? <snape>I think the point was to allow service upgrading ;p <snape>but now, not only "sudo herd restart cuirass" doesn't work, but stopping the service before reconfiguring doesn't work either. <Laalf>georges-duperon: this doesnt actually work. <snape>hmm maybe it's because the Shepherd was still the old one <georges-duperon>Laalf: Too bad :( . I'm sorry I can't help more, not having a real GuixSD system… <Laalf>does anyone run cronjobs as a user in guixsd? @reboot doesnt exist if i got that right <EternalZenith>Are there any good, clearly written configs to use as examples for configuring GuixSD? <EternalZenith>I've found a couple, but most seem to be messy, really simple, or old <snape>EternalZenith: there are some in the manual. Did you have a look at them already? <atw>whoa, there's a lot in there <snape>home, work, mail1, mail2, build <georges-duperon>Silly questions: where's the doc for (invoke "executable-name"), and how do I find the documentation for other functions like this in the future? <georges-duperon>I tried looking in all of Guix's online documentation, nothing relevant, and nothing in the index of the Guile scheme documentation either… <snape>georges-duperon: in the source, and a little bit in the NEWS file <snape>oh, you want the source of guix locally, right <EternalZenith>I was assuming that each install kept the source locally for whatever version you have installed <snape>EternalZenith: ps auxww | grep guix-daemon <snape>where is the binary is also the source <snape>or otherwise you can 'guix package -i guix' <snape>but it's usually not recommended <snape>should lead you to the source too <snape>to get the Guix you pulled, you can cat $(which guix), and look for "guix.*modules" (the regexp) in there <Laalf>is there anyone running commands at startup as a user in guixsd? if so: how? i would still be ok with rerunning the program every x minutes but i dont get mcron to work. i know it runs but it just doesnt work. <snape>it's subtle because the guix of 'which guix' is not the same as the one from guix-daemon, which is the one packaged <snape>Laalf: I don't think we have user services yet <snape>would a root service be enough? <EternalZenith> So each user might have a different guix version than root? <snape>EternalZenith: but 'root' doesn't have to use guix <snape>the daemon is run as root though <EternalZenith>Is there a suggested way to split system configuration between the system-wide configuration and the user config? <EternalZenith>Or do people just put things necessary to boot in the /etc/config.scm or wherever, and everything used daily in their user's config? <snape>EternalZenith: there is no user config, appart from the manifest, which contains a list of packages <snape>there is nothing user specific in there <snape>EternalZenith: well, users can do whatever they could normally do, plus installing and removing packages <snape>(that's the positive way of looking at it :p) <snape>basically, users can't use 'guix system' <snape>but they can use 'guix package', 'guix build', etc <EternalZenith>I was under the impression that guix could be used to configure a user's environment through something like guix system <snape>all the user environment is setup through other means (xsession, bashrc, etc) <Laalf>couldnt guix system vm theoretically be run as user? <Laalf>you can at least initiate it. i dont know if it works <EternalZenith>Does 'guix system vm' work to test configuration changes as in nixos? <snape>you can pass a config.scm and test a specific config I think <snape>but my computer is pretty slow and doesn't have KVM, so I don't use 'guix system vm' <snape>I reconfigure my system to test <EternalZenith>snape: I'm going to have to build a custom kernel to get my wifi working, and grub takes a while to load with an encrypted root, even with an ssd, so I was thinking it might be easier to just try building a vm <snape>EternalZenith: Yes, it's a good idea I think! <snape>but you'll have issues when it comes to making sure your VM finds your Wifi adapter <snape>I don't know, that's why I prefer rebooting <EternalZenith>Oh yeah, it would probably create some abstracted virtual network interface or somesuch <snape>and if it doesn't work you won't know if it's because of the VM or because of something else <snape>it could, I don't know, I prefer not taking the risk <EternalZenith>One other thing: is there any way to see all the services and their configuration options that are available? Does the manual fully detail all that there are? <snape>there is 'guix system search' <EternalZenith>Not sure how I missed that every other time I tried to find it <snape>(that can be used as a user btw) <EternalZenith>So, the guix executable itself is always stored in a directory owned by the user who's running it, and it interfaces with a guix-daemon that has all the priveleges necessary to preform whatever task is given by that user? <snape>Laalf: could you paste your whole config.scm? <snape>your error comes from your use of 'append', which doesn't appear in the snippet you showed <snape>georges-duperon: yw! in the source, it's in guix/build/utils.scm <Laalf>snape: I will in an hour or so. Left my desk rn. I will have to modify it a bit to cut IP addresses. <snape>Laalf: ok. It may be that you used 'append' instead of 'cons*' or something like that <snape>because 'append' expects a list as its first argument <javistacruz>1444444444444444//3330303...3...069*****8888888888888858555555555858558548 <kurimi>Hello, i have tried running guix pull as a user and i got error message "guix pull: error: symlink: Permission denied: "/home/kurimi/.config/guix/current-1-link.new"" the folder ~/.config/guix is owned by root and doesnt have any files in it. what can i do to solve this? <kurimi>georges-duperon: really only that? okay. thanks <georges-duperon>kurimi: most of the time this happens when you run a command using sudo but actually shouldn't have. <georges-duperon>kurimi: Linux has two notions of the "current" user. There's the current permissions, and the user that started the commands using sudo (roughly, or it might be the $HOME that isn't properly adjusted). And some programs get confused and place files owned by root in your ~. <kurimi>yeah but im not sure that it worked first time <kurimi>btw... if group kurimi doesnt exist ... do i do just kurimi:users? <lrvick>So I noticed that unlike the official nixpgs repos, all commits in Guix are signed. I was unable to find a way to get an authoritative list of keys to compare against though. Are there plans to have something like the Arch Linux pacman-key tool for maintainer key distribution as well as getting both Hydra and end clients to do signature verifications? <lrvick>Would love to hear (or be pointed to) thinking here in general <lfam>I don't recall where we discussed the decision to sign all commits, if it was in that thread or somewhere else. At that time, there were only two mailing lists, guix-devel and bug-guix, so it shouldn't be too hard to search <lfam>IMO, signing commits is okay for seeing who made which commit. But, beyond that, it's not a good technique for "code-signing", because Git doesn't distinguish between bad signatures and signatures whose keys have expired. <lfam>That could be fixed in Git, of course, but I'm skeptical about basing this on using the `gpg` command-line tool, which is extremely complicated and not really designed to be used interactively, even though the GnuPG team strives to maintain the command-line interface <lfam>Ultimately what we should do is implement The Update Framework <https://theupdateframework.github.io/>. They have already thought about this problem exhaustively, and it will be more efficient to build on their work than try to approach the problem from scratch <lrvick>I think VCS signing proving integrity there so consumers of the git repo (like hydra) can verify it and authorship but TUF makes more sense for the actual release flow imo <lrvick>Looks like Guix already sign every commit though so preaching to choir :) <lfam>After we decided that all commits would be signed, once in a while somebody would make a mistake and forget to do it, or even make a bad signature with a buggy GnuPG client. So we made a pre-push Git hook and ask Guix committers to install it when we give them commit access, in the HACKING file: <https://git.savannah.gnu.org/cgit/guix.git/tree/etc/git/pre-push> <lfam>It verifies the signatures of the commits being pushed and blocks the push if any of the commits are unsigned or the signature can't be verified <lfam>It's a bit crude and needs to be disabled when pushing a new branch but that's a rare case <lfam>IMO that drawback shows another weakness of Git commit signing for even the use case of knowing who made the commits <lrvick>I am not sure that I follow how a hook not knowing to respect per branch enforcement impacts the ability to know who made the commits. <lfam>From Git's point of view, when you push a new Git branch to a remote repo, you are effectively pushing the entire Git history up to the HEAD of your branch. Since we didn't sign commits at the beginning, the verification will fail. So, signature verification must be done by the human, and they do make mistakes :) It doesn't exactly affect the ability to verify commit pushers, but it shows that the Git model is not well-suited for this use case, in my opinion. <lfam>In the pre-push hook, this is the case '["$remote_sha" = $z40 ]'. <lfam>($z40 is explained in the comment at the beginning of the hook) <lfam>Oh, it's actually not explained there, sorry lrvick <lfam>It's just a Git convention for a non-existent commit, for example a new branch or a branch deletion <lfam>Anyways, these sorts of little "gotchas" in the implementation really highlight that the tools could be improved, at least <lfam>But to clarify, they are way better than nothing! <lrvick>I do agree there is a lot left to be desired in git signing. Particularly if you want to attach signatures after the fact. I have taken to adding sigs on the git notes interface for some of my projects, allowing adding reviewer sigs later, or even including the expected binary hash. <lrvick>It does mean having to use a git plugin though which is not ideal but... tradeoffs.