IRC channel logs

2015-12-13.log

back to list of logs

<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
<lfam>fps ^
<fps>lfam: oh ;)
<fps> https://github.com/collective/icalendar/blob/master/setup.py#L20
<fps>tests_require = []? :)
<fps>maybe they disabled the tests in the default build?
<lfam>fps: Is that what that means? I figured it meant that there were no special dependencies for the tests.
<fps>lfam: nah, i'm just guessing :)
<lfam>Thanks anyways. It's not much fun to bang your head against the wall by yourself
<fps>i was also brushing over this:
<fps> https://pythonhosted.org/setuptools/setuptools.html#test-build-package-and-run-a-unittest-suite
<fps> https://github.com/collective/icalendar/blob/master/src/icalendar/tests/test_encoding.py
<fps>things seem to be wrapped hmm
<fps>hmm, src/ doesn't contain an __init__.py
<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.
<lfam>But I see that nose is in maintenance mode, and requests that users try another tool: https://nose.readthedocs.org/en/latest/
<fps>lfam: hmm, sadly i need to get some sleep. but good luck! :)
<lfam>Thanks!
<stack>on first installation I modified the conf in etc and launched reconfigure, now guix is re pulling every package, is this normal? :)
<alezost>stack: you need to do "guix pull" before reconfiguring
***ttuegel_ is now known as ttuegel
<nateo>Hi. I've been trying to install 9.0 but it can't download nss-3.19.2
<nateo>any work-arounds?
<lfam>nateo: version 9.0 of what?
<lfam>Do you mean version 0.9.0 of Guix?
<mark_weaver>nateo: run "guix pull" to update to the latest version of all packages, and then try again.
<mark_weaver>nss-3.19.2 has security flaws. since 0.9.0 was released, we've updated to nss-3.20.1
<mark_weaver>there have been several other important security updates as well
<lfam>It looks like mozilla removed the 3.19.2 sources. When trying to download, the connection just stays open without progressing.
<lfam>Maybe, the first time a profile is created on a system, Guix could recommend the user `guix pull`
<fps>lfam: maybe it's just time to release 0.9.1 :)
<ecraven>greetings :)
<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>yeah, i have it on my laptop
<fps>i had to use some nonfree stuff though.. which i don't promote at all..
<ecraven>fps: but it's possible to integrate non-free things?
<ecraven>I mostly use Emacs for everything, so things might be fine there.. how does guix play together with melpa packages?
<fps>i shan't not sa more..
<fps>ecraven: note that guixsd is alpha
<fps>features are still changing
<stack>this guix pull is compiling libtool, does this mean that hydra didn't precompiled this package?
<fps>stack: you ran guix pull and during the runtime of it libtool is being built?
<stack>yes
<fps>hmm, it might just be that hydra was unreachable when you issued the command
<fps>are you on guixsd?
<stack>yes
<fps>version 0.9
<fps>?
<stack>freshly downloaded yesterday evening, let me see the version..
<stack>fps: is there something like lsb_release /etc/*version ..etc?
<fps>stack: not sure. i'm still a relative noob myself. but recompiling things besides that package definitions and the guix code itself never happened to me
<fps>stack: maybe run sudo guix --version
<stack>so if that was hydra being unreachable, I can stop it and reissue the command, maybe a warning shuuld have been kind from guix :)
<fps>that's a general rule :)
<fps>things are transactional
<fps>stop and restart at your heart's content :)
<stack>0.9.0
<fps>ok, at least it's not 0.8.3 :)
<fps>if you stop and restart you'll lose all progress thoug
<fps>maybe more 0.9 packages dropped off hydra?
<stack> https://imgur.com/SZFz2go
<fps>that looks fine
<fps>let it run
<fps>compilation of the packages will take quite a whie
<fps>whie
<fps>gnah
<fps>while
<stack>one question, if a user is using previous version of packages, are them keeped ?
<fps>yes
<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>once root does guix system reconfigure
<fps>the system profile will be changed..
<fps>the user is always free to have their own version of guix though
<fps>and install packages into their profile..
<fps>i'm still a little bit fuzzy on the details, but that's my understanding
<fps>the user might even go as far as cloning the guix git repo, checkout a particular revision, build it, and then use ./pre-inst-env guix package -i ... to install specific versions
<fps>the user is also free to keep different profiles around, too :)
<stack>in my understanding guix should be used in place of virtualenvs, am I right?
<fps>so in general it's, i think, recommended, to keep the system profile as sparse as possible and leave most to the users..
<fps>virtualenvs? that's a python thing?
<stack>yes, python package management
<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 :)
<fps>sorry, gotta run. good luck
<fps>just shooting out a question to the channel in general though [will be back later]: is it true that substituters do not serve fixed-output derivation results?
<iyzsong>'guix pull' update the guix repository to latest from git repository hosted on savannah, it update what package recipes avaliable to you.
<fps>i.e. downloads
<iyzsong>fps: don't really get what you mean.. hydra serve sources tarball (which is fixed-output) well.
<fps>iyzsong: it does? ok, then.. laters..
<fps>if you care to, you can add http://fps.io:9999 to your list of substituters. it has some packages available..
<fps>off now :)
<iyzsong>bye~
<efraim>fps: I got "SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)" through iceweasel
<fps>iceweasel tries to be smart and fails
<fps>that's not SSL. http://fps.io:80 forwards to 430 though
<fps>try links http://fps.io:9999
<fps>:)
<efraim>resource not found: /
<fps>as expected..
<stack>are package definitions signed somehow?
<fps>it's a guix-publish service..
<fps>hold on
<fps> https://pastee.org/2mvz
<iyzsong>that's for 'guix ... --substitute-urls=http://fps.io:9999', it worked for me :-)
<fps>public key. really off
<fps>it has a wild mix of packages, don't expect tooo much :)
<stack>so the next step is servig them via torrent?
<stack>:)
<iyzsong>stack: no, all definitions is in the guix git repository, and I think commits aren't signed.
<stack>iyzsong: is it being discussed somewhere
<stack>?
<iyzsong>yes, real P2P by GNUnet, that's the plan.
<stack>wow
<stack>is there somewhere a roadmap for guixsd and guix?
<efraim>we have a TODO list in the git repo, not sure about how up-to-date it is
<stack>ok
<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
<efraim> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation step 7
<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..
<roelj>Okay. How can I fix this?
<efraim>big attack on `guix refresh -t gnome` done for now, 22 patches to push ...
<iyzsong>roelj: try add '--bootstrap' when building profile
<roelj>iyzsong: And how can I build profile?
<iyzsong>guix package -r emacs-auctex --bootstrap
<iyzsong>both 'install' or 'remove' packages from profile is 'build'.
<roelj>Ok, thanks :)
<iyzsong>well, I guess a real fix will be get the guile by 'guix build guile' and maybe 'guix pull'.
<civodul>Hello Guix!
<roelj>Hello civodul
<efraim>hi!
<roelj>iyzsong: Luckily it built this time.
<iyzsong>roelj: what get built? profile or guile?
<roelj>iyzsong: guile-2.0.11 and guile-2.0.11-debug
<iyzsong>that's fine :-)
<anonymiss>hi.. sorry for double sending, but I'm not sure if i was connected:
<anonymiss>and now paste is empty :/ okay, then I'll try again
<anonymiss>when i first setup systems with guixsd, user accounts i define are created, but never their homefolders, although i include them.
<davexunit>anonymiss: my guess is that /home isn't on the root partition
<davexunit>I've experienced this, too, and I'm pretty sure ludo is aware of the limitation.
<anonymiss>it is not on the same partition as root part. ah, isee
<anonymiss>also, how do i tell the default login manager that i don't use en_US layout when the systemwide locale is en_US.utf8?
<anonymiss>i know qwerty on qwertz already, but it's annoying
<anonymiss>or is it limited to the systemwide locale setting? i can loadkeys $lang, but i would prefer to have the graphical login with working de layout
<davexunit>that I don't know
<iyzsong>anonymiss: they're seperate things, you can set the X11 keyboard layout in xorg.conf (using the 'extra-config' field of xorg-configuration-file).
<anonymiss>ah, okay. i was used to a different x11 setup by now. okay, I'll try. thanks
<iyzsong>or a easy way, just put 'setxkbmap xxx' in ~/.xsession, that only work after the slim login though.
<anonymiss>i know how to do that :) it just wasn't obvious to me in guix :)
<civodul>GDM, thanks iyzsong!
<stack>I'm in libre software oversode, now librejs is blocking all non apparently libre script :)
<civodul>anyone CSS-savvy knows what to do with http://bugs.gnu.org/22115 ?
<TML>civodul: Can you duplicate it? Site looks fine for me in Firefox 42.0
<civodul>TML: it looks fine for me in Conkeror based on IceCat 38
<civodul>well, "fine" is a strong word, but not as bad as in that bug report
***tardyp_ is now known as tardyp
<TML>Agreed :)
<TML>Without being able to reproduce the problem, it's a bit tough to say what is going on.
***mattl_ is now known as mattl
<efraim>building gcc-5.3.0 now, unpack phase looks longer than tex
<moyamo>Hi, I'm new to guix. I ran guix pull and now it's compiling. I thought guix pull was supposed to pull binaries
<lfam>moyamo: `guix pull` is updating your list of packages. Since Guix is written in Guile Scheme, the package definitions are also Scheme code. Think of `guix pull` like `apt-get update`.
<moyamo>So it's compiling scheme code?
<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>Correct
<lfam>When you want to update a package that you have installed with Guix, you will use `guix package --update foo`. To update all the packages, you will do `guix package --update`
<efraim>the time `guix pull` takes depends on your cpu
<moyamo>My old laptop nearly freezes up everytime I compile code :(
<moyamo>And now 'make' crashed because I ran out of memory :(
<efraim>awww, that's going to make it hard
<efraim>more swap?
<moyamo>I think the problem is /tmp is a tmpfs. I've ran into this problem before. Is there any way I can tell guix to use /var/tmp instead?
<cehteh>TMPDIR=/var/tmp ?
<efraim>not specifically that I know of. I changed my /tmp to be 5GiB
<efraim>that might work, the change to hardcode /tmp shouldn't be in moyamo's copy yet
<lfam>moyamo: What operating system are you using?
<efraim>that was today
<lfam>Wait, why hardcode /tmp?
<efraim>reproducability issues
<moyamo>Arch Linux
<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>Okay.
<lfam>sneek: later tell moyamo: If `make` actually can't get enough memory, then I'm not sure what to do.
<sneek>Will do.
<efraim>how much does it need? 2GiB?
<lfam>efraim: my /tmp is 3.3 GB and I can't compile libreoffice in there.
<efraim>oh, I was thinking make for guix itself
<lfam>efraim: Are you talking about moyamo's RAM issue?
<efraim>yeah
<lfam>efraim: I have my armv7 Allwinner A20 computer's guix-daemon limited to 768 MiB RAM, and it works. But of course it slows things down.
<lfam>Not that I tried to compile libreoffice on that one
<lfam>I had to limit the CPU and RAM on that machine because it doesn't handle low-resource situations gracefully (crashes)
<efraim>even with a large swap?
<lfam>efraim: The main filesystem is on a micro-SD card. There is spinning-rust-over-SATA but it's not always attached. So I really try not to swap on that machine.
<anonymiss>compiling libreoffice from sources needed at least 4gb swap/ram iirc
<anonymiss>just for numbers on tmp... whoever wanted to know
<lfam>Wow
<efraim>iirc kernel is less than 2gb
<anonymiss>yep
<anonymiss>libreoffice, and the webkits are big
<lfam>And just so we can copy a (IMO) crappy way to write text from the proprietary world
<efraim>tex is about 5gb also
<anonymiss>but conpiles faster than libreoffice on old architecture naybe.. lo was the longest si far on 2ghz 2cores, 7-9 hours iirc
<efraim>oh wow, glad I haven't tried that one
<lfam>It's brutal. And currently, we aren't building it on i686 due to a failed dependency.
<lfam>I wonder if that bug report will have any results
<efraim>gccgo-5 takes me about 6 hours
<lfam>efraim: Are you using Go on Guix?
<efraim>still trying to get gccgo-5 to compile correctly so I can compile go-1.5
<efraim>as long as we have a bootstrap from gcc it doesn't make sense to download the binary bootstrap
<lfam>I've been meaning to look over codemac's Go branch. It will be very good to get Go in Guix.
<efraim>i forgot to check on hydra how long the mips/arm machines take to compile gcc-5.2 since they're normally a pretty good indicator of how long it'll take me
<moyamo>So TMPDIR=/var/tmp seems to be working. Since you say you've hardcoded it to /tmp in new versions. How do you suggest I mitigate this problem in the future?
<sneek>moyamo, you have 2 messages.
<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?
<moyamo>Is that a filesystem?
<efraim>bindmount /tmp to /var/tmp?
<lfam>:) LVM is the Logical Volume Manager. It's a way to set up your block devices (disks) and partitions so that it is relatively easy to change them without reinstalling your system.
<moyamo>What about the files already in /tmp?
<moyamo>lfam: I'm probably not using LVM.
<lfam>The files already in /tmp are meant to be disposable. If a program relies on /tmp being persistent then the program is broken.
<moyamo>Lot's of programs stick sockets in /tmp
<lfam>moyamo: https://wiki.archlinux.org/index.php/LVM
<lfam>moyamo: Yes, but in the situation where you are reallocating disk space with LVM, those programs won't be running.
<moyamo>Argh. It's using tmp again.
<lfam>moyamo: Did you restart the daemon after changing TMPDIR?
<moyamo>No, I ran TMPDIR=/var/tmp guix pull .
<moyamo>The daemons started by systemd
<lfam>I think you have to pass TMPDIR to the guix-daemon
<moyamo>will TMPDIR=systemctl restart guix-daemon work?
<lfam>moyamo: Look at this: http://paste.lisp.org/+3QCZ
<lfam>You should edit the systemd service file. It's probably at /etc/systemd/system/guix-daemon.service. Maybe at /lib/systemd/system/guix-daemon.service if you installed Guix from an Arch package.
<lfam>If it's under /lib, copy it to the /etc path and edit the copy
<moyamo>If I change the TMPDIR will guix clean up after itself?
<moyamo>Or do I have to manually clean /var/tmp
<lfam>moyamo: It will delete the build sub-directories unless you do `guix build --keep-failed`
<lfam>Alright, I have to go enjoy the fact that is 35° F warmer than it should be where I am. Good luck!
<efraim>gcc-5.2.0 on mips was 8.5 hours, about the same on arm
<efraim>so looks like i'll be building gcc-5.3.0 all night
<moyamo>From the messages. guix pull is definitely buidling C code.
<davexunit>sounds like you have substitutes disabled.
<davexunit>or are using a version of guix that is old enough to no longer have substitutes available
<davexunit>so you have to build from source.
<moyamo>I'm using version 0.8.3
<davexunit>that would explain it.
<moyamo>How do I enable substitutes. My laptop is not very good at compiling GCC :P
<davexunit>there are no longer binaries for that release
<efraim> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation step 7
<moyamo>So enabling substitutes won't work?
<moyamo>from efraim's link?
<efraim>that's how you enable substitutes, but the actual substitutes from 0.8.3 got garbage-collected already due to lack of space
<moyamo>Okay, I'll reinstall guix from scratch then.
<efraim>if you enable substitutes and run guix pull then you should get substitutes from hydra
<moyamo>acc 5 on
<civodul`>francis7: would you have recommendations on hardware to build our next server on top of the D16?
<civodul>that would be great
<fps>anonymiss: that's weird. their initial home dirs should get created fine
<fps>oops, was scrolled wrongl
<fps>y
<fps>btw: http://fps.io:9999 should have substitutes for almost all of 0.9.0 available now and a good chunk of somewhat current master
<fps>good night..
<civodul>fps: note that people cannot use them if you don't publish the key
<civodul>and if you do, there's potentially a trust bootstrapping issue :-)
<fps>civodul: how do you officially publish the key?
<fps>i pasted it here a few times
<fps>it's just an offer if you find hydra to be too slow. don't use it if you don't trust me to not screw you over...
<moyamo>How do I verify the piblic key of hydra.gnu.org?
<fps>how about publishing the public key on / which right now returns 404 ;)
<fps>along with an explanatory text?
<fps>also how can i trust gnu.hydra.org not to inject bad code into packages?
<fps>sure i could challenge all packages now. but it might not serve them all of the time..
<fps>it;s an interesting problem :)
<civodul>yep :-)
<civodul>if you want to fps.io to be more widely used, you could send its public key in a message to the list, and have that message signed with your OpenPGP key
<moyamo>Guys, how can I check that the hydra.gnu.org key I got is valid?
<civodul>(guys & gawls)
<civodul>moyamo: see http://www.gnu.org/software/guix/manual/html_node/Substitutes.html
<civodul>"If you installed Guix from source, make sure you checked the GPG signature of guix-0.9.0.tar.gz, which contains this public key file. "
<civodul>night/day!
<moyamo>civodul: Thanks. Sorry for asking suck stupid questions. Good night.
***raulet_ is now known as raulet
<paren-match>hello
<paren-match>I want to build a kernel for my guixsd. Is there anything I should look out for?
<fps>paren-match: what kind of kernel?
<paren-match>linux kernel
<paren-match>or what do you mean=
<paren-match>of course by build I mean compile
<fps>paren-match: you can just guix build the linux-libre kernel then
<paren-match>hm didn't know I had that option
<paren-match>but I wonder if that's really what I want
<paren-match>will it have the drivers I need?
<fps>i wonder how i can get some more info out of the slim display manager
<fps>to find out why bspwm doesn't start righ
<fps>oh, creating an .xinitrc, and symlinking it to .xession and .xsessionrc and making it executable works. thanks slim :)
<fps>ugh bspc says "unknown command" for every message