IRC channel logs

2015-06-09.log

back to list of logs

<ewemoa>does video.scm seem like a good place for arandr?
<paroneayea>hello, *!
<ewemoa>i'd like to understand how inputs, native-inputs, and friends differ -- is there documentation for these things?
<civodul>hello!
<civodul>ewemoa: yes, see "package Reference" in the manual
<civodul>in current git
<ewemoa>civodul: thanks -- does there happen to be a web-accessible version of that?
<civodul>no, i just update it for new releases
<civodul>but you can use "info -f ./doc/guix.info" for instance
<civodul>or "make doc/guix.html"
<ewemoa>civodul: thanks -- both of those tips worked fine :)
<civodul>yw!
<amz3>guile-json and gnu-tls are missing dependencies for the pypi importer
<civodul>missing in what sense?
<civodul>the manual does say that you need them for that :-)
<amz3>after installing them, it's ok
<amz3>Is it ok if I submit some package that are IMO required "all the time" flake8 (linter) and jedi (refactor tool used in elpy emacs package)
<civodul>amz3: of course! packages are always welcome
<phant0mas>Good morning civodul
<phant0mas>In patch I think it will be better to just declare PATH_MAX in lib/pathmax.h, that's what they suggest it in the comments of the same file anyway.
<phant0mas>second rpctrace just segfaults, and with gdb I get EXC_BAD_ACCESS, Could not access memory
<ewemoa>using icedtea7 on a guixsd 0.8.2 machine, getting errors trying to use ssl via a java program: https://pastee.org/kv62c -- any ideas?
<amz3>ewemoa: what does this error mean: «the trustAnchors parameter must be non-empty»
<amz3>it looks like a programming error
<ewemoa>amz3: search engines seem to suggest something about certificates -- the truth is i tried to use a program i know works elsewhere (leiningen) and it doesn't work for my local guixsd installation so i tried to find a minimal example
<amz3>hmm
<ewemoa>i get essentially the same error w/ https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein
<amz3>maybe the certificate are missing
<ewemoa>w/ the shebang modified
<amz3>Or more probably that icedtea can't find them
<ewemoa>that seems possible
<ewemoa>ah, i see rekado mentioned in java.scm...may be he would know something
<rekado_>do you have nss-certs installed and the various SSL_* env vars set?
<rekado_>the URL to the lein script uses curl, so that's unrelated to IcedTea6/7.
<ewemoa>rekado_: i didn't have nss-certs installed so i installed that -- set | grep SSL shows SSL_CERT_DIR and SSL_CERT_FILE set to /etc/ssl/certs and /etc/ssl/certs/ca-certificates.crt respectively now -- running the simple java program in the pastebin still gives the error about trustAnchors parameter must be non-empty
<iyzsong>there had someone talked about certificates-java issue with mark_weaver, IIRC it's just not packaged yet.
<rekado_>ewemoa: here it says that you need to pass an option at runtime to make Java find the certs: https://community.oracle.com/thread/1078314
<ewemoa>rekado_: thanks for the lead -- specifying -Djavax.net.ssl.trustStore=/etc/ssl/certs/ca-certificates.crt leads to a different error, so i'm looking into that now
<ewemoa>iyzsong: thanks for the info -- may be if that gets packaged, it will solve this difficulty...
<rekado_>I'm unaware of a discussion about anything relating to certs in Java that would require packaging. Do you have any link to the discussion? I only remember something about SSL certs in general.
<iyzsong>I don't know how to find the log, but I'm sure it's releated to this => https://packages.debian.org/stable/ca-certificates-java
<civodul>phant0mas: the GNU standards recommend against such arbitrary limits, so it's better to avoid them if we can
<civodul>s/so/and/
<paroneayea>hello, *!
<civodul>howdy, paroneayea!
<rekado_>hello!
<civodul>for the interested readers: https://hal.inria.fr/hal-01161771/en
<civodul>(don't advertise yet because it's been submitted and we don't have an answer)
<paroneayea>civodul: rekado: cool :)
<rekado_>davexunit: on two different systems I get an error when attempting to configure guix-web: "configure: error: newly created file is older than distributed files!"
<rekado_>I cannot find anything wrong with my system clock
<civodul>rekado_: see in 'configure' what it does exactly to determine that something's wrong
<davexunit>oh I've gotten that error
<davexunit>and been completely stumped by it
<phant0mas>civodul: understood :-)
<rekado_>davexunit: the configure script checks the output of "ls -t $srcdir/configure conftest.file"; in my case $srcdir happens to be "..", so there is no "configure" there, so the output of the command differs unexpectedly.
<rekado_>not sure why srcdir is ".." rather than ".", though.
<davexunit>me either
<davexunit>I certainly didn't tell it to do that
<davexunit>:/
<davexunit>what I have done wrong...
<rekado_>civodul: feedback from the bio-packaging mailing list: sending patches to the guix-devel mailing list is considered a barrier and they'd prefer to submit pull requests on Github.
<davexunit>rekado_: heh, well they aren't going to get that.
<davexunit>proprietary software aside, github's pull request system encourages bad patch sets.
<efraim>freebsd has some magic voodoo that takes github pull requests and turns them into tickets
<rekado_>I would not mind maintaining a clone on Github to screen pull requests and massage them into nice patch sets.
<davexunit>I'd rather not encourage that
<rekado_>it doesn't need to be anything official, you know.
<civodul>rekado_: if you're willing to do some triage on GitHub, that'd be great
<civodul>but yeah, i'm personally not going to invest in that
<civodul>and the main method will remain good ol' messages
<rekado_>I'd also much rather see more people adopt the patch-sending workflow, but I realise that there's many people out there who don't know how to contribute if something's not on Github.
<civodul>i'm afraid it also means they're not familiar with review processes, git rebase, etc.
<rekado_>*If* I *do* do this I'll make sure to add instructions on how to do it the right way.
<rekado_>civodul: this wouldn't be surprising to you if you had taken a look at a big chunk of bioinfo software... :-/
<Steap>civodul: hum, there are reviews on github :)
<civodul>having taken a look at other pieces of HPC software, i can imagine ;-)
*Steap nods
<civodul>Steap: i know, but...
<Steap>rekado_: and you use Python
<Steap>not C code that comes in with a Makefile.inc
<civodul>that rings a bell ;-)
*Steap remembers the fear in his eyes when speaking to some former colleagues
<civodul>:-)
<mark_weaver>iyzsong, ewemoa, amz3: we currently lack the machinery to create the CA certificate database that java expects.
<mark_weaver>in Debian and derivatives, this is handled by the ca-certificates-java package.
<mark_weaver>in Guix, it will probably have to be part of 'ca-certificate-bundle' in guix/profiles.scm.
<mark_weaver>(it's a profile hook, run to create extra files in profiles that result from a merging of potentially multiple packages in the profile)
<mark_weaver>profile hooks are used to create things such as the info 'dir' file, the single-file CA certificate bundle /etc/ssl/certs/ca-certificates.crt, etc.
<mark_weaver>one thing though: we must not add a requirement for a java implementation to create *any* profile.
<mark_weaver>users should have to install java unless they are really using it, so we'll have to be selective, maybe using a similar hack to what's done in 'ghc-package-cache-file'
<mark_weaver>someone other than me will have to do this job. I don't know Java.
<mark_weaver>rekado_: like davexunit, I think it's a bad idea for us to enable a development practice that depends on github proprietary software.
<mark_weaver>beyond the fact that we here don't want to deal with it, I would prefer to actively resist that way of doing things.
<Steap>Plus if someone cannot send an email, how good can their patches be ? :p
<mark_weaver>right
<Steap>Using git send-email seems so much easier than all that login/click sutff
<mark_weaver>we could perhaps set up some web interface for patch submission and review, as long as there's a way of participating that doesn't require using a major web browser.
<mark_weaver>and of course, it would have to be free software
*mark_weaver goes afk
<rekado_>Oddly, they seem to be okay with sending email (and I extracted my most recent contribution from an email to bio-packaging); I can only guess that it's the unfamiliarity with another approach + the perceived high barrier that keeps them from submitting a proper patch via email.
<amz3>rekado_: there is an opensource software that does Pull Request and is written in Python
<rekado_>Personally, I find sending patches via email so much more easy than using Github.
<davexunit>Steap: the github style review process is a bad one. I do github based reviews all the time.
<amz3>rekado_: https://kallithea-scm.org/
<davexunit>linus torvalds has a good rant (on a github pull request no less) about how bad it is
<rekado_>actually, I don't think we should bother with setting up any additional web interface for patch submission and reviews.
<Steap>davexunit: yeah, I use gerrit at work all the time
<rekado_>if I understand correctly, what they really want is "Github", not "a web interface".
<Steap>the nice thing about it is that it allows you to keep track of your opened patches easily
<davexunit>gerrit didn't seem very good when I looked at it.
<Steap>(and some people use it through emacs :p)
<davexunit>I'd like a patch review tool that had a nicer UI than a mailing list, but didn't make any assumptions about the version control system the project used
<davexunit>patches are patches.
<rekado_>I keep track of my patches by looking at the distance between master my branch in magit-log.
<davexunit>the workflow is 1) upload patch set 2) receive feedback 3) repeat
<Steap>yeah, I don't think gerrit can be used with anything else than git
<mark_weaver>rekado_: okay, well, it's a bad idea to develop a practice that depends on all the software one works on to be hosted on a single service based on proprietary software.
<rekado_>mark_weaver: agreed.
<Steap>now it is really cool to just run "git review"
<Steap>about as cool as running "git send-email"
<davexunit>that is cool
<rekado_>I'm not suggesting we maintain some "official" clone on Github.
<rekado_>I'm just forwarding a message :)
<davexunit>I'm just not sure that contributors that expect github and refuse to learn anything else are contributors that we want.
<mark_weaver>rekado_: understood, and I appreciate your efforts!
<rekado_>davexunit: while in general I would agree, I think that it would be nice if people who develop tools make the additional effort to write a package definition for Guix.
*mark_weaver really goes afk now...
<amz3>github is a no go, but I'm not sure why web Pull Requests are bad, it can lead to a lot of noise I understand that.
<davexunit>amz3: they discourage clean patch sets in favor of a base patch set plus a ton of "fixup" commits in response to feedback
<rekado_>davexunit: I mean, some people currently have .spec files in their public repos (and they have no idea where to send them to to have their package adopted by Fedora/CentOS/etc). I think we *do* want those contributions, even if they don't result in an increase of regular contributors.
<davexunit>of course, you can use git push --force to rewrite the history
<davexunit>but encouraging the use --force is scary
<davexunit>when we rebase branches in guix, we delete the remote branch first, then push the new version.
<paroneayea>hey grothoff, glad you got gnunet built
<davexunit>on github, doing that will close the pull request with no way to re-open it, as I found out last week.
<cehteh>some automatic itegration would be nice, build packages, run tests, await signatures from trusted people and then stage this up until it finally sinks into the distro
<paroneayea>grothoff: are you considering making a taler package, or using guix's environment tools for setting up a nice hacking environment for it? :)
<davexunit>github has built their tool to service the lowest common denominator: programmers who have no idea what they're doing.
*paroneayea just watched your talk
<paroneayea> http://taler.net/news the one here, that is
<davexunit> https://github.com/torvalds/linux/pull/17#issuecomment-5654674
<davexunit>linus saying how PRs are bad
<davexunit>"And the fact that other projects apparently have so low expectations of commit messages that these things get used is just sad. People should try to compare the quality of the kernel git logs with some other projects, and cry themselves to sleep."
<paroneayea>while I agree that github style pull requests don't encourage good commit style as much, https://github.com/torvalds/linux/pull/17#issuecomment-5659970 comments like that of linus' make me really mad
<paroneayea>that's no way to treat anyone, even if they're wrong.
<davexunit>polarizing, yes.
<paroneayea>it's also really cruel to just call someone "a moron" like that, especially someone who probably looks up to you
<paroneayea>I know I'd be really hurt
<rekado_>the comment he is responding to appears to have been deleted.
<davexunit>part of me goes "well that's rude", but another part is glad that he speaks honestly.
<rekado_>still, even if out of context, I think speaking honestly does not require insults.
<paroneayea>rekado: yes, I think that's true.
<davexunit>sure, but hey we don't need to sugarcoat everything either.
<paroneayea>I'd rather lean on the side of sugarcoating than straight out insults
<paroneayea>linus has told people they should have been aborted by their parents for making some commit mistake
<paroneayea>that's no way to run a community
<rekado_>I like the way it's done here. I don't think anyone is sugercoating criticism, yet I haven't seen any insults yet.
<davexunit>people take those comments too seriously.
<paroneayea>yes I think #guix is a friendly place
<davexunit>I of course wouldn't want that behavior here.
<davexunit>but I think people miss the massive exaggeration in those insults.
<paroneayea>I think it doesn't always feel like exaggeration when you're in the receiving end.
<paroneayea>at any rate, it's just not needed.
<paroneayea>but anyhow
<paroneayea>sorry to throw it so off topic of #guix :)
<davexunit>all good
<davexunit>I got this party started by posting that
<paroneayea>:)
<davexunit>knowing that it would likely cause thhis
<paroneayea>heh :)
*davexunit goes back to the nginx salt mines
<paroneayea>flow my tears, the salt miner said
<paroneayea>(an actual request, since they lost their tear ducts due to salt mining)
<davexunit>ouch
<efraim>guix refresh: error: mkstemp!: Permission denied any ideas?
<bavier>efraim: are you running refresh from a git clone?
<efraim>i am in the git clone directory, but I assumed it was targeting the installed version
<bavier>you wouldn't be able to modify the installed recipes
<efraim>that would explain the permission denied
<bavier>efraim: guixsd?
<efraim>binary tarball install
<efraim>/home/efraim/.config/guix/latest/gnu/packages/unrtf.scm:28:13: unrtf: updating from version 0.19.7 to version 0.21.9...
<efraim>the line before the error message
<mark_weaver>efraim: normally ~/.config/guix/latest points to a directory in /gnu/store, which is immutable.
<mark_weaver>efraim: 'guix refresh -u' is meant to be used within a git checkout directory.
<efraim>that would make more sense
<mark_weaver>linus is an asshole
<mark_weaver>and not a particular interesting one either. every once in a while I start to watch one of his talks, or a panel he's on, and am soon reminded of what it's a waste of my time.
<mark_weaver>s/what/why/
<mark_weaver>bah, too many typos
<efraim>I like Deb from mediagoblin's talks at conferences, and her point of "there's plenty of projects out there, find one with a nice community that overlaps with your interests"
<paroneayea>efraim: :)
<civodul>mark_weaver: looks like we'll need to rebuild core-updates: gcc's libbacktrace is built with -Werror, which unsurprisingly breaks in a libc header
*civodul is outraged to see that a growing part of GCC is BSD-licensed
<efraim>thats a bit absurd
<davexunit>civodul: what, how?
<davexunit>that's very alarming.
<civodul>it's code written by Intel (libofflaodmic, libcilkrts), Google (libbacktrace, bits of Go), etc.
<civodul>it's "only" runtime libraries, not the compiler itself
<civodul>i find it alarming nevertheless
<davexunit>copyleft feels more like a losing battle every day...
<civodul>some of these were maybe not specifically written for GCC
<civodul>but libbacktrace for instance was explicitly non-copyleft to help llvm: https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02095.html
<civodul>davexunit: call-with-clone should protect against THUNK
<civodul>like (dynamic-wind (const #t) thunk (lambda () (primitive-_exit 1)))
<civodul>otherwise the child process may end up executing weird things if THUNK throws
*civodul booted his first container \\o/
<davexunit>civodul: oh yes, good idea.
<davexunit>civodul: did you use my minimal config?
<civodul>i was a bit unsure whether running "run-container" as root was reasonable :-)
<civodul>i used gnu/system/install.scm
<civodul>which config do you use?
<davexunit>oh really? that booted? cool!
<davexunit>the one I posted on the ML
<civodul>well, it failed at console-tty*
<davexunit>civodul: okay, that's the one failure point.
<davexunit>I mean, things should be mostly alright
<davexunit>other services will run
<civodul>apparently it stop after all the services have been started
<davexunit>civodul: I haven't posted this yet because it's broken, but I have another guile script that allows one to spawn a process within the namespace
<civodul>ah ok
<davexunit>I was able to use it to launch bash
<civodul>yes, that's the bit i miss ;-)
<davexunit>unfortunately, setns(/proc/<pid>/ns/mnt) fails
<civodul>i guess mingetty cannot work, right?
<civodul>oh
<davexunit>I'm not sure of the details of that
<davexunit>ttys are still confusing to me
<davexunit>enlightenment needed :)
<civodul>well i'm not sure what's supposed to happen
<civodul>depends on if the tty nodes are bind-mounted
<civodul>dunno
<davexunit>I bind mounted /dev/tty
<davexunit>I'm still trying to figure all that out
<civodul>ok, so i would guess the two mingettys would be competing
<paroneayea>tty later
<civodul>:-)
<paroneayea>sorry :)
<davexunit>because we *can* make device nodes currently, but we won't be able to once we use user namespaces.
<davexunit>which I'm not sure is even feasible.
<davexunit>things are still very cloudy in that regard.
<civodul>we would need fewer things for "guix environment --container", no?
<civodul>just a bunch of bind-mounts for /dev, /gnu/store, and some user dir?
<davexunit>civodul: yeah
<davexunit>we can do with less there.
***tschwing_ is now known as tschwinge
<davexunit>gotta run though!
<davexunit>would like to discuss this more another time!
<civodul>oops
<civodul>i have a dozen of containers running now
*paroneayea reads backlog
<paroneayea>wow!
<paroneayea>it looks like the container stuff is really coming along
<civodul>yes, definitely
<civodul>very cool
<civodul>and fun :-)
<ewemoa>mark_weaver: thanks for the clarification -- i see that there is some related discussion at https://gnunet.org/bot/log/guix/2015-05-20