<amz3>svetlana: you can do it, it simple scroll up to read the command from civodul
<mark_weaver>well, a disk image anyway. we don't yet have the mechanism to create an ISO
<amz3>well one can create usb disk live image it can be enough for linux users
<carif>mark_weaver, so at the end grub-install appears to fail and I need to 'grub install --boot-directory=/mnt /dev/sda' for my target disk drive /dev/sda. When I boot, I get the grub cli to which I must load the configfile with 'configfile (hd0,msdos1)/boot/grub/grub.cfg'. Then I boot.
<cirno9>oh no, failed install grub2 after populating /mnt/gnuguix
<carif>this might be unique to me since I'm doing this crufty kvm thing
<carif>mark_weaver, well with a little bit of futzing it appears doable. Looking at the email archive, others have managed too. It's a good way to "kick the tires" if you don't have a spare pc lying around.
<carif>i was handicapped a little by learning qemu-img/kvm/virt-manager in parallel.
<daviid>mark_weaver: off topic, should i send the g-wrap [which is a non gnu project] release email to email@example.com? asking because it is an essential component to guile-gnome[clutter] which are gnu projects ... don't know
<daviid>mark_weaver: i guess not, someone can forward it later anyway, sorry to bother you with that.
<mark_weaver>daviid: I'm not sure, but I suspect it's not appropriate to post a release announcement for a non-GNU program to info-gnu
<mark_weaver>bdwgc is an essential component to guile, but bdwgc announcements aren't posted there either.
<daviid>yeah, agreed, i did not [just sent it], tx
<davexunit>ACTION waits on newly built world downloads so he can wget the soon-to-be release image
<mark_weaver>anyway, this is a discussion that should happen with civodul present and engaged. email might be best.
<mark_weaver>I agree that something like this would be good, I'm just not quite sure what it should look like.
<mark_weaver>we have "guix environment" to create an environment fairly close to the build environment.
<mark_weaver>and we have the -K option to keep the failed build directory. when needed, I usually chmod -R that to my user, create a shell with the environment variables used in the build (by running "env -i $(which bash)" and then "source environment-variables".
<mark_weaver>but I agree that we could use some more polished tools for this.
<paroneayea>mark_weaver: I'd love a way to reproduce that :)
<effa>Hi, I'm trying to package a program whose tar doesn't generate it's own directory, but puts files in the current directory. I need to patch the source and I find that, as soon as you have a 'patch' field in 'origin', guix tries to generate a new patched tar. The problem I'm having is that it chooses the first directory in the current directory as the location of the source and only include the chosen directory in the patched tar. In
<effa>this case the chosen directory is 'dir' and is empty, while the source is in 'src'. I've tryied with a snippet, but the source directory appears to be chosen before the snippet is run. Any suggestion? Thanks!
<davexunit>bah, the container tests fail when building guix-devel. guess I'm gonna leave that phase active for now.
<svetlana>I mean having an iso would make it possible to try a live cd out of the box. I am sure it is planned at some release I just don't know when. I'm not sure why I'm asking either as I don't yet have the hardware so it's more of a theoretical question.
<civodul>USB slots are more common than CD players now
<yenda>browse with icecat and you realize how few of the web is entirely
<mark_weaver>I don't see anything that looks like a test suite running
<mark_weaver>however, running 'file' on the build library looks like it's the right architecture.
<mark_weaver>yenda: if you change the package bound to variable 'python-2', then you will have to rebuild a *lot* of stuff that uses it. however, if you make a new package, inheriting from 'python-2' but with a different variable name, then it won't force rebuilds, since it won't be the one that is used as build inputs for other things.
<mark_weaver>yenda: our python 3 package inherits from 'python-2', so you can see an example of inheriting.
<mark_weaver>just inherit 'python-2', and override the 'version' and 'source' fields.
<mark_weaver>I would start by copying the 'source' field from 'python-2', with just the hash updated to match the tarball for your chosen version.
<davexunit>yenda: 2.7.10 has a built-in pip? that's nice.
<davexunit>though, of course, in guix land you would like guix to be your only package manager ;)
<yenda>in guix packages updates are updates of the whole thing rather than patches ?
<davexunit>the thing to note is that it 'guix import' is just generating code snippets for you.
<yenda>ok I wasn't sure if it was just a warning or somethign went wrong
<davexunit>you still need to copy/paste that snippet in a scheme file
<davexunit>and make the tweaks necessary for it to build successfully
<davexunit>'guix import' is a boilerplate reducer. it takes as much of the machine automatable work away from you as it can.
<yenda>davexunit: where should I put the scheme file ?
<mark_weaver>yenda: if you have a built guix git checkout, then put it in gnu/packages/*.scm. otherwise, put it in a new directory and set GUIX_PACKAGE_PATH to the absolute path name of that directory.
<davexunit>yenda: in this case, it would go in gnu/packages/python.scm with the other python packages.
<mark_weaver>also, the module name in your file must correspond to its location in the filesystem relative to GUIX_PACKAGE_PATH
<davexunit>if you intend to submit this as an upstream patch, that is.
<mark_weaver>e.g. a module named (gnu packages foo) needs to be in $DIR/gnu/packages/foo.scm where $DIR is one of the components of GUIX_PACKAGE_PATH
<mark_weaver>however, I would recommend that you build guix from it's git checkout, to facilitate contributing your work to us, and, if you like, to allow you to make (and easily maintain) arbitrary modifications to your private branch of guix.
<mark_weaver>within the subshell spawned by 'guix environment guix', cd into the git checkout, run "./bootstrap && ./configure --localstatedir=/var --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) && make"
<mark_weaver>maybe add a -j<n> to that "make" command, where <n> is the number of cores you have
<yenda>ok thanks for the help I have to leave, I'll do all of this tomorrow
<alezost>civodul: I'm going to push man-db commits now; isn't it too late? Also I would like to push "gnu: Add sox." patch I sent about a week ago, I've just tested it again (with the latest packages) and it worked. Is it ok?
<mark_weaver>maybe because this is the first time I'm building a profile in the new core updates, which entails building glibc-utf8-locales, which I guess is based on a different glibc than the "final" one.
<ryouma>i'm just a leecher here, hoping everybody else will do the hard work, in my place, of creating a distro and make it good enough and popular enough that i can switch to it from debian, at which point i will contribute like a normal person :)
<davexunit>ryouma: jump in the pool, the water is fine.
<ryouma>what kind of booting does guixsd use? i have been frustrated by debian's grub and update-initramfs setup
<yenda->tonight my goal is to switch to vanilla kernel
<yenda->at least linux-libre made me realize how much hardware makers suck
<ryouma>what do you do if you run guixsd and your video card doesn't work because the free driver no longer works for some moronic reason, or if you need the guest additions for virtualbox (which are in contrib in debian for some reason even though there is no nonfree code iirc)?
<mark_weaver>you could also periodically merge upstream master into your branch, if you prefer.
<yenda->I was ready to give up my gpu for guix, but even my onboard gpu has proprietary firmware so I don't have much choice until I have the money to change it. And since I would like to convince other people to use guixsd, I don't see myself telling "btw buy a new pc first"
<mark_weaver>a less flexible method that some people might prefer is to put private package definitions in a private directory and set GUIX_PACKAGE_PATH to include that directory.
<ryouma>yeah i will not buy a new video card until i get a computer with a free-compatible card (like presumably intel cpu onboard is the most likely to be compatible). (as it is now, wheezy free works, but jessie free does not.)
<mark_weaver>civodul: I vaguely remember learning that ocaml includes camlp4, but maybe I'm misremembering.
<yenda->but as mark_weaver told be the other day intel is the worst because even though the gpu might be free compatible at the system layer, the bios is not at all right ? and the northbridge chipset as it's own firmware with internet access ?
<ryouma>mark_weaver: it's a question based in ignorance, perhaps, but i thought nix controlled enough elements to ensure binary reproducibility ootb, thus guix wo8uld also already, but i guess not. in any case glad to see there's an effort to ensure it.
<civodul>Nix & Guix have tight control over the build environment, which definitely helps
<civodul>but there are sources of non-determinism that are beyond that
<mark_weaver>sources of non-determinism that can leak into builds include: the clock, the random number generator, the kernel in use, the hardware details
<ryouma>perhaps file metadata like ownership and umask?
<mark_weaver>our methods of build isolation should take care of umask and most metadata.
<mark_weaver>but the uid/gid of the build process is accessible, and could leak into the build outputs in some cases
<civodul>mark_weaver: could you build the armhf tarball from commit 5d09263?