IRC channel logs


back to list of logs

<janneke>mingw patch set ready and sent to -devel
<civodul>ACTION -> zZz
<civodul>good night!
<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?
<ghettoname>Jip en Janneke.
<efraim>another new version of gzip
<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>I'm testing the update of mysql to 5.7.12 due to this security advisory:
<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
<jmd>How is that so?
***kelsoo1 is now known as kelsoo
<civodul>Hello Guix!
<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"?
<civodul>actually that won't work
<jmd>I'll run that (takes a while).
<jmd>Ahh "emacs-no-x"
<civodul>ACTION adds checks to 'guix lints'
<civodul>emacs-no-x is fine no?
<civodul>bootstrap-tarballs isn't
<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 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?
<janneke>you may need pkg-config
<ngz>Oh. I added it, thank you. I'm now one step further. The next error is 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.
<janneke>ngz: guile-2.0-dev?
<robsyme>Hi all
<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)?
<robsyme>jlicht: Cool, thanks
<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>~2 years
<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 is unusable?
<ngz>civodul: OK.
<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.
<ngz>civodul: It seems you already solved the problem a couple of years ago ( I still wonder why I need to pass a guix prefixd instead of using default Debian prefix.
<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>oh no
<rain1>thats strange
<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?
<jmd>rain1: No
<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/ is linked against
<Steap> wow
<davexunit>got some catching up to do
<jmd>How can I get a list of all iterations in my profile?
<davexunit>jmd: guix package --list-generations
<jmd>No. I mean from guile
<davexunit>jmd: read the implementation of the above
<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)
<jmd>civodul: Thanks
<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's explanation helps a bit.
<davexunit>civodul: would the "distro" part be some distro base image?
<davexunit>we could use call-with-container instead of VMs
<civodul>yes, base image
<davexunit>civodul: cool
<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
<davexunit>not thinking straight
<civodul>but anyway, either way would work
<davexunit>would be nice to just use a container
<davexunit>VMs are heavy.
<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
<davexunit>civodul: oh
<davexunit>I don't see how that could possibly work
<davexunit>but I guess they make it work...
<davexunit>someone else can implement this.
<davexunit>it's definitely over my head.
<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.
<civodul>bah, what a mess
<civodul>iyzsong: could you do that?
<iyzsong>civodul: ok :-)
<civodul>cool, thanks :-)
<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.
<jmd>/gnu/store I mean.
<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>jmd: a store object
<jmd>How do I get one?
<davexunit>the source code should have plenty of examples
<davexunit>look in the (guix store) module
<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.
<civodul>jmd: don't miss and related pages
<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..
<davexunit>jmd: we use the nix daemon
<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 :-/
<davexunit>jmd: so you want to use open-connection
<davexunit>what's odd about it?
<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.
<iyzsong>not today, but next day is ok :-)
<df_>jmd: that's a fairly fundamental part of the design, all access to the store is through the daemon
<davexunit>jmd: the daemon controls the store
<davexunit>right, it's a fundamental design feature.
<davexunit>jmd: and you're not just getting access to the store, you want to find out the output path of a package
<davexunit>and that requires computation
<davexunit>that the daemon does that
<jmd>I see
<davexunit>the package must be converted into a derviation
<davexunit>and hashes
<davexunit>and hashed*
<davexunit>etc. etc.
<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
<davexunit>and you can tell it to not use substitutes
<davexunit>the 'guix build' code will have an example
<Steap>How do I import python.scm in openstack.scm and openstack.scm in python.scm ?
<davexunit>Steap: please don't do that. :)
<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
<Steap>I sort of need to
<davexunit>Steap: guix doesn't allow circular dependencies. the package graph is a DAG
<Steap>davexunit: yeah I know
<davexunit>Steap: you'll have to rearrange packages
<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
<davexunit>Steap: right, that makes sense.
<rekado>I think we have statistics import machine-learning and the other way around
<Steap>rain1: that seems counter-intuitive
<davexunit>Steap: move the packages to python.scm then
<Steap>davexunit: so I'm just fucked here
<davexunit>if they are not specific to openstack
<rekado>python.scm is soooo big!
<Steap>davexunit: should we give up on openstack.scm ?
<rain1>but does it work or not?
<davexunit>Steap: no
<Steap>rain1: I have no idea, I don't get Scheme at all :D
<davexunit>Steap: move the non-openstack specific stuff out.
<Steap>I see
<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>iyzsong: i'm trying gtkmm now
<civodul>df_: no, though we'd rather stay on a 3-level module names ('fold-packages' kinda expects it)
<davexunit>df_: we don't want more subdirectories
<davexunit>but we could have 'python-whatever.scm'
<davexunit>whatever makes sense
<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>yousty: last patch+with comments here:
<janneke>i have addressed the comments and trying a new build, will send updated patch later
<civodul>janneke: neat :-)
<civodul>hmm, what's the name of the X11 server that doesn't display anything?
<civodul>found it: Xvfb, part of xorg-server
<random-nick>yeah Xdummy is just a dirty hack
<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>yoosty: what's your setup like?
<janneke>the short answer is: save the patches (it's a set of 2)
<janneke>go to your git checkout of guix
<janneke>say git am <patch1>
<janneke>git am <patch2)
<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>and they work in a REPL.
<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"
<rekado>it's more flexible this way
<rekado>ACTION has to go now
<janneke>yoosty: like rekado says; have a look at the manual:
<janneke>"Running Guix Before It Is Installed"
<janneke>esp. footnote (1) on that page
<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
<civodul>ACTION has a fix for gtkmm \\o/
<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.
<lfam>Steap: But, upstream's GitHub page says that 3.3 through 3.5 are supported, so I suppose it could work if you needed it:
<civodul>bavier: not yet, we need a package! :-)
<civodul>i'm impressed by all the new features
<bavier>yeah, me too
<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.
<lfam>a few hours prior
<civodul>hello lfam!
<civodul>lfam: you get that error when building the package, or when running 'make'?
<civodul>the latter no?
<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
<cehteh>.. btw, before updating to gcc 6.1 read the release notes:
<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`
<lfam>jmd ^
<davexunit>jmd: we allow texinfo in descriptions
<jmd>davexunit: What does it use to interpret them?
<davexunit>jmd: guile
<davexunit>guile comes with a texinfo reader
<jmd>Wow! since when?
<davexunit>hmm not sure
<davexunit>awhile. :)
<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>BTW davexunit, there is a new stable release of nginx. Maybe you'd like to try it out?
<davexunit>lfam: thanks
<davexunit>that reminds me to update node to 6.0.0
<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 can try it then
<davexunit>I don't yet have my servers using guixsd
<davexunit>too many missing components
<lfam>I have a Debian server where Nginx is provided by Guix. That would be my test box
<katco>how do i provide as an input to my gnu-build-system build?
<efraim>katco: maybe ("libgcc" ,gcc "lib")
<janneke>ACTION has spammed -devel again
<civodul>gobject-introspection et al. is craziness!
<civodul>ACTION just went through the Gjs test failure
<janneke>what's our hope for a saner world?
<civodul>i wonder
<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ö ß\\|"
<wingo>sounds legit
<jmd>... but perverse!
<davexunit>ACTION pushed nodejs 6.0.0 update, btw
<civodul>there's a lot to learn from
<davexunit>civodul: how so?
<davexunit>because it's a tutorial?
<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
<civodul>emyles: could you email you would send this output, plus information on how you installed Guix, and what versiosn of the dependencies are used (those listed at
<jmd>emyles: Does this happen with other packages too or only with glibc-locales?
<emyles>civodul: k thanks, will do
<civodul>thank you
<emyles>jmd: anything:
<emyles>» guix
<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
<civodul>emyles: be sure to say how you installed it (from source, binary installation, distro package, etc.)
<emyles>yes, binary btw
<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