<OriansJ`>bavier`: perhaps a more important perspective is not the number of packages per given programming language but rather can we deliver consistently high quality. Ideally to the level required for other people/groups to use our work as a solid foundation.
<pkill9>the article that's cited regarding Guix not being able to handle npm packages was published May 2015, dunno if things have changed since then, I know there's an importer for npm packages
<rekado>pkill9: that importer is not part of Guix.
<OriansJ`>Survival is the metric of concern not victory, as in the seeds of success lay the roots of its destruction.
<rekado>pkill9: and it has similar problems as the import solution for Nix. But that’s really an npm problem.
<pkill9>yeah i think the NPM ecosystem being an unmaintainable forest of dependencies is their fault :P
<OriansJ`>pkill9: the big problem with npm is that entire ecosystem has little regard for engineered build processes, copyright or binary dependencies
<pkill9>it sounds like an accident waiting to happen
<OriansJ`>pkill9: it already had major security incidents
<pkill9>what even is node used for that can't be done in something like python, maybe with a little more effort
<OriansJ`>nothing says $25K salary bump in silicon valley like a 5 minute tutorial about a beta level quality program that makes absurd claims
<OriansJ`>Where developers don't even use databases that ensure the integrity of the data put into them
<OriansJ`>Where millions of dollars of developer time and effort are wasted on meaningless projects to produce a "cutting edge solution" to a long solved problem, only to do it worse with an order of magnitude more wasted resources and human effort
<OriansJ`>Where the solution to a slightly messy but perfectly functional program written in Java that was the product of 7 years of development and tens of millions of developers of work; is to throw the entire thing away and start again from scratch because there is no other way to justify their .....
<vagrantc>OriansJ`: sometimes, i really feel at home here in #guix
<OriansJ`>vagrantc: agreed, I really appreciate the people here are thoughtful, considerate and actually care about doing the right thing.
***Guest97367 is now known as nkaretnikov
<atw>I'd like to report a bug for this https://paste.debian.net/1012487/ emacs crash that I'm seeing, but I think I need more information about the problem. How can I find the derivation, build log, etc of the bad emacs?
<OriansJ`>atw: the unique derivation is found by doing ls -hal $(which emacs)
<OriansJ`>Where you should see /gnu/store/bk22dmj4x23h71pvpj1ndj5xdsm3mgdj-emacs-25.3/bin/emacs or something similiar.
<atw>OriansJ`: that will turn up false positives if I have many builds of emacs, right?
<OriansJ`>atw: that will turn up all of the .drv files related to emacs. Which if you need a quick way for pin-pointing which goes to which grep bk22dmj4x23h71pvpj1ndj5xdsm3mgdj $(find /gnu/ -iname '*.drv' | grep emacs) will show you the .drv that has the out which is bk22dmj4x23h71pvpj1ndj5xdsm3mgdj which was the piece that the first command I posted showed you
<atw>thanks OriansJ`, really appreciate the help :) My current plan is to post on help-guix with the .drv attached. Is there anything else I should include?
<OriansJ`>atw: you might wish to include the last version that you know was without the issue to reduce the time it takes to track down the issue, provide tests if possible and we should be able to collectively solve your problem
<atw>I have a profile generation where I know emacs works, and therefore the good-emacs store path and derivation. I can include that too. What's weird is I've been unable to correlate the failures I'm seeing with a change to the emacs package
<OriansJ`>atw: there is always a possibility emacs is simply manifesting a side effect of a change in one of its dependencies. Hence narrowing of the search space is essential.
<atw>True. glibc appears in the stacktrace but I don't see indicative changes to glibc.scm either
<OriansJ`>atw: it could be a code change that is causing the issue and the fix will have to be done upstream
<rekado_>wish list for ant-build-system: 1) a way to specify manifest changes; 2) some way to edit build.xml files more conveniently.
<rekado_>substitute* is nice, but not great for xml files.
<civodul>rekado_: perhaps sxml + sxml-match would help?
<rekado_>civodul: I’m using pre-post-order from (sxml transform), but it’s very verbose.
<rekado_>better than sxml-match, though, which is sensitive to ordering.
<rekado_>I’d like a wrapper around pre-post-order that does the right thing by default (e.g. wrt *text* and *default* handlers), that operates directly on “build.xml” (i.e. reads it, writes the modified version, and atomically swaps out the original), and that has sxpath support.
<nckx>...that said, you'll have to learn yet another thing: manual user/group management (using groupadd, useradd) is not going to end well. Use users and groups in your operating system configuration file instead.
<g_bor>I've ran a few tests on this java-jeromq issue. It seems that the fix really resolves the problem rekado reported. However we still have a regression that is inherited from 0.4.2, I'm now trying to identify which tests to disable to have a reasonably stable build.
<roptat>do replacements always have to be private?
<budric[m]>hi, has anyone run guix under gentoo? I get errors when trying to search/install packages on version 0.14.0 "guix/ui.scm:1452:12: In procedure setvbuf: Wrong type argument in position 1 (expecting port that supports 'setvbuf'):"