<orbea>guix pull = how to update guix? <orbea>ACTION wonders how to view the guix package changelog... <orbea>Not as simple as "guix log" :P ***francis7 is now known as emacsuser
***emacsuser is now known as francis7
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
***shymega_ is now known as shymega
***tschwing_ is now known as tschwinge
<efraim>between your and ricardo's suggestions I have python2-oauthlib building. I thought I had to edit python2-cryptography to fix python2-oauthlib, but now I understand everything that uses python2-cryptography needs to be specifically told what to do <Gottox>I'm currently trying to compile elogind and got this error: <Gottox>config.status: creating Makefile <Gottox>config.status: error: cannot find input file: `po/Makefile.in.in' <civodul>Gottox: are you building it with guix, or from a checkout? <civodul>it's bootstrapped, so you don't need autoconf/automake/gettext to start building it <Gottox>I hope, that I can use elogind to build gnome with logind support on voidlinux. <Gottox>We currently rely on consolekit support, but that's fading away. <Gottox>./.libs/libelogind-core.a(libelogind_shared_la-clean-ipc.o):clean-ipc.c:function clean_ipc: error: undefined reference to 'mq_unlink' <civodul>you're welcome to fix it upstream, of course ;-) <rekado_>I wonder if we could bootstrap gcc not from a binary of gcc but with the binary of a much smaller C compiler, which we could build from a simple compiler written in plain assembly. <civodul>there's interesting stuff to be done in that area <civodul>tinycc is the smallest i know of, but it's not that small either <civodul>but anyway, GCC needs a C++ compiler nowadays <efraim>if it were assembly wouldn't we need one for each architecture? <efraim>x86 is pretty set but I don't know a lot about arm. would one armv7 version be enough for 32-bit arm or would we need chipset specific ones? <rekado_>or we could bootstrap GCC first and then build cross-compilers for other platforms, no? <civodul>that's what we're doing already, IIUC <rekado_>yes, but we bootstrap with a GCC binary. <Gottox>efraim: We at voidlinux are using one armv7 gcc-cross for all our platforms. <civodul>rekado_: then i don't understand your suggestion ;-) what did you mean by "bootstrap GCC first"? <rekado_>well, in my dream world there is a tiny compiler for a subset of C written in assembly, which would be used to build tinyCC, which would be used to build GCC, which can then be used to build cross-GCCs. <rekado_>it's not much of a suggestion, I'm just dreaming out loud. <civodul>the problem is not cross-GCCs, but rather everything before <civodul>and unfortunately, by switching to C++, GCC spoiled our dream <rekado_>could an older version of GCC be used to build the C++ compiler? <rekado_>my dream is just to move the root of the graph a few more turtles down. <civodul>an older version might work today, but it's not sustainable <civodul>most likely we'd have to build a very old GCC, to build an old one, to build a recent one, to build the latest one <civodul>and the old versions would probably need patching here and there, more and more over time <civodul>unless we also build old binutils and glibc <civodul>maybe worth trying though, maybe i'm overly pessimistic <efraim>something else I learned poking around python, later versions of python-mock depend on python-pbr, which already depends on python-mock <efraim>wait, giux import pypi mock says it's ok with the bootstrap 0.11 version, so nvm ***francis7 is now known as vimuser
***vimuser is now known as emacsuser
***emacsuser is now known as francis7
<iyzsong>civodul: ah, yes. I see it, but haven't try. it use systemd for user services, also manager user files, etc. <civodul>yes, this is similar to the idea you proposed a while back <civodul>we could do that with per-user dmd instances <Gottox>hmm... will elogind be started via dbus or do I need an init script? <iyzsong>Gottox: the service file of elogind have a wrong Exce=/bin/false, so it can't be activated <iyzsong>doesn't davexunit already work on managing user's files? <fps>hmm, hmm, building the world does indeed take a while :) <fps>is there a guix package invocation to find out what packages have been built already? <fps>ls'ing /gnu/store and fiddling with cut is boring <fps>result of find /gnu/store -type d -maxdepth 1 <fps>fps@raksha ~$ guix package -A | wc -l <fps>about halfway done then,maybe <fps>and ca. 22G of diskspace used <fps>i also have a feature request :) <fps>is it possible to prepend every line of output of guix build with the package name that's being built? <civodul>iyzsong: yes, davexunit said he was looking at managing files in general, which could include user files <civodul>fps: unfortunately no so easily, because we get those lines directly from the daemon, and only the daemon knows what's going on <civodul>and the daemon doesn't think in terms of packages, but in terms of "derivations" <civodul>but i'd really like to have a way to disentangle the logs that the daemon sends <fps>civodul: and derivations are not named, right? <fps>civodul: they are just some sort of low level program that the daemon executes? <civodul>derivations are the /gnu/store/xyz.drv things <civodul>and yes, it's a low-level build program, as you write <fps>oh ok, the daemon could then maybe prefix the lines it sends with the derivation name.. that might help already to judge what's going on :) <fps>[configurable, of course] <fps>civodul: the guix-build daemon is the nix-daemon in the guix repository? <fps>ugh, manual options parsing. boost::program_options exists :) <fps>raw pointers. what's this? the 20th century? ; <fps>this code comes from people that love functional programming? :) <fps>raw pointers, naked strcpy's, global variables <fps>ayayayayay, ole, l'allegria! <fps>rekado_: you don't like boost? what parts of it and why? :) <civodul>fps: code for the daemon is in nix/, with the interesting bits in nix/libstore, and with the relevant bits in nix/libstore/build.cc :-) <fps>disclaimer: my previous comments were a bit tongue in cheek :) <rekado_>fps: the long-term goal is to rewrite the daemon in Scheme. Few people here like to hack on C++. <fps>i can imagine. c++ is horrible :) <fps>i'm not a functional programmer by any means, but most c++ programs can benefit heavily from the lessons functional programming taught us <cehteh>civodul: about all this build-server, funding stuff and more .. i would really like if guix could sustain with a completely distributed infrastructure, gnunet, bittorrent, signed builds where anyone trusted can cooperate <civodul>cehteh: sure, that's part of the goals <civodul>we would still need a build farm for continuous integration though <civodul>but yeah, the more decentralized, the better! <cehteh>even continous integration could be distributed eventually <rekado_>I'm confused about propagated-inputs and inputs in the ghc-* packages. <rekado_>do we really need to propagate inputs for Haskell applications/libraries? <rekado_>should the "inputs" in most of these ghc-* packages not really be "native-inputs"? <civodul>rekado_: since Haskell doesn't have anything like RPATH, we have to propagate stuff <rekado_>I just find propagation really icky. <civodul>for the mess it introduces in profiles? <rekado_>users must be aware of propagation (you can't tell just by looking at a package in the list); I usually notice only when guix tells me about conflicts. <civodul>OTOH it's the kind of thing i would use 'guix environment' for, or install in a dedicated profile <civodul>as opposed to installing them in ~/.guix-profile <rekado_>I usually end up doing that, but only after seeing all these conflict warnings. <mark_weaver>fps: here's what I do: "ls -ltr /var/log/guix/*/*", optionally piped to 'tail' <civodul>rekado_: i think fixing it requires support from the language itself :-/ <mark_weaver>rekado_: replacing just the compiler wouldn't really help all that much, because you still need binaries of all the other utilities, plus a kernel. <mark_weaver>rekado_: my dream is to implement a minimal little subset-of-scheme REPL that works as a coreboot/libreboot payload, and then document a set of REPL commands that gradually builds up the system to the point of being able to compile the GNU toolchain and go from there. <mark_weaver>another example of a coreboot/libreboot payload is GRUB <rekado_>civodul: I was convinced that Python offered a way to "import /path/to/module", but I was shocked to learn that this doesn't actually exist. <desiderantes>hello, i see that a systemd .service file is provided when installing guix for users <rekado_>Ruby supports this, though, and I really think it's worth working on a build phase that replaces plain "require lib" statements with "require /path/to/lib" <rekado_>mark_weaver: that's a nice dream :) I'd like that. <mark_weaver>and part of the bootstrap process would involve compiling the last version of GCC (4.6?) that doesn't require C++ to compile, and then using that to compile the newest version of GCC that can be compiled with that version of GCC, and so on, until we get to the version of GCC that we want. <mark_weaver>rekado_: this may be of interest. not quite what I was going for, but along similar lines. it's a shame he chose the RPi to do it, but it could be ported: http://interim.mntmn.com/ <mark_weaver>the main difference is that I'd like to start from something so small that it's quite practical for one person to audit and understand the assembly code. <civodul>desiderantes: no, there's no upstart job; but if you write one, we can add it :-) <desiderantes>civodul, i've been testing it and it seems to work properly, how can i propose it for inclusion? <civodul>desiderantes: post it to guix-devel; better: if you're familiar with the autotools, post a patch that integrates it similar to etc/guix-daemon.service.in <civodul>specifically, do something similar to commit d2825c96 <mark_weaver>civodul: well, my main concern about all of the reproducible builds projects that currently exist is that they all requires putting one's faith in a *huge* pile of binary code to start with. <mark_weaver>which is not to say that this is not a logical first step, and an important one. <mark_weaver>but I for one will not be satisfied until we can start from something whose machine code is fully auditable by a single person in a reasonable length of time, and then have the rest of the bootstrap be 100% source code in the true sense of the term (preferred form for editing) <mark_weaver>but in the meantime, it would be interesting to see how small we can make the Guix bootstrap binaries. <civodul>OTOH, Lunar suggested that, if we do double-diverse compilation of the bootstrap binaries, then we can be sure they are free from the Thompson attack <civodul>yes, to me, we still want to make the bootstrap binaries smaller, regardless <mark_weaver>the diverse compilation idea is a good one, but it's important to remember that the compiler is only one of the components where such a Thompson attack could be launched from. the assembler, linker, and kernel are other places to be concerned with. <civodul>not to mention the various compilers, interpreters, etc. <mark_weaver>and taking into account all of those places, the amount of diversity we have available to work with is far too limited to give much comfort. <civodul>yeah, even if we restrict ourselves to C++ compilers, we have only two of them in fact <civodul>and it's not even clear that they can compile each other <civodul>i think one option for us to remove the number of bootstrap binaries would be to have more things written in Guile <civodul>not feature-full, but good enough as replacements for, say, coreutils, findutils, ld, etc. <civodul>basically unpack the bootstrap-binaries tarball, see what we can implement, and remove it from there <mark_weaver>although Guile itself is too big, and so it would be good to write such code with an eye toward running it on a simpler scheme implementation during the bootstrap. <mark_weaver>although maybe at some point we can work on making Guile itself more modular, with a very simple core. <mark_weaver>dunno, some of these ideas are off the top of my head, and not fully baked :) <mark_weaver>anyway, I have to go afk for a while. happy hacking! <zacts>I may try installing guix on my laptop today <zacts>I want to contribute towards full disk encryption via cryptsetup + LVM2 <zacts>so maybe we can work on this <civodul>Sleep_Walker already went pretty far on that front, but then we dropped the ball <civodul>i remember there were shortcomings with the mapped-device design that needed to be addressed <Sleep_Walker>zacts: you can find some information on ML archive, but I'm not sure, how relevant it still is <zacts>yeah I'll ask civodul later today or this week <rekado_>as I also have a fully encrypted disk with LVM I'd be willing to help if you need to verify some techniques. <zacts>let me know how you did it, and what problems you encountered... <civodul>rekado_: did you have a chance to submit a proposal for the HPC track at FOSDEM? <civodul>ACTION shamelessly tries to offload work :-) <civodul>if we were many to go there, there are several devroom where we could talk: distributions, config management, containers, and security <civodul>ACTION sends a call for proposals :-) <civodul>Steap: you're gonna talk about Guix-Tox at FOSDEM, right? <Steap>civodul: I don't know, got any money to send me there ? <civodul>come on, you earn twice my salary! ;-) <civodul>it's surprising there's no OpenStack devroom <avoine>is it normal that when I create a vm with guix system vm ... that in it /gnu/store is read-only? <civodul>avoine: yes, because the VM shares the store with the host ***6JTACKCGI is now known as paolo
<rekado_>civodul: I wanted to submit, but haven't yet. I'm always away from my personal machine. I'll try to submit the talk in the HPC track tonight or tomorrow morning. <rekado_>ACTION goes afk to meet with the local FSFE group ***joehillen_ is now known as joehillen
***necronian_ is now known as necronian
***catern_ is now known as catern
<fps>if the publish service is running <fps>are all built packages automatically available over port 80? <fps>no idea if that's the expected behaviour. is the protocol documented somewhere ***keverets_ is now known as keverets
<sirgazil>hmmm, guile-sdl is failing to build, so I can't install guile-sly :( <rekado_>submitted two talk proposals for FOSDEM2016, one in the HPC track, the other for the Guile devroom. <fps>how can i check if the build service actually provides builds there? <rekado_>civodul: thanks for the reminders. I had this FOSDEM submission page open in a tab for much too long and always managed to procrastinate... <fps>this is a not very stable ssh port forwarding to the local port 80 on the guixsd vm :) <fps>if i access it with links i just get Resource not found: / <civodul>if you publish the public key, people will be able to use substitutes from there <civodul>sirgazil: did you disable substitutes? <fps>service might go away anytime though.. <fps>fps@raksha ~$ find /gnu/store/ -maxdepth 1 -type d | wc -l <fps>also it's just 1657 packages as of now ;) <civodul>sirgazil: is this a recent pull or git checkout? <fps>i'll have to ponder how to make the port forwarding more relibale <fps>but not tonight. that involves reading and stuff.. <sirgazil>I did a recent pull, but other packages install alright. <fps>fyi: that's: /dev/sda1 99G 28G 67G 29% / <civodul>sirgazil: ooh indeed, it's failing here <fps>including the base system before that which was like 3G <civodul>so 70G for two thirds of the packages? <fps>i guess it might be worthwhile to tailor the config.scm including cron jobs, etc, so other people can just slap it onto a vm and let it do work.. <civodul>sirgazil: could you email bug-guix@ with this problem, mentioning the architecture and commit? <fps>feel free to hammer it :) <civodul>thanks, and sorry for the bad experience :-/