IRC channel logs
2016-06-09.log
back to list of logs
<ng0>maybe I just got guix to succesfully run inside gentoo! <ng0>that's more than I had before <ng0>still the unmount problem :/ <ng0>ha! :) it needs special settings on gentoo-hardened, but switching to gentoo-sources kernel and guix is running its first guix pull <ng0>this means we can start moving out overlay from ebuilds to contributing to guix <ng0>ACTION seriously considers dropping all other portage related efforts and just commit a finished guile, guile-eselect, and guix <ng0>I'm not at the point where I can test, but weechat got recently upgraded to 1.5 <cbaines>Nearly getting somewhere with my attempt to script package building... but, my code now crashes as it tries to build a package that has already been built <lfam>It's not checking if the build is cached? <cbaines>that is, I have a package, and a coresponding derivation, and when I try to "(build-derivations store (list derivation)", I get a crash in a unknown file (Wrong type to apply: #t) <cbaines>is there a cannonical way of doing that? <cbaines>I looked at both the packages and derivations modules, as well as the store, and could not see anything more abstract than just checking if the listed outputs exist on the disk <cbaines>(which I will do after sleeping, if I don't hear of a better solution by then) <lfam>Check out the manual section 5.3 The Store. There is a database that keeps a list of store items <cbaines>That looks a bit too low level? I was expecting some way of just asking, is this built, or for build-derivations to do nothing and just return #t, but not just crash <cbaines>Thanks anyway, I'll take another look later, goodnight <lfam>I'm not sure, that was just the first place I would look. <lfam>kete: You have to provide a list of mapped-devices, as with file-systems <lfam>The example in the manual is a little misleading <lfam>(mapped-devices (list (mapped-device ...))) <kete>Does anyone know how to unmount after starting herd or guix system init? <cbaines>civodul, could I trouble you for a quick opinion on the problem I posted about earlier? <cbaines>The code is quite short, I'm running: (with-store store (run-with-store store (mbegin %store-monad (build-derivations store (list derivation))))) <cbaines>and when the derivation has been built, I think it crashes in run-with-store, as the mval (2nd parameter) is #t <civodul>the code mixes monadic and non-monadic stuff <cbaines>Is there a way of checking, for a package or derivation, if it needs building? <civodul>build-derivations is not a monadic procedure <civodul>so it cannot be used in a monadic context <civodul>instead, you should use (built-derivations (list drv)) <civodul>note the subtly different spelling ;-) <civodul>to check whether something needs building, you can check whether its output is "valid", as per 'valid-path?' <civodul>so roughly, (valid-path? store (list (derivation->output-path (package-derivation store p)))) <cbaines>Ok, using build-derivations somehow worked, as I did build something, but maybe it crashed after that <cbaines>using built-derivations also crashes, but in a different place in guix/derivations.scm (I think( <cbaines>but using valid-path? looks good, I'll try that now <cbaines>civodul, that has done it, thanks :) <janneke>civodul: i rebased mingw to core-updates...it works there <janneke>after I disabled tests for automake, haven't looked into that yet <janneke>i haven't looked into why yet, maybe we don't have to? <janneke>what would your preference be, send a new tested patch set rebased on core-updates, or find the problem, fix master etc...? <janneke>i can only formulate the problem from the perspective of the observation of me as a user... <janneke>when i type: ./pre-inst-env guix build --target=i686-w64-mingw32 readline <janneke>that eventually fails with: builder for `/gnu/store/m6gq2xz5kd3vn4zm1i0i6j0immlgyhmg-make-boot0-4.1.drv' failed with exit code 1 <janneke>sadly I don't have a clue as to where in the process something goes wrong <civodul>ah yes, that one (i was confused by "automake") <efraim>civodul: read-and-compile isn't working for me with "wc -l foo" and when I substitute "pwd" I get the same error <civodul>efraim: it works for me in current master <civodul>did you try running make check TESTS=tests/bournish.scm? <efraim>ok, i'll take another whack at it <civodul>the error looks like what happened before the fix i committed a couple of days ago <efraim>i can make clean and see if that helps <civodul>you're using "./pre-inst-env guile"? <civodul>you need to use it so you actually load the latest modules from master <efraim>woo! $2 = ((@@ (guix build bournish) wc-l-command-implementation) "foo") <janneke>civodul: okay, i'll investigate first <janneke>very welcome -- i'm happy that my blockage seems to be cornered now :-) <davexunit>ld: cannot find crti.o: No such file or directory <davexunit>bavier: not yet, waiting on a rebuild of a bunch of software to see if a change lower in the stack fixes it <davexunit>this is all custom software for a guix "pilot" that I'm doing at work <bavier>ok. I usually see that error when something like LIBRARY_PATH isn't set correctly <davexunit>bavier: it should be set correctly here, because I'm not doing anything to change it <ng0>hm.. /gnu/ directory shouldn't be root:root for directories and files, right <ng0>I get many I/O errors <ng0>some files nad dirs are :guixbuild owned <ng0>will guix be sad when I chown recursive :guixbuild /gnu/ ? <ng0>it's no solution to the problem, but /gnu/ is root:guixbuild, but not the new files <ng0>guix runs under user root with group guixbuild... might tht be the problem? <ng0>I'm not an expert with openrc initscripts <ng0>a shutdown delay of 10 minutes because of the guix script shows that I need to fix at least the stop() sequence ;D <ng0>correction, /gnu/ is root:root <ng0>maybe this was something I should've fixed in the initial setup process. <bavier>ng0: some store files in /gnu originate from the installation process, others are a result of builds <davexunit>I don't recall ever having to create /gnu/store <bavier>builds are run as a user from the guixbuild group <ng0>i know. but /gnu/ should still be root:guixbuild, not root:root <ng0>this is not in guixsd, guix on top of gentoo, fixing the guix ebuild still <davexunit>ng0: do you start the daemon with the correct flags? <ng0>one moment, I can show you the initscript <ng0>maybe I should ommit the user. <ng0>ideally I make it configurable (for group etc), i know how to do that, just fixing start, stop isn't my favorite part. <ng0> /gnu/ is root:root , /gnu/store/ is root:guixbuild <ng0>now I ommited the user it might've worked <ng0>but guix package -i glibc-locales still gets I/O errors as normal user, as root it succeeds. I just have to assume there are things I only install from root <ng0>one problem I can upload as paste in a moment. the base is, yesterday night I succeeded in running guix on gentoo. it works, but some packages throw errors. like the following: <ng0>root with the same problems: <ng0>when compiling and installing <ng0>so I think either the setup of guix is borked, or the service I wrote is bad. <ng0>what is this XML file even <ng0> https://ptpb.pw/G4EV this is inside the /gnu/store/ of what I just installed, so at least on this dir level it looks alright to me <bernalex>hi. quick question regarding the distro: do you do OpenPGP-signing of snapshots, or something else so that end-users can verify the integrity and be protected from MitM? <davexunit>bernalex: our releases and disk images are signed <davexunit>we are working on securing non-release updates via 'guix pull' currently <bernalex>davexunit: OK, great. I'm looking at differences between guix & nixos. this is an incredibly strong point in favour of guix imo. <bernalex>OK, so two more questions. with guix -- 1. is it trivial for me to compile things on my own computer, rather than going through a build farm? and 2. is there a large degree of supported customisation of compile flags, à la what Gentoo offers with USE flags? <ng0>define your definition of trivial <ng0>you don't need a buildfarm <ng0>2) currently not - but you can customize the packages <bavier>bernalex: it's trivial to run the daemon with --no-substitutes <bernalex>ng0: I want to compile everything on my own computer. ideally I'd like to just set a default "don't use a build farm" or something, and that's it. <ng0>I am debuging guix on gentoo atm fyi, if you just want the pakcagemanger for smooth transition <davexunit>you can run the daemon without any substitute provides <bernalex>davexunit: yes, I know it's simple and nice in nix/nixos. <bernalex>davexunit: I do not know what a substitute is in this context. <ng0>binary substitutes , ie compiled on hydra <davexunit>package recipes are source code, so they are easy to customize. <bernalex>I guess that means "goodbye guix" from my list of distros to consider. <davexunit>that would result in lots of nondeterminism. <bernalex>davexunit: I don't want to have to deal with a billion individual packages to be able to say "I never want you to compile gtk support, and I want you to always compile qt support", as an example. <ng0>you have to rethink when you come from gentoo, and also consider that GuixSD is 3 or 4 years old and Gentoo is very mature. <davexunit>bernalex: you can customize packages that aren't to your liking quite easily because they are represented as first-class objects in our Scheme code. <bernalex>davexunit: yes, but if you can't say '-gtk' or similar somewhere, that sounds to me like customisation is way too much work. <davexunit>but if you want Gentoo, then I recommend using Gentoo. <ng0>the effort to running Gentoo is almost equal to running a customized GuixSD, I'd say running a customized GuixSD is even less effort than Gentoo <davexunit>and I've seen no proposal that would work well. we make packages "full featured" typically, and make minimal variants where desired. <davexunit>it's pretty easy to make variants as needed. <ng0>speaking from enough experience with gentoo, bernalex. <davexunit>no distro besides Gentoo has this global state of flags, and I don't think it's a particularly elegant system. <ng0>some gentoo originated distros evolved their use of sets, like @world @server etc <ng0>where the sets provide iuse flags <bernalex>I'm not exactly a fan of state or mutation either, but I am a fan of saying "I never want any package to compile support for foo", or "I always want support for bar". <davexunit>bernalex: every package needs to be written to consider the state of the flags, and interpret what they mean to enable/disable the right features. <bernalex>davexunit: sure, but that's a maintainer burden to make the distro nice for users. <ng0>so maybe when I spent enough time with guixsd I can figure out a solution.. I have other features to focus on. <davexunit>it would mean that pretty much everyone would be compiling everything from source all the time <bernalex>davexunit: yes, that's what gentoo users typically *want*. <davexunit>instead of using our build farm, because they used some combination of flags that we don't pre-build <bernalex>davexunit: couldn't you crowd source that btw? <davexunit>we want our users to be able to user pre-built binaries and *trust* that they are getting what they expect via deterministic builds <ng0>bernalex: there's gnunet-fs distribution of packages on the roadmap at the end. <davexunit>bernalex: the variants of each package to build increases exponentially with each flag added <ecraven>do packages in guixsd have options, like in nixos? to set extra config options, for example? <davexunit>ecraven: you can very easily modify package expressions to do what you want them to do. <davexunit>but a package object describes *PRECISELY* what the build does <davexunit>and gentoo-style global use flags do not fit that model. <ecraven>hm.. so there's no simple way to just say "use this in the config file", like in nixos, instead I'd have to specify a modified package? <davexunit>ecraven: I'm talking abotu Guix, not GuixSD. <ecraven>I'm looking at guix/gnu/packages/openldap.scm <davexunit>you're confusing package management and system configuration <davexunit>system services are different and also customizable <davexunit>but out of scope of this particular conversation <ng0>I really wonder why I get I/O error <davexunit>ecraven: system services are configured without changing the underlying packages that they use to provide the daemons that they manage <ecraven>davexunit: my specific problem (with nixos) was customising openldap's ldap.conf <ecraven>so I was just wondering how to achieve this in guixsd <davexunit>if we had an openldap service, then the config file to use would be an argument to the procedure that creates that service. <ecraven>looking at that openldap.scm, I don't see anything that looks like customisable options <davexunit>ecraven: services are different from packages. <davexunit>you're talking about a service, not a package. <ecraven>davexunit: well, the problem is, ldap.conf is *not* for a service, but for the ldap client library <ecraven>there is no service that takes a config file <ecraven>it is a global config file for the openldap client library that other things use <davexunit>ecraven: okay, well then in that case I imagine that the openldap client accepts a flag for the config file to use <ecraven>php uses the ldap library, lots of other things do too <ecraven>yes, lots of things are broken, that's not the point :) <davexunit>I imagine there's a misunderstanding somewhere in here. <davexunit>I find it hard to believe that a client library reads a file on disk, and only a single hardcoded file that is specified at compile time <ecraven>I have tried many things, but there's really no good way to change settings except for changing ldap.conf.. it needn't be in /etc/openldap/ldap.conf, it can be in the store, but it *needs* to be modified on installation <ecraven>I've found an environment variable (LDAPCONF), but that doesn't work (at least not on nixos) <davexunit>there must be a way to say which file to use <davexunit>it doesn't make any sense that there wouldn't be <ng0>hrm.. i dont get it. only equal problem which popped up was sqlite and a mmap problem of kernel <ecraven>davexunit: where would I look for documentation on service configuration on guixsd? <ng0>well fonts are functional now, but the xml error is confusing. <ecraven>can guixsd automatically generate documentation for service parameters like nixos does? <davexunit>holy fuck is groovy2shoes on #scheme an idiot <davexunit>basic argument: "the hello package in guix is 20 lines so it sucks" <davexunit>it's such a trivial package that it should be no more than 8 lines or something <ecraven>well, I've learned some APL over the last few weeks, at the start I thought "holy moly, how can you ever program like that", but after some time, and getting to know it closer, things seem better now <ecraven>great, I'll read that on the ereader while commuting :) <ecraven>davexunit: you mentioned that guix was built in a better language (I definitely agree) and on a better foundation / api than nixos.. can you elaborate on the "better foundation / api" a bit? that sounds interesting <ecraven>have to leave, but I'll read the backlog, if you write anything <suppi>ecraven, I'm currently reading the paper about guix. i think it talks a bit about that so you might want to read it if you are interested <ecraven>is there a specific reason why php isn't packaged? the nix derivation doesn't look too complicated. <efraim>I don't think anyone got around to it yet <ecraven>if I understand how to do it, I'll give it a try :) <lfam>There was some activity on guix-devel in the last few months. You should check if there is anything worth finishing before starting from scratch <ecraven>do I understand correctly that I just need to put the scheme code in a file in ~/foo/bar.scm, then run GUIX_PACKAGE_PATH=~/foo guix build my-php-test to try building it? <davexunit>ecraven: I tried well over a year ago and couldn't get it to build. <ecraven>davexunit: I never built it from scratch, but the nix derivation doesn't seem to do anything special :) <lfam>ecraven: More or less. Make sure the exported module path of your file matches the filesystem layout <ecraven>I have a nixos server with nginx and php-fpm, that I'd like to duplicate in guixsd <lfam>For example, I keep some packages in ~/pkgs/leo/packages/foo.scm <lfam>So, foo.scm must start like this: (define module (leo packages foo ... <ecraven>ah, the package name must match the file name? <lfam>And GUIX_PACKAGE_PATH must be ~/pkgs <lfam>No, the module name is different from the package <ecraven>guix build just loads all the .scm files in that directory to find the right one? <lfam>I actually have a bunch of modules in that directory. I used foo.scm as an example <lfam>If you get stuck, refer to how the modules in gnu/packages are defined <ecraven>hm.. is there a way to get pre-built derivations, like in nixos? my bare-bones installation seems to build everything <ecraven>lfam: yes, I just cloned the savannah git repo, to look at other packages <lfam>If you can reach the substitutes server over the network, you will get pre-built substitutes if they are available on the server <lfam>The derivations you are requesting might not be available. <lfam>Can you ping mirror.hydra.gnu.org? <ecraven>a general question, say someone packages php 7.1... then after some time, 7.1 gets updated to 7.1.1... doesn't that mean that a system description will result in a different image? <ecraven>I install package "php" (which is version 7.1) <ecraven>after some time, the repo gets updated, so "php" is now 7.1.1 <ecraven>if I build the exact same system definition on another server, I will now have a different php version, right? <lfam>I still don't understand your question. You will get whatever version of PHP is in the set of Guix packages you are using <davexunit>ecraven: if you want the same results, you must build with the same version of guix. <lfam>+1, ideally referenced by a Git commit of the Guix repo <ecraven>so guix 0.10 will never get a new php version? <davexunit>ecraven: guix includes all the package recipes. they are a single unit. so if you use the same version of the guix source, you will get the same builds. <optikalmouse>install guix, keep running the package recipe until it does the right thing? <Sleep_Walker>unfortunatelly guix is in case of syntax error just ignoring the file so running guile is required as well <Sleep_Walker>./pre-inst-env guile -c '(use-modules (gnu packages <your_changed_module>))' <optikalmouse>I know I had this conversation a few weeks or a month ago, but what happens with ruby gems ? <optikalmouse>I have particular versions that I'm tied to, what do I do in that situation? <bavier>ecraven: to which php package are you referring? AFAICT php isn't packaged for guix yet <rekado_>after an update I get a fontconfig error when running lilypond <rekado_>it tries to access /gnu/store/p7jvbh4g2hqfmrkqwhljd9fq984jbaci-fontconfig-2.11.94/etc/fonts/fonts.conf <rekado_>but this store item doesn't even exist on my machine. <ecraven>though I fully intend to package it, once I understand how :) <rekado_>janneke: might be that our lilypond package does not retain a reference to fontconfig. When I run "guix build lilypond" it is downloaded again, but when I ran "guix gc" yesterday it must have been deleted. <taylan>what happened to gnu-system.am ? <taylan>ah, that seems to be it, thanks :) <janneke>rekado_: if lilypond depends on fontconfig and still lets it be gc'd, something is not good :-) <rekado_>hmm, the latest package looks fine. Maybe it's a problem with my slightly older lilypond package. <rekado_>my lilypond package has a reference to /gnu/store/rvlwbx8fcq2bfh12bni4dzhxmmzmjrs5-fontconfig-2.11.94 <rekado_>but at runtime it looked for /gnu/store/p7jvbh4g2hqfmrkqwhljd9fq984jbaci-fontconfig-2.11.94 <rekado_>now that I ran "guix build lilypond" again it has downloaded the latter. <rekado_>"guix gc -d /gnu/store/p7jvbh4g2hqfmrkqwhljd9fq984jbaci-fontconfig-2.11.94" works <rekado_>fontconfig is among the regular inputs. <rekado_>this particular variant of fontconfig is pulled in by python@2 and tk. <rekado_>looks like lilypond uses that at build time instead of the direct input. <ecraven>how do I add ssh keys to users in config.scm for guixsd? <rekado_>/gnu/store/hf32n7k87zshhn9ngm9pyfjipyyjpl81-libxft-2.3.2 and tk both have that variant of fontconfig as references. <daviid>avoine: tx. so if you fire guile-2.0 from your guix installation and enter %global-site-dir) what do you get? and what do you get for %load-path? <daviid>does this mean people using both guile-2.0 and guile-next have to install twice g-wrap, guile-cairo and guile-gnome? <avoine>daviid: guile-next will not be able to load g-wrap, cairo, etc <daviid>avoine: you see, guile on guix still look for modules in ./share/guile/site as well <avoine>that would need to be fix in the guile package itself then <daviid>you mean in the g-wrap... packages <daviid>as I just showed you, guile-* look for modules in share/guile/site as welll <daviid>and that is were any guile scheme module compatible with guile-2.0, guile-next should be installed, imo