<lfam>paroneayea: I made the old python-3.5 patch work <lfam>Do you want me to take it over, or do you want to revisit it yourself? ***fkz is now known as Guest95711
<lfam>Okay, will do. Thanks for getting it this far :) <catern>hello, #guix. does guix support http_proxy and https_proxy yet? <catern>because guix doesn't seem to me to support http_proxy and https_proxy <catern>'cause all my source tarball downloads are failing <catern>"ERROR: In prodcedure connect: Network is unreachable" <catern>ah! it was due to not having gnutls, I guess?? <catern>ah... okay.... nevermind it's still happening. <catern>now that I have gnutls, I do get a warning "substitute: warning: 'https_proxy' is ignored" <catern>but uh, http_proxy also still seems to be ignored? <mark_weaver>catern: if that's going to work at all, http_proxy will need to be set within the environment that runs guix-daemon <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 <catern>hmm, I was using pre-inst-env, would that affect it? <catern>other than that I was starting guix-daemon from the same shell as guix build, http_proxy was definitely set <galex-713>Why aren’t emacs 25.1 and gnupg 2.1.15 inside guix? how can I build them? <catern>mark_weaver: wget works just fine for instance so I think it's correct <catern>(and the wget log says it goes through the proxy) <mark_weaver>catern: you can look at /proc/<PID>/environ, where <PID> is the process ID of guix-daemon, to see the environment <catern>i will try that when I next get a chance <mark_weaver>galex-713: emacs-25.1 is not yet released. I've been using its prereleases and rc's on my own system for some time, though. <mark_weaver>gnupg is not updated on master because it requires a newer libgpg-error, which would require rebuilding a large amount of other stuff.. too much. <galex-713>mark_weaver: how can I rebuild that large amount of other stuff myself then? <mark_weaver>you can run guix out of a git checkout, and update those recipes yourself in your copy of the source. <mark_weaver>"guix refresh -l libgpg-error" tells me that 2316 packages would need to be rebuilt <galex-713>actually I installed guix from git, then installed guix again with guix, then make-uninstall-ed the guix I installed through git… so now where are my recipes? <mark_weaver>I don't recommend running "make install". just use ./pre-inst-env to run it uninstalled, or set the ~/.config/guix/latest symlink to point to it after its been built. <galex-713>gpg --full-gen-key only proposes me combinations of DSA, RSA and ElGamal <galex-713>Anyway, now guix is installed with guix, where are stored the recipes? <mark_weaver>gpg --version tells me that it supports ECDH, ECDSA, and EDDSA, among others <mark_weaver>maybe you're using it wrong. "gpg --version" claims it supports more pubkey algorithms than those. <mark_weaver>I really doubt that they would add major new features like that between micro versions <mark_weaver>it may be a bug in the menus presented by --full-gen-key <galex-713>So I need to find again what’s the weird way to make a pubkey so that you have curves25519 <mark_weaver>anyway, if you want emacs-25.1-rc1, the easiest way would be to use the --with-source argument. see section 6.1.2 (Package Transformation Options) in the manual <mark_weaver>although in my case I updated the 'emacs' package in my private git branch, which also forced rebuilds of some other things like guix and magit, etc. it wasn't too bad though. <galex-713>Probably more reasonable to wait for the “stable” release :) <galex-713>You can configure guix to use a git release? :o <mark_weaver>yes, that can be done, but I was using the tarballs available at ftp://alpha.gnu.org/gnu/emacs/pretest/ <galex-713>if you use a git release were you checkout-ed the tag of a stable version, will the hash be the same than if you did compiled from an official release? <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. <galex-713>if you can control that in guix that makes me think we should always hash *after* uncompressing, unarchiving and autotools so that hashes do match <galex-713>so that you don’t duplicate a two stuff that are the same version of same software with same dependencies? <galex-713>I mean, if that wouldn’t be necessary we could as well use random UUID instead of hashes to identify packages in guix <galex-713>But it’s not, so getting identical packages to have identical hashes seems a feature to me <mark_weaver>you mean so that if someone writes an alternate package definition that fetches uses git instead of a tarball, so that it will save them one rebuild? <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. <galex-713>If erasing “random” information isn’t enough <mark_weaver>it would be easier to just avoid using tarballs altogether and always use the upstream repo <mark_weaver>but the problem there is that we can't do that for any package that git depends on.. <galex-713>circular dependency is not a problem as long as you can bootstrap <mark_weaver>we would need to add git and all of its dependencies to our set of bootstrap binaries, and that would bloat them up quite a bit. <galex-713>Yet why would be so much a lot of work to make autotools deterministic? <mark_weaver>we hope to eventually make our bootstrap binaries much smaller <galex-713>Anyway it would be better to improve security of most systems using GNU software, and autotools are already GNU software, etc. <mark_weaver>because when you run autoconf, it doesn't just use stuff from that package, it uses *.m4 files provided by all of the dependent packages <mark_weaver>which are typically installed in ${prefix}/share/aclocal <mark_weaver>afaik, the autotools are deterministic as long as all of the dependent package versions are fixed. <galex-713>mark_weaver: anyway under guix the package hash includes dependencies right? <mark_weaver>or at least I've not heard of non-determinism there. I don't know for sure <mark_weaver>it includes the hash of everything that's made available within the build container <galex-713>Then we have to try to make autotools not to include what’s available but not necessary in the final files you usually release <mark_weaver>well, within the build environment, only the dependencies are made available in the chroot. <galex-713>Would probably simplify the work of reproducible builds <mark_weaver>look, it would be better if you did your homework first. read the papers in the help section of our website. <mark_weaver>starting with the Nix thesis and the paper of Guix as well. <mark_weaver>and then, if you want to discuss making these kinds of changes, better to discuss it on guix-devel <galex-713>anyway, let me guix refresh -l libgpg-error \\o/ <mark_weaver>there are patches on the ML to update gnupg to 2.1.15 which will be applied to core-updates <mark_weaver>if you want, you can apply it to your private branch and build it out, but I'm not aware of any compelling reason to be impatient about it. <mark_weaver>you could get 2.1.15 sooner by adding a *new* package for the newer libgpg-error, which would inherit from the old one, and be used only by gnupg <mark_weaver>just give it a different scheme variable name, and then most packages won't use it. <galex-713>my reason to be impatient is I need to generate a new GPG key, and tomorow most people will quit the GHM so I will loose any occasion of giving a pubkey fingerprint afk :) <galex-713>But I have 1 or 2 hours to do this, since I only need to be there at 8 am <mark_weaver>as I wrote above, --quick-gen-key accepts an 'algo' argument <mark_weaver>it's probably just a bug in the menu presented in that --full-gen-key <galex-713>mark_weaver: is the ECDH pubkey algo Curves25519? <mark_weaver>I don't know, but if you really suspect this was added recently, check out the release notes for gnupg 2.1.14 and 2.1.15 <galex-713>I’d also really prefer an interactive interface, so I don’t forget anything <mark_weaver>I'm sorry, I can't afford to spend more time on this now. good luck <galex-713>I know and saw that, didn’t notice curves25519 <galex-713>But I didn’t on any version of 2.1.x, so I’m probably too bad at noticing stuff x) <mark_weaver>seen section 4.1.3 "How to manage your keys" of the gnupg manual. search for 25519 <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! <amuck>What gexp should I use to change default shell to zsh? <mark_weaver>amuck: I guess it would be #~(string-append #$zsh "/bin/zsh") <amuck>That's what I was looking for <amuck>Do you know how I can fix my root device configuration if it's currently a #vu8? <amuck>ERROR: In procedure string-append: Wrong type (expecting string): #vu8(238 7 192 252 193 141 65 85 159 94 138 94 24 230 209 77) <amuck>When I try guix system reconfigure <amuck>My config file has (device "/dev/sda2") <amuck>But I did previously try to use a uuid <amuck>Also, that zsh gexp complains about "Unbound variable: zsh" but I'm just using a hardcoded path for now <mark_weaver>that will import the (gnu packages shells) module, which exports 'zsh' <amuck>Now it's just the broken device <mark_weaver>as for the reconfigure error, it's happening while trying to build the old grub entries: one for each system profile in /var/guix/profiles <mark_weaver>for each system in there, it reads the <system>/parameters file <mark_weaver>and uses the information therein to generate the grub menu entry <alezost>and I also couldn't reproduced the described bug <amuck>I did run 'sudo guix pull' and I just ran it again and it says I'm up to date <mark_weaver>in this case, it needs to be run as root, since "guix system reconfigure" is run as root. each user has their own snapshot of the recipes ***retroj_ is now known as retroj
***samis is now known as CompanionCube
***lewo_ is now known as lewo
<amuck>mark_weaver: It says I'm up to date and I still get the same error <amuck>I even ran the pull and reconfigure in the same 'sudo -s' shell <alezost>amuck: does "guix system build" succeed? <amuck>alezost: No, it fails with the same error ***erdic_ is now known as erdic
<alezost>ACTION has a guess that removing links for the "bad" system (with broken root device) from /var/guix/profiles/ can help <amuck>Can I just update the parameters file to use a string instead of a byte vector? <mark_weaver>no, the parameters files are in the immutable store. <mark_weaver>if you build guix from git, it would allow you to test a possible fix that I will soon come up with. <alezost>the thing I don't understand is why "guix system build" fails, as it doesn't care about previous system generations <amuck>mark_weaver: How can I build it from git? <jmd>Where is the kernel and the initrd located on the installer image? <mark_weaver>they are in the store. see /boot/grub/grub.cfg for references to them <jmd>Hmm. makes it awkward to boot then. <mark_weaver>or just find the *-system in the store, and it has symlinks to the kernel, initrd, etc. <mark_weaver>awkward to boot from what? from grub, you can just use the 'configfile' grub command to load the grub.cfg <mark_weaver>amuck: see section 8.1 (Building from Git) in the Guix manual <jmd>I get "error: USB Mass Storage stalled." <mark_weaver>phcoder is the long-time GRUB maintainer, and the message above says "Premise: me and phcoder think its a bad/slow USB drive." <jmd>When you say "drive", what exactly do you mean? <jmd>I'll see if I can find another one. <mark_weaver>typically flash storage, but it shouldn't matter for the Guix USB installer <jmd>Ahh, putting it in another slot helped! <mark_weaver>alezost: good question, I found that surprising as well. it turns out that we *always* build grub.cfg, even for 'guix system build' <mark_weaver>alezost: now I'm not sure why "guix system build" fails. <jmd>ACTION makes note to self that that slot seems to be dodgy. <alezost>mark_weaver: yeah, I checked the code when that bug appeared but was stuck as I couldn't reproduce it and didn't see why "guix system build" fails as was reported <mark_weaver>in the line referenced above, (previous-grub-entries) is called, even if the resulting 'grub.cfg' derivation is never built <mark_weaver>the fix that ludovic mentioned didn't fix handling of the root device in the 'previous-grub-entries' procedure. <mark_weaver>it is assumed that (boot-parameters-root-device params), bound to 'root', is a string. but in this case it's a bytevector. <mark_weaver>in ludo's fix, various other bits of code were changed to handle this case, but not this one. <mark_weaver>I guess it shows that no one else has been using uuids to reference their root partition <jmd>What is an optimal swap size to have? <alezost>I don't have it at all (I have 3GB of RAM) <amuck>mark_weaver: It seems to work <amuck>I'm heading out for the day, but thanks for you help <jmd>How much stuff is installed with guix system init ? <mark_weaver>jmd: it depends entirely on what packages and services you specified in your OS config <jmd>I'm following the documentation verbatim. <mark_weaver>I guess you mean that you're just using the desktop.scm example file unmodified? <jmd>Not unmodified. I modified it according to the instructions. <mark_weaver>anyway, I don't know off hand how much that ends up being <jmd>Maybe the documentation ought to have some examples of a minimal install. <mark_weaver>my GNOME 3 system on i686 weighs in at about 2100 MiB <mark_weaver>desktop.scm also includes Xfce, and so might be somewhat larger <mark_weaver>and x86_64 is probably also a bit larger than i686, I guess, although I don't know off hand how much <jmd>I suggest sections 7.1.4.2 and 7.1.4.3 of the documentation are swapped. <jmd>How do I setup my wifi in guixsd ? <efraim>the default desktop template has wicd as part of its packages <mark_weaver>the desktop config includes wicd-service, which allows you to config wireless easily from a gui <jmd>easily if you know how. <jmd>well I tried both. Which would you recommend? <mark_weaver>in Xfce, click on the icon on the right side of the top panel. <mark_weaver>in GNOME 3, move the cursor to the bottom left corner and a little tab should pop out. click to expand it, and then click on the icon there. <mark_weaver>this will be nicer when we have network manager working, but that seems a tough nut to crack <efraim>Time to check what actually changed between python-2.7.11 and 2.7.12, the later built on the first try, and it doesn't look like there are any new tests <jmd>presumably if I do guix package --install as root, then installed packages are available for all users? <mark_weaver>the 'packages' field in the OS config is where to specify packages that will be available to all users <jmd>And then I have to system init again ? <jmd>Are substitutes enabled by default? <jmd>Hydra must be down then. <efraim>so I learned that python-2 doesn't support Minix, and the Windows copy bundles the libraries, which got updated to deal with various CVEs <jmd>package --install is installing sources. <mark_weaver>substitutes for guix-0.11.0 should be fully populated on hydra, I think. <jmd> I didn't see one, but maybe I missed it. <mark_weaver>you should run 'guix pull' in any case, though, to get the latest security updates, etc. <jmd>That has to be done as root? <mark_weaver>does "ping www.gnu.org" show connectivity? what about "ping hydra.gnu.org" ? <mark_weaver>it has to be done as both root and your normal user. <mark_weaver>each user has their own copy of guix, and 'guix pull' updates it just for that user. <jmd>Both pings show "unknown host <jmd>It is odd then that package install managed to download things. <jmd>That seems to have made a difference <mark_weaver>maybe network service caching daemon? or something along those lines. <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>would you like this email bug-guix@gnu.org about this, so that it won't be forgotten? <jmd>Once I install an email client ... <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 <efraim>ignore that, system just reconnected <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) <roptat>which do you think would be better? <roptat>there's no netlink support in scheme sockets currently (you can only do tcp or udp as far as I can tell) <efraim>whats the status of the python-3.5 update? while i'm hitting python in core-updates should i get python3 up to 3.4.5? <davexunit>roptat: using the netlink C interface via the FFI is the right way <jmd>Running a script in gimp, I get: Traceback (most recent call last): <jmd> File "/gnu/store/x6mqbpkga2w42bc2rp142nqpphzpkq4l-gimp-2.8.16/lib/gimp/2.0/plug-ins/python-console.py", line 19, in <module> <jmd> from gimpfu import * <jmd> File "/gnu/store/x6mqbpkga2w42bc2rp142nqpphzpkq4l-gimp-2.8.16/lib/gimp/2.0/python/gimpfu.py", line 76, in <module> <jmd>ImportError: could not import pygtk <jmd>Any idea what package I have to install to fix that? <jmd>Yep. I tried that. It didn't fix the problem. <jmd>I'm completely python ignorant so I wouldn't know where to start. <efraim>it might just need a substitute* somewhere to hardcode the location <jmd>I wondered if it might be something like that. <efraim>I can't find anything to subsitute, it might need to have python2-pygtk wrapped in the path, or it might be missing something else <efraim>I don't use gimp so I'm not really sure what I'm looking for with it <efraim>but either way I'd send a report to bug-guix@gnu.org and hope someone else has an idea <jmd>Uggh it seems that imagemagick has similar problems. Bummer. <ng0>it is said that guix keeps build logs, of the process what is run etc, like on hydra. where can I find those if they exist, for local builds? <balduin>how can I only use make to build a package? <balduin>is there any build system which uses only make? <ng0>does something fail for you? <ng0>no configure, no check? <jmd>What determines the user's environment variables? <ng0>for check you can do #:tests? #f ; reason why <ng0>and if there's no configure I tend to either replace it or if not doable, delete <balduin>@ng0: I try to build haxe. I get an error while building it with guix, but if I try to build it localy on my computer the build output is different. <balduin>@ng0: I deteleted the configure-phase <ng0>waht's different? can you provide logs? <ng0>i'll be present soon again, i have to report a bug. <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 <iyzsong>jmd: there has gcc-toolchain, but easier way is to use 'guix environment'. <jmd>iyzsong: I will look into those. Thanks. <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? <jmd>gcc-toolchain doesn't seem to provide crtl.o <iyzsong>balduin: look like a parallel build issue, you may try add '#:parallel-build? #f' to arguments. <balduin>@lysong: yes, it is a parallel build issue. I did that already :-) <balduin>but how is this parallel build done in guix? <ng0>can someone tell me where the build logs land (not the output in /tmp)? <ng0>sneek: later tell galex-713: gnupg-2.1.15 is in core-updates <iyzsong>ng0: it's at /var/log/guix/drvs, `guix build --log-file xxx' may help. <ng0>sneek: later tell galex-713: nevermind, I've read that lfam already told you <ng0>could've just used sneek forget though.. <ng0>oh i looked in there already, but found it hard to find what i wanted.. so these are the build log.. <ng0>why should we build gnupg with readline? what does it do for gnupg? <jmd>ng0: I think readline provides interactive completion and history buffers etc. <ng0>if it's not already added, I send a patch based on my test-corrections test <ng0>we should really stick with gnupg-2.1.15 and libgcrypt-whateverversion in core-updates now.. the updates after $now can be added to a core-updates-next <ng0>there is readline support in gnupg on core-updates added <ng0>iyzsong, i think --log-file was not correct <ng0>i see, it takes no output name <jmd>I have installed glib but it doesn't seem to have put anything in ~/.guix-profile/bin <jmd>Oh I need the bin output perhaps. <ng0>why is it that the gnome terminal in ubuntu has opacity/see through effect while ours doesn't? <ng0>does ubuntu not use gnome but something else? I don't follow ubuntu development <balduin>@ng0: ubuntu has it's own desktop environment which is called unity. They abanndoned Gnome a long time ago. <balduin>If I build binary tools with guix they are not executable (executable bit) is not set. How to I resolve the issue? <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 <jmd>I'm not exactly sure how to do that. <ng0>i never had to deal with that in gentoo.. what exactly are suid binaries? <ng0>there's this suidfix script in gnunet.. and binaries need to be suid, either sudo or root build is requied for that <ng0>suid just does what i assum, set-user-id or something? <jmd>Why does guix have to update substitutes in order to *remove* a package? <lfam>efraim: I'm working on the python-3 update for the wip-python branch. That branch has updates to a lot of the core Python packages <lfam>I actually thought it already had an updated python-3. But I realized that it doesn't <lfam>From e368327 (WIP python update to 3.5, create 3.4.4 ), everything seems normal. But the most recent two commits cause every version of Python to use the python-3.5.2 source <lfam>But the most recent two commits are standard package update commits. I can't see what would cause this issue <lfam>And the hashes appear to be correct <lfam>`./pre-inst-env guix build --source python@3.4.5` 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. <lfam>balduin: Check section 5.1.1 package Reference <balduin>@lfam: aswome, but it is described under: inputs (default: '()) <balduin>sorry. popagated-inputs -> that does not really make sence. It would be better to place this direclty under native-inputs <lfam>Those are the three types of inputs. I think it makes sense to discuss them together. And, if you open the manual and search for "native-inputs", that is the first result <lfam>But, if you really think it should be changed, you can edit 'doc/guix.texi' and propose your changes on guix-devel <lfam>I don't make many edits to the manual myself. I find it a lot harder to get right than editing code <joshuaBPMan_>Hello, I am trying to run sudo guix system reconfigure /etc/config.scm. Everytime that I do though I get this error: <joshuaBPMan_>guix system: error: symlink: File exists: "/var/guix/profiles/system-2-link" <joshuaBPMan_>is it ok for me to delete this file? Or am I going to break something? <joshuaBPMan_>Well I just found an irc chat log that said that some guy just deleted the file and it worked. so I'll try that. <jmd>Why is it that after package --switch-generations new package installs don't create a new generation? <jmd>joshuaBP`: I guess I'll have to wait until civodul has come back from the mountain. <joshuaBP`>also just out of curiosity what wm or desktop environment are you using on GuixSD? <joshuaBP`>I'm trying to get awesome to work right now. <jmd>joshuaBP`: Right now I'm using gnome. but normally I just use ratpoison. <joshuaBP`>ok. I'm going to try to log out and see if I can log into awesome. <joshuaBPMan_>It is not using my awesome config file yet, but hopefully it will soonish. <joshuaBPMan_>Does anyone know how to get awesome wm to work with GuixSD. I've got it running, but it is using the default rc.lua file. <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: <OriansJ>Actually I plan on making it completely impossible. Thus the only thing that could change the results would be malicious hardware. <OriansJ>Thus the only way for an attacker to corrupt our root binaries is to corrupt all hardware platforms in the exact same way, including those made in TTL logic by hobbyists <OriansJ>All we need to do to ensure that such an attack hasn't happen is make something like this: http://monster6502.com/ and simply walk the bootstrap steps. <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> [09:51:51] If I build binary tools with guix they are not executable (executable bit) is not set. How to I resolve the issue? <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. <jmd>The /nonexistent directory is misnamed. <mark_weaver>it doesn't exist on my GuixSD systems. I have no idea how it got created on yours <mark_weaver>does anyone else here have a /nonexistent directory? <jmd>Well it was created at 11:14 this morning, which is approximately the time I installed the system. <mark_weaver>it's the home-directory for the "nobody" user-account, which is part of %base-user-accounts <mark_weaver>ah, I don't include %base-user-accounts in my GuixSD systems. I guess that was added since I started using GuixSD. <mark_weaver>I guess that's a bug. can you email bug-guix@gnu.org about it? <jmd>It kind of reminds me of those stupid user manuals I see which have pages with a single sentence in the center: "This page is intentionally blank." <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. ***Ulrar_ is now known as Ulrar