IRC channel logs


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?
<OriansJ>THFKA4: by default yes
<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>ok, so not out of the box then
<THFKA4>probably involves modifying the bootloader config to depend on the kernel image and write it to /boot
<THFKA4>anyway, thanks for the help!
<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
<OriansJ>Thus no need for that tweak
<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_>Hi Guix
<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>hello guix!
<g_bor>it seems to me the weather is not good :(
*g_bor building guix
<rekado_>49.4% substitutes available :-/
<g_bor>any idea why?
<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>tune: I don't think it is.
<g_bor>I will have a closer look in a few minutes.
<g_bor>tune: no, it is most probably not packaged yet.
<tune>hm alright
<tune>thanks for checking
<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.
<civodul>Hello Guix!
<roptat>hi guix!
<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_: looks like we're having ENOSPC on some machines:
<civodul>in this case it's /tmp that's full
<civodul>rekado_: it's .132, running the gc, but that one has too little space on /
<civodul>morning g_bor!
<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_>civodul: oh, I’ll take a look now
<rekado_>.132 has 37G on /
<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>rekado_: maybe yes
<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
<civodul>but anyway / is only 50G, right?
<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.
<rekado_>no, /gnu/store is just on /
<rekado_>the 500GB on the RAID is not used.
<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 would buy me some time
<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_>the web interface on
<rekado_>I agree.
<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>It would be nice.
<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?
<g_bor>rekado_:I belive we could.
<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?
<g_bor>rekado_: that would be nice
<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_>comments welcome:
<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/
<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
<rekado_>roptat: thanks, I’ll try that
<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>something like that
<rekado_>makes sense
<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'"
<civodul>anyway i like the idea!
<rekado_>do I need to wrap these string literals in (G_ …)?
<rekado_>I guess not.
<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>roptat: for x86_64, right?
<civodul>could you check for other arches?
<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?
<civodul>just to give them a heads-up
*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
<janneke>civodul: thank you!
<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)
<civodul>dunno about ecryptfs
<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>efraim: cool!
<civodul>i think there's another patch or two where you need to follow up, hint hint ;-)
<efraim>Still chokes on some packages
<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 :/
<rekado_>brendyyn: feel free to send a ping
<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
<THFKA4>yep, i see it now, thanks
<janneke>how are we doing wrt a postfix+mailman setup in Guix?
<civodul>janneke: i'm afraid we're not doing
<pkill9>civodul: would a simple check to see if the kernel package is an inferior be acceptable to be merged in guix to fix this issue?:
<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
<pkill9>yeah that's what i mean
<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.
<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.
<janneke>allana: No, i'm guessing that it's a known bug
<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>oh, not sure what do then...
<allana>to make mine more like the "working" example:
<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>thanks janneke
<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
<allana> it as root?
<allana>sorry for the bad paste.
<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>I get this error:
<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> oh yeah!
<civodul>rekado_: should we republish it on the blog?
<roptat>civodul, "dependencies"?
<civodul>the variable called 'dependencies' at guix/import/utils.scm:433:41
<roptat>how should I fix that?
<civodul>actually i have no idea, having never touched this code :-)
<civodul>i was just trying to provide inspiration
<roptat>ah, I think I understand
<g_bor>hello guix!
<civodul>hey hey!
<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?
<roptat>civodul, it works :)
<civodul>g_bor: the offload location is not stored but it appears in cuirass.log
<civodul>we could store it in the database
<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.
<civodul>like if you go to
<rekado_>(well, *any* monitoring allows us to “better monitor […] the build farm”…)
<g_bor>ok, nice :)
<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
<g_bor>civodul: that is strange
<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
<pkill9>oh ok
<bavier>which indicates the tarball was changed upstream
<OrangeShark>looks like the substitute
<rekado_>pkill9: how would this differ from “guix pull”?
<pkill9>rekado_: i mean an alias of `git clone` =P
<pkill9>i thought of it when i accidently typed `guix clone`, lol
<OrangeShark>so you can start hacking on the source code? :P
<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_>oh, okay
<civodul>ah that would work too
<rekado_>well, it’s uglier
<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?
<amz3>query snape
<amz3>is swedebugia around?
<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