IRC channel logs

<rekado_>civodul: oh nice: 285f63e805f4a895c1d301efe6d40e93c4e2f704 !

<civodul>rekado_: ah yes, glad you like it :-)

<civodul>not as nice as we'd like: https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00487.html

<civodul>but we'll get there!

<rekado_>cool stuff!

<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?

<methalo>hey phant0mas

<Apteryx>When I find a bug & fix it, should I sent the patch to bug-guix or guix-patches?

<Allanitomwesh>hello i have a few questions

<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>100% free software

<buenouanq>it's not all gnu though

<buenouanq>oh, do you mean will it have everything that \\emph{is} gnu? idk

<Allanitomwesh>yes that latter point is my meaning

<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.

<Allanitomwesh>seems like a good goal in my opinion

<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>the whole java thing though

<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

<Allanitomwesh>i like the idea of the guix package manager.

<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.

<buenouanq>Allanitomwesh: so do we :3

<brendyn>I'd use it, but I can't keep gnunet running for very long due to it maxing out my CPU

<buenouanq>interesting, what OS?

<brendyn>I tried to download a file from my local node, and it went about 1KiB/s

<buenouanq>or distro rather

<brendyn>I'm just being critical though. I hope GNUnet improves too

<buenouanq>do we have a gnunet service yet?

<brendyn>ng0 has been working on it I think.

<buenouanq>godspeed

<buenouanq>that would be great to have

<Allanitomwesh>I dont have any hardware that works well with linux-libre but ill give it a go when i get a new laptop

<Allanitomwesh>though probably parabola will be main

<buenouanq>mucking with users like that by hand for things that should be never goes well for me

<buenouanq>s/should be/should be daemons/

<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

<Allanitomwesh>yeah but lately im more conscious about my freedoms

<snape>does anyone have an emacs snippet that would format a raw scheme output? Like a .drv or a builder

<Allanitomwesh>what do you mean by guix on top? like a VM?

<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

<buenouanq>catonano: you have to su as a login shell

<buenouanq>su --login su -l or just su -

<buenouanq>alias su="su --login"

<catonano>buenouanq: thanks.

<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

<amz3`>tx!

<brendyn>Best try one command at a time

<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

<amz3`>I get a new error: http://dpaste.com/14D3FT0

<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

<amz3`>I think

<catonano>it's not. But sometimes a wrong deinition causes errors in files that are far away from the file containing the original error

<catonano>it's just a suggestion though

<amz3`>I am checking tx!

<amz3`>indeed

<brendyn>How is that the case if you are on the latest git version?

<amz3`>I commited something... sorry for the noise.

<brendyn>Oh right

<brendyn>Probably best uses branches for changes

<brendyn>Then you can keep master clean

<davexunit>has anyone had any luck using hp all-in-one printers without needing proprietary drivers?

<davexunit>I was about to buy one but the hplip page scared me http://hplipopensource.com/hplip-web/models/color_laserjet/hp_color_laserjet_mfp_m477fdw.html

<davexunit>I imagine that *someone* has got to be using an hp printer on guixsd around here :)

<Allanitomwesh>im back

<Allanitomwesh>brendyn: please explain the not needing guixSD to use Guix?

<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>Allanitomwesh: https://www.gnu.org/software/guix/manual/html_node/Installation.html#Installation

<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

<brendyn>Hmm, guix package -u hangs for me

<brendyn>using a reasonable amount of cpu

<janneke>brendyn: is it building some stuff? have a look at /tmp/guix-build-*

<brendyn>Doesn't seem to be

<brendyn>I ran it with strace and the strace just stops dead at read(12,

<brendyn>And then the cpu ramps up

<janneke>hmm

<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>But normally there is output

<janneke>yes

<brendyn>And guix will check substitutes, and announce what is to be build

<brendyn>built

<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>don't upgrade those

<paroneayea>yeah I know that

<paroneayea>I wonder if we have or could have an option to just upgrade what's available

<brendyn>Hmm. that seems useful

<paroneayea>ACTION files a bug

<paroneayea> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26608 "bug" filed, though it's more of a feature request

<paroneayea>I'm not sure if bug-guix is the right place for that or not

<slyfox>should be ok

<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>:)

<janneke>i understand it from the viewpoint of the reporter...just not from the viewpoint of the developer

<janneke>`the code does X, /me wants Y'

<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>It's interesting that when I kill all guix processes, restart the guix daemon and run guix environmen guix, I get this http://paste.lisp.org/display/344875/raw

<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

<brendyn>I use systemd

<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

<brendyn>I just did what it said here: https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html

<slyfox>looks correct

<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?

<brendyn>0.12

<slyfox>odd. i'd expect 'systemctl restart guix-daemon' to pick up a new version

<brendyn>Maybe because it's just a symlink

<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

<brendyn>Maybe I'll have to *gasp* reboot

<janneke>`configure: error: C preprocessor "/lib/cpp" fails sanity check

<janneke>whut?

<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

<slyfox>is it linux/glibc?

<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

<janneke>yes, perhaps

<slyfox>current guix master builds fine from under 'guix environment guix'

<slyfox>(at least configures)

<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.

<slyfox>only systemd systems

<Petter>I see. Nice going solving it!

<slyfox>heh, thanks :)

<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

<efraim>check out brotli

<Petter>Nice, thanks!

<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'

<efraim> https://sources.debian.net/src/gcc-4.9/4.9.2-10/debian/rules.defs/#L763 i'm going to test locally if I change gccgo's custom languages from '("go") to '("c" "c++" "go") if that produces a gccgo binary

<Petter>ACTION crosses fingers

<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.

IRC channel logs

2017-04-22.log