<ewemoa>does video.scm seem like a good place for arandr? <ewemoa>i'd like to understand how inputs, native-inputs, and friends differ -- is there documentation for these things? <civodul>ewemoa: yes, see "package Reference" in the manual <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 <ewemoa>civodul: thanks -- both of those tips worked fine :) <amz3>guile-json and gnu-tls are missing dependencies for the pypi importer <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>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 <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>maybe the certificate are missing <amz3>Or more probably that icedtea can't find them <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. <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. <civodul>phant0mas: the GNU standards recommend against such arbitrary limits, so it's better to avoid them if we can <civodul>(don't advertise yet because it's been submitted and we don't have an answer) <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 <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. <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. <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>not C code that comes in with a Makefile.inc *Steap remembers the fear in his eyes when speaking to some former colleagues <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 <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. <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. <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 <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. <Steap>now it is really cool to just run "git review" <Steap>about as cool as running "git send-email" <rekado_>I'm not suggesting we maintain some "official" clone on Github. <davexunit>I'm just not sure that contributors that expect github and refuse to learn anything else are contributors that we want. <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>when we rebase branches in guix, we delete the remote branch first, then push the new version. <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 <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>that's no way to treat anyone, even if they're wrong. <paroneayea>it's also really cruel to just call someone "a moron" like that, especially someone who probably looks up to you <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. <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 <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>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. *davexunit goes back to the nginx salt mines <paroneayea>(an actual request, since they lost their tear ducts due to salt mining) <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 <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. <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. <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" <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 <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 <davexunit>copyleft feels more like a losing battle every day... <civodul>some of these were maybe not specifically written for GCC <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/ <civodul>i was a bit unsure whether running "run-container" as root was reasonable :-) <davexunit>civodul: okay, that's the one failure point. <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 <davexunit>unfortunately, setns(/proc/<pid>/ns/mnt) fails <civodul>i guess mingetty cannot work, right? <civodul>well i'm not sure what's supposed to happen <civodul>depends on if the tty nodes are bind-mounted <civodul>ok, so i would guess the two mingettys would be competing <davexunit>because we *can* make device nodes currently, but we won't be able to once we use user namespaces. <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? ***tschwing_ is now known as tschwinge
<davexunit>would like to discuss this more another time! <civodul>i have a dozen of containers running now *paroneayea reads backlog <paroneayea>it looks like the container stuff is really coming along