IRC channel logs
2016-07-28.log
back to list of logs
<myglc2>davexunit: used OpenSCAD for 2 projects, highly recommended. <sapientech>hi all, wanting to make an environment with python2 instead of python3. looks like (build-system python-build-system) uses (default-python) which is python3 <sapientech>in guix buid-system python.scm, there is an option for (default-python2), which is what I would like to use instead <sapientech>i managed to make this work by copying all these procedures into a build script (some where private so i couldn't access them), but this seems pretty hacky <sapientech>was wondering if there is a straightforward way to do something like (build-system python2-build-system) <Sleep_Walker>I miss command `tree', does anyone know what package it is? <efraim>apparently its in a package called tree, in admin.scm <sneek>civodul, you have 2 messages. <sneek>civodul, jlicht says: the first command (installing hello) and then running it only works if someone has set up their guix properly (by setting PATH) <sneek>civodul, jlicht says: so it might lead to people 'installing' guix, and then trying the examples they saw on the front page (which won't work) <civodul>sneek: later tell jlicht good point; they would get a message about setting PATH though <fps>hmm, is there possibly a race somewhere in the "guix build" commands? i do several ones in parallel and sometimes one gets hung with: <fps>waiting for locks or build slots... <ng0>email just got a bit less frustrating with switching to notmuch :) i can finally catch up and sort <efraim>the guix install instructions only instruct you to create 10 guixbuild users <ng0>so good in sorting, i can even take on reviewing more :) <civodul>fps: it's not a race, on the contrary: the daemon centralizes everything, and so one client "wins" over the others (the others wait until the thing is built) <ng0>i think what got my first attention of Guix was the 0.8.2 release email.. i just found this through this new gained structure :) <efraim>I first heard about Guix through Phoronix with 0.8.2 or 0.8.3 <ng0>I'm also skipping through about 6000 emails the next days to tag them, so if I find any inspiration what could be added to the docs through questions which stand out, i'll write messages <ng0>there's one already: <ng0>do we have a policy on how to choose the installed documentation formats? <ng0>if not, i'll open a bug (seems the most obvious place for me for thing which should be done) <ng0>it was a question civodul asked at the end of "[PATCH] gnu: unison: Add "doc" output." "maybe we should have..." <ng0>about not pdf... i have the lispf4 still as work in progress. it needs to get fixed. revisiting it now, i would if not already done so move the docs to :doc as they include lots of big pdfs, scans etc <efraim>then that shouldn't be a problem. PDFs generally take a lot of space, that and the texlive dependancy, is I think why people don't like them too much <efraim>and they're hard to read from the terminal <ng0>that's not really true <ng0>there's a tty reader <ng0>completely independent of X <ng0>but yes, the size is problematic. <Sleep_Walker>2] is there tool which can solve this question generically? <ng0>not yet.. I'd loveto have something like e-file (pfl) for guix, but it requires a database available, like for e-file. <ng0>i mean e-file requires that, which is gentoo specific. <ng0>the send-email output <ng0>I'm about to add something to the contributing doc, but the example is too long, at least for the pdf generated output <ng0>should i break the line or (...) <ng0>breaking makes more sense <fps>hmm, how does one clone from notabug.org? <fps>ah, got it. was just a little hidden <fps>hmm, the running instructions are a bit unclear <fps>i have cuirass checked out, but there's no pre-inst-env.sh like there would be in the guix repo after building <fps>it needs automake and other things i suppose <fps>guix environment guix gives me autoreconf and automake. so i did autoreconf and automake --add-missing. but now configure errors out <fps>i'll wait until the docs are a bit updated instead of guessing arounf <civodul>maybe you should post the configure error you get though, because docs won't be updated magically if nobody knows what the problem is :-) <fps>fps@guix ~/cuirass [env]$ GUILE_LOAD_PATH=$GUILE_LOAD_PATH:/home/fps/guix/ ./configure <fps>was about missing guix module :) <fps>here's another one, though: <fps>configure: error: required guile module not found: (sqlite3) <fps>i'll figure it out later. still at work :( <fps>would be nice, if there was a cuirass guix package definition included :) <civodul>fps: oh sorry, i though you were talking about guix itself <civodul>you need to install guile-sqlite3 i suppose <civodul>mthl is not here right now, maybe you could ping'em on the list <Sleep_Walker>I've got frequently `504 Gateway Time-out' when accessing build logs on hydra - shouldn't be there bigger timeout value? (I guess it is expected to got slow responses in such cases...) <civodul>Sleep_Walker: the rationale was that if Hydra cannot reply within ten seconds (!), then we'd rather not overload it further <civodul>you should access logs on mirror.hydra.gnu.org though <civodul>with luck, they'll already be cached <civodul>"guix build --log-file foo" directs you to the mirror nowadays <civodul>no, it checks for local and then remote build logs <civodul>but sometimes there are no logs, of course <davexunit>does anyone have recommendations for caldav server software? <davexunit>maybe something is already packaged in guix? :) <davexunit>I'm going to give this radicale program a shot <myglc2`>Can I repeat '(bootloader (grub-configuration (device "/dev/sdX")))' in my system config to install the boot loader on multiple HD? <civodul>myglc2`: no, only one of them is taken into account <davexunit>I am happy to report that the radicale works well <civodul>we should probably add a service for that <davexunit>my server right now is a debian + guix setup, so I can't take advantage of guixsd services. <roelj>How long does it normally take to compile qt-everywhere? <roelj>I guess I'm at approximately 1% then <myglc2`>civodul: thanks, so... how to have a copy of boot loader on each RAID drive? Manual dd? <civodul>myglc2`: i'm not familiar with this use case, you should probably explain on the mailing list <lukeshu>With Parabola GNU/Linux-libre, I'm working on a project called "notsystemd" that has pretty much the same goals as elogind, but more than just logind. <lukeshu>i.e., also being able to use say, timesyncd, or systemd-nspawn, outside of a systemd environment. <Gottox>lukeshu: we're searching for such a thing for void linux. <lukeshu>Gottox: I would be very pleased if it found use outside of just Parabola! <lukeshu>It's still not quite ready yet, but hopefully will be soon. <lukeshu>Gottox: yes, it is an FSF-endorsed Arch fork <lukeshu>Anyway, I thought it would be a good idea to reach out to the developers of a similar project. <ng0>should I ask at notmuch or at emacs channels/lists about how to save inline patches displayed in notmuch to a file? <ng0>1 inline patch was always okay for me or 2, but 16 means the end of my inline copy&paste+corrections system <lukeshu>ng0: I think 'v' saves to a file? I use wanderlust, but I think that it's a generic keybinding from the common mime-view-mode, but #emacs would be a better place to ask. <ng0>the problem with notmuch threads are, it's all one buffer. <ng0>i can imagine a notmuch search and then pipe the individual messages init *.patch but there has to be something else. <ng0>and as notmuch isjust a reader, "v" does not work. <ng0>looks like the answer is to write a script which does this. <ng0>i think Ifound something in the notmuch archive. <ng0>but it did not work… grm <ng0>i have a minimal workaround: tag messages as guix-patch-review-$number and then work with that to save to file. <sapientech>hi all, i have an interesting issue that ive been trying to parse. trying to get a solid build for kivy, and it looks like its having trouble finding sdl stuff <sapientech>however when i do: pkg-config --cflags sdl2, i get: <sapientech>-D_REENTRANT -I/gnu/store/9r4cn1rl7spf1gmj8cnm9qq3i3iych4w-sdl2-2.0.4/include/SDL2 <bavier>sapientech: are you asking about the GLES error or about the SDL missing components? <sapientech>bavier: yes, well im not sure if they are related, but more particularly sdl components <sapientech>but the gles error is also something im trying to figure out <bavier>sapientech: are you using sdl-union? <sapientech>bavier: i am not, doesn't show up with guix package -A sdl-union <bavier>sapientech: it's a function in (gnu packages sdl) <bavier>there are various examples of it's use in the guix tree, e.g. gnu/packages/games.scm <ng0>as our commits start usually very standardized (gnu:,doc:, etc) I could even automate this extraction with just a few lines :) <sapientech>bavier: okay i see a few instances where people just use "sdl" (sdl-union) and others "sdl" (sdl-union (list sdl-pkgs...) <bavier>sapientech: yup. so it looks like kivy needs sdl, mixer, ttf, and image <sapientech>getting same error with ("sdl-union" ,(sdl-union (list sdl sdl2 sdl-image sdl2-image sdl-mixer sdl2-mixer sdl-ttf sdl2-ttf))) <bavier>sapientech: does it work with just the "sdl2" packages? presumably it only wants a single version of the libraries <sapientech>believe i've done that, let me try again to confirm... <sapientech>yes that also does not work. wondering whether it has to do with the way i configured python2.7 <davexunit>sapientech: you do not want to mix sdl 1 and 2 <davexunit>applications either support one or the other <sapientech>davexunit: thanks for info, i originally had just sdl2, but then added sdl when that didnt work <sapientech>well in the log it says: sdl2 missing sub library sdl-mixer for example, so i was thinking, hmm wonder why its asking for sdl-mixer not sdl2-mixer <ng0>started the review building.. got thison the dep. graph. is there a new release of it or is it not available on hydra atm? <ng0>substituter-failed /gnu/store/afbyqf4xqp09mc16y2a7yvfnlkdnrpjz-perl-devel-symdump-2.14 0 hash mismatch in downloaded path `/gnu/store/afbyqf4xqp09mc16y2a7yvfnlkdnrpjz-perl-devel-symdump-2.14': expected 0219596b189ae2ccea660909d7735211c2581ebd65afb2c2bc51b00045852185, got 1a8df0f0120eb0bcb959566979c1209545830f9f9cd8c9a9ef1356e1aa57835f <ng0>and 2.14 no longer in "other releases" .. idk if that means it is gone poof for ever <sneek>jlicht, civodul says: good point; they would get a message about setting PATH though <ng0>no, seems to be available on 1 cpan mirror. <ng0>no.. this 16 packages bundle of perl packages is too much perl for me, someone with more perl knowledge needs to review this <bavier>I've been offline for a while, but I'll have some time to review patches this weekend <ng0>thanks :) i just tried and i can't do it at this moment. i'll fix one dependency which i found to be outdated. <ng0>that's the one: Today 11:19 [23/23] Danny Milosavljev... [PATCH v4 00/16] Add missing dependencies of Spamassassin (guix-patch guix::patch:review guix::patch:review:01 g$ <ng0>i might also be that due to one of its dependencies it is not reproducible. One has to try --rounds=2 again once all the package problems are fixed <lfam>mark_weaver: commit ae46cd0e (gnu: gd: Update to 2.2.3 [fixes CVE-2016-6207]) causes libgd to fail to build on x86_64. I'm going to revert it on master and merge the reversion into core-updates in a few minutes if I hear no objections. <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, ng0 says: thanks for merging gmime :) <ng0>also i think the 15 patches would not be dependent on each other so much when they followed what's written in perl.scm - please add new modules in alphabetic order. <sneek>Welcome back catonano, you have 1 message. <sneek>catonano, jlicht says: that I started using paroneayea's json module. I'll update my repo to reflect soon <catonano>jlicht: yes, thank you. I managed to run your recursive npm importer for the first time <civodul>ACTION tries to come up with a cleaner demo video <jlicht>catonano: Hi! Currently, modules that can't be imported for one of many reasons are just skipped by the importer <jlicht>and, as some people pointed out, it might be the case that the importer 'imports' a package multiple times <jlicht>civodul: what was your setup for recording the demo video? <civodul>yesterday i tried obs, but i didn't managed to get much out of it <civodul>and then avidemux to edit the video, although that one sucks too <jlicht>I have _zero_ experience with any kind of recording or video editing software <civodul>jlicht: cool, thanks for checking :-) <civodul>mark_weaver: could you copy it to audio-video.gnu.org? <jlicht>It would somehow still be nice to convey what you want to do <jlicht>"Lets install package `hello`" or something along those lines, in ugly green semitransparent letters :P <civodul>someone more competent with video would need to help though <civodul>but i figured that even as-is, it's better than what's currently on the front page <sapientech>update on sdl2: i realized that kivy looks for sdl2 in /usr/include, which wouldn't be available if i used guix sdl2 <sapientech>so i installed sdl2 with pacman, to see if kivy would find them. with a system wide python setup.py build, they were found <sapientech>however, they are not found when i do guix package -f kivy.scm <sapientech>1. is it correct that guix should not know about /usr/include? <lfam>sapientech: Yes, that's correct. <sapientech>lfam: yeah that seemed correct. adding /usr/include to include path however, should work right? <bavier>sapientech: is there any configure options to have kivy pick up sdl2 from pkg-config? <sapientech>obviously the solution is getting kivy to find guix sdl2 without the include path, but for the time being, going to check this <lfam>sapientech: Adding it to the include path in the Guix package definition? No, that won't work. '/usr' is not available when building Guix packages. <lfam>But it can happen at run-time, although I'd consider it a bug. It breaks the promise of deterministic and stable package builds. <lfam>Because, what happens in '/usr' is not accounted for by Guix <sapientech>lfam: not in the package definition, but a system wide include path <sapientech>lfam: doesn't adding items to the system path affect guix? <lfam>So, your program might break when, for example, Debian makes some incompatible change to sdl2. <sapientech>and only environment --pure will get rid of them <sapientech>lfam: note that this isn't a long term solution, just trying to identify if this is the problem <bavier>sapientech: builds don't see anything but what's in the store for declared inputs, and a few other files <lfam>Actually, only --container will really hide '/usr'. --pure just clears your environment, but the '/usr' directory is still accessible <lfam>sapientech: Yes, I've done that while debugging packages. If the packages honor the environment variable in question, they will indeed be able to follow it to '/usr' <lfam>Or, not the package, but the binary that the package creates <sapientech>lfam: roger, but if the package needs something in /usr to compile, that work work correct? <lfam>By "compile", do you mean you are running `make` by hand, or do you mean `guix build foo`? <lfam>The former will work, the latter will not <sapientech>lfam: sorry for not being clear, guix build, not by hand. thanks so much for the info, going to see if to have kivy get sdl2 from pkg-config <lfam>When doing `guix build`, all the action happens in a chroot that Guix populates only with what you put in the package definition. Things like '/usr' won't be accessible unless the chroot can be broken <lfam>Which would be an exceptional case <sapientech>is there a way to pass environmental variables to a build in guix? if i am able to pass KIVY_SDL2_PATH, then kivy will work <sapientech>lfam: i don't think it would work since thats like adding an include path to the guix package definition <lfam>sapientech: Sure, grep in 'gnu/packages' for 'setenv'