<mark_weaver>but if all else fails, you can download files using some other method and then run "guix download file:///home/xxx/file.tar.gz" or whatever, and it will add that to the store, then restart the build.
<catern>yeah, http_proxy was set in the guix-daemon environment
<mark_weaver>catern: are you sure? looking at the code, it appears that we've made an effort to ensure that those env vars are propagated to the download derivations
<mark_weaver>no, for a couple of reasons, one of which is that tarballs typically contain more files than are in the git repo.
<mark_weaver>e.g. they typically have had automake/autoconf/libtool/autopoint/etc run on them, to generate things like ./configure, which are often not in the git repo.
<galex-713>yeah but can’t these files be deterministically generated from the GNU autotools?
<mark_weaver>but also, the hash of a tarball is the hash of a single file, the compressed tarball, whereas the hash of a directory checked out by git is the hash of the directory serialized using nix's special way of serializing directories for that purpose.
<mark_weaver>it doesn't matter whether they "can" be deterministically generated. the point is, a tarball has different stuff in it than the git repo, so it's going to have a different hash.
<mark_weaver>but anyway, the result of running autotools depends on a lot of details that are typically not controlled, e.g. the versions of all of the dependent libraries that provide *.m4 files to contribute to the resulting ./configure
<mark_weaver>we can control those things in guix, but most developers are running that stuff on a more traditional distro where the results depend on the details of their system.
<mark_weaver>anyway, you wouldn't be able to accomplish that in practice anyway.
<galex-713>But maybe some high level stuff too like using shared binaries
<mark_weaver>it would be a *large* amount of work to arrange to duplicate the same autotools setup and same versions of all dependencies that the upstream developer happened to have on their system when they ran autotools to create a release tarball. and that work would need to be repeated for every upstream release.
<mark_weaver>we would need to do things like package up old versions of other software, e.g. to match the versions that are in debian on that developer's machine
<mark_weaver>it would be an *insane* amount of effort and work, just to save some rebuilds
<galex-713>mark_weaver: why not just erasing “non deterministic” information of autotools-produced files, just like we erase timestamps on binaries?
<mark_weaver>it would be easier to go in the other direction. to *remove* the stuff from tarballs that are not present in the git reop.
<mark_weaver>galex-713: I figured it out. you need to run "gpg --expert --full-gen-key" to see the ECC options
<mark_weaver>description of the --expert option: "Allow the user to do certain nonsensical or "silly" things like signing an expired or revoked key, or certain potentially incompatible things like generating unusual key types. This also disables certain warning messages about potentially incompatible. As the name implies, this option is for experts only. If you don't fully understand the implications of what it allows you to do, leave this off."
<galex-713>mark_weaver: yeah! now I remember that trick!
<mark_weaver>there was a time when I very frequently had to restart that, especially after reconnecting to the net, but everything has seemed to work very well for me in recent months, and I've not had to touch it.
<jmd>Would it not be a good idea for guix pull to happen as the last thing in the install process?
<mark_weaver>it's probably good for the initial 'guix system init' to use the release version of guix, because that should reduce the possibility of lots of local builds, or things being broken.
<mark_weaver>however, we should probably recommend that after successfully booting into the installed system, 'guix pull' should be run and then 'guix system reconfigure
<mark_weaver>the cost of a failed 'guix system init' is usually quite high, because it typically requires starting again from scratch.
<mark_weaver>however, the cost of a failed 'guix system reconfigure' is trivial, because you can just select an older generation from the GRUB menu.
<mark_weaver>so, we should encourage using a minimally-modified, well-tested configuration for the initial install.
<jmd>Presumably guix system can be run only as root?
<mark_weaver>'guix system build' can be run as anyone. ditto for several of the other commands.
<mark_weaver>however, 'guix system init' and 'guix system reconfigure' require root access of course.
<efraim>guix system init can take over building from where it failed if it failed to download a package, but if you start with a tested or a minimal OS configuration it shouldn't be too bad to get started again
<roptat>so I'm trying to get more networking support in containers, and as I read how it should be done, I had a question
<roptat>to create a new network device, you would have to use iproute2 utilities or use the netlink protocol directly (either by writing a c library and a scheme binding, or directly using existing socket bindings in scheme)
<jmd>debian has a "pseudo package" build-essential. Is there a similar thing in guix ?
<balduin>@ng0: This is the output of guix + haxe: http://paste.lisp.org/display/323723 and this is the output if I build it locally: http://paste.lisp.org/display/323724 . The guix build stops at: make: *** No rule to make target 'libs/ilib/il.cmxa', needed by 'src/typing/common.cmx'. Stop. The native build does not have the problem. Another interesting fact is that the native build goes into more directories `entering directory xyz` and builds the `ilib` directory later
<balduin>@ng0: okay, while trying to explain the problem to you, I figured out that the build order is more random in guix. I added #:parallel-build? #f now it does not stop there. Does guix always build targets in random order parallel?
<ng0>i have a problem with suid i think. either i need to build as "root" or i need sudo, where sudo is not wokring in build env. can the suid be fixed after the setup or is there some package doing it already I can take a look at?
<jmd>I think suid binaries have to be listed in /etc/config.scm
<lfam>`./pre-inst-env guix build --source firstname.lastname@example.org` returns the expected source tarball, but `guix build` wants to use the tarball for 3.5.2
<balduin>what is the difference between native inputs and normal inputs?
<lfam>balduin: native inputs are built for the architecture of the build machine, rather than the target machine. This matters when cross-building. In practice, native inputs are typically things only used at build time
<balduin>@lfam: could you add this sentence to the guix documentation?
<balduin>it is not documented what the difference is.
<joshuaBPMan_>I'll try poking at the GuixSD manual and see if that says anything
<OriansJ>Good news everyone stage0 updates include a python3 Web Debugger and a line macro processing program, which is flexible enough to convert any assembly to hex or octal. https://github.com/oriansj/stage0
<OriansJ>joshuaBPMan_: actually it is going to be a full set of tools that would enable one to bootstrap the entire Guix root binaries. There just remains alot more work to do before it is complete.
<OriansJ>I am effectively having to write assemblers, loaders and other support tools in hex. Once that is done, I'll leverage them to make the next step up in terms of tooling, until that is reached.
<joshuaBPMan_>OriansJ: I am a bit of a newbie here. Why are you so motivated to do this? Don't we already have tools that can bootstrap the Guix root binaries?
<OriansJ>joshuaBPMan_: Yes you are correct, however I desire to reduce the number to trusted binaries in the root to a sub 512Byte hex monitor
<OriansJ>I've already had the x86 hex monitor independently verified on a dozen different Hardware architectures, which means once I am done we will have a set of binaries that are trusted completely and can be manually verified [or hand toggled in if desired]
<joshuaBPMan_>OK. So you're wanting to make it harder to do something like this:
<mark_weaver><jmd> [08:03:41] gcc-toolchain doesn't seem to provide crtl.o
<mark_weaver>jmd: what exactly did you try, and what was the error output?
<mark_weaver>jmd: regarding setuid binaries, see section 7.2.8 (Setuid Programs) in the Guix manual
<mark_weaver><jmd> [10:05:54] Why does guix have to update substitutes in order to *remove* a package?
<mark_weaver>jmd: because any operation in 'guix package', including removing a package, actually doesn't remove anything, it only builds something new, namely a new profile containing a new set of packages, and part of that process involves running programs to build that new profile, and it uses the latest available versions of those programs to do that. if you don't already have those, then you'll need to download or build them.
<mark_weaver><jmd> [12:01:08] Why is it that after package --switch-generations new package installs don't create a new generation?
<mark_weaver>jmd: what happened when you tried to install a package after that?
<mark_weaver>if the profile you were trying to create had already been built, then it wouldn't have to build it again, it could just move the symlink.
<jmd>mark_weaver: In which order should I answer your questions?
<mark_weaver>balduin: can you tell me what command you tried, and what happened?
<jmd>It modfied the current generation instead of creating new one.
<jmd>There were link errors due to unresolved symbols.
<mark_weaver>jmd: can you give me a self-contained example, e.g. a simple test program and an exact command so I can reproduce what you're seeing?
<mark_weaver>did you install binutils in the same profile? if the 'ld' you're using is the one from 'binutils' and not the one from 'gcc-toolchain', that could explain this.
<mark_weaver>(gcc-toolchain uses 'ld' from the 'ld-wrapper' package, which handles adding rpaths so that shared libraries can be found)
<mark_weaver>'gcc-toolchain' includes 'gcc', 'binutils', 'glibc', and 'ld-wrapper'. if you have those other things installed separately, you should remove them from your profile.
<jmd>So far as I'm aware I've only been dealing with one profile.
<mark_weaver>jmd: regarding the profile thing: yeah, that's how civodul chose to make that work, although it should be said that it doesn't actually *modify* anything, except for the symlink for that profile generation. the profiles themselves are immutable store items.
<mark_weaver>the mapping from profile number to store item is in /var/guix/profiles/per-user/jmd
<mark_weaver>so, if you roll-back to generation N, and then make a new profile, it creates it as generation N+1, removing the pre-existing symlink for generation N+1. feel free to engage civodul in a converstion about whether that's desirable or not :)
<mark_weaver><jmd> So far as I'm aware I've only been dealing with one profile.
<mark_weaver>jmd: I guess we are using the word "profile" in a couple of different ways. in one sense, a new profile (/gnu/store/...-profile) is created every time you make any "changes" to your profile using "guix package", even when removing packages.
<mark_weaver>but sometimes we use "profile" in a different sense, where we say that there's one profile per user (possibly more than one if they run "guix package -p ...", and one system profile /run/current-system/profile.
<mark_weaver>and when we use "profile" in that sense, we are referring to the symlinks ~jmd/.guix-profile, ~root/.guix-profile, /run/current-system/profile
<jmd>mark_weaver: So it would seem we have a proliferation of profile purportations.
<efraim>sneek: later tell lfam if its not too disruptive go ahead and pull in the python-2.7.12 update f0499100a62e0b36ea31ad46021d30a9868b71ea , it really ended up being a drop-in replacement for 2.7.11.
<jmd>How should I add my own private packages to a GuixSD installation?
<mark_weaver>jmd: my preferred way is to build guix from a git checkout, and then run guix out my own private branch, which I periodically rebase to upstream master. however, another way is to use GUIX_PACKAGE_PATH. see section 7.5 (Package Modules) in the guix manual.