IRC channel logs
2017-04-22.log
back to list of logs
<rekado_>civodul: oh nice: 285f63e805f4a895c1d301efe6d40e93c4e2f704 ! <civodul>rekado_: ah yes, glad you like it :-) <rekado_>redesigning RPCs sounds like it would tie in with replacing the daemon <civodul>ah maybe yes, i hadn't thought this far <civodul>those progress bars for substitutes are great no? <Apteryx>When I find a bug & fix it, should I sent the patch to bug-guix or guix-patches? <brendyn>It's IRC custom to just ask questions with asking if one can ask first, else someone has to inform the asker that they are allowed to ask and it gets frustrating ;) <Allanitomwesh>ah okay, is the goal of this project to be 100% gnu packages? <buenouanq>oh, do you mean will it have everything that \\emph{is} gnu? idk <brendyn>Well, we want to package all free software, ultimately <brendyn>But that's a big goal. Packaging all GNU software is a reasonable goal too, but I don't know if anyone has explicitly stated that <brendyn>Guix's packaing goals are the same as any other distro like debian or Fedora, except without any nonfree bits. <buenouanq>I think that as it matures, at some point every single official GNU thing will prolly be available - But I'm not sure this is a goal of Guix, explicit or otherwise. <buenouanq>I just want a functioning widely adopted stable gnunet ( ._.) <brendyn>I have played with gnunet a little bit. It seems a fair way off that goal <brendyn>On the other hand, i2p is quite usable <buenouanq>they're quite different things really and prolly shouldn't be compared <brendyn>Well, they are both anonymising networks <buenouanq>gnunet is like the good parts of i2p, freenet, and ipfs, minus the shortcomings of each of these alone, done right <brendyn>So it claims, but when I test GNUnet, it uses an enormous amount of CPU and bandwidth filesharing is crude and slow <brendyn>buenouanq: Would you like to test filesharing? <buenouanq>some of that would be helped if more people were using it <buenouanq>brendyn: I've never had issues with sharing files over gnunet. <brendyn>I'd use it, but I can't keep gnunet running for very long due to it maxing out my CPU <brendyn>I tried to download a file from my local node, and it went about 1KiB/s <brendyn>I'm just being critical though. I hope GNUnet improves too <Allanitomwesh>I dont have any hardware that works well with linux-libre but ill give it a go when i get a new laptop <buenouanq>mucking with users like that by hand for things that should be never goes well for me <buenouanq>Allanitomwesh: if you can run parabola, you can run GuixSD <brendyn>Gnunet is in guix though, and it seems to work better than the parabola build. with the parabola version, I found gnunet-fs was broken <Allanitomwesh>i cant run parabola either (used the live iso to test) but i intend to acquire hardware that can <brendyn>Well I suppose you can run Arch and then put Guix ontop <snape>does anyone have an emacs snippet that would format a raw scheme output? Like a .drv or a builder <brendyn>No. Guix is a package manager that can be run ontop of any distro. GuixSD is the distribution that is based on using Guix as it's package manager <brendyn>You do not need to use GuixSD in order to use or contribute to Guix <catonano>I become root with su and as root the "guix" command cannot be found <catonano>is this normal ? I remember tat guix was indeed present in the root env <amz3`>I tried to build guix from git but it failed <amz3`>with an error about 'guix pack' <amz3`>I will paste the exact error when I reproduce with a clean repo <brendyn>amz3`: guix environment guix; ./bootstrap; ./configure --localstatedir=/var; make <brendyn>The first one starts a new shell with the right environment variables so everything after it should hopefully work <snape>amz3`: make sure you don't pollute your environment with exports in .bashrc, they should be in bash_profile <catonano>amz3` the first line suggestes that yo have edited thhe ile "guile.scm". Sometimes unbalanced parenses lead to "Unbound variable" errors, in my experience <amz3`>the error is not in guile.scm <catonano>it's not. But sometimes a wrong deinition causes errors in files that are far away from the file containing the original error <brendyn>How is that the case if you are on the latest git version? <amz3`>I commited something... sorry for the noise. <brendyn>Probably best uses branches for changes <davexunit>has anyone had any luck using hp all-in-one printers without needing proprietary drivers? <davexunit>I imagine that *someone* has got to be using an hp printer on guixsd around here :) <brendyn>Allanitomwesh: Guix is a package manager like pacman, expect it keeps all it's packages in a single directory in /gnu/store <brendyn>So its easy to use Guix ontop of other distributions <brendyn>Probably most Guix users use Guix this way <janneke>davexunit: i'm using a hplj2300 -- plain postscript <janneke>brendyn, that's how I started with Guix -- however if you like guix, why would you want to ever run another distro again? <brendyn>Well it still seems quite difficult to setup and missing lots of things <janneke>brendyn: is it building some stuff? have a look at /tmp/guix-build-* <brendyn>I ran it with strace and the strace just stops dead at read(12, <brendyn>Do you know any debugging things I can do to find out more? <janneke>sorry, i don't -- i have only noticed sometimes guix seems to quietly build stuff, that's why i suggested to look in /tmp <brendyn>It's curious that the strace halts without finishing a line of output <brendyn>And guix will check substitutes, and announce what is to be build <brendyn>But in this case there is no output at all <brendyn>It seems I need to update the version of guix root has <brendyn>the guix-daemon is still using guile 2.0 <paroneayea>there isn't a "guix package --upgrade --only-substitutes" flag type thing I'm missing, is there? :) <paroneayea>for when I want to upgrade what i can, but not have my cpu spin on libreoffice or emacs or clojure or whatever the current expensive thing to upgrade is <brendyn>Well the upgrader does use substitutes whenever they are available <brendyn>So you either have to build some stuff, or cancel the upgrade <paroneayea>brendyn: right, I mean, if they aren't available <paroneayea>I wonder if we have or could have an option to just upgrade what's available <paroneayea>I'm not sure if bug-guix is the right place for that or not <janneke>ACTION is still waiting for someone to explain the difference between bug and feature request <paroneayea>janneke: bug is "it's broken"; feature request is "we don't have this but I'd like it" <paroneayea>they can get muddled, but I think mine definitely falls on the feature request end :) <janneke>i understand it from the viewpoint of the reporter...just not from the viewpoint of the developer <slyfox>the intended benaviour is X, the real behaviour is Y <brendyn>Ok so I have guile 2.2, but guix still uses guile 2.0.14 when I check htop <slyfox>i think it's expected. only core-updates branch (not master) uses guile-2.2 by default <brendyn>Both user b and root have updated to guix 12.0-8.d72b <slyfox>guix-daemon looks like it's running from old guix <slyfox>do you know what restart daemon on your machine? <brendyn>yeah it must be because the namespace is still old <slyfox>how does .service file encode path to guis-daemon? through /usr/bin or through root profile? <brendyn>ExecStart=/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild <slyfox>if you resolve that /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon link. does it point to new 0.12 or old 0.11 guix? <slyfox>odd. i'd expect 'systemctl restart guix-daemon' to pick up a new version <brendyn>There is no actual change to the systemd file <slyfox>systemd should still stop/start process using specified path. unless systemd resolved and cached that symlink on it's own <brendyn>I tried disabling and reenabling the service. didn't work <janneke>`configure: error: C preprocessor "/lib/cpp" fails sanity check <janneke>/gnu/store/ai76islikqy4iki802p60vyx2km5v675-profile/include/limits.h:145:17: error: missing binary operator before token "(" <janneke> #if __GLIBC_USE (IEC_60559_BFP_EXT) <slyfox>i guess your toolchain does not defne __GLIBC_USE macro <janneke>its a server running ubuntu 16.04 + guix -- been running that for ~1y <janneke>and now...update guix git and *boom* <slyfox>which package did it try to build? <janneke>haven't really looked into it yet, it looks so weird <janneke>this is ./configure in guix after doing ./bootstrap <slyfox>perhaps guix git fails to build in a year-old guix environment <slyfox>current guix master builds fine from under 'guix environment guix' <slyfox>AFAIU that include/limits.h comes from some glibc version provided by guix <slyfox>at wors you can fallback to system's glibc <slyfox>but it could be fun to find out what is broken as well :) <Petter>slyfox: This TasksMax thing. Is this an issue only for Guix on a systemd system? <Petter>I didn't encounter it on GuixSD at least. <efraim>don't tell anyone, but mips and aarch64 aren't actually supported by go-1.4, and gccgo doesn't produce a gccgo binary anymore <Petter>How to do the equivalent of `git clone --recursive ...` in a package recipe? <efraim>Petter: git grep shows we have a '#:recursive? #t' option for git downloads <rekado>there’s a problem with linux-libre-4.1 <rekado>I get this error on master when reconfiguring: output path `/gnu/store/0wphpff2bd763caazl77y7sxfy4hymsp-linux-libre-CVE-2017-6074.patch' should have sha256 hash `1x40slfz1qxgiaznyy13bwlh34450pkyyrkljpyjlx6c4mrzb1jj', instead has `0g8prnirhrqwvdc4rg3a339d4n97f6hnxm84gryr5ksc2cn5l63x' <Petter>The package I'm working on has a dependency on qt and in the install phase it tries to create a directory in /gnu/store/...-qt-5.6.2, obviously it can't do that. Not sure how to overcome this though. Any tips? <Petter>It tries to create the directory qml/QMLTermWidget (if that means something to someone). <rekado>Petter: usually in these cases the Makefile reuses some paths that it should not. <rekado>Petter: I had this problem with some of the SELinux packages. <rekado>Petter: they wanted to install the Python bindings to the prefix of the “python” package, so I had to patch the Makefile. <Petter>rekado: Thanks. I will try some different things. I suspect changing the path(s) isn't the full solution in this case. <Petter>I assume this is how they notify qt of their existence, but there's probably an alternative way. <Petter>Hm, maybe I should just disable that thing and see what happens. <rekado>I guess you should just install it in the current package’s prefix. <rekado>At build time we create a union anyway, so Qt will find it when building a package depending on this. <Petter>Aha, interesting! I'll try that.