***catonano_ is now known as catonano
<g_bor>guix.info/manual returns me 403 forbidden. Is this ok? <rekado>you can access the English manual at guix.info/manual/en <rekado>and the French one at guix.info/manual/fr <g_bor>actually I came about it through the link on the help section. <rekado>right, that’s discussed on the bug report. <rekado>“guix system reconfigure” with an old daemon is awfully quiet since the merge of wip-ui. <rekado>I think it might be waiting for an ongoing build. That message is swallowed, though. <nly>guix would be great for declaring research paper references <nly>It's nice to jump around in guix package sources using M-. and M-, I was imagining a similar thing for research paper references. <nly>Maybe emacs-guix like interface <nly>Also, the transparent reference/dependency(?) graphs would help in understanding the assumptions. <roptat>civodul: I thought the gcc bug we had was fixed? <roptat>I could use gcc-8 to compile openjdk9, but gcc-8 doesn't build openjdk10 (it warns about an impossible branch and fails on warnings) <roptat>or maybe I'm running out of memory <civodul>roptat: the bug in the strmov patch is fixed only on core-updates <civodul>it took me a while to find out, which is a bad sign i guess... <civodul>but there are ways to work around that gcc@5 segfault <g_bor>civoudl: speaking of that, when do we expect a core-updates merge? <civodul>g_bor: i was about to ask as well :-) <roptat>ah then I'll try to switch to core-updates and build openjdk <civodul>roptat: sounds like a good idea, especially since core-updates is getting ready for merging <roptat>of course I'm rebuilding the full java bootstrap <efraim>Speaking of Java bootstrap, I think aarch64 will have to go icedtea@1-armhf -> icedtea@2-aarch64 <nly>What is the guix equivalent of nixos-install? <nly>Can I install guix on top of my current distro with `guix system init conf.scm /`? <roptat>nly: guix system init installs GuixSd (the distro) in place of your current distro <roptat>you should still be able to boot your old distro, but you'll have to carefully add the menuentry to your config <roptat>otherwise, booting your distro and using guix (the package manager) on top is better I think <nly>roptat: thanks, I read about it somewhere & it seems to work for a few people. I think I will give it a try. I may wipe the old distro(nixos) completely to save space. <nly>*I read that people install usual linux distros over old installations not functional distros <rekado>I’m going to remove the rapicorn package, because a) it cannot be built without heavy patching, b) it segfaults when built, and c) it’s no longer needed by the latest version of Beast. <rekado>oh no! “beast” will depend on npm in the future :( <rekado>it’s a synthesizer and composition environment <rekado>it used to have Guile support, but instead of upgrading to Guile 2 they dropped it :( <rekado>according to the project website they want to replace the existing GTK user interface with an Electron interface. <pkill9>why would they shoot themselves in the foot like that <rekado>I think it can make sense for people who are unaware of the problems. <janneke>tbf, i fell for it two years ago -- very hard to get off that train <rekado>I get the appeal of having a user interface that feels less constricted. <janneke>node+npm looks really great, if you don't consider bootstrappability or reproducibility <janneke>...or a language that has somewhat predictable results :-/ <civodul>it's terrible in many ways, but it's probably the language with the largest user base, which in itself makes it attractive <civodul>fortunately we kinda live in a parallel universe ;-) <roptat>is there really nothing we can do for npm? <roptat>we somehow managed to get maven and co, how much harder is npm? <janneke>right, the large user base is what makes it very attractive <janneke>it's easy to fall for let's also board that train, "all those people can't be wrong" :-) <janneke>the common npm build systems have 5,000-10,000 dependencies, with cycles, and about 200 packages that have no license <janneke>iow, the biggest problem is not technical, imo, it's a culture/awareness thing <demotri>I noticed that the node/npm-importer from Jelle isn't integrated into Guix. What's the status of it? <janneke>and it works pretty well, if you can find a repository with packages that do not have missing source dependencies or cyclic dependencies <demotri>janneke: So why isn't it part of main Guix? <janneke>npm packages cannot be bootstrapped from source; the npm way of building a package "from source" is to install all its dependencies in binary form <janneke>that's prolly how all the cyclic dependencies came to pass <demotri>janneke: Yes, I also see this more a social problem than being a technical one. All people I met either didn't care or were totally scared. <janneke>demotri: jlicht gave up, i did a streak and gave up, no-one reviewed or made the effort to put it in <janneke>i championed the idea of allowing binary npm package builds, which was a terrible idea <janneke>anyone's free to continue work on it <demotri>janneke: I see. I have other things that are more important to me, and so it is probably for most of us. <janneke>i did get good support and some good reviews on my work and the conclusion was: this can't go in as is <janneke>i needed this for a client of mine, since then i have been working to steer them away from node and towards guile <roptat>pulling in binary dependencies... that's also how maven works <roptat>if we have a package for the dependencies of an npm package, is there a way to give them to npm? <janneke>roptat: the problem is in the cycles -- can't build one binary package without the other <janneke>and in the sheer magnitude of dependencies <roptat>hm.. can we build a union of packages to try and break cycles? <janneke>of course it can be done -- it /was/ done in the past <roptat>if A depends on B and B on A, we can build AB and then have both A and B depend in AB <janneke>i'm sure we could take this forward, if we find someone who wants to do the work <roptat>that's very close to some of the things I've seen in Java <janneke>it's obvious when you see it, it was a new idea for me :-) <roptat>I'm starting to get interested in the javascript world <nly>That sounds v cool roptat <roptat>so maybe at some point I'll help :) <janneke>nice, i may create a blog post about my npm experiences <janneke>civodul: i'm working to inspire Rutger to start working on Gash and come to R+B <janneke>he has been creating some magnificent patches for Guile PEG and wants to have them done before revisiting Gash work <janneke>he wrote an `expect' syntax to stop back-tracking and get sensible error messages on syntax errors, and a whitespace skip helper <ecbrown>hi all, is it possible to have postgresql with ssl support? <lfam>ecbrown: Probably! Do you know what's missing? <ecbrown>i would reckon openssl and the requisite flag. <ecbrown>sorry, my question is more in haste, whether there is a variant that i am missing rather than whether it could be included in and scm file <lfam>ecbrown: No, I don't think there is another variant with OpenSSL <ecbrown>ok, thanks. perhaps i can submit a patch sooner than later <ng0>efraim: I did not test it on my desktop computer (dvd drive) yet, but mplayer with libdvdread in inputs compiles without complaining about java and on my laptop when I run a command which would lead to libdvdread being used I get a message from libdvdread (showing functionality and complaining about the drive I don't have not being found) <ng0>so in short, it works. <ng0>testing it in the next days on the desktop computer and then i'll send a patch <ng0>I have to package Buildbot, picked up my old package last night. I discovered some build and test failures in python packages and I have to re-package/re-distribute a dependency of a dependency. If I send this before end of October in an acceptable and tested form, can we get this merged until end of October? It is required for the Taler server and I don't want to just pull in a repository of mine when it can <ng0>i know we can get no priority treatment, but having it in Guix would make the migration more smooth. If I/we can manage it, there'll even be a system-service coming with it <ng0>so far I guesstimate around 10-15 patches depending on how much broken I still discover. there's 2 big packages in its 2nd level dependencies. <ng0>i'll be back, mention me in replies so that I can filter hte backlog easier. ***Timotheus_Canens is now known as Guest36063
<civodul>i think you have experience with Knot and all that, no? :-) <rekado>civodul: looks like grafts are not displayed as “grafting” but as “building”. <civodul>rekado: yes, that's expected, to me at least ;-) <civodul>do you think we should special-case them somehow? <rekado>has this always been like this, though? <rekado>I thought we used to show “grafting” messages <civodul>i think it was this way before the (guix status) merge <civodul>apparrently the former build-output-port in (guix ui) didn't special-case grafts <civodul>and before that we'd display everything <civodul>that including "grafting ..." messages <rekado>but … didn’t we show messages like “grafting /gnu/store/123-foo to /gnu/store/987-foo”? <civodul>yes, but just like any other message coming from the build log <civodul>if you use 'guix build' you still see them i guess <civodul>we could special-case them if you think it's useful <rekado>how do we know something is a graft derivation? <civodul>so we'd have to play tricks, like another "@" trace <ng0>about my messages earlier: I can work on this without getrting it directly into guix, but will send patches once it all works. keeping the work on this in a repo. Also: Because Taler packaging buildbot took priority, I am not sure if I can work on returning the logs on gnunet.org next month.