IRC channel logs


back to list of logs

<rekado_>civodul: oh nice: 285f63e805f4a895c1d301efe6d40e93c4e2f704 !
<civodul>rekado_: ah yes, glad you like it :-)
<civodul>not as nice as we'd like:
<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>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
<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:
<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!
<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
<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>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
<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
<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>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> "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>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
<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:
<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?
<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>/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> 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.