IRC channel logs
2014-12-08.log
back to list of logs
<tadni`>Anyways, hopefully this turns out to be a non-issue in even the shortrun. My deemed assignment from Ludo, I more or less resigned from the other day -- but I am officially now, because I have finals week starting tomorrow. <tadni`>But depending on what RMS says in the forseeable future, I can see this topic coming up in relative mass -- without any of my involment whatsoever. <Sleep_Walker>in that case - there are different variable names holding package with same name? <mark_weaver>gcc, texinfo, gnupg are some examples that come to mind <Sleep_Walker>and for dependency evaluation is used name, not variable name? <mark_weaver>the packages names are only used for purposes of the UI, e.g. "guix package", "guix build", etc. for purposes of dependency evaluation, etc, the package objects themselves (bound by variable names) are used. <Sleep_Walker>so I can't have two packages as dependency candidates unless I do some extra care <mark_weaver>I'm not sure what you mean by "dependency candidates" <mark_weaver>in the 'inputs' field, in an entry like ("gnupg" ,gnupg), the string "gnupg" there is only used to reference the input from within the build phases, e.g. (assoc-ref inputs "gnupg"). the ,gnupg is what actually refers to the package object that will be used as an input, and that's a scheme variable reference. <Sleep_Walker>in RPM I can define some symbols like notification-daemon <Sleep_Walker>then, some packages can require notification-daemon without really caring, which one it will be <mark_weaver>in guix, every build input is precisely specified. not only what package and what version of that package, but also the precise inputs used to produce those inputs, the compiler used, all the way back to the bootstrap. it's needed to achieve our goal of purely functional, reproducable builds. <mark_weaver>however, what you *can* do is to create a function that maps package objects to other package objects. <mark_weaver>so then, instead of (define foo (package ...)), you can do (define (foo qt) (package ...)) and then 'qt' can be used as an input to the package object, but here 'qt' refers to the local argument passed to 'foo'. <mark_weaver>there are a number of such examples in gnu/packages/cross-base.scm. for example, 'cross-binutils' takes a 'target' argument and produces a cross-binutils for that target. <mark_weaver>'cross-gcc-arguments' takes 'target' and 'libc' as arguments, where 'target' is a string and 'libc' is a package. <mark_weaver>sorry, 'cross-gcc' is a better example. that actually returns a package :) <mark_weaver>and for an example of these being used, see 'ath9k-htc-firmware' in gnu/packages/firmware.scm. one of the inputs is ("cross-binutils" ,(cross-binutils "xtensa-elf")) <Sleep_Walker>mark_weaver: thanks, I understand the reasoning, but I'm not sure if it doesn't bring complications with maintainability of package definitions <mark_weaver>Sleep_Walker: well, agreed. I recommend asking civodul about this later, as he likely has a better answer for you. <Sleep_Walker>interesting POV, I have to dig into those definitions and think about that <mark_weaver>Sleep_Walker: out of curiosity, what package and input did you want to allow multiple candidates for? <mark_weaver>another example worth looking at is 'emacs' vs 'emacs-no-x-toolkit' in emacs.scm <mark_weaver>although in that case, it is done by having 'emacs-no-x-toolkit' inherit the 'emacs' package and make some changes to it. in practice, that's usually how we handle multiple variants (or versions) of a package. <tadni`>Oh man, a "GNU Carol".* That punny greeting must have made no sense, this morning... <nkar>sneek: later tell civodul ocaml's testsuite passes in /tmp. any idea why it timeouts while building as usual? do I need to increase the time before the exception is raised or something? <Sleep_Walker>mark_weaver: good morning, sorry, I somehow fall asleep :) but I have logs so not a single line was wasted, thanks again for your time <Sleep_Walker>I'm not currently interested in other than understanding Guix' specifics <Sleep_Walker>but I have for example one Qt application with sources long time gone which runs only with some (old enough) versions of Qt, but I don't want to force other application to use old version as well <mark_weaver>Sleep_Walker: that's a common case, where we need to keep an older version of some library around for a particular program. <mark_weaver>an example is readline. our newest version is readline-6.3, but some programs won't work with it, and need readline-6.2 <mark_weaver>so, in readline.scm, you'll see a readline-6.2 package, used by parted (disk.scm), mailutils (mail.scm), and lsh (lsh.scm) <Sleep_Walker>I assume that the only reason why tig (nice ncurses interface to git) is because you use something better, directly in emacs. Is that correct? <mark_weaver>I think there are some words missing from that sentence, but many of us use magit, an emacs interface for git. <mark_weaver>I guess the missing words are "hasn't been packaged" <mark_weaver>civodul, davexunit and I are among the magit users here. <rekado_>I'm having trouble using Guix on Fedora. <rekado_>I installed guix-0.8 from the tarball, followed the instructions on setting up the guix-daemon and tried installing powertop as my first package. <rekado_>now I get this error: guix package: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv' <rekado_>BTW: it seems that the manual doesn't mention the initial setup required for per-user profiles. I mkdir -p /usr/local/var/guix/profiles/per-user/rekado only after an error message prompted me to do so. <rekado_>I also had to chgrp /gnu/store after creating the guix-builder accounts; this was not mentioned in the manual, but an error message told me that this was required. <iyzsong>ah, yes, I remembered have to create the per-user dir too. *rekado_ will be back about 45 mins later *iyzsong is packaging xfce :) <taylanub>rekado_: you might want to report a bug for the per-user profile thing and other such things which are obviously bugs and their cause known <taylanub>rekado_: to what did you have to chgrp /gnu/store though? for me, everything in /gnu/store is root:root. (though I did that myself some time; a couple were guix-builder:guix-builder before) <taylanub>IIRC newer Guix versions make it all root <rekado_>The problem, I think, is that the guix-builder accounts have no permission on /gnu/store, so I had to change group ownership. <rekado_>I did "chgrp guix-builder /gnu/store && chmod 1775 /gnu/store" just as the error message told me to. <rekado_>how can I debug this error: "guix package: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv'" <rekado_>I get this when running "guix package --verbose --no-substitutes -i powertop" <iyzsong>I'm not sure what's the error mean, maybe the latest version (from git or by `guix pull`) will help. <rekado_>building path(s) `/gnu/store/c5cs53y3j5vkvvshxn9x0ms9dgjm5vhf-guile-bootstrap-2.0' killing process 10189 guix pull: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv' <rekado_>I get this after a long list of derivations <rekado_>Also, for every guix command I run I see this: <rekado_>;;; note: source file /usr/local/share/guile/site/2.0/guix/config.scm <rekado_>;;; newer than compiled /usr/local/share/guile/site/2.0/guix/config.go <rekado_>I haven't edited anything. Just ./configure; make; sudo make install; and then created the build users <rekado_>(To note: none of these problems are related to SELinux; SELinux is disabled.) <rekado_>Is there something else I need to do before I can install my first package? <iyzsong>rekado_: I don't think so, could you please file a bug at bug-guix? <tadni`>rekado_: Is ... the deamon running currently? <rekado_>It is running as root, command line is: guix-daemon --build-users-group=guix-builder <rekado_>my user account does not need to be a member of the build users group, right? The build users are only used by the daemon when it wants to drop root privileges. <tadni`>rekado_: Okay; so it's installed (obviously), you set up the deamon, the deamon is running, you made a user directory for your profile to be placed, gave that direcroy priveleges. <rekado_>is there a way to convince guix to be a little more verbose? --verbose doesn't seem to do much. <rekado_>I'd like to actually read the error, possibly with a backtrace. "build failed" isn't all that helpful <tadni`>rekado_: Not sure if one still needs to do this, but did you fix permissions for /gnu/store? <rekado_>tadni`: what do you mean by "fix permissions"? I had to change the group owner to guix-builder <tadni`>Something along the lines of "chgrp 1002 /gnu/store; chmod 1775 /gnu/store" <rekado_>drwxrwxr-t 3 root guix-builder 53248 Dec 8 14:17 /gnu/store/ <rekado_>tadni`: yes, I was prompted to do this. <tadni`>rekado_: Does working via the pre-inst-env do anything? <rekado_>(It's a bit odd that the config is newer than the compiled one as I haven't touched it.) <Tsutsukakushi>guix system reconfigure /path/to/the/config seems to appear in the logs <rekado_>tadni`: I don't know what this means. What is the pre-inst-env and how do I get there? <rekado_>note: I only use guix as a package manager on Fedora, I don't run the GNU system. <tadni`>rekado_: It's a way to test Guix, before you install it directly to your system. It's useful for developing Guix. It's in your guix-0.8 directory. <rekado_>(I mean: the Guix system distribution of GNU) <iyzsong>in the source dir, I usually do ./configure --prefix=; make; ./pre-inst-env guix ... <rekado_>as a regular user (the only one for whom I created a profile dir) I run "./pre-inst-env guix pull" from the guix-0.8 dir but I get the very same error message. <tadni`>civodul: Hey, rekado_ is having a problem where guix won't grab guile-bootstrap. <rekado_>civodul: no matter what guix command I run (guix pull or guix package -i) I get this error after a list of derivations to be built: <rekado_>guix pull: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv' <rekado_>I have not been able to install a single package yet, so I don't mind rebuilding guix. <civodul>rekado_: that happens on the installed system, or on the installation image? <rekado_>civodul: I'm using guix on Fedora 20. <civodul>did you run the 'useradd' commands as shown in the manual? <rekado_>and I had to chgrp the /gnu/store directory to give access to the builders <rekado_>hmm, I see that the derivations are all owned by root:root <rekado_>they all have funny timestamps, too: Jan 1 1970 <civodul>rekadocould you run guix-daemon with --debug, and then see if there are additional messages? *tadni` has considered having his hand at writing a Fedora 21 copr, package for Guix. <tadni`>That being said, I'm hoping to be on GNU Distro on my main machine -- by the time Fedora 22 rolls around. <rekado_>civodul: "build error: unable to make filesystem `/media/local-home/rekado/VirtualBox VMs' private: Invalid argument" <rekado_>I have a bind mount from /media/local-home/rekado/VirtualBox\\040VMs to /home/rekado/VirtualBox\\040VMs <rekado_>so... is this because of *any* existing bind mount or because of the directory name containing a space? <tadni`>phant0mas: You and Davexunit just joned, was just saying hi. :^P *tadni` is doing forced procrastination in here! :^) <tadni`>My professor didn't upload the keys for our prior tests, like he promissed Friday; For the final. So he's hanging around till thoses get posted. <jxself>The Fedora people like living on the edge. <tadni`>jxself: Yeah, it's a step removed from a rolling release. <tadni`>Even though they've been talking about switching to a Rolling Release Model, for like 5+ years now. <tadni`>I wonder if GNU Distro ever gets popular, if there will ever be some attempt to maintain a set of packages as if it was a long-term support release. <tadni`>davexunit: So ideally, you wouldn't need to even run a custom instance of Hydra and/or mirror with x types of packages? <davexunit>yeah, hydra would build both the stable branch and the master branch <davexunit>I think we would have to adjust the guix pull tool to be aware of branches, if it isn't already. <iyzsong>and iirc all packages's sources is just mirrored by hydra. <davexunit>I would imagine so since they are also in the store <davexunit>I don't know what makes hydra tick, really. I want to learn more about it. writing 'guix publish' will be a step towards learning more. <tadni`>Well, I mean -- it'd be trivial to add a function to config.scm for "(package-repo 'stable)" or something similar. <tadni`>From a user perspecitive, that is. <tadni`>But with a stable release, we would have to have several different versions/releases in the long term. <davexunit>I don't know if the system configuration will need to know such details <davexunit>you would just install that system using a long-term-support version of guix and that would be that. <tadni`>davexunit: Would it update each release, automatically? Like say we have a 2016 release of stable, when the 2017 version comes along does the whole system update -- or do you have to manually specify such a thing? <davexunit>I imagine that you would just guix pull and run the package updater. <davexunit>--update? I don't have a guix system in front of me to check <tadni`>I'd like (package-repo 'stable_2015) or whatever in your config.scm, just for the fact that if you run Guix pull and leave your computer, you don't accidently end up with the latest version, if you explicitly wanted such a thing. It's not a huge deal, since we can rollback, put it's still a decent visual que. :^P <tadni`>Maybe people won't check there config.scm, so that's cemented in their heads though. <davexunit>keep in mind that each user can use a different version of guix :) <tadni`>davexunit: I mean, sans the (operating-system) s-exp, is there anything config.scm does that an underpriveleged user could not? <tadni`>We could specify at least what packages each user has in their profile. <tadni`>I guess we could declare a specific user module, just for a config.scm that is relevant to non-root users. <davexunit>user profiles are currently completely separate. <davexunit>I sort of want a way to specify what each user should have in their profile. that way I could create a machine with a user dedicated to running a web server or something, and the packages are only installed for that user. <tadni`>davexunit: Is this what I am suggesting? To write a "guix user reconfigure ~/.config.scm" that one could specify certain packages in a regular user profile and two, run local services. <iyzsong>I have got guix to build a dmd.conf to start my openbox <tadni`>I know very, very little about the actual interworkings of Guix -- but I wouldn't think it'd be that diffrent from guix system? <civodul>rekado_: so it's a mount(..., MS_PRIVATE) call that's failing with EINVAL (see nix/libstore/build.cc) <civodul>maybe because it's already a bint-mount beneath? <tadni`>iyzsong: Is the point of making a openbox-service for such a thing -- to not have to use slim-service, and make a .xsession file specifying other environments? <tadni`>How does that work too, if it's not going through slim? <iyzsong>tadni`: this way I can control the environment and make restart easily. <civodul>iyzsong: the "normal" way would be to exec openbox from ~/.xsession <tadni`>iyzsong: So, I'm assuming you don't have slim-service running, so you have a text prompt, you login to your non-root user, and it boots into Openbox? <iyzsong>I have tried systemd as user session manager, now with dmd. more simple. <iyzsong>tadni`: I have let the root start X server, I login as user, run dmd. <tadni`>iyzsong: That's pretty cool actually, I'm going to mess around with this when Finals are over. <tadni`>Probably not as clean/pratical as just using slim-service and a .xession ... but, such a thing could probably be prettied up a bit. <civodul>iyzsong: so dmd is started from ~/.xsession, or from some other script that X runs on startup? <tadni`>Can NixOs do per-user orriented profile, config files, currently? <tadni`>To a degree, that's not a border-line abuse, like using 'guix system' as a non-root user. <iyzsong>there have effects, nix-rehash, NixUP, etc.. <tadni`>iyzsong: Ah, but nothing upstream/canonical? <tadni`>It's great to see such efforts are being done by our spiritual predecessor and minor, technical predecessor. <tadni`>This class of OSes configuration, really is something neat and something I haven't seen in mass outside of GNU Distro and NixOS. <iyzsong>Guix is like as OS framework for me, with many things to be discover :) <tadni`>I haven't played with NixOS enough to know if there are like tools on that side of things, but the fact that one can produce customs usb images and potentinally even *.iso in the future due to the efforts of zdavis, really does place GNU Distro more into a distribution Platform -- than a formal distribution for me. <tadni`>davexunit: Well, I meant in-terms of actually using their software? Aren't we only using there deamon? Obviously, the inspiration is /huge/ but I tie that into the spiritual aspect. <tadni`>davexunit: Ah, okay. Again, I haven't look very much at all at Guix or Nix internally. It just seemed like the deamon was underplayed a bit, if it really is that hard to replace. <davexunit>the UI and packaging language is important, too, of course. but the very core of guix and nix are the same. <davexunit>eventually we will diverge and have our own daemon written in guile. <tadni`>davexunit: Is this actually a long-term, roadmap'd goal? <davexunit>I don't know if it's explicitly on any roadmaps, but I see it as an inevitability. <davexunit>the daemon being a C++ application makes it hard to hack on <davexunit>picture this: the daemon is written in guile, and by using a REPL server, one could hack on the daemon *as it is running* <tadni`>davexunit: I mean, ideally, wouldn't we want as much as possible in Guile? <tadni`>Dmd, Guix, Guile-compositor (wayland), Guile-tooklit (graphics toolkit), guile-emacs, etc. <tadni`>davexunit: I mean, I think I've mentioned to you before.I heard a guy, who wants to work on a microkernel -- that's just implements enough C, to get guile going and go from there. :^P <tadni`>AH, COMEONE PROF; Respond to my email... I actually want to study for once and can't! It's driving me mad. <tadni`>I guess I'm gong to try and nap; And see if he responds by the time I awake. I really shouldn't be back on till late Wed at the very earliest. <Tsutsukakushi>guix package -i tmux vim htop has been going for 10 hours now... <tadni`>Tsutsukakushi: Darn you, so close. <tadni`>Tsutsukakushi: Did you verify the *.pub? <tadni`>Tsutsukakushi: If not, it will try to build everything from source. <tadni`>Because it's not verifired to use the pre-built binaries. <taylanub>Tsutsukakushi: it will even compile the compiler though :) <Tsutsukakushi>but now i'm feeling stupid because i forgot to add the flags to remove x support from vim <tadni`>Anyways, I really should try to nap if he's not going to email me in the next 10 minutes. :^P <tadni`>Peace for real and peace for awhile. o/ <Tsutsukakushi>freebsd's ports were nice since they had the dialogs where you could just choose what you want <Tsutsukakushi>will everything be compiled from scratch for every package or does it reuse the packages that were just compiled from scratch <civodul>davexunit: the daemon in Scheme is an inevitable thing, indeed; probably long-term <civodul>the nice thing with starting from Nix is that we had a "smooth" path to do our stuff <Tsutsukakushi>like if i want to compile two programs that depend on x will x be compiled twice or just for the first programs, assuming they don't need any special flags for x or they require the exact same flags <civodul>think of builds as pure functions, whose result can be cached <Tsutsukakushi>system wide packages need to be specified in config.scm, right? <Tsutsukakushi>so if i install vim as super user and want everyone to be able to use it <civodul>yes, you would add 'vim' to the 'packages' field of the OS config <rekado>how can I see a list of the bugs that were reported to the mailing list? <rekado>Is there an Emacs interface for the bug tracker? <rekado>re Emacs interface: never mind, apparently I can use debbugs for that. <Tsutsukakushi> what are your guix thoughts on the container based package management that lennart has been talking/writing about? <davexunit>"container based package management" makes me suspicious. *jxself imagines giant, 1GB "packages" <davexunit>I don't have the time to read that now, but a quick skimming over the second article on that page makes it look like they aren't aware of what nix and guix have already done. <Tsutsukakushi>but i was thinking maybe it could have something you haven't thought yet that could also benefit guix <rekado>I just installed my second binary package (emacs) and I get this warning: <rekado>warning: collision encountered: /gnu/store/wsa1hpnqa9rzpw3irkr03ad6q3xblpmj-info-dir/share/info/dir /gnu/store/wapxmiwdw5w2ipfr3mpi4j1vi89kk6fs-emacs-24.4/share/info/dir <rekado>warning: arbitrarily choosing /gnu/store/wsa1hpnqa9rzpw3irkr03ad6q3xblpmj-info-dir/share/info/dir <rekado>Is this a defect? (Two packages claiming the same directory?) <taylanub>rekado: that's fairly common, and so far unsolved AFAIK *civodul just realized that bavier's big patch set adds LLVM & Clang <civodul>bavier: congrats on that, probably not the easiest packages :-) <civodul>davexunit: are we waiting for something for msmtp? <davexunit>civodul: I think I just had minor comments on that, right? *davexunit doesn't remember <taylanub>I just noticed that python2-pygtk has been added. I guess I can continue with nmap. <civodul>davexunit: i think so; if you think it's good, feel free to apply it <davexunit>civodul: okay, I'll try to remember. I'm a little frantic atm, lots of server problems at the FSF right now. <civodul>taylanub: oh right, i had almost forgotten <civodul>the Binutils/GDB people experimented with a patch tracker <taylanub>what might cause 'guix build: error: open-file: No such file or directory: "/gnu/store/...-nmap-6.47.tar.bz2.drv"' upon 'guix build nmap'? <civodul>maybe Guix was reconfigured with a different --localstatedir? <taylanub>hm, don't think so. but I might have messed something up by deleting some links manually from /usr/local/var/guix/profiles/per-user/<name>/ <taylanub>I also tend to override my installation by just running 'make && sudo make install' from the guix source tree after a git pull. maybe I need to clean something up. <civodul>yes, so if for some reason --localstatedir changed, then you can run into such problems <civodul>i very rarely run 'make install', FWIW <civodul>i usually take my end-user hat and run 'guix pull' ;-) <Tsutsukakushi> i get the following when trying to reconfigure: guix system: error: system locale lacks a definition <taylanub>Tsutsukakushi: I think people were recently switching to en_US.utf8 in place of en_US.UTF-8 so maybe try that. <rekado>Tsutsukakushi: shouldn't it be en_US.utf8? <civodul>ok, it's now a frequently answered question ;-) <Tsutsukakushi>it worked fine when installing, something like that shouldn't be changed, at least if you don't automagically fix the configs when doing so <civodul>the manual that's on-line is that of the latest stable version <Tsutsukakushi>if my version says 0.8, i'm going to read the manual for 0.8 <Tsutsukakushi>add something like -dev to the end so the user knows which manual they should read <civodul>the problem with the on-line copy is that it's necessarily a snapshot <civodul>so far, i've just left it at the latest release <civodul>no you're right, there's a problem with how the version number is determined <nkar>civodul: it seems sneek didn't send you my question: ocaml's testsuite passes in /tmp. any idea why it timeouts while building as usual? do I need to increase the time before the exception is raised or something? <civodul>nkar: no, we'd need to look at the faulty test to see if it's doing i/o, networking, or whatnot <civodul>it could be anything, but we might have clues by looking at the test <civodul>what do you mean by "installed"? in /run/current-system/bin? <mark_weaver>Tsutsukakushi: inkscape is built, not installed. it is used to convert an rsvg image into a bitmap file for the grub background image. <mark_weaver>it would be nice if we had a lighter way to do that conversion though.