IRC channel logs
2018-12-19.log
back to list of logs
<THFKA4>is it possible to have encrypted root with the kernel/initrd/grub unencrypted on the boot partition? trying to avoid typing in the password twice <OriansJ>THFKA4: the only way to avoid typing the password twice is either: 1) have an unencrypted /boot or Have an encrypted /boot with a keyfile loaded in your initrd <THFKA4>that makes sense, but the kernel is still in the store, which is encrypted, right? <THFKA4>can i specify in the configuration that i want the kernel in the unencrypted /boot? <OriansJ>THFKA4: you can specify anything about the system you want. <THFKA4>probably involves modifying the bootloader config to depend on the kernel image and write it to /boot <OriansJ>THFKA4: The default and easy configurations are just the ones the active Guix developers want. As Guix is written in Lisp, it be extended to crazy levels; it is just a matter of effort. For example you could put lvm ontop of a single luks and thus the password grub asks for will unlock the entire lvm <THFKA4>yep, i have that going with NixOS, which also puts the kernel into /boot by default <THFKA4>i would still need to keep the EFI partition unencrypted with LVM/LUKS i think <OriansJ>THFKA4: I use coreboot and libreboot myself, so that I am unsure of <tune>I'd like to have passwordless sudo for the guix command. What is the best way to do this? <tune>Sometimes I leave my machine and have told it to do a 'sudo guix pull' followed by a 'sudo guix system reconfigure' but then it's stuck at a password prompt and times out instead of getting things done while I'm away <rekado_>we’re still having a problem with Haskell packages <rekado_>I wonder if it would be enough to sort the directory read output. <rekado_>the problem is that packages built on different machines are not necessarily compatible with one another. <g_bor>it seems to me the weather is not good :( <rekado_>maybe we should disable building core-updates on berlin. <g_bor>rekado_: could we use hydra to build core-updates? <tune>is perl 6 packaged? I was thinking of trying it out, but I can't find it <g_bor>I will have a closer look in a few minutes. <g_bor>tune: no, it is most probably not packaged yet. <rekado_>g_bor: core-updates isn’t ready to be built at this point. It’s still changing. <g_bor>rekado_: ok, I see. Then it would be safe to disable it on berlin. WDYT? <rekado_>yeah, should be fine, but I’m not comfortable with disabling this in the sqlite database. <rekado_>hmm, some users have a problem with “offload” failing. They are using the current guix after running “guix pull”, but the shared daemon is from a git checkout, running inside of an environment that has guile-ssh <rekado_>maybe I should build the daemon in an environment lacking guile-ssh? <rekado_>we are currently working around this by passing “--no-build-hook”, but it’s not a good look. <g_bor>rekado_: I have no idea, but if you can try this, then please go ahead. <roptat>civodul, what are the steps to get staging merged? <civodul>roptat: ensure there are no regressions and that important substitutes are available <civodul>you could try 'guix weather' on that branch <civodul>rekado_: it's .132, running the gc, but that one has too little space on / <roptat>civodul, it seems that my opam importer broke the guile 2.0 compatibility :/ <civodul>roptat: np, we'll drop 2.0 compatibility <roptat>civodul, 31.1% substituts disponibles <efraim>drop 2.0 compatibility from the opam importer or from guix? <g_bor>efraim: I believe civodul meant from guix. <rekado_>it has 470G on /data/local, which is on a RAID. <rekado_>this machine still hasn’t GuixSD on it. <rekado_>civodul: maybe there are too many builds moved to that very same node. <civodul>we should not give it too high a "speed" factor <civodul>well also it has 16 parallel builds, which is why it gets a lot <rekado_>/ is just supposed to have, well, the system. Everything else is supposed to be stored on the RAID. <civodul>but /gnu/store is not separate from /, right? <rekado_>I’m not sure I know how to configure the RAID properly on GuixSD, so I haven’t yet attempted the conversion. <civodul>usually for i arrange to run "guix gc -F80G" once per day :-) <civodul>so on this machine, in the meantime, we can do two things: reduce 'parallel-builds' so it doesn't do too much work, and run "guix gc -F20G" twice a day or more <rekado_>I could bind what is now /data/local to /gnu and relocate /gnu/store <rekado_>that machine will have to be set up properly one day anyway, so I can just do this manually today. <g_bor>istm that from the current web interface it is difficult to get an overall state <g_bor>it would be nice if we could provide a page with some aggregated data <rekado_>it shows us new builds per evaluation, but doesn’t say anything about the total workload <rekado_>I’d love to see a nice visualization of total scheduled jobs and total jobs in progress, all linked to their evaluations. <g_bor>Some problems are easy to spot this way, for example the lot of rebuilds triggered by the update of git. <g_bor>An overall view would be really nice. <rekado_>something completely different: we have a bunch of profile hooks that scan the profile. This happens repeatedly. Can we introduce a higher level abstraction that would allow us to fuse these directory traversals? <g_bor>The current view could be improved by showing the commit message. <rekado_>g_bor: isn’t that already displayed well? <rekado_>we have evaluations, the commit that caused them, and the number of new builds introduced by this evaluation. <rekado_>so sudden rebuilds can already be spotted, I think. <rekado_>it’s just the overall workload that we can’t see. <rekado_>nor can we see the distribution of builds — what machines have the builds been offloaded to? <g_bor>rekado_:yes, and that is fine, but having some text besides the commit id would be nice. Currently I search my git logs to find it. <rekado_>we could link it up to the savannah web interface; would that help? <g_bor>rekado_: do we have the info needed to do this aggregation? <rekado_>I don’t know if the information about offloaded builds is readily accessible <g_bor>rekado_: in the evaluation subpages we have the jobs with status, only we don't know offloading information. <g_bor>so it seems we can get a schedule/completed/failed overall easily <g_bor>it seems we don't have in-progress <rekado_>roptat: I wonder about translations here. The derivations have a property “hook” that contains a human readable name, but I don’t know how to get this translated. <g_bor>rekado_: seems like a nice improvement <roptat>rekado_, make sure guix/status.scm is in po/guix/POTFILES.in <g_bor>thinking about the overview we could easily count(*) group by jobstatus. That could be done easily. <roptat>you can run "make dist" and check that the resulting tarball has the new strings in its pot file <civodul>rekado_: i'd suggest storing symbols instead of strings, like (hook . ghc-cache) <rekado_>and then replace them with strings on the host side? <civodul>and then the UI code would print: "running profile hook: ~s" <civodul>where ~s would be (hook-name->string 'ghc-cache) <civodul>or maybe even (hook-message hook), that would match on the hook type, and return either "building GHC cache" etc., or, as a generic fallback, "running profile hook of type '~a'" <rekado_>do I need to wrap these string literals in (G_ …)? <rekado_>so… I’d like to also have a progress indicator. We know the number of derivations that will be built and I guess we also know how many are left to be built (though this may be tricker with parallel builds). <rekado_>Can we print something like [3/42] in front of the messages? <efraim>I'd suggest incrementing the [x/42] on the completion <roptat>civodul, 73.2% substituts disponibles from mirror.hydra <civodul>then it would be great if you could send an update to the list, Cc'ing those who were involved <civodul>and then make the decision together :-) <civodul>i didn't follow the branch so i can't really tell much <roptat>what do you mean those who were involved? <civodul>rekado_: for literals you'll want (G_ "whatever"), so they can be translated <civodul>roptat: those who worked on that branch, i think there was mbakke, Rutger, and maybe Danny and others? *janneke starts hacking again on the gash/geesh merger <civodul>janneke: i've just started the rebuild of bootstrap-tarballs with the commit you gave <brendyyn>Has anyone managed to setup ecryptfs encrypted home directories with GuixSD? <civodul>brendyyn: i have a LUKS-encrypted home on a machine (and otherwise LUKS-encrypted root) <brendyyn>That's a partition I guess. I always install with a single filesystem <efraim>brendyyn: if you want to work on it I'd suggest creating a system test and hacking on that until it works <brendyyn>efraim: I'll have a look. I guess it'd involve creating a service <efraim>That's my plan for getting GuixSD on btrfs raid 1 experience <brendyyn>I'll try find out how it works on other distros <efraim>civodul: I think I'm also about ready to submit my recursive refresh for first view <civodul>i think there's another patch or two where you need to follow up, hint hint ;-) <efraim>I know, I think I also have that one in my stash <brendyyn>The last patches I sent just got forgotten by the looks of it :/ <rain1>is there code in guix using old guile-json API? i can help update it to the new release (if wanted) <janneke>i would like/hope for the new release to mature a bit -- be less obnoxious? <janneke>while i think i see the problems, i managed to work around them until now <janneke>also, i like that the old guile-json is almost identical to emacs' json <THFKA4>are there any ideological/licensing issues with packaging ungoogled chromium for guix? <rain1>this may be a bit subjective but one of the difficulties with it is that it takes enormous resources to build from source <bavier>THFKA4: there's an ongoing effort to package it <THFKA4>bavier: thanks, reading the guix-devel archives now <pkill9>THFKA4: i think that parts of the chromium source are unknown of what their license is, and in those cases it's assumed to be nonfree <janneke>how are we doing wrt a postfix+mailman setup in Guix? <pkill9>i forgot to mention in that email the use-case which is to reconfigure the system with a newer guix without recompiling a custom kernel if any of it's dependencies have changed <civodul>pkill9: i suppose we could add an (if (package? kernel) ...) there <allana>I'm failing to successfully mount a luks device as my home partition in guixsd. Can another set of eyes help me diagnose my problem? I'm getting the error: device '/dev/mapper/my-home' not found. I am able to successfully mount the device manually. https://paste.debian.net/1056583/ <janneke>allana: i'm afraid you'll have to use the uuid for the device, label won't work <allana>janneke: Ok, I must have misunderstood the docs regarding the mapped-device target. <allana>janneke: Thanks. I got really excited seeing that example, but it seems to still fail with the same error. The uuid is the source for the mapped device, but it seems that /dev/mapper/<target> is not created. <allana>janneke: Also, I am curious how this works. does guix prompt me for the passphrase? <janneke>yes, and if you luks root then grub wil also ask you <divansantana>how does one gc vms? so guix system vm /some/manifest , then i guix pull and do it again. Will the old one be gc? <janneke>allana: i cannot spot any problem in your example <allana>janneke: You have been very helpful. Thanks for that. I think that in <allana> my case nothing is happening with dependencies or the <allana> mapped-devices. Could it have something to do with how I am trying to <allana> run guix system reconfigure? does it make a difference that I run it <allana> as my normal user "allana" with sudo privileges instread of running <efraim>par-for-each has an unspecified return value, so it can ignore errors in recursive-refresh <roptat>I'm trying to add a recursive feature to the opam importer but it doesn't work... <roptat>I used the same kind of thing as with the pypi importer (recursive-import) <roptat>but the result from it causes an error <roptat>it's supposed to be an srfi-41 stream, but I can't do anything with it <roptat>guix/import/utils.scm:433:41: In procedure car: Wrong type argument in position 1 (expecting pair): () <kristofer>is there a mechanism to restrict which virtual network device a service in a container has access to? <kristofer>I guess just restricting the container to a specific vportX is all I really need <civodul>roptat: looks like 'dependencies' is the empty list in your case? <civodul>the 'car' there looks dubious, at least we should check whether 'dependencies' is empty, i think <civodul>rekado_: should we republish it on the blog? <civodul>the variable called 'dependencies' at guix/import/utils.scm:433:41 <civodul>actually i have no idea, having never touched this code :-) <civodul>i was just trying to provide inspiration <g_bor>civodul: we were thinking about having an overview pag on berlin's web interface <g_bor>some things we would need to know: where a build gets offloaded, and when the build actually start <g_bor>do we have this info somewhere? <civodul>g_bor: the offload location is not stored but it appears in cuirass.log <civodul>there may be cases were admins don't want to publish that info though <civodul>as for when the builds actually starts, i think you can see it in the status <rekado_>for berlin this would be a very useful piece of information; we could better monitor the utilization of the build farm. <rekado_>(well, *any* monitoring allows us to “better monitor […] the build farm”…) <g_bor>I will try to come up with something, and see if that works for you. <civodul>well the queue currently says nothing is running <g_bor>I believe we can have an opt out from that. <civodul>but there are definitely things going on <civodul>it might be that the list is not longer correctly sorted <civodul>normally things with buildstatus >= 0 come first <pkill9>bikeshedding suggestion of the day: add 'guix clone' to automatically pull the latest guix with git <OrangeShark>I am trying to do a system reconfigure but I am getting a sha256 mismatch for nss-certs-3.39 <pkill9>OrangeShark: i think i had that issue as well, i just built it from source <pkill9>just run `guix build --n-substitutes` <pkill9>`guix build --no-substitutes nss-certs`* <bavier>but that doesn't help if the mismatch is on the source <bavier>which indicates the tarball was changed upstream <rekado_>pkill9: how would this differ from “guix pull”? <pkill9>i thought of it when i accidently typed `guix clone`, lol <civodul>OrangeShark: you can also use --fallback to sidestep the hash mismatch issue <rekado_>civodul: thanks for the review of bug#33802. Should I also wrap the fall-through case (in hook-message) in (G_ …)? <roptat>so now I'm trying to add an updater for opam, but I don't know how to "advertise" it? <roptat>like importers are in a list in guix/scripts/import.scm <rekado_>Or may I only use the format string itself with G_? <roptat>ah, mh.. it's in the list-updaters <rekado_>I modified hook-message so that it doesn’t have a fallback; it instead returns #f and the fallback message is printed by the caller with (format port (info (G_ "running profile hook of type '~a'...~%")) hook-type) <civodul>rekado_: yes the fallback case should be (format #f (G_ "running ... ~a") hook-type) <rekado_>having (G_ (format #f "…" hook-type)) would be nicer. <rekado_>I’m just not clear on what is and is not allowed with G_. <roptat>I might have broken something... <roptat>Throw to key `git-error' with args `(#<<git-error> code: -14 message: "the index is locked; this might be due to a concurrent or crashed process" class: 10>)'. <roptat>that's from a normal guix (outside of my repo) <rekado_>roptat: you may need to clean up the git state in ~/.cache/guix <amz3>sneek: tell snape what'up regarding database issues? <sneek>snape, amz3 says: what'up regarding database issues? <civodul>rekado_: G_'s argument must be a literal string because that's what xgettext looks for when it creates POT files <civodul>other than that G_ is just an alias for gettext