<mark_weaver>f0ff: the hash is of the description of how to build the package, and the descriptions of all the inputs available while building the package, transitively, all the way back to the bootstrap binaries.
<mark_weaver>as well as the hashes of all raw inputs used along the way, e.g. of all sources and bootstrap binaries
<mark_weaver>f0ff: what part of the manual gave you the impression it was only a hash of the ./configure && make && make install ??
<f0ff>but what is the point of hashing the inputs? if a package is comprimised it wont show?
<kqb>mark_weaver: hi, using guix system with "bare bones" example on arch; getting KVM permission denied error; Kernel modules are enabled; BIOS: VT-d enabled; any ideas?
<f0ff>sheesh a test in libarchive fails and i can't continue :( one tiny test fails heh
<hyperreal>mark_weaver: Can you read my text above when you get a chance?
<mark_weaver>hyperreal: what is the output of "stat /gnu/store/...-harbuzz-1.0.6-bin" ?
<hyperreal>mark_weaver: I have the output of the stat command for that exact package, but since it is on another machine, I have no way of showing you. I can't figure out how to start ssh, because then I would just cat the output to a file and scp the file over to this machine, and then paste it into pastebin.
<hyperreal>Anyway, is there any specific info you're looking for in that stat output?
<mark_weaver>owner, mode (permissions), and type (i.e. symlink or directory) ?
<efraim>guix build: error: build failed: derivation `/gnu/store/kcfch6xs5rbxakvhzhl96wq6rlyhbyrv-vim-7.4.1008-checkout.drv' has incorrect output `/gnu/store/pfspp60wvc4bg3hgqla6mjxfqxd4z5n2-vim-7.4.1008-checkout', should be `/gnu/store/7k0zs9cbz3wy6p7hc8jiz1anl27ivr2d-vim-7.4.1008-checkout'
<rekado>I just remembered that I still have this patch to delete "gcc" and other conflicting executables from alternative gcc packages (such as gfortran or gcj). Since hydra hasn't been so busy these days I'll plan to push them today.
<Jookia>roelj: No, native-inputs are things that run on the computer doing the cross-compiling. Like the cross-compiler itself, the build tools (autotools). They don't have to be platform independent, they just have to run
<roelj>Jookia: So, then Bison would be just a regular 'input'?
<taylan>if e.g. bison were a normal input instead of a native-input, the build process would get the bison for the *target* platform, which would fail to execute during the build phase
<Jookia>I am, because it means one day you'll look at my coreboot patches. ;) Joking. Though I think some EFI work needs to be added on top of it. I think it'd be a good idea to make 'device' platform-dependent, so on UEFI they can specify a partition
<civodul>Jookia: i'd say we are here to save the world from chaos
<Jookia>I love how the manylinux1 proposal seems somewhat portable up until they say a requirement "To be eligible for the manylinux1 platform tag, a Python wheel must therefore both [include long list of libraries] and work on a stock CentOS 5.11  system that contains the system package manager's provided versions of these libraries."
<Jookia>"pip users remain free to use the "--no-binary" option if they want to force local builds rather than using pre-built wheel files." This is going to be a default?
<Jookia>The more I read this the more sick I feel. "Distribution of bundled wheels through PyPI is currently the norm for Windows and OS X." "This closely parallels the security implications of the distribution of binary wheels on Windows that,"
<JeanLouis>warning: failed to install locale: Invalid argument, after guix command, is there something i have to do?
<davexunit>I am not in favor of changing the default from the autotools standard
<Jookia>JeanLouis: btw you need to delete /gnu and restart over
<NiAsterisk>a short question: if gnunet-gtk inherits gnunet in the original package, and I have written (or better fitted in and restructured Jookia's patch) a gnunet-svn which inherits gnunet, and now I need a gnunet-gtk which inherits gnunet-svn, is that possible with guile? I assume "yes" and I only ask to avoid some minutes of rebuild and rewrite if I figure out that this inherit chain does not work.
<Jookia>JeanLouis: Or rather, not delete it. But delete /usr/local/var/guix
<suitsmeveryfine>apparently this is a problem that affected T60 Windows users several years ago and it disapperared with a lenovo Bios upgrade. Apparently libreboot has instead regressed in this regard. I've not bothered to investigate this yet.
<JeanLouis>Jookia: I am watching videos from FOSDEM, there are few. And I know the future is shaped by Guix -- but I would like to see the future target or plan, if you know some reference, how GuixSD will change future of free software, let me know
<Jookia>JeanLouis: See Docker, NPM, package managers that download dependencies or lets you deploy programs without caring about the underlying OS packages? Guix does away with that
<JeanLouis>Jookia: yes I understand, there will be sanity.
<JeanLouis>I got a problem, as root, I cannot run nothing
<mark_weaver>civodul: do you know how to fix the problem where we end up with multiple variants of the same grafted package?
<mark_weaver>maybe something needs to be sorted to be deterministic?
<JeanLouis>I have followed the binary guix install, and it is in /usr/local/bin -- but I don't see info guix...
<suitsmeveryfine>a_e: I was just about to try your unecrypted /boot + encrypted / setup but now I remember this: on the particular computer I will try this on I won't be able to access GuixSD's GRUB menu.
<a_e>Since when you do "guix system init" inside the USB installer, it does not reboot automatically. It just installs everything.
<suitsmeveryfine>mark_weaver: I've got an LCD that's not entirely compatible with coreboot
<mark_weaver>one of the things that the "#$sugar" (i.e. eye-candy) does is "terminal_output gfxterm" which may have the effect of switching the output away from the serial console and to a screen that you can't see
<suitsmeveryfine>mark_weaver: I see, so that I can see it in GNU Screen. I will try this!
<mark_weaver>we should probably be installing a separate libreboot_grub.cfg (or is it coreboot_grub.cfg now?) that avoids things like that
<Jookia>mark_weaver: I have a patch that that can be built on
<a_e>suitsmeveryfine: But even then, you should edit the grub.cfg _before_ you reboot.
<Jookia>It already creats coreboot_grub.cfg and friends
<JeanLouis>yes it is just with new mutt version, no problem
<JeanLouis>collectively of course, but isn't it that packages are assigned to package maintainers?
<JeanLouis>for example, to suggest ./configure option to mutt, like --enable-hcache
<JeanLouis>for example, I tried changing: at line 1008: of mail.scm: "mail.scm" 1008: "--enable-hcache" and now: guix package -f mail.scm fails with: ERROR: In procedure string-prefix?: Wrong type argument in position 2
<a_e>You can create a patch, try it out and send it to the mailing list.
<a_e>But in that case, you should start from a current git checkout.
<CompanionCube>ACTION is not using guix texlive because of it being a huge monolithic package
<a_e>That is what all developers use. And the line numbers are different.