IRC channel logs

2016-07-24.log

back to list of logs

<lfam>What do people think about the propagated-inputs in this patch? http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01022.html
<lfam>Is it normal to propagate those?
<ng0>oh.. python-sphinx is at 1.4.5 … is this in core or -next ?
<lfam>ng0: It's on the python-updates branch. We will do a whole bunch of Python stuff soon
<ng0>is someone by any chance packaging "tup"?
<lfam>I haven't heard of anybody doing it yet
<ng0> http://gittup.org/tup/ is something i need as a dependency
<ng0>okay
<ng0>lfam: what do you think of tup? someone just told me it's smaller to package than packaging make itself..
<ng0>the gentoo and archlinux packages look small
<lfam>ng0: I'm not sure, I've never used it. The Arch PKGBUILD shows there are a few non-standard things, but maybe they will be simple to adapt. You should try it if you need it
<ng0>pbpst needs it
<ng0>so, yes
<koosha>Hello friends !
<koosha>I got an error while executing the 'guix system reconfigure' command :
<iyzsong>koosha: hi! what's the error?
<koosha>iyzsong: Hi , I paste it .
<koosha>iyzsong: It's the address : https://paste.ubuntu.ir/elbu
<iyzsong>koosha: that one failed to download, did add `--fallback' to the command help?
<koosha>iyzsong: No
<koosha>iyzsong: What command should I exacly run ?
<iyzsong>koosha: guix system --fallback reconfigure '/path/to/config.scm'
<koosha>iyzsong: Okay , thank you .
<rekado>I really think we can use mu-guile to build a simple patch tracker and use Guile’s built-in HTTP server for the web interface.
<rekado>If I’m not mistaken we wouldn’t even need an additional database to keep track of things. We’d just move processed email to the archive to exclude them from future consideration.
<alezost>sneek: later tell koosha from the output you pasted at <https://paste.ubuntu.ir/elbu>, I see many things will be built locally. Most likely this is because you didn't do "guix pull" for some time
<sneek>Okay.
<efraim>is it weird that I love iso8601?
<ijp>yes
<ijp>rfc 3339 is essentially the same format, but with less moving parts
<jlicht>hello guix
<catonano>Hi jlicht
<koosha>I ran the guix system reconfigure . It's downloading so many things . Is it normal ? I have those installed .
<sneek>koosha, you have 1 message.
<sneek>koosha, alezost says: from the output you pasted at <https://paste.ubuntu.ir/elbu>, I see many things will be built locally. Most likely this is because you didn't do "guix pull" for some time
<koosha>sneek: No I did guix pull .
<koosha>Hello friends !
<koosha>I have finally lsh installed but when I try lsh localhost I get this error :
<koosha>lsh: Connect failed, (errno = 0)
<koosha>Something is wrong with my lsh server , right ?
<koosha>I solved it .
<koosha>lsh now works for me but it's slow . What could be the reason ?
<lfam>efraim: Thanks for the openssh update!
<paroneayea>hiya everyone
<paroneayea>ACTION replies to that recent mailing list thread
<lfam>Is it just me or did `guix pull` get faster recently?
<Sleep_Walker>is there a way, how to trace guile interpreting initrd?
<Sleep_Walker>I'm a bit lost
<mark_weaver>sneek: later tell koosha: 'guix pull' only updates guix for the user who runs it. each user on a system has their own version of guix. in your case, I suspect you ran 'guix pull' as your normal user, which is the right thing to ensure that normal 'guix package' commands as your normal user will install up-to-date software. you also need to run 'guix pull' as root to ensure that 'guix system reconfigure' uses up-to-date software.
<mark_weaver>this is a common confusion.
<sneek>Got it.
<mark_weaver>sneek: botsnack
<sneek>:)
<efraim>civodul: I think you have a typo with gnupg@2.0, you used %standard-phase instead of %standard-phases
<koosha>Hello
<sneek>Welcome back koosha, you have 1 message.
<sneek>koosha, mark_weaver says: 'guix pull' only updates guix for the user who runs it. each user on a system has their own version of guix. in your case, I suspect you ran 'guix pull' as your normal user, which is the right thing to ensure that normal 'guix package' commands as your normal user will install up-to-date software. you also need to run 'guix pull' as root to ensure that 'guix system reconfigure' uses up-to-date software.
<koosha>sneek: Yes I read it , Thank you :)
<koosha>I have a question : When I use openssh it's fast (On my Debian system or GuixSD) but when I use lsh it's slow to run commands (On GuixSD or Debian) . What's the problem ?
<ng0>vlc on core-updates is solved?
<ng0> https://hydra.gnu.org/job/gnu/master/vlc-2.2.4.armhf-linux reads like it
<ng0>at least for arm
<ng0>and all else
<mark_weaver>koosha: I'm not sure. to be honest, I use openssh.
<mark_weaver>ng0: that URL is for master, not core-updates
<ng0>oh
<ng0>rigth
<ng0>i'll see to rebase and send gnupg-2.1.14 and gpgerror with corrections tomorrow
<mark_weaver>sounds good, thanks!
<mark_weaver>efraim: you're right, it's a typo. would you like to push a fix?
<mark_weaver>and maybe test build it, to make sure it's good? clearly it wasn't tested.
<mark_weaver>efraim: also, that phase should return #t at the end
<ng0>vlc: autotools/test-driver in the source, line 107: "$@" >$log_file 2>&1 this can not be problematic for us?
<ng0>it's one of the last outputs before failure
<ng0>probbably not
<ng0>i'll be looking at vlc cvs to see if there's anything
<mark_weaver>thanks for working on it
<efraim>ok, fix made, i'll check it quickly and push it
<ng0>there's something on my todo list which fails 200 tests or more.. vlc is more joy^^
<ng0>dbacl
<koosha>mark_weaver: Well , there is no openssh service in GhuixSD
<koosha>*GuixSD
<ng0>but the client and the software itself
<ng0>it's only not there because no one wrote it yet
<ng0>guix build --keep-failed does not work with the vlc build it seems.. this makes it harder to look at the test outputs
<ng0>oh
<ng0> /tmp not /var/tmp
<ng0>okay, this is more helpful
<ng0>[0000000000604288] core libvlc warning: cannot read /tmp/guix-build-vlc-2.2.4.drv-0/vlc-2.2.4/src/.libs/vlc/plugins/plugins.dat: No such file or directory
<ng0>test_libvlc_equalizer: libvlc/equalizer.c:122: test_equalizer: Assertion `isnan(libvlc_audio_equalizer_get_amp_at_index (equalizer, u_bands))' failed.
<ng0>this file should have been generated by the Makefile, without looking at our package definition. i did not package vlc here, were there some previous errors in the process?
<ng0>okay it is documented.. i shall see what i can make of it
<mark_weaver>ng0: it could be a parallel build issue.
<ng0>i'll be testing it now, thanks
<koosha>mark_weaver: How do you use openssh while it's service is not in GuixSD ?
<ng0>i need to read through the whole new thread about reviewing etc which is going on at the moment.. vlc has this (https://wiki.videolan.org/Sending_Patches_VLC/) which also has a section "following your patch" "getting your patch merged" after the "sending it" and "checllist"
<ng0>this is not our core problem, but could be added to the docs maybe, something similar
<ng0>if not existing already
<ng0>mark_weaver: no, it is not a parallel-build problem. with it disabled it fails, but the number behind the fail is a different one
<civodul>efraim: barf, sorry!
<civodul>efraim: i'll fix it right away
<ng0>now i think i should locate what these high exit code numbers mean
<ng0>same failure in test-suite.log though
<ng0>without further talking i'll go think about it for a bit. for those interested, this is with and without parallel-build disabled: /tmp/guix-build-vlc-2.2.4.drv-0/vlc-2.2.4
<ng0>eh wrong url
<ng0> https://ptpb.pw/PMEO.log
<lfam>civodul: Already fixed :)
<civodul>lfam: perfect, thank you!
<civodul>lfam: i was going to do that gpg2 -> gpg change we discussed, then introduced that typo, and then forgot what it was i was doing
<civodul>getting back on track now ;-)
<lfam>civodul: I guess we set configure gnupg@2.1 to build the executables without the trailing '2' as well? I have that on an old Git branch
<lfam>s/set/should
<civodul>lfam: oh i thought you had done that already?
<lfam>Not yet :)
<civodul>ah no, my bad, sorry
<civodul>well yes, we should use --enable-gpg2-is-gpg or whatever it's called
<civodul>WDYT?
<civodul>sorry for the confusion!
<lfam>I was worried about the inconsistency with gnupg@2.0. But, now you've solved it :)
<civodul>cool :-)
<civodul>i seem to do a lot of mistakes these days
<civodul>time for vacation!
<ng0>the review process thread got long quick.. going through all the messages and selectively replying next week with thoughts i have
<efraim>libotf seems to be missing
<civodul>ng0: don't reply too much or we'll all drown ;-)
<lfam>Every reply to that thread requires one patch review reply ;)
<ng0>i need to reply to get some input which maybe gives me additional ideas to my longterm project.
<efraim>we packaged rdup 1.1.14 and fossies has 1.1.15
<lfam>I love the slogan of that project: "The only backup program that doesn't make backups!"
<ng0>so far i can say that Guix is not hard on QA if you compare to Gentoo QA or even getting something into Gentoo's upstream if you are not getting run over by some gentoo dev on the loose who dislikes communication.
<ng0>but our qa dance is just at the beginning and not set in stone the ways people can dance
<civodul>:-)
<ng0>it's a "good" thing i'm currently unfit for work, so i have much time to think and write about certain bigger thoughtprojects or discuss with people.. I have nothing I can put in a short summary so far, but I see failures in git as a system, but to improve something one has to engage in discussions and share ideas with other people.. Ideally it would be a framework for social coding which addresses some
<ng0>problems people behind git do not see and also implements or can plugin certain democratic functionalities and (hardest part for it all) solve the problem in how to keep code repositories available which are rarely accessed (let's say community forgets something exists for 10 years..). this is after or in parallel to the other thing I'm slowly getting to.
<ng0>it's bad that i do not know enough Scheme so far and put myself off, with the final moves i need to move last software from gentoo to guix and updating the ones i use use etc, from fixing the git service, go to the gnunet service, etc.. gnunet service is file based and easier than git. no idea why i picked something entirely different.
<ng0>and my work in progress list of packages has like 20 or 30 packages i think.