<lfam>Any thoughts on how to run the tests for python-icalendar, which I am trying to package? There is no output during the check phase so I don't think that the tests are actually being run. But, there are a bunch of tests in "src/icalendar/tests". Here is my WIP package definition: http://paste.lisp.org/+3KFK
<fps>lfam: do you see any cpu usage in e.g. top during the tests?
<lfam>The test phase is lasts <1 second, so I really can't tell
<fps>oh, i misread setuptool's find_packages() documentation.
<fps>lfam: maybe go into an environment and call setup.py manually to see if it runs the tests? :)
<lfam>I tried that but I had the a similar result.
<lfam>Shooting in the dark, and based on some other packages in python.scm, I tried including python-nose as a native-input and replacing the check phase with (system* "nosetests"). That reported "Ran 81 tests in 0.387s", which is about as long it the check phase was taking before I started asking about it here.
<ecraven>I've been playing around with Nixos, but I'd prefer to use guix (Scheme!). Should it be possible to use GuixSD (mysql/postgres, apache, a few custom scripts) in production? Or are things still too unstable?
<ecraven>also, are people using GuixSD for their personal machines?
<fps>well, if the user installed them into their own profile using e.g. guix package -i package
<stack>so for example I'm thinking to this use case, I develop a python web app that uses system packages, the sysadmin issued a guix pull, those system packages are upgraded too, she has no way to fix them?
<fps>there's a system profile and then there are user profiles [or one]
<fps>the guix pull will not upgrade any installed packages at all..
<fps>ok, no idea then. note though that the user is still free to just install a particular python version into a particular profile, and then use the interpreter to do all kinds of funky things in their home :)
<stack>guix asking permission before installing dependencies would be cool!
<nateo>So, here's my problem: I am installing Guix 0.9.0, but Mozilla seems to have removed the sources for nss-3.19.2, which apparently has security problems. This causes the build to fail. I tried doing a guix pull, but this fails with a message "failed to download up-to-date source". I already checked to make sure I have connectivity with the Internet and I do. Any ideas?
<efraim>if you allow substitutes then if hydra has a copy you can download it from there
<roelj>I think my Guix has a problem.. I issued 'guix package --remove emacs-auctex'. Then it wants to build six packages and download another 17.. Why can't it simply remove the package..
<roelj>Next, downloading is super slow and fails around 1MB. So I ran 'guix package --remove emacs-auctex --fallback --no-substitutes', and let it run for a night to find out this morning that it failed all of the builds..
<roelj>When I try to remove a font it also wants to build and download the same packages..
<iyzsong>roelj: yeah, I think they are packages required by profile hooks. what is going to build? texinfo, ghc or gtk+?
<roelj>profile, module-import, module-import-compiled, gtk-icon-themes, ca-certificate-bundle, and info-dir
<roelj>Downloaded packages is guile, texinfo, gzip, grep, readline, libgc ...
<iyzsong>I'm not sure, guess this will happend when update guix and the bootstrap guile changed..
<lfam>`guix pull` takes a little while, dependent on much has changed since your last `guix pull`. Since you just installed Guix, you are updating the package list since Guix 0.9.0 was released, in early November. Next time it will be faster.
<lfam>moyamo: You can use systemd to limit the memory consumption of the guix-daemon. That will help you.
<lfam>re: hardcoded /tmp: Sigh... time to dust off my notes on using LVM.
<lfam>Debian's "guided" partitioning gives users a /tmp that is way too small for Guix.
<moyamo>Won't limiting the memory cause it to crash again?
<lfam>sneek: later tell moyamo: Probably, your kernel killed the guix-daemon because your whole system was out of memory. By using the systemd unit parameters "MemoryLimit" and "MemoryAccounting" you can limit the total memory available to the guix-daemon.
<sneek>moyamo, lfam says: Probably, your kernel killed the guix-daemon because your whole system was out of memory. By using the systemd unit parameters "MemoryLimit" and "MemoryAccounting" you can limit the total memory available to the guix-daemon.
<sneek>moyamo, lfam says: If `make` actually can't get enough memory, then I'm not sure what to do.
<lfam>moyamo: Are you able to increase your /tmp? Are you using LVM?