IRC channel logs
2015-07-13.log
back to list of logs
<sneek>civodul, you have 1 message. <sneek>civodul, bavier1 says: yes, I've done quite a bit of work trying to get 'refresh -l' to be more reliable in the face of implicit inputs. Handling dynamically created packages (e.g. with package-with-python2) then became a critical issue. I haven't yet gotten a solution that's fast or accurate enough for my taste. <civodul>bavier1: using bags instead of packages would be an improvement already <civodul>ACTION hacks multiple-server support in 'guix substitute' <mark_weaver>civodul: the release of linux-libre-4.1.2 is considerably delayed, and I wanted to create a new 'source' package for it that creates linux-libre-4.1.2-gnu.tar.xz from linux-libre-4.1.1.tar.xz and patch-4.1.1-2.xz from kernel.org. however, it looks to me like there's no straightforward way to do that. the only way I could find is to create a new origin method. am I missing something? <mark_weaver>it seems that I cannot create a normal package whose output ends with .tar.xz <mark_weaver>and also, 'patch-and-repack' can't handle compressed patches <civodul>mark_weaver: i think you could use a snippet for that, possibly writing it as a gexp <mark_weaver>nor can it create an output tarball with a different version number than its original source. <civodul>if it's a gexp, you can have it depend on xz, patch, and whatever is needed <mark_weaver>ah, that's interesting, I hadn't thought of using a gexp snippet. <civodul>but yeah, i think the output file name is fixed <civodul>but do you think it's important not to wait for the upstream release? <civodul>actually, you can specify a file name via the 'file-name' field of <origin>, no? <mark_weaver>well, my understanding is that these kernel updates are almost always security relevant. <civodul>maybe we should get in touch with aoliva & co.? <mark_weaver>civodul: I thought of that, but the pre-patched one should have 4.1.1 in the name, and the post-patched one should have 4.1.2 in the name. <civodul>mark_weaver: that's OK: 'file-name' is for the result, i.e., the post-patched one <mark_weaver>I exchanged a message with him yesterday on #libreboot, and he said that he had just returned from FISL and that it should be done by last night. <mark_weaver>civodul: if I set 'file-name' to include 4.1.2, will that also mean that the pre-patched one also has 4.1.2 in the name? <civodul>no, but the pre-patched one is "invisible" anyway <mark_weaver>yeah, at this point I've mostly given up on this, except that I'd like to improve guix to make this nicer. <mark_weaver>well, I don't like things being mislabelled in the store. <mark_weaver>sometimes, a patch will be to change the version number of something. it should be possible to have a different name after patching, I think. <civodul>ooh, you're right that the pre-patched one ends up having the same name as the post-patched one <mark_weaver>and it would be nice if 'patch-and-repack' handled compressed patches from a downloaded URL. <mark_weaver>I was looking into how to do that without forcing a full rebuild, and concluded that it should be possible but that I don't yet know enough about gexps and monads in guix. <mark_weaver>anyway, I'll let you get back to multi-server support; I have to afk anyway. thanks for the chat! <civodul>sometimes, avoiding rebuilds requires nasty hacks <civodul>like entangled conditional code generation <mark_weaver>well, I thought it might be possible to do it in 'instantiate-patch' in 'patch-and-repack'. <mark_weaver>by detecting the extension on the derivation filename and wrapping a new derivation around the old one that does the uncompress. <civodul>that function has grown big, we should make a (guix build origin) module someday :-) <civodul>the nice thing is that evaluation of that branch is *much* faster... <civodul>hmm, our nss-certs has nothing matching the signer of fencepost.gnu.org's cert <paroneayea>so, I started making baby steps towards figuring out how to do server deployment with guix / guixops over the last week <paroneayea>first was getting davexunit's wip-deploy branch actually working <paroneayea>second was getting those pelican patches to the list <paroneayea>and third, I've got some patches that I *think* do port forwarding for virtual machines though guix system spawn/vm but I'm not sure yet :) <civodul>i need to look at the patches you posted, BTW <paroneayea>but I think foruth, I spent some time searching for how to supply config files through the system definitions, only to find out that I wasn't missing something, there's no official way currently? :) <paroneayea>mark_weaver pointed this out, said there was a thread on how to do so but it hasn't gone places yet <paroneayea>I got excited about the functional system definition approach to this though when I read this: <paroneayea>which, the idea of also being able to roll back a system configuration just the same way you can roll back packages is *appealing* <paroneayea>though it seems we don't quite have the things in place for that yet <paroneayea>not sure what the direction will be, or if I can help with it <paroneayea>civodul: btw, do you remember anything about that topic being on the list? I searched the archives but searching for "file" and "system" aren't exactly meaningful search terms :) <civodul>paroneayea: GuixSD does support roll-back and all that <paroneayea>civodul: it does indeed! but there doesn't seem to be anything that integrates with the system stuff and files <paroneayea>civodul: I needed to supply a config file to nginx for example <paroneayea>and it would be nice to drop that into the system definition <civodul>so one can do: (syslog-service #:config (local-file "/home/ludo/foo.conf")) <civodul>so for nginx we can do something similar <paroneayea>civodul: but maybe there could be some way to put something on the system definition <paroneayea>civodul: it would be nice for sure to also have such things for nginx service definitions <paroneayea>civodul: but maybe a generic way to attach to the operating-system declaration <civodul>paroneayea: currently config files can be passed to the specific service procedure that needs them <civodul>most services in gnu/services/*.scm do that in fact <paroneayea>civodul: maybe we can have a static-file-service :) <civodul>you mean to install files in a specific place? <paroneayea>civodul: probably, I mean so that they'll appear in the profile in "specific places" <paroneayea>civodul: or do you think that will be frowned upon as encouraging non-functional usage of relying on things at these specific paths? <paroneayea>as opposed to based on being composed from inpus <paroneayea>civodul: it nonetheless seems to me like maybe a good idea for some things, though right now I'm having trouble pointing out which ones they might be :) <tyrion-mx>I am still trying to install guix :) (sooner or later I will succeed) <tyrion-mx>I was wonder, why do I need to install grub on the guix partition if I already have it on my system? <tyrion-mx>wouldn't it be possible to just add an entry to the existing grub? <alezost>tyrion-mx: yes, I always use "--no-grub" option for any "guix system" command <mark_weaver>alezost: does --no-grub mean that you don't get the grub.cfg either? if so, that means no easy way to boot older instances of the system, right? <mark_weaver>I had recommended installing grub, but installing it on /dev/sdaN instead of /dev/sda, so that it doesn't actually interfere with the existing system grub. <mark_weaver>and then he could add an item to his host grub.cfg that loads guix's grub.cfg <alezost>mark_weaver: I can easily boot the older instances by editing a number of my "stable" system in the grub menu <tyrion-mx>mark_weaver, could you remind me why I cannot prepare my partition using the guix that I have currently installed on ubuntu? <alezost>I have my own manually managed grub.cfg and I don't allow anything but me to touch it :-) <mark_weaver>alezost: okay, I guess it's doable, but this way seemed a bit nicer to me than having to manually edit <mark_weaver>tyrion-mx: you can use 'guix system init' from guix running on ubuntu, yes. <mark_weaver>I suggested the usb stick, but you could do it either way <alezost>mark_weaver: actually I have never needed to boot any system but the "current" or "stable" ones <alezost>tyrion-mx: no difference, I installed GuixSD from another distro <mark_weaver>tyrion-mx: as long as the guix you build for ubuntu has --localstatedir=/var and the store in /gnu/store (the default), it should be the same, I think. <mark_weaver>(--localstatedir=/var is *not* the default when building from source) <tyrion-mx>.. anyway the manual says to run: deco start cow-store /mnt <tyrion-mx>can I safely skip that step when installing from ubuntu? <tyrion-mx>where should I put the "mapped-device" declaration? <alezost>tyrion-mx: I've never used mapped-device, but according to source – yes, to "mapped-devices" <tyrion-mx>thanks, because I couldn't find it in the docs <tyrion-mx>I hope guix does not destroy it, otherwise I am fucked <alezost>tyrion-mx: I've found the mention of "mapped-devices" in (info "(guix) operating-system Reference") <tyrion-mx>does anyone here uses luks with guix? I need a bit of help setting up encrypted ram <mark_weaver>I'd like to learn about setting up luks with guix at some point, but haven't yet done so. <tyrion-mx>an other question, if I want for example to add an other file-system or user to the system after installation <mark_weaver>I'm not sure if guix supports an encrypted root partition yet. <tyrion-mx>am I supposed to edit the file, and tell it to update, or can I edit directly the conf like I do on ubuntu <tyrion-mx>I mean, is the whole os like a "pure" functional thing, or only the packages <mark_weaver>you edit the os config and then run "guix system reconfigure <os-config>" from within the installed GuixSD system. <tyrion-mx>so then guix takes care of editing the files in /etc for me? <mark_weaver>btw, at present, /var should be on the root partition <civodul>paroneayea: many packages put sample configuration files in their SYSCONFIG, which is PREFIX/etc <mark_weaver>at some point we'll lift that limitation, but right now some things are created in /var before any other filesystems have been mounted. <mark_weaver>civodul: so, one other thing I want to get in this core-updates cycle is passing --build=<triplet> by default from gnu-build-system. <mark_weaver>but I looked at it and was a bit uncertain of how to go about it. <civodul>mark_weaver: if in doubt, we can delay it until the next cycle, which will be soon anyway <mark_weaver>nix-system->gnu-triplet is in (guix utils), and I don't really want to move that logic into the build side. <mark_weaver>because I want to be able to extend that logic without rebuilding everything. <mark_weaver>so I was thinking that instead that logic would be used when the derivation is created, and passed in via an argument <civodul>even better: via a GUIX_TRIPLET env var <civodul>alezost: it's interesting that you prefer to manage grub.cfg by hand! <mark_weaver>civodul: so, would this logic go in 'gnu-build' in (guix build-system gnu) ? <mark_weaver>maybe by passing GUIX_TRIPLET as an env-var to the call to 'build-expression->derivation' in there? <mark_weaver>hmm, although cross-builds have to be handled differently. <mark_weaver>my other thought was to add it to the 'configure-flags' passed to 'gnu-build' in 'builder' within 'gnu-build' in (guix build-system gnu) <civodul>for cross-build, there's already #:target passed to the build side <mark_weaver>civodul: well, I mean that maybe I should avoid passing --build when doing a cross-build? perhaps by looking for the 'target' keyword argument? <mark_weaver>actually, I guess that we could pass --build during cross-builds as well. <civodul>yes, --build can be passed unconditionally <civodul>mark_weaver: can you remind me what config.guess returns on ARM vs. what we want to pass? <mark_weaver>unfortunately, the hard drive I was using on my novena is close to death, with lots of I/O errors and such, so further testing on armhf may be delayed. <mark_weaver>civodul: well, in cases where config.guess didn't work, I've just been passing the result of 'nix-system->gnu-triplet' <mark_weaver>for armhf-linux, that returns "arm-unknown-linux-gnueabihf" <mark_weaver>well, I don't remember off-hand what an up-to-date config.guess returns on Novena, but it depends on what kind of arm device you're running on, and also on whether config.guess is new enough to support the machine. <mark_weaver>okay, I just ran config.guess from guix on the novena, and it returns: armv7l-unknown-linux-gnueabihf <civodul>and the problem is that it might strip the "v7l" part on other machines? <mark_weaver>as I recall, I experimented with various triplets and settled on arm-unknown-linux-gnueabihf because some build systems (generated from ancient autotools) didn't cope well with the v7l or similar. <mark_weaver>our gcc is configured to generate code for arm7 anyway, so in the overwhelming majority of cases, it shouldn't matter. <mark_weaver>it's possible that there are some packages where we'll want to override the triplet passed via --build, but I expect that to be rare. <mark_weaver>so maybe it should be a build system argument, with a defaulting to (nix-system->gnu-triplet (%current-system)) <mark_weaver>civodul: sorry, to answer your question: the problem with config.guess is that it decides what triplet to report based on the details of the build machine, e.g. the specific CPU in the machine, and maybe also the kernel that's running. <mark_weaver>which is a source of non-determinism in the builds that are not factored into the nix hash. <mark_weaver>and also means that if we use an armv8 build machine, the builds done on that machine will not run on armv7. <mark_weaver>so the whole idea here is to avoid config.guess, since it doesn't do what we want. <mark_weaver>it happens to work well enough on intel machines in practice (perhaps because we don't have an i586 port), but on other architectures it looks at things like /proc/cpuinfo and uname output. <mark_weaver>so, on arm, that 'armv7l' comes directly from the output of 'uname -m' <mark_weaver>and that is ultimately coming from the kernel's probe of the arm processor it's running on. <civodul>mark_weaver: it's a good idea to make #:build a build-system argument, just in case <mark_weaver>so, on my novena, /proc/cpuinfo reports: "model name: ARMv7 Processor rev 10 (v7l)" <mark_weaver>civodul: okay, sounds good. I think I know what to do now. thanks! <civodul>tyrion-mx: these are all harmless (but annoying) <tyrion-mx>anyway guix downloaded a lot of stuff and installed it but I still don't see anything under /mnt ? <civodul>so you run 'guix system init config.scm /mnt', right? <tyrion-mx>and also now I am getting: WARNING: compilation of /gnu/store/5cqm1pk28agrc5yys99c6ng8i9ki5chg-guile-2.0.11/bin/guild failed: <civodul>ok, so it will eventually complete, i guess <civodul>these are all build logs that maybe we should silence <tyrion-mx>ERROR: failed to create path for auto-compiled file "/gnu/store/5cqm1pk28agrc5yys99c6ng8i9ki5chg-guile-2.0.11/bin/guild" <- and then this <tyrion-mx>it is repeating this error every 5 lines or so.. <civodul>if something goes wrong 'guix system init' will simply fail <tyrion-mx>gnu/packages/$somename.go <- is that stuff written in golang? <amz3>.go is the extension of source files of golang, compiled program are single binaries <amz3>I think they have .so files too