<ng0>I think I know how I can do this. but I'm still open to suggestions before I do it. the service will come with the 0.11 release of gnunet anyway, because there's some guix specific issues to solve
<roptat>although this is the runpath of libsnappy.so: /gnu/store/4amdzkqix0grksrgw3h5wcv2azvz6pkd-snappy-1.1.7/lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..
<roptat>that may be it though: icedtea has gcc-4.9 as a native-input
<civodul>roptat: i'm not sure that's a reasonable approach: Scala is a complex language with some features not found in Java, like case classes
<g_bor>rekado_: Is there any reason, why icedtea has gcc-4.9 as native-input?
<g_bor[m]>I feel sometimes guix package -s output ordering is problematic...
<g_bor[m]>One thing I noticed is that when searching for python I get all python packages as relevance 10. It would be nice to have packages with exactly matching names ordered first.
<g_bor[m]>Another thing that would be nice, is if we have a matching variable defined, then bring it to the to of the version list, and maybe add (default), or something like this to title, so when searching for example for gcc, or icedtea we could see the default version. WDYT?
<roptat>civodul: I don't know, it looks easier than writting a scala compiler
<roptat>I don't exactly understand how case classes are compiled for instance, but it gets compiled somehow, so we can probably transform the AST to have something that's compatible with java
<roptat>actually using older versions of scala is not a solution
<roptat>there are hundreds of versions we would need and I think at some point there are missing versions
<jlicht>roptat: just like the rust bootstrap (if the C++ rust compiler project did not exist)
<roptat>so what would be the best approach? I think a complete scala compiler is harder than a transpiler to java
<civodul>g_bor[m]: i found a simple trick to give a higher relevance score for exact matches in 'guix package -s'
<roptat>and, how do I make sure libsnappy.so uses gcc5's libstdc++?
<g_bor[m]>roptat: I tend to agree. I was thinking about building a tool filter out the unnecessary version from this kind of chain, something like to bootstrap using two different versions, and try until the result is the same. I think that your approach might be the best. At least you just have to write only one half of the compiler.
<rekado_>g_bor: due to a bug in the patches to GCC an internal compiler error was triggered. The cause was not known at that time.
<rekado_>g_bor: you are welcome to revert that change if you can work around that compiler segfault. (There’s a bug report to track this problem.)
<g_bor[m]>civodul: Thanks, that would be so nice :)
<g_bor[m]>rekado_: Ok, I guess I remember that, it was that give an initializer to statics...
<civodul>g_bor[m]: actually, in all modesty ;-), i think the relevance code is quite fun
<g_bor[m]>roptat: Do you think, that the snappy problem would be solved if we switched icedtea to gcc-5?
<g_bor[m]>I'm in the final of changing the default jdk to java8. I've returned to a problem I had earlier, it can be tracked easily, but if there is a better idea, I'd like to hear that. I would like to add ant-junit to native-inputs of all packages using ant-build-system, and having junit as native input. My current approach is to add it manually. Two solutions I thought about was to add it to ant-build-system, that result in adding it
<g_bor[m]>to packages not using junit at all, and to propagate from junit, but that adds it even if we don't use ant-build-system. In the perspective of having maven, and soon gradle, I don't like this either. WDYT?
<rekado_>Is the concept of a native input applicable for Java?
<rekado_>if you were to cross compile, you’d run the tests for the target platform, right?
<rekado_>So I guess it should just be a regular input.
<rekado_>is it a *problem* to add the package only where needed?
<rekado_>the ant-build-system is a very low-level build system, and I hoped that it would not become popular
<rekado_>with maven packaged, I’d suggest putting more effort into a maven-build-system
<g_bor[m]>rekado_: Actually it seems, that input and native input are used as synonyms in ant build system. Once we have a maven build system, we can start switching packages to that. I guess that it makes sense then to stick to the manual method in the transition.
<efraim>Back in my day your computer could time out while grafting texlive
<pmikkelsen>Is anyone in here using emacs-use-package? There seems to be a problem with the source tarball we are using, as it only contains four files, where the current master tarball from github has alot more.
<pmikkelsen>The package gives me errors in emacs, but I have tried to use the current source and rebuild the package, and now it works.
<nckx>efraim: That doesn't sound right if 31.xxx is the one seen by outside services. I can't ping 100.xxx (also, that netmask...)
<efraim>zebra.flashner.co.il points to flashner.duckdns.org which says my IP is 100.82.54.47
<nckx>But is it correct? It's easy to have your dyndns client poll your router, get the wrong IP somehow, and push it to duckdns.org, for example.
<g_bor[m]>should I do this java8 switch on staging?
<nckx>Just saying I can't ping the thing or connect to ports 80 or 22 (that's no proof of anything, of course, but unusual).
<efraim>nckx: it should respond at 12345, 12346, 52522 and probably 80
<g_bor[m]>Or should I wait for the staging merge? My problem is that it is hard to notice breakage currently, and the ant-build-system fixes are on staging.
<nckx>efraim: Hmm... it turns out that neither seems to respond to a simple netcat or curl. Firewall? Anyway, I'm still positive that 31.xxx is the right IP if either of those is correct. At least it exists.
<nckx>If you have a VPS, you should be able to confirm.
<thomassgn>as a learning exercise I'm going to create a program that I can use to check for updates to remote files, battery status and then react to them. Looking at guile + 8sync. I realize this is quite similar to shepherd - so the question is: does shepard have the possibility of timed restarts and reactions; or would that be the job of the daemons shepard manages? What I'm looking at is maybe closer to cfengine,
<thomassgn>though I don't know either of them very well.
<jlicht>thomassgn: Could you possibly give an example of what you want to do?
<civodul>rekado_: BTW, could you reconfigure a couple of build machines with the qemu-binfmt-service for arm, aarch64, and maybe mips64el?
<rekado_>it’s much less hairy than yours, I’m sure :)
<thomassgn>jlicht: say, check battery level every 15 min. if less than 20% display notice on screen. Or check for new commits in remote git repo. if newer - pull and build. Or check local file exists, if not regenerate it. Stuff like that.
<ng0>I fell into the elixir pot recently. I think we can have a gnusocial/mastodon/pleroma server in guix without depending on nodejs with this. so the pleroma devs told me, about pleroma
<ng0>I hope we can get rid of this before 0.11 for Guix: Jun 29 20:29:45-584202 hostlist-8357 WARNING Download of hostlist from `http://v10.gnunet.org/hostlist' failed: `Peer certificate cannot be authenticated with given CA certificates'
<rekado_>ACTION is happy that in Emacs 26.1 M-x shell no longer leaks memory when running “guix build”.
<ng0>the development snapshot release works though.. passes the whole testsuite (which is why it was released in the first place), but I think due to it being a development release we could not include it?