<janneke>mingw patch set ready and sent to -devel <efraim>rekado: I changed the propagated inputs of something, probably python2-pandas, and that caused python2-pysnptools to stop building <efraim>my plan was to decrease the number of propagated inputs, targeting packages used for testing and packages that are already referenced with `guix gc --references python-foo` <lfam>New nginx stable version (1.10.0). Unfortunately my switch died today so I can't test the update on my home server. Anyone want to try it? <yoosty>I've made it to IRC on a GuixSD machine! wheee! <yoosty>now to buy a Raspberry Pi so i can flash the BIOS to coreboot.. <lfam>Changing mysql would rebuild 84 packages. Should it get updated on master? <lfam>Okay, it builds. Too bad it's not deterministic, but it does build <lfam>Now I'm going to work on the icedtea / java updates <jmd>It seems that fold-packages iterates some packages for which the name and/or synopsis is #f ***kelsoo1 is now known as kelsoo
<jmd>civodul: Hi. It seems that fold-packages iterates some packages for which the name <jmd> and/or synopsis is #f <rekado>lfam: thanks for taking care of the icedtea updates. Only for icedtea-7 and icedtea-8 updates were released. <rekado>you also need to update all of the "drops" that are among the inputs. <civodul>jmd: could it be in GUIX_PACKAGE_PATH? <civodul>can you try "guix lint -c synopsis"? <jmd>I'll run that (takes a while). <jmd>civodul: You're right. My bad. <civodul>i've fixed a couple of these, as a test for the new lint checker :-) <jmd>I suppose it doesn't really matter if some synopses are #f, but it suprised me. <ngz>Hello. I'm using guix (binary installation) on top of Debian stable. I cloned the git repo. When I move inside its root directory, and call, e.g., ./pre-inst-env guix package build something, I get an error about permission (bash: ./pre-inst-env: Operation not allowed). What am I missing? <janneke>ngz: did you ./bootstrap; ./configure --localstatedir=/var; make? <ngz>I didn't. However, I just tried and get a bunch of errors, the first one being ./bootstrap: 5: exec: autoreconf: not found <ngz>I guess I'm missing some packages from Debian (this is a fresh install). <janneke>yes, you'll need autotools (autoconf, automake) <janneke>there's also a debian package that you can build and install <ngz>With autoconf and automake, I get farther. Thank you. There is yet another error, but it is my fault. I'm looking into it. <ngz>janneke: I still get configure.ac:68: error: possibly undefined macro: PKG_CHECK_MODULES <ngz>. I tried to export ACLOCAL_PATH to something meaningful (ie., /usr/share/aclocal/) to no avail. Do you know what could be wrong? <ngz>Oh. I added it, thank you. I'm now one step further. The next error is configure.ac:69: error: possibly undefined macro: GUILE_MODULE_AVAILABLE. <ngz>Guile is installed on the system. <ngz>Maybe I'm missing libtool <ngz>No, actually, this one is installed. <robsyme>It looks to me like the ruby-ansi package is broken. Can anybody check if 'guix environment --ad-hoc ruby-ansi' fails or succeeds? <jlicht>robsyme: I get an error in the install phase <robsyme>jlicht: Ah, me too. Just wanted to make sure that it wasn't just me doing something dumb. <jlicht>something about delete-file being called on something that does not exist, to be more specific <robsyme>jlicht: Was it when trying to delete the gem file (which doesn't exist)? <jlicht>Is it true that tagged released on GitHub are regenerated in a nondeterministic way? I.E., are they not suitable as a remote url in guix package definitions? <Gottox>jlicht: We (at voidlinux) never experienced this behavior. But there are no guarantees, afaics. <ngz>janneke: Correct. Thank you again. Unfortunately, I now have checking whether /usr/lib/libgcrypt can be dynamically loaded... no <ngz>configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'. <ngz>Both libgcrypt and libgcrypt-dev are installed. <jlicht>Gottox: hmm. I'll take my chances then. You mention that you (at voidlinux) have not had any problems with this. Might I ask for how long you have been mkaing use of this feature? <Gottox>oh, to be clear: anyone with commit access can overwrite tags. <jlicht>that seems like a relatively safe bet then <jlicht>as far as having GH play such a central role in free software infrastructure goes then, of course... <civodul>ngz: could you check config.log for details about why it thinks libgcrypt.so is unusable? <civodul>iyzsong: it seems gnome-updates is built on x86 <civodul>iyzsong: could you check if the problems that mark mentioned have been fixed? <ngz>civodul: Is configure:8000: checking whether /usr/lib/libgcrypt can be dynamically loaded result:no normal? <rekado>re ruby-ansi: the problem is this: installing into parent path /gnu/store/is8536m4c9ks97r3jsiykl72zgpl4bps-ruby-ansi-1.5.0/lib/ruby/gems/2.3.0/gems/.index of /gnu/store/is8536m4c9ks97r3jsiykl72zgpl4bps-ruby-ansi-1.5.0/lib/ruby/gems/2.3.0/gems/ansi-1.5.0 is not allowed <rekado>the delete-file error just happens because "gem install" failed. <jmd>Whenever I do anything in guix I get this warning: "warning: cannot access `/home/john/guix/gnu/packages/.#xorg.scm': No such file or directory" <rain1>I think the # thing is a temporary file created by emacs <rain1>they're really annoying, you can just delete them <jmd>rain1: I have done. and now guix is warning me that it doesn't exist. <rain1>i wonder who is trying to point ot that file <janneke>how do i create a new profile, with the packages of a guix enviroment <package> <rain1>does grepping for #xorg.scm turn up anything? <rain1>I don't know what this could be then <jmd>I suspect it is in one of my .go files <civodul>ngz: most likely because you are mixing the C lib from Debian and that from Guix <ngz>civodul: You are most certainly right. However, I don't quite understand how it happened. I installed a fresh Debian. Installed Guix binary on top of it, cloned repo, and tried the ./bootstrap, etc. invocation. <civodul>ngz: Guix uses Guile from Guix and its libc, which is different from that /usr/lib/libgcrypt.so is linked against <jmd>How can I get a list of all iterations in my profile? <jmd>No. I mean from guile <jmd>which can be found .... ? <davexunit>I don't know off the top of my head, but it might involve connecting to the daemon and doing some RPCs <civodul>jmd: 'profile-generations' in (guix profiles) <civodul>Steap: Nixpkgs has had the infrastructure for several years, and we have more than half of it, so i guess we could/should do something ;-) <civodul>(re building stuff in foreign distros) <Steap>do they run Nix on a Debian machine ? <Steap>How do they match the packages from the Debian repo ? <civodul>it's a function that takes a derivation (package) and a distro, and runs the derivation's build script in that distro in a VM <davexunit>this would be cool to have, because at work we build packages using Docker... <davexunit>would be great to be able to point to Guix as an alternative there <civodul>i can help with it if someone commits to communicate ;-) <civodul>anyway, nice to see Snabb is sold to this! <davexunit>I don't think I have the bandwidth right now. I also need to understand more about how it would be implemented. <davexunit>civodul: would the "distro" part be some distro base image? <davexunit>we could use call-with-container instead of VMs <civodul>can we use call-with-container inside a derivation? <civodul>i thought there was a problem with user namespaces inside the chroot? <davexunit>civodul: er, I guess we already have a container in that case hehe <jmd>What is the easiest way to tell if a package is in the local store ? <davexunit>so this "foreign package" package could use, say, the theoretical debian-build-system? <davexunit>jmd: convert the package to a derivation and then check if it's outputs exist. <civodul>davexunit: no, you keep the original build script unchanged <civodul>i.e., the build script produced by gnu-build-system <iyzsong>civodul: ah, the merge of gnome-update doesn't have effects.. <jmd>How do I get the store object? <civodul>iyzsong: i haven't restarted an evaluation of master yet, is that what you mean? <jmd>Or does it just want a directory name? <iyzsong>civodul: no, look at packages in gnome.scm, they're still 3.1x. I think we have to revert mark's 4 'Revert ...' commits. <jmd>No. It would seem not. <jmd>So what is the correct way to call package-output ? <davexunit>civodul: I just can't stop trying to understand how this nix foreign distro thing could work. how can the build script stay the same when we do so much guix-specific patching? <civodul>davexunit: in Nixpkgs, the inputs as passed as environment variables (one variable per input) <civodul>so you can invoke the derivation's builder in there <civodul>and possibly set the env vars, though i don't think they even do it <davexunit>does this mean that the built foreign package bundles the full closure of the guix package? <jmd>What does this %store-monad thing do? <davexunit>it provides a purely functional interface for building programs that use the guix daemon <jmd>Hmm. So thing to do with the store then. <iyzsong>civodul: push it as gnome-updates, since 'make assert-binaries-available' fails.. and I disable the spell checking for gedit-3.20 now, also it's true that the skipped gjs test may be a real problem. I have report them to upstream (aspell-devel and gnome bugzilla). <jmd>So what am I supposed to pass as the first argument to package-output ? <davexunit>the source code should have plenty of examples <jmd>davexunit: I've been scouring that for the last 30 mins. <civodul>iyzsong: i'm being told evolution-data-server, gedit, gnome-control-center, gnome-session, gtkmm, totem still fail to build, which i didn't notice <jmd>It doesn't have any helpfull examples. <davexunit>how about all the modules that use (guix store) ? <jmd>I've looked at many of those too. <davexunit>jmd: open-connection creates a store connection object <jmd>I thought that made a connection to the nix server. <iyzsong>civodul: oops, I haven't checked them too. I will continue to work on it.. <jmd>Yes that's what I meant. <civodul>iyzsong: i don't know why they didn't show up in the diff Andreas sent to the list :-/ <civodul>iyzsong: do you think you can find time to work on it today? <civodul>i don't want to pressure you, just to see how we can organize <jmd>It seems strange that I have to open a connection to the deamon, just in order to access the store. <df_>jmd: that's a fairly fundamental part of the design, all access to the store is through the daemon <davexunit>jmd: and you're not just getting access to the store, you want to find out the output path of a package <davexunit>the package must be converted into a derviation <Steap>lfam: do you remember why there is no Py3 version of python-unicodecsv (see 13edb0e5c36181bc8a48fa6a28005b3e3046174a)? <jmd>So package-outputs seems to call the substituter by default. How can I tell it not to? <davexunit>jmd: there's a procedure to set options for the daemon <Steap>How do I import python.scm in openstack.scm and openstack.scm in python.scm ? <davexunit>circular dependencies are very hairy and bad. <rain1>maybe create a new file which imports them both <davexunit>guile modules are allowed to have circular dependencies, but I recommend avoiding them wherever possible. <Steap>davexunit: yeah well, that is basically what package manageemnt is <davexunit>Steap: guix doesn't allow circular dependencies. the package graph is a DAG <Steap>but like packages in openstack need Python <rekado>circular module dependencies are not always bad, though, are they? <Steap>cuz OpenStack is written in Python <rain1>Steap: what about my suggestion <Steap>and well, sometimes package Python need stuff produced byOpenStack <rekado>I think we have statistics import machine-learning and the other way around <Steap>rain1: that seems counter-intuitive <Steap>davexunit: so I'm just fucked here <Steap>davexunit: should we give up on openstack.scm ? <Steap>rain1: I have no idea, I don't get Scheme at all :D <davexunit>Steap: move the non-openstack specific stuff out. <Steap>well, guess I'll jsut do that <Steap>let's cat *.scm > packages.scm :D <df_>is there any theoretical reason python.scm couldn't be split out into python/<whatever>.scm? <civodul>df_: no, though we'd rather stay on a 3-level module names ('fold-packages' kinda expects it) <df_>it seems inevitable for things to get unweildy as guix grows more packages though? <yoosty>speaking of package .scms.. I wanted to add the package "gnome-tweak-tool" and was wondering where in gnome.scm I should stick it? Are there any guidelines for where in a .scm to add a package? <davexunit>yoosty: there's a patch on the mailing list for gnome-tweak-tool already <davexunit>but in general, put the package where it makes sense to you <janneke>i have addressed the comments and trying a new build, will send updated patch later <civodul>hmm, what's the name of the X11 server that doesn't display anything? <civodul>ah so it exists? didn't know that one :-) <random-nick>it's a script that starts the server with overloaded shared libraries <random-nick>so it points to a dummy display driver instead of a real one <janneke>ACTION has heard of the hidden sound system, never of a hidden video system <yoosty>janneke: awesome news on the gnome-tweak patch :) <yoosty>how might I apply the current patch to my running system? <janneke>the short answer is: save the patches (it's a set of 2) <rekado>I still don't understand why my replacement for parse-rfc-822-date does not work in practice. <rekado>I'm doing this inside (unless (guile-version>? "2.0.11") ...): (module-set! %web-http 'parse-rfc-822-date parse-rfc-822-date) <rekado>when I do this in a REPL it's all fine. <rekado>but "./pre-inst-env guix build" is unaffected. <rekado>it's a very stupid replacement for parse-rfc-822-date that I defined; just adds two more branches to the cond. <rekado>hmm, I guess I'll just send the proposed patch to the ML tomorrow. <yoosty>janneke: I have a Lenovo X220 with GuixSD installed as of Monday and "guix pull"-ed as of a few hours ago <rekado>yoosty: I suggest switching to a git checkout rather than using "guix pull" <janneke>yoosty: like rekado says; have a look at the manual: <janneke>"Running Guix Before It Is Installed" <janneke>and probably first 8.1: Building from Git <civodul>rekado: you're doing this in http-client.scm or download.scm? <civodul>there's some duplication to be aware of, as bavier mentioned yesterday <yoosty>rekado/janneke: thanks, I'll go poke around <bavier>has anyone tested out the gcc 6.1 release? <lfam>Steap: IIRC, Python-3 can do CSV in Unicode without an external module / program. <civodul>bavier: not yet, we need a package! :-) <civodul>i'm impressed by all the new features <civodul>and i like that they pay attention to "cosmetic" and UI stuff <lfam>When building a package from git, does anyone ever get a failure like "No code for module (guix ui)"? Paraphrasing because I closed that terminal emulator. I had to run `make` even though things were working with the same commit a few prior. <civodul>lfam: you get that error when building the package, or when running 'make'? <lfam>When building the package <civodul>never seen that, it would be great if you could paste the output <lfam>Okay, this is not the first time it's happened, so it will probably happen again. When it does, I'll capture the output and make a bug report <davexunit>it would be easy enough to test gcc 6.1 in isolation with a new gcc-toolchain <cehteh>i expect it to work, testing is quite time intensive, and still if things later fail with undefined errors that would be ugly and hard to debug <Steap>lfam: yeah, I think one of my packages needs it <lfam>Steap: Okay, well I didn't even try it, so hopefully it will work for you! <lfam>Oh man, building MySQL is very intense! My 4-core machine has a load of 10, without any I/O or CPU contention! <jmd>The font-un package has erroneously got Texinfo artifacts in its description field. <lfam>What do you mean? They seem to render properly when doing `guix package --show=font-un` <jmd>davexunit: What does it use to interpret them? <jmd>Then why does Gnu still mess around with that perl interpreter? <bavier>the guile texinfo interpreter is still missing support for some constructs <lfam>o_O My Debian Iceweasel just became Firefox 45 <davexunit>yeah they no longer have to call it iceweasel <lfam>And they jumped from 38 to 45! <davexunit>yeah they don't need to use LTS releases anymore, either. <davexunit>now if only mozilla would fix the problems that necessitate icecat <lfam>I'd do it but I'm having hardware trouble so my server is offline <davexunit>I don't actually run nginx on any systems yet <lfam>Oh, I figured you did :) I should be "up and running" again this weekend <lfam>I have a Debian server where Nginx is provided by Guix. That would be my test box <katco>how do i provide libgcc_s.so as an input to my gnu-build-system build? <efraim>katco: maybe ("libgcc" ,gcc "lib") <civodul>gobject-introspection et al. is craziness! <civodul>ACTION just went through the Gjs test failure <janneke>ACTION remembers using g-wrap to wrap some guile-gnome library <jmd>What rules/conventions do we have for acceptable package names? <jmd>Thanks. (Seems quite liberal) <jmd>I think I'll name my next package "!@#8 x/(8ö ß\\|" <civodul>wait, i let the reader find out what's to be learned! <emyles>Hi, I have installed guix (on Arch Linux) and it works for root, now I want to set it up for my user as per "2.6.1 Locales" in the manual, but $ guix package -i glibc-locales gives a segfault, what can I do now? <civodul>emyles: could you paste the whole "guix package" command and output? <emyles>civodul: » guix package -i glibc-locales <emyles>[1] 20776 segmentation fault (core dumped) guix package -i glibc-locales <jmd>emyles: Does this happen with other packages too or only with glibc-locales? <emyles>[1] 20982 segmentation fault (core dumped) guix <jmd>The backtrace would also be usefull to append to the bug report. <emyles>in the journal there is a bit more: <emyles> kernel: guix[20982]: segfault at 0 ip (null) sp 00007fffb8c00018 error 14 in bash[400000+c1000] <emyles>I think I've got a backtrace so I'll email it to bug-guix@gnu.org <civodul>emyles: be sure to say how you installed it (from source, binary installation, distro package, etc.) <bavier>I think it would be useful to be able to specify a default value in substitute-keyword-arguments <civodul>bavier: perhaps ensure-keyword-arguments does what you want