<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 realization that a dozen lines of html, 3lines of CSS and 100 lines of PHP are replaced by a 4 million line javascript code base that only works on the latest version of chrome. <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`: I'm looking for the .drv <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 <atw>I'm gonna try gdb real quick... <atw>Furthermore, I observe one other GTK app crashing. Emailing help-guix now... <g_bor>I wonder if we have been contacted by outreachy applicants already? <g_bor>If so, could you also point me where these contacts are. <civodul>g_bor: rekado_ & i were contacted by one person at least <rekado_>someone else contacted me yesterday. <rekado_>they will contact the mentors directly; after passing the eligibility test the contact info of the mentors is revealed to them. <rekado_>civodul: I’d like to get the glibc graft into master <rekado_>civodul: the official way of passing a configure option would have some unexpected side-effects (disabled features). This may not be the right thing to do for the patched RHEL kernels. <efraim>after running make: gnu/build/linux-modules.scm:206:13: warning: possibly unbound variable `load-linux-module/fd' <civodul>efraim: that's expected; maybe we shouldn't compile that module <civodul>no prospects of other options i suppose? <efraim>the #:log-file for the openntpd service worked <civodul>rekado_: one part of me wants to say "these people should upgrade to a decently recent kernel", and the other part just doesn't want that to be a problem <civodul>you confirm that programs work well with the patch, right? <rekado_>I’ve been running it for about 1.5 weeks now <rekado_>there’s one thing that’s worrying: guile spits out a GC warning related to pthreads. <rekado_>but on the other hand all software we ran so far didn’t abort with “FATAL: kernel too old” <rekado_>another weird thing is the behaviour of “guix environment -l” (without “--ad-hoc”). <rekado_>for some reason we end up with an ungrafted glibc, so people using “guix environment -l my-env.scm” on the cluster get spurious “FATAL: kernel too old” errors. <rekado_>(e.g. when R runs ldd, which is provided by our glibc package in the environment) <rekado_>I wrote email to guix-devel about this <rekado_>but these two things are the only problems, and I prefer having those than having “FATAL: kernel too old” for every application running on the cluster. <rekado_>the grafted glibc shouldn’t have any negative effects on anything else. <efraim>oh I forgot I pushed the libunistring update to core-updates <rekado_>civodul: the thing about a “decently recent kernel” is: they *have* upgraded to a new kernel! <rekado_>the patched 2.6.32 is nothing like the stock 2.6.32. The RHEL kernels are heavily patched and still supported until 2020. <rekado_>So the problem won’t disappear any time soon, I’m afraid. <rekado_>I just wonder if until 2020 the kernel version string will increase; because that would be bad and invalidate the glibc patch which is tied to this particular version. <civodul>problem is, if we use our patched glibc on a "real" 2.6.32 kernel, it might not work, no? <rekado_>but from what I understand they’ll stick with 2.6.32 until the end of the 6.x series. <rekado_>yes, it probably wouldn’t work right on a stock 2.6.32 kernel. <rekado_>but a 2.6 kernel is no longer supported anyway <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. <rekado_>with pre-post-order you can only match on tag symbols, but I’d prefer to match on xpaths. <pkill9>where do i send patches for package definitions? <nckx>pkill9: Just don't git send-email 10 patches to that address and you'll be fine. <orelozno1>Hello :) I am an end user of debian and since a few days of GuixSD that I installed successfully \\o/ and I would like to use libvirt <orelozno1>This morning, I tried to add the group 'libvirt' to the system, for the purpose of initiation in my gnome user session. <orelozno1>~# groupadd --system libvirt (this command seems to have worked) <orelozno1>But the next step fails: Inspired by the manual, I typed the following bash command including the shadow command line mode: <orelozno1>~# for i in `seq -w 1 10`;[Enter] do[Enter] useradd -g libvirt -G libvirt;[Enter] -d /var/empty -s `which nologin`;[Enter] -c "Guix build user $i" --system;[Enter] guixbuilder$i;[Enter] done[Enter] <orelozno1>-bash: -d: command not found. Bottom line: bash: -c: command not found. Bottom line: -bash: guixbuilder10: command not found <orelozno1>As a user / explorer, I have no idea what I should do ... <nckx>orelozno1: Ermm... I'm not quite sure what you're trying to do there. <nckx>orelozno1: Am I correct in assuming you pasted that into a terminal without really knowing what it does? [No offence intended...] <efraim>are you trying to add your guixbuilders to the libvirt group? <nckx>Are you trying to add your libvirt user to the libvirt group? <orelozno1>nckx: you are right, in the same time i think to understand a few :) <orelozno1>efraim: yes, i want install it to use in user session <nckx>If so, all you need is ‘useradd -g libvirt -G libvirt’, all the rest is code to create 10 of something which you definitely don't want. <nckx>orelozno1 (to efraim): Right, but I don't think you actually want to do that. Unless you're doing some advanced sorcery that I don't understand. <efraim>i think you want something like `usermod -a -G libvirt guixbuilder{01,02,..,10} <nckx>Yeah, I don't think that's actually what they're trying to do... <efraim>i think you might want the kvm group for kvm features, not libvirt <rekado_>but why should guixbuilder be in that group? <nckx>orelozno1: what exactly are you trying to do in the for-loop you pasted above? I think we're all making assumptions that might not be correct. <orelozno1>nckx: i am allright, i just try to get use of libvirt and qemu <nckx>OK, good luck :-) Please don't hesitate to post any questions/problems, since I *think* libvirt might have some rough edges on Guix. Throwing a foreign distro into the mix won't help. <orelozno1>I'm a very happy user of GuixSD, thank you very much for all the work <nckx>Ah, I misread that bit. No Debian no more. Welcome to GuixSD :-) <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. <orelozno1>nckx: ok I will consider these recommendations <bavier`>OriansJ`, civodul: thanks for sharing your thoughts on the article I linked. I had mostly the same reactions. <bavier`>while I really like our importers, and batch/recursive importers I think would be really great, I think providing a solid foundation is really important <civodul>bavier`: right, although that's the argument many (Fedora, Flatpak, etc.) use to justify a core/application split <civodul>essentially, traditional distros would provide the "core" (aka. the boring low-level stuff), and the remainder would come from a bundle jungle or similar <nckx>ACTION remembers ‘bundle jungle’. <htgoebel>I have a patch (30654) which this causes 600 rebuilds. Danny adviced to "take care not to overload Hydra." <htgoebel>How do I? Should I commit this patch to core-updates? <htgoebel>(I know the HACKING guide requres core-update starting at 1300 rebuilds only.) <rekado_>htgoebel: we also have a staging branch, but I don’t know its current status. <ajjlmau>can I install shepherd on other distributions? <rekado_>ajjlmau: yes, but you probably wouldn’t use it as PID 1. <nckx>htgoebel: I think the mbakke/lfam staging cabal want to merge the current one soon. Can it wait for the next staging iteration? <htgoebel>rekado_: Looks like last time staging was merged into master was 2017-10-10 - 4 month ago?! <mbakke>I see Hydra is available, so I'll merge and start a new evaluation shortly. <htgoebel>nckx: If staging is merges soon, this is a good chance to get my patch in. Why wait for the next staging iteration? <mbakke>htgoebel: Yes, the previous core-updates round took a while longer than usual. <htgoebel>mbakke: Please wait a few minutes, I'l push my patch to staging then. <mbakke>We've already built most of staging. <nckx>htgoebel: Hm? If staging is almost built, it won't save time.... <mbakke>If it fits within the dependency closure of json-glib, go for it :P <nckx>mbakke: staging built manually, rite? <htgoebel>I have a patch (30654) which this causes 600 rebuilds. Danny adviced to "take care not to overload Hydra." So where should I commit it to? <mbakke>nckx: Someone has a push a button in Hydra, just like with 'master'. <nckx>mbakke: OK, all is as I thought then. :-) <mbakke>So, pushing a patch with 600 rebuilds now would nullify a lot of the already built staging substitutes. <mbakke>We should probably be more vocal about when a branch is "open" or "bugfix-only". <dustyweb>since Golly is a leaf package and it never had a correct url and thus never built <dustyweb>ok to just push that single commit to master? <nckx>dustyweb: master is fine. <htgoebel>mbakke: To be frank: I don't care about these details. I just want to get rid of the (approved) patch. <htgoebel>Normally I would simply push to maser since 600 < 1300. <mbakke>htgoebel: I think the limit for master is 300, not 1300 :) <nckx>...anyway: is there anything wiki-like under Guix control? Otherwise we could make a simple status tracking page for both branches. <nckx>staging: hold your patches, core-updates: open; nothing complicated. <bavier`>civodul: good point, that kind of split doesn't seems sustainable either <htgoebel>mbakke: Hmm, maybe. I thought the limit is stated in HACKING, but it not. <htgoebel>Anyway: Where should I commit my patch to? <mbakke>htgoebel: I'm afraid you'll have to sit on it until the next staging round. <nckx>htgoebel: staging is for > 300 rebuilds, so by definition master is <= 300. <mbakke>The current branch will be merged in maybe two days, after which a new one can be made. <htgoebel>Related: Am I right that staging as merged into master last on 2017-10-10? <mbakke>All the work went into core-updates after that. <htgoebel>Do all iterations of staging take so long (4 months)? <rekado_>no. It was just not used for a while. <rekado_>staging is usually merged more often — when we’re actually using it. <g_bor>rekado_: I've received some mail from the outreachy mentors' mailing list. Do you also receive those, or should I forward those to you? <rekado_>g_bor: but I found none of the messages to be in need of my response. Many of them are really directed at the organizers. <mbakke>In the future, I think we should continue doing staging in parallel with core-updates, in case there are holdups. <demotri>Actually, I stumbled in docs upon staging and already thought it is dead and docs needs to be updated, until the last core-updates merge set focus on staging again. <demotri>I think the whole branches/continous integration topic is not clear, even for people following Guix longer. <nckx>‘Sourceforge project sites are currently under maintenance. Please check back later. We thank you for your patience.’ <nckx>At least they have the decency to double-space. <nckx>See? Single points of failure are bad! Let's all move to GitHub. <nckx>Which hydra is hydra.? Obviously not the one in Guix. <nckx>...which is approaching its one-year breakaversary. Oh dear. <bavier`>nckx: yeah... that package needs help <nckx>I'm guessing the current deployment is... ironically stateful. <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? <roptat>there is a patch for gd that fixes a CVE <roptat>but the patched version is required by php to pass its tests <roptat>do I need to duplicate the replacement (gd-for-php)? <efraim>php so its probably OK to just patch it <roptat>efraim: don't I need to fix gd (gd/fixed)? ***Digitteknohippie is now known as Digit
<efraim>I haven't looked at it, I'm actually on my phone atm <nckx>Now let's just push my R package updates to ma— oh. <roptat>efraim: ok, I'll push the php update <rekado_>nckx: I’m using “guix refresh -t cran,bioconductor -u” for that, but with an extra change that also imports the package anew and compares the sets of inputs. <nckx>Oh. I'm using... curl and, er, emacs. I must learn to trust and love the importer again. <nckx>Got burned by pushing one invalid source URI too many, but that problem might be limited to cpan. <rekado_>(I also build all packages after updating them.) <nckx>I try to rebuild all dependents as well, but that takes ages on my hardware. <rekado_>yeah, it’s pretty slow in general. The R stack is not too bad, though. <nckx>About an hour into that is when I see someone else commit the same changes. <nckx>Currently building r-gdtools and dependents, any reason you didn't push that, rekado_? <rekado_>e3ddb563297c9707a8fc0e5c64e55915a4e842a5 <nckx>Oh. Never mind. /me re-rebases <nckx>Now I have an idle netbook. <nckx>Not ideal in these temperatures. <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'):" <bavier`>budric[m]: there was a small bug that affected setvbuf for guile 2.0 <budric[m]>I see, thanks. the official ebuild repositories don't have anything newer, I'll see if I can find something <budric[m]>I just wanted to play around with guix. do the official repositories contain binaries of software or only source? <budric[m]>I mean build from source package descriptions <bavier`>budric[m]: guix is source-based with transparent substitution of binaries from build servers <rekado_>ACTION tries to visualise a package’s full dependency graph with R <davexunit>rekado_: is there anyway to see the build status of something on berlin like you can with hydra? <rekado_>davexunit: you can use M-x guix-hydra-latest-builds and you can visit berlin.guixsd.org/status, but neither of these are as informative or usable as the hydra web interface. <davexunit>I can't reasonably build it on my machine so I can't updated my system :(