IRC channel logs

<civodul>Apteryx: that'd give you the security updates

<civodul>as long as you don't use --no-grafts, everything's fine

<kyamashita>I sent my patch to the mailing list twice, but I hasn't shown up yet...

<Apteryx>civodul: OK!

<Apteryx>Is it me or we don't see the scrollbar in IceCat with the default GTK3 theme?

<kyamashita>I can't either.

<Apteryx>ok

<kyamashita>Geez, I need a Scheme shell.

<kyamashita>I'm finding myself typing Scheme at my Bash prompt.

<lfam>kyamashita: Sometimes it takes a little while

<kyamashita>lfam: Lol, yeah. "bash: define: command not found"

<lfam>I meant about the email to guix-devel :)

<lfam>But it also takes some time to switch brain modes too :)

<Common_Era>Cinnamon Bun Oreos...

<kyamashita>Common_Era: What dark sorcery is this?

<Common_Era>The delicious kind.

<Apteryx>Is is tormal that 'xfontsel' doesn't find any font?

<Apteryx>Probably. It's so old, it must be looking for fonts in another format (1989).

<Apteryx>I'd like to try the "terminus" font in Xterm, but haven't been able to figure out how to configure my .Xresources file's XTerm*font parameter. I always get a message: couldn't find the font terminus

<himmAllRight> /connect freenode

<Apteryx>Oh, found a solution. You can use XTerm*faceName as well for the terminus font, like:

<Apteryx>... like:

<Apteryx>Ah! My term is not cooperating: XTerm*faceName:Terminus:style=Regular:size=11

<Apteryx>Woo! guix gc did a terrific job, slashing my hard drive space from 9.9GB to 5.2G

<Apteryx>s/space/usage

<Apteryx>I'm a bit surprised to find that gcc-toolchain depends on glib?

<catern>huh interesting https://www.gnu.org/software/userv/

<catern>a GNU project already exists to provide privilege-execution-of-commands-over-IPC...

<catern>written by Ian Jackson even :)

<catern>abandoned, unfortunately

<lfam>This is a strange failure of openssh on mips64el on core-updates: https://hydra.gnu.org/build/1577611/nixlog/2#line-2384

<lfam>ERROR: Invalid ELF #vu8(127 69 76 70 1 1 1 0 5 0 0 0 0 0 0 0 3 0 8 0 1 0 0 0 32 43 0 0 52 0 0 0 144 147 1 0 39 [...]

<Apteryx>Hey, I was looking at the package udisks, and notice we are disabling the man pages with configure arg: "--disable-man"

<Apteryx>I know there is a udisks:doc output, but these are HTML pages. I think the default udisks:out should still come with its manual.

<lfam>Yeah, probably. Give it a shot :)

<Apteryx>lfam: OK :)

<Apteryx>I'm not setup with a git checkout yet, so I'm copying the freedesktop.scm file the udisks package is defined in in my ~/devel, making the changes to it (Emacs), and then how would I test an install of it? I thought "guix package -f freedesktop.scm", but I'd like to select just the "udisks" package of the freedestop.scm file?

<Apteryx>I get: (guix-command "build" "--file=/home/maxim/devel/freedesktop.scm" "udisks")

<Apteryx>guix build: error: #<unspecified>: not something we can build

<Apteryx>Also, it doesn't seem to support cryptsetup, but I can't seem to find much information on how to enable that.

<rekado>Apteryx: “guix package -f” assumes that the last value is the package you want to build.

<rekado>if you only have definitions there’s no value.

<rekado>you could add to the very end of the file the variable corresponding to the package you want to build.

<rekado>alternatively, use GUIX_PACKAGE_PATH

<Apteryx>rekado: Thanks! I think I got what I wanted with this: (guix-command "package" "--install-from-file=/home/maxim/devel/freedesktop.scm" "--install" "udisks")

<Apteryx>How do I iterate though? The second time I try this it says the package is already installed, even if I change the package definition.

<Apteryx>Trying with "--upgrade".

<Apteryx>That didn't quite work :D. Updating all my packages.

<Apteryx>Qt doc could be optional. It pulled a 130 MiB archive of doc, simply because I have keepassx installed (depends on Qt).

<Apteryx>rekado: I'm trying to put the package on the last line, like this: (udisks), but it fails with "Wrong type to apply: #<package udisks@2.1.7 ...".

<civodul>Hello Guix!

<csanchezdll>hi!

<civodul>davexunit: on the EOVERFLOW issue in the 'pivot-root' test: https://bugzilla.kernel.org/show_bug.cgi?id=183461

<civodul>"is there a use case", they ask

<civodul>well well :-)

<rekado> http://guix.mdc-berlin.de/documentation.html

<rekado>These are the docs I provide to users at the MDC.

<rekado>maybe some of that is generally useful.

<rekado>includes info on sharing environments

<civodul>rekado: pretty cool!

<civodul>so "BIMSB" is you? :-)

<thomasd>Hi #guix,

<thomasd>I'm working on a kdevelop package, but there's a number of issues with various PATHS that I'm not sure how to solve (best)

<civodul>hey, thomasd

<civodul>tell us everything :-)

<civodul>ACTION spawns M-x doctor

<civodul>so you say you have issues with kdevelop

<civodul>what makes you say so?

<thomasd>:0) ok. so one thing is, kdevelop needs kio at runtime, to spawn some service-providing daemon

<thomasd>would that make kio a propagated-input?

<rekado>yes, BIMSB is us. (Berlin institute for medical systems biology.)

<civodul>rekado: i was specifically referring to "if in doubt, ask BIMB" ;-)

<civodul>thomasd: kio is a daemon?

<civodul>or a client lib + daemon?

<thomasd>oh wait, I'm mixing up (this KDE stuff is complicated)

<thomasd>kinit provides the daemon, so that needs to be on the runpath

<thomasd>we'll get to kio later ;-)

<thomasd>so then I think kinit should be a propagated input?

<thomasd>or the other solution would be to wrap the kdevelop executable in a script that sets PATH (and QT_PLUGIN_PATH)

<civodul>thomasd: assuming 'kinit' is a standalone program, you could patch the thing that invokes it so that it refers to its absolute file name

<civodul>this is better than propagating it

<thomasd>civodul: do you mean patching the source (not sure how complicated this gets), or generating a wrapper script that adds kinit's store directory to PATH?

<civodul>thomasd: patching the source is nicer

<civodul>grep -r for "kinit" in the relevant package

<thomasd>I'll have a look, then :)

<Digit>things have been going wrong for me here in my devuan. ... it may please some of you to know, that in this panicked alarmed state of "oh no, it's gonna die", it's GuixSD i find myself reaching for. :)

<rekado>Digit: have you been using Guix on top of Devuan so far?

<Digit>i had been using GuixSD prior. i do have Guix installed on this devuan and have used it for a small handful of packages.

<Digit>this was kinda unexpected for me. i didnt realise GuixSD had become my "go-to" distro.

<rekado>heh

<Digit>:/ hrm. "ping: unknown host", tried setting up wired connection. what does one do when this happens? the install documentation doesnt cover this. i was using the connection minutes ago on that machine using an old pendrive os, so it should work.

<Digit>orrrr... maybe it did cover it, in https://www.gnu.org/software/guix/manual/html_node/Hardware-Considerations.html#Hardware-Considerations which i skipped. maybe it wont work on the lenovo x60t then. :/ ... not unless i get it liberated.

<Digit>i didnt expect the wifi to work, but the ethernet should have, i thought. "02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller" :(

<Digit>aaanyway, that's not the machine with the iffy devuan. ... but i was sure that was where i was running guixsd prior.

<civodul>Digit: FWIW i have "Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection" and it works perfectly with Linux-libre

<Digit>thnx. that's what i thought.

<Digit>oh, wait, different one, right.

<civodul>different number, but it's probably similar

<Digit>o_O curious and curiouser. just as i was starting to suspect my change of isp... while running through this from a fresh reboot, now instead of ping returning just the one line "ping: unknown host", it "works", 3 packets transmitted, but 0 packets received. *scratches head further*

<Digit>oops, forgot the .org that time. lol. works. idk wth i could have done wrong first time. excuse my pebkac bilge.

<Digit>only thing different i did, afaict, was use a different usb port. o_O

<davexunit>civodul: so does this break call-with-container completely on newer kernels?

<civodul>davexunit: no, not at all; it's just that 'pivot-root' test that relies on this behavior

<civodul>so in a way, we don't seem to have a "use case"

<civodul>OTOH, it looks like weird behavior to me

<davexunit>yes it's definitely odd

<civodul>i guess i could just reply that

<davexunit>but difficult to give them a solid use-case

<civodul>yeah

<davexunit>maybe our test could avoid a tmpfs?

<davexunit>the other container stuff just makes a directory in $TMPDIR

<civodul>dunno i couldn't think of any simple way to write the test differently

<civodul>because i think it expects the mount that's currently a tmpfs to be a different mount point than the underlying file system

<civodul>(i don't know if i'm being clear...)

<davexunit>ah, okay

<davexunit>well I guess we can just go back and explain that we have a unit test for our pivot-root wrapper that we'd like to pass

<davexunit>maybe they'll give us an alternative testing method

<civodul>oh sorry i just replied: https://bugzilla.kernel.org/show_bug.cgi?id=183461#c3

<civodul>but feel free to complement/amend!

<civodul>rekado: do you plan to look at the ARM patches by Theodoros?

<rekado>civodul: which do you mean? The last ARM-related stuff I see is openocd + gdb-arm-none-eabi.

<civodul>yes, that

<rekado>civodul: they have both been pushed by David already. I only fixed up the license of openocd after that.

<catern>hey #guix

<catern>can I use haskell's Stack with Guix?

<catern>Stack has some kind of --nix flag which uses Nix as the backend for... doing things

<catern>I don't really know how it all works

<davexunit>there's no such guix integration

<davexunit>haskell folks tend to use nix, not guix.

<civodul>rekado: oh great, sorry for the mess

<rekado>civodul: np!

<civodul>davexunit: that could change :-)

<rekado>civodul: I’m still working on some of hgoebel’s patches for Java. To make them clean requires a couple of changes to the ant-build-system.

<davexunit>maybe, but I'm skeptical. ;)

<rekado>they are not forgotten, I’m just slow.

<davexunit>the Nix language appeals more to them

<davexunit>because it doesn't have 'set!'

<catern>well

<civodul>not everyone if fond of external DSLs though, even a Haskellified JavaScript

<catern>I'm proposing a minor project at work

<catern>some people are enthusiastic about using Nix for it

<catern>I'm trying to persuade that we should use Guix instead

<civodul>neat :-)

<catern>but there are some haskell fans

<civodul>catern: maybe we should investigate how Stack uses Nix exactly

<civodul>well there are definitely more Haskell packages in Nixpkgs than in Guix

<catern>well we don't actually use Haskell

<catern>so it doesn't *really* matter

<civodul>ok

<rekado>(I'm a recovering Haskeller and I prefer Guile over the Nix language)

<catern>but some people like haskell on their own time

<civodul>let'em know that the Nix language has little in common with Haskell, contrary to popular belief ;-)

<civodul>then the arguments IMO would be that Guix has a cleaner UI and is more hackable

<catern>more hackable how?

<catern>(my personal reason for favoring Guix is that I want to use the package manager of the GNU system, because I use Emacs and info and so on :))

<civodul>essentially it's a library, with well-defined API

<civodul>it has a notion of "package", which are disjoint from other object types

<civodul>(types! :-))

<rekado>I just wrote a simple tool that spits out conda package recipes from Guix packages. It uses Guix as a library.

<rekado>really convenient.

<civodul>maybe we could market Guix as a helper for home-made package managers ;-)

<davexunit>I came pretty close to writing a bundler->guix converter

<davexunit>for ruby stuff

<davexunit>(but ultimately at work I'm using fpm + docker to make debian packages of ruby web applications)

<janneke>hi!

<OrangeShark>would be interesting to have guix build docker images

<davexunit>that's possible, Nix does it

<OrangeShark>ya, I remember reading that blog post

<catern>doesn't it do that already?

<catern>for guix system container?

<davexunit>no

<davexunit>container != docker image

<civodul>'guix system container' allows you to run GuixSD in a container, i.e., in separate name spaces

<davexunit>Docker maintains a database full of binary disk images that form "layers", the image you ultimately ask Docker to run in a container is a stack of images merged together.

<davexunit>Guix has a different design and needs no such thing.

<Digit>is there no lxde-desktop-service ?

<davexunit>all guix needs to do is make a bunch of bind mounts from /gnu/store into the container file system.

<Digit>ACTION wondering how necessary xfce-desktop-service (or some such) is, but doesnt want the bloat... usually happy without any DE, oft just using slim login manager... unsure how to configure initially

<catern>davexunit: right, but then you can just copy that result out

<catern>and you've got a container image

<davexunit>catern: it's not that simple

<davexunit>though it's probably not too much harder, either. ;)

<catern>what complicates it?

<davexunit>I don't know exactly what needs to be done, but there's likely some communicating that needs to be done with the docker software

<catern>oh

<davexunit>to insert the image into the database, tag it, etc.

<catern>right sure you need to turn that filesystem tree into the format Docker expects

<catern>but I'm certain that there's already tools outside Guix for that

<catern>probably something built into Docker

<davexunit>so it's all that glue that I don't know anything about

<catern>ah :)

<davexunit>I would love for someone to write such a tool

<davexunit>would help guix interop with our "competitors"

<civodul>wingo once suggested that we look at https://github.com/docker/docker/blob/master/image/spec/v1.md

<civodul>it's not that difficult to generate images in that format, it seems

<paroneayea>oh, http://ring.cx has joined gnu!

<davexunit>finally, it's public :)

<civodul>pretty cool

<davexunit>I was consulted during the process due to ring's dependency bundling issue.

<bavier>exciting news indeed

<davexunit>I didn't actually do anything, just listed some concerns with all of the bundled deps.

<paroneayea>someone started packaging ring in guix

<paroneayea>I don't think it made it in yet

<davexunit>now we've gotta get this packaged

<paroneayea>Lukas Gradl

<paroneayea>sent the patch series

<davexunit>yeah

<davexunit>now we need to update to the beta2 series

<Petter>Great news about ring!

<davexunit>I'm curious about how they solved the multi-device problem

<davexunit>which they have in beta2

<janneke>ACTION has some more progress on the reproducible-.go front...rebuilding guile-next+patches again...

<Apteryx>rekado: This is useful, thanks.

<Apteryx>Is binary diffs something we could use to patch security issues (and globally to reduce wasted bandwidth)?

<Apteryx>Since the packages are supposed to be deterministic in Guix, it seems it would apply well to it.

<davexunit>probably not

<davexunit>security issues are handled by grafting

<Digit>after removing all the packages it was complaining were unbound, with an almost empty "(packages (cons*", (just nss-certs), i'm underway with my guix system init :)

<davexunit>binary diffs seem unworkable because you'd have to know what to diff against.

<davexunit>I don't see how you get all of the information you need in order to do it.

<Apteryx>You'd need a diff for each package_old_hash --> package_new_hash transformation, from what I understand.

<davexunit>I don't think it's feasible

<davexunit>the substitute server would have to have both in the store, which seems unlikely

<davexunit>and the client would have to tell the server what the old hash is.

<janneke>hmm, guile uses a buildstamp!? "buildstamp", "2016-11-04 14:08:09"

<civodul>janneke: cool! did you see http://bugs.gnu.org/20272 ?

<janneke>any better suggestions for this than date EPOCH?

<Apteryx>davexunit: Well the server could have a database of all the binary diffs upgrade paths available, and the client would do the right thing?

<janneke>civodul: yes, thanks. I sent patches to that

<davexunit>Apteryx: nope.

<janneke>i could imagine buildstamp...something GIT

<Digit>oh good. guix is psychic. it's pulling in slim and libwacom

<davexunit>Apteryx: I don't see any way to be able to answer the question "what is the previous build of package 'foo'?"

<davexunit>guix has no notion of this

<davexunit>what does previous even mean?

<davexunit>each guix (that is, every commit) is distinct

<davexunit>it knows what is, not what was.

<davexunit>and the daemon doesn't even know what packages are.

<davexunit>it just builds "derivations"

<catern>hey, is it still true that Nix and Guix can use the same daemon?

<davexunit>the only workable route would be a client asking a server "my profile had hash X for package FOO, now I want hash Y, can you send me the difference if you have it?"

<davexunit>but I have a feeling the answer to that question will almost always be "I don't have anything for hash X, so I'll send you the whole thing"

<davexunit>but maybe it could work, provided that servers keep around enough old builds to provide a good hit/miss ratio

<catern>you could solve it at a lower level by deduplicating blocks of data

<janneke>civodul: I'm working on Guile reproducibility patches for Guix and intend to give them som pounding...see if Marks' confidence can be boosted by that ;-)

<civodul>janneke: excellent!

<catern>"I have these blocks of data, and I would like these packages. Send me what I'm missing"

<janneke>of course, mark_weaver did 90% of the work

<davexunit>I don't know how to say "I have these blocks of data"

<Digit>are a stream of many "warning: possibly unbound variable" normal n expected on first guix system init? in ./gnu/build/linus-boot ...

<civodul>catern: more or less; this is changing with the introduction of built-in derivation functions, though

<civodul>Digit: yes, they're harmless

<Digit>good good.

<Digit>i'll assume the collision warnings and arbritrary choice warnings are likewise harmless. :)

<davexunit>yes, hence "warning", not "error"

<Apteryx>davexunit: Right, the client would eventually need to tell the server what it has, or what it needs.

<Apteryx>Right now the only information the client sends to the server is the package names?

<Apteryx>s/is/are

<davexunit>Apteryx: no

<davexunit>substitution is lower-lvel

<davexunit>level*

<davexunit>you ask the server for any given store item

<davexunit> https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/

<catern>civodul: built-in derivation functions?

<davexunit>docker doesn't have working GC!

<Apteryx>davexunit: OK. Still unsure how the client figures out what hash (snapshot of a package) it needs?

<bavier>Apteryx: the hash is computed from the package inputs

<civodul>catern: as discussed at http://bugs.gnu.org/22774

<davexunit>Apteryx: package objects can be "lowered" to derivation objects and the hash can be obtained from that.

<catern>civodul: 404?

<Apteryx>So, depending on what is currently available in my store, the computed hash will differ, right?

<Apteryx>(currently available dependencies, or inputs)

<catern>civodul: seems to redirect me to http://debbugs.gnu.org22774/ (note the missing slash)

<civodul>catern: oh, intereting, try https://debbugs.gnu.org/22774

<catern>there we go, it works with https :)

<catern>fitting given the title of the bug :)

<catern>ah, interesting

<davexunit>Apteryx: the store has nothing to do with it

<davexunit>the guix code itself has all of the information needed to compute the hash

<davexunit>the store is merely a place to store the results of actually building these things

<Apteryx>So, suppose I have package C depending on package python-2, and I already have /gnu/store/83er...-python-2 in my store. Will it use that one, or will it use whatever the db of guix currently holds (Which is refreshed with `guix pull`) ?

<davexunit>Apteryx: you're getting things mixed up.

<davexunit>if a package depends on python-2 it will use *that*

<davexunit>if it's not in the store, it will build it.

<davexunit>if it can download a substitute from somewhere, it will.

<davexunit>otherwise it will build from source.

<davexunit>the store is a *cache*

<Apteryx>So when a package requires an input, guix doesn't care about a specific hash for that input. But the inputs hashes will go into the computed hash obtained for the package being installed. for the bpackage

<ng0>sneek: later tell lfam: i'm not sure about the keyservers, sending ed25519 works, receiving.. idk. take a look at http://ng0.chaosnet.org for keys. I'll eventually copy that again to https://n0.is

<sneek>Okay.

<Apteryx>The way I'm thinking the hash computation works right now would be like this: f(current-package-source-hash, other-inputs-hashes) -> current-package-hash

<davexunit>the hash for a package is determined by the hashes of all input packages, recursively

<davexunit>in addition to things like the package name, version, and target processor architecture

<Apteryx>davexunit: OK :)

<Apteryx>I think I'm starting to see through. Thanks for your patience.

<davexunit>np

<davexunit>it will click eventually

<civodul>anyone here using Guix in an institute/company setup like rekado does?

<davexunit>me

<civodul>like the other bioinfo people maybe?

<civodul>oh cool!

<civodul>i wasn't sure if you had succeeded at that ;-)

<civodul>nice

<davexunit>in a limited capacity, but guix builds our speech recognitiion stack

<davexunit>it's a complicated web of dependencies that guix was well-equipped to handle

<civodul>that's good

<Apteryx>fontconfig grafts bug came bag, and I didn't "guix gc". Wonder how that's possible.

<ng0>same on a new system here

<paroneayea>Apteryx: hm, is it showing up in all programs?

<paroneayea>rekado mentioned some font issues yesterday but I think he thought it was related to switching his icecat rendering engine... so probably not related I GUESS

<Apteryx>Pretty sure anything which requires fontconfig will be affected.

<paroneayea>oops

<paroneayea>stupid kinesis shift

<bavier>paroneayea: you've gotta really want that shift on the kinesis boards

<paroneayea>bavier: yeah, I hear the reason it sticks is buggy microcode

<Apteryx>paroneayea: So far it has an effect in xterm and emacs

<Apteryx>And ratpoison menus.

<Apteryx>I think mostly it is visible because usually I configure mono and fixed to the "Hack" font in a ~/.config/fontconfig/fonts.conf file.

<Apteryx>And this bug causes this file to be ignored, and Hack is not visible.

<ng0>no, it's even there without this

<Apteryx>So everything falls back to a very wide and strange looking Deja Vu Books or something.

<ng0>i have no fonts configured or installed separately and get the messages

<ng0>oh, re read your comment

<Apteryx>ng0: OK. But is your font rendering changed at all from the defaults?

<ng0>it looks w2orse, yes

<ng0>well and the fonts seem to fallback

<ng0>to something i did not define

<ng0>i used to have a definition, which is now ignored

<Apteryx>OK. Yeah. Not restarting this weechat anytime soon ;)

<Apteryx>As a workaround, you can define the variable "XFONTCONFIG=~/.guix-profile/etc/fonts"

<catern>hello #guix

<catern>I'm still trying to persuade my coworkers to use Guix over Nix

<catern>they say, "the package language doesn't matter, you only interact with that for a very short time, when you're writing something to generate expressions in the package language"

<civodul>catern: how come you haven't succeeded yet? ;-)

<catern>and then "since the package language doesn't matter, what other reason should we use Guix over Nix?"

<Apteryx>udisksctl unlock -b /dev/sdb doesn't work for me. Seems like it doesn't have the permissions to use cryptsetup as a regular user.

<catern>civodul: don't know, I guess I need help :)

<catern>what should I say?

<davexunit>catern: you can't win an argument where it is assumed that "the package language doesn't matter"

<Apteryx>catern: Words are weak. Demo it.

<Petter>catern: Can you give them a lecture on Freedom?

<davexunit>at some point, you have to decide whether a battle is worth fighting.

<civodul>catern: the "nicer" CLI (search paths, package transformation, etc.), security updates, etc.

<civodul>right

<catern>davexunit: can you give me an example of a way in which the package language matters? I mean, I certainly want to write in Guile, but they don't, I guess...

<civodul>in the end, it's also a matter of taste

<civodul>i'd suggest browsing the documentation of each project

<catern>civodul: they belittle the nicer CLI as not really important. what do you mean by security updates?

<civodul>or trying them out to get a feel

<catern>Apteryx: they are already familiar with Nix to some extent so I don't think there's much else to demo

<davexunit>I think trying out both would be a reasonable proposal

<civodul> https://www.gnu.org/software/guix/manual/html_node/Security-Updates.html

<catern>davexunit: I think this battle is worth fighting. If Guix takes off at my work, that would be awesome :)

<catern>davexunit: do you mean just have both installed in parallel?

<civodul>just try them out and pick what works best for the team :-)

<catern>or do you mean sharing a store daemon?

<davexunit>if they are familiar with Nix, maybe they could give Guix a fair shake

<Apteryx>catern: OK! That's a good start!

<catern>well, the primary application for Nix/Guix right now is just, providing unprivileged package management for developers (who don't have root on their systems)

<davexunit>I want Guix more widespread, too, but even as a Guix developer here I am at work using Docker

<davexunit>catern: the sysadmin (the person who does have root) will need to install guix for them

<davexunit>and I imagine the same is true of Nix

<catern>davexunit: right, that's true - and it is costly in time to have the sysadmin install either guix or nix, so it's tricky to ask for both....

<davexunit>if you are familiar with 'guix environment --container', maybe a demo of that will help show them that we can do better than nix-shell

<catern>(in reality it's not "the sysadmin installs", it's "we deploy this debian package")

<catern>(but that package has to be examined and OK'd by security...)

<davexunit>catern: when I said "try both" I didn't mean "install both everywhere and use both all the time", but rather "have the people making decisions give guix a fair shake and then choose"

<catern>davexunit: oh, okay

<catern>well, I am one of the ones making decisions, so I can kind of unilaterally decide...

<catern>(but that would make others unhappy)

<catern>davexunit: I don't really know nix-shell, so I can't really demonstrate how guix environment --container is better :/

<davexunit>if no one would be happy using guix, then guix will lose, no matter if it is better or not.

<davexunit>why is docker so popular? because it's good or because they've convinced everyone to use it?

<davexunit>the latter :)

<catern>:D

<catern>davexunit: oh no, I'm sure people would be happy using guix. it's just that the other 2 people interested in deploying nix/guix at my job, are interested specifically in Nix

<catern>and before everyone can use this, it first must be deployed...

<davexunit>there must be some professional way to evaluate the pros/cons of both that will work for your team

<catern>well, the status quo position is Nix, since Nix is more popular and has more packages...

<ng0> https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ just read this, wow

<catern>so I need to make effort to get us to go with Guix instead

<catern>hmm, question

<catern>if I performed a binary installation of Guix, how would I update the daemon?

<catern>I assume I would need root to update the daemon?

<rekado>catern: the big difference is that Guix is a library. If you can think of just one case where this might be useful go with Guix.

<rekado>catern: the daemon runs as root, so although you don’t need root to build it (just do “guix pull”) you need root to start the new daemon.

<catern>don't I also need root to point root's profile at the new updated daemon?

<catern>my question ultimately boils down to this: if my method of installing Guix is with a Debian package and no other use of privileges, I'll need another updated Debian package to update Guix. right?

<davexunit>no

<davexunit>users update guix with 'guix pull'

<catern>sorry, I misspoke. I mean, I'll need another updated Debian package to update the Guix daemon.

<davexunit>no

<catern>but a user doing 'guix pull' won't update the daemon, I'd need to do 'guix pull' as root

<davexunit>the binary installation docs recommend using the guix installed to root's profile

<davexunit>a debian package cannot work for this upgrade

<davexunit>guix is its own packaging system

<catern>well... I guess that's true. perhaps my "updated package" then would just perform a "guix pull" as root, restart the daemon, and nothing else

<rekado>catern: you can have regular user who does “guix pull” and set up the service such that it uses that user’s daemon.

<rekado>catern: I’m not saying this to recommend this approach, but it shows that you don’t need root to update the daemon.

<catern>rekado: hmm, but restarting the daemon would still need root I guess, if you want it to be run with systemd/sysvinit/whatever

<catern>(although you could always restart the whole box...)

<rekado>Right, as the daemon runs as root and the systemd runs as root you’d need root to restart it.

<catern>rekado: is there something wrong with the approach of having a dedicated user, whose profile you run the daemon out of? that seems like a pretty good way to do it, then you don't need root to update the daemon, you just need access to that user

<janneke>aaarghhh: at the very end guile/gnu build system says: WARNING: 'makeinfo' is missing on your system.

<bavier>yeah, idk why we don't check for that in configure

<davexunit>bavier: because users don't need it to build

<davexunit>it's only needed for building from git

<bavier>oh, right

<davexunit>and the configure script needs to work for users building release tarballs

<bavier>but there must be some condition we could look for

<bavier>that would be satisfied when using the release tarball but not from git?

<davexunit>I think that way lies madness :)

<bavier>yeah, maybe, I'll scan the manuals a bit

<amz3>hey #guix

<amz3>I've posted a package for link grammar a few days ago, but not reply... ^^'

<amz3>wait it was reviewed

<amz3>sorry

<ng0>rekado: idn is not disabled in gnurl, so I think if libidn2 works for curl I should update the guix gnurl package once libidn2 is in?

<amz3>ark! I hate google inbox, those g products are so broken in so many ways

<ng0>ACTION is picking up the mach build battle again

<ng0>damn palemoon build system

<Exagone313>Hi, I'm reading parts of GNU Guix manual, it seems an interesting approach to have that per-user basis. I have a question about it, about network-based accounts, in an enterprise or school. Users are commonly not advanced, and administrators want users to use the latest version of software for security reason. Also, having multiple versions of the same tool (let's say of the same major version) makes

<Exagone313>potentially excess use of space. Is there something about that use-case?

IRC channel logs

2016-11-04.log