IRC channel logs


back to list of logs

<paroneayea>pmikkelsen: ah, I guess it uses javascript for scripting then?
<pmikkelsen>paroneayea: Yes it does
<pmikkelsen>It is possible to build it with external spidermonkey (mozjs in our repos), but it requires version 31 which we don't have
<pmikkelsen>some day I might get it done, but not today haha
<efraim>it looks like something with the screen on my main machine died, and its been a real PITA to try and diagnose
<efraim>i get ocassional flashes of display, but otherwise its black
<efraim>hooked up to an HDMI monitor it can use that as screen 2, but that means no windowmanager, and "can't find display" errors when I try to make it my only display
<efraim>my salvaged P4 with the dying powersupply is throwing kernel panics so it looks like i'll need to reinstall guixsd on that
<efraim>and my donated macbook is missing essential keys like page-up/down and home/end
<mark_weaver>rekado: looks like pardre-1.1.5 upstream source tarball has been modified in place. see
<mark_weaver>rekado: we lost the original source tarball with hydra's disk failure
<efraim>whats the link to the hydra list of all the jobs?
<efraim> found it
<rekado>mark_weaver: leo informed me about this some days ago and I still had the old tarball.
<rekado>most of the changes are non-functional (changes to a “.cproject” file in which identifiers have changed)
<rekado>but there are also added “fflush” statements, and “Utils::popcount” has been reimplemented in a way that I don’t understand.
<rekado>here’s the diff:
<mark_weaver>rekado: I think we should give it a new version number, as we've been doing recently in cases like this
<rekado>do we have a common way to update version strings in these cases? Should we name it “1.1.5-1”?
<mark_weaver>unfortunately, I've forgotten which package(s) we did this for, and I've also forgotten how we changed the version number.
<efraim>checking the repo it looks like we add a revision
<efraim>gnuplot was one of them
<mark_weaver>efraim: ah, thanks!
<efraim>if I want enlightenment as my DE on GuixSD then do I need to add it to my OS config or is it enough to install it as a user?
<koosha>Hello !
<koosha>Is there some article which shows the differences between nix and guix ? Thanks .
<koosha>Nothing ? :D
<koosha>Does lsh have irc channel ?
<catonano>koosha: it's august. Try again in september ;-)
<koosha>catonano: What you mean ? :D
<catonano>koosha: usually there's more activity, here. Now many people are on vacation, either phisically or psychologically ;-)
<koosha>catonano: Oh , see :D
<koosha>catonano: My lsh is slow . Both in Debian and GuixSD . Where can I solve the problem ?
<catonano>koosha: I don't know, I'm sorry.
<koosha>catonano: Thank you :)
<koosha>I have a question about guix package -i . How does it work exactly ? just downloads some binary file or ... . Where can I read about it ?
<catonano>koosha: there's the manual
<catonano>koosha: here
<catonano>also, there is some literature
<catonano>about the so called functional package management
<koosha>catonano: It wasn't in the 3.2 Invoking guix package , -i package . It didn't describe the structure .
<catonano>I also saw an article about Guix but I haven't got the link under my fingers right now :-/
<catonano>the 3.2 of what ?
<koosha>the manual
<catonano>ah here
<shymega>Try the Info manual. Its very comprehensive.
<koosha>catonano: Thanks
<koosha>shymega: What manual do you mean ?
<catonano>It's the sama manual I indicated. Only, instead of being on the web, you can read it through the Info system
<koosha>catonano: How ?
<shymega>catonano: ah, sorry. Am on EDGE data, very laggy
<catonano>shymega: that's ok, no prob
<catonano>koosha: in the terminal type "info guix"
<shymega>catonano: nearly home now - sweet WiFi here I come!!
<catonano>if you have Guix installed, that is
<koosha>catonano: Thanks :D
<catonano>koosha: you can also read the manual through the infoy system in Emacs. But I never tried that
<koosha>catonano: Right
<catonano>koosha: as far as I know you can search for words or even for regular expressions through the manual, when using the info system
<catonano>but again I don't know how, exactly
<koosha>But that's the same in the web . I thought you mean it's something different .
<catonano>koosha: no, it's the same
<catonano>koosha: if you want to know about binaries and the structure of the system, you could start reading this
<koosha>catonano: Infact I want to understand how does guix package -i works .
<catonano>long story short, "package -i some-package" will download a binary from a server. But in case such binary is not available on line (for whatever reason) your local Guix installation is able to produce a binary on its own that is supposed to be exactly equal to the one on line
<catonano>you don't have to trust a central binaries provider. That des exist but it's just for convenience
<koosha>How do you know that ? the story :D
<catonano>koosha: I've been following Guix for a while now ;-)
<koosha>catonano: I mean from what source ? book or etc .
<catonano>koosha: mainly the manual, also there are several talks that the Guix guys (mainly Ludovic Courtes) gave and there are the footages, I watched them
<catonano>also I keept reading this channel, the mailing lists
<catonano>for a few months
<ngz>It looks like font-xfree86-type1-1.0.4 is failing to build
<shymega>ok, back
<shymega>i was on my phone, so i could only answer briefly
<catonano>koosha: just give you some time to read ;-)
<catonano>koosha: also the people on the help mailing list is very kind and helpful
<shymega>i've been meaning to watch Ludo's talk at FOSDEM
<shymega>i've watched the one with dave thompson and chris webber, though
<catonano>shymega: they're all quite good, overall. Sometimes I have a hard time understanding when they talk too fast or when the words are uttered or the sound is not crisp, but overall they are an important contribution to understanding
<shymega>catonano: With regards to audio, I agree. I do find the quality a bit off sometimes, but perhaps I need to download a different format.
<catonano>ngz: can't help you, sorry. You might want to read the build log or try asking for help in september
<ngz>The error is "configure: error: mkfontscale is required to build font-xfree86-type1"
<ngz>It probably is trivial to fix.
<ngz>Anyway, I was not asking for help, but merely thinking out loud. I wanted to test guix 0.11 but cannot because of this error.
<catonano>ngz: it seems like "mkfontscale" should be in the inputs. That way configure will find it
<catonano>you should inspect the recipe of font-xfree86-type1 and verify if mkfontscale is anywhere around there. But I'm the less competent guy around, so beware
<shymega>you sound pretty competent to me
<shymega>i'm still very much a newbie to guix, haha
<shymega>still in love with it though :D
<catonano>ngz: I understand you weren't looking for help. It just slipped out of my fingers ;-)
<jlicht>greetings guix
<kchrez>So I have a quick question for the people developing on guixSD, I tried out the 0.10 version, and it went fine. And now I am trying out 0.11, but I am unable to use the Ethernet because "Missing Free firmware"
<kchrez>Now I am just wondering, did "you" guys remove any non-free firmware in between version 0.10 -> 0.11, or would this be a bug of some sorts?
<bavier>kchrez: it's possible the firmware was removed from the latest version of linux-libre
<bavier>but I'd be surprised if such a thing happened for ethernet
<nidhogg>Hi, I have a newbie question. I installed gnucash with `guix package -i gnucash`, but it fails to start, and I get the following error message:
<nidhogg>gnc.gui:ERROR:gnc-icons.c:96:gnc_add_stock_icon_pair: assertion failed: (pixbuf1 && pixbuf2)
<nidhogg>However, if I create a new environment with `guix environment gnucash`, and run gnucash from within that environment, it starts properly. What am I missing? Do I have to set up some additional PATHs or other environment variables?
<mark_weaver>nidhogg: it sounds like a problem with our gnucash package, where it needs some other package to be installed in the environment in order to work.
<mark_weaver>this can happen when the original package author has the other package installed already, so never noticed the problem
<mark_weaver>if you can figure out what other package is needed, we could add it to 'gnucash's propagated inputs, or better yet, arrange for it to be able to get what it needs from that other package without it being in the environment
<mark_weaver>nidhogg: but for now, can you please email about this?
<mark_weaver>so we won't forget about the issue
<nidhogg>Yeah, I'll email this to
<mark_weaver>thank you!
<nidhogg>This additional package required must be one of those in inputs, native-inputs and propagated-inputs, right?
<mark_weaver>it might be helpful to run gnucash within 'strace', and seeing what failure(s) occur shortly before the assertion failure
<nidhogg>Ok, I'll try that...
<mark_weaver>nidhogg: I guess the additional package must already be in either the inputs or native-inputs, or one of the propagated inputs of one of those.
<nidhogg>Ok, I just wanted to confirm that.
<mark_weaver>because those are the packages that are placed in the environment by 'guix environment gnucash'
<mark_weaver>I'm speaking somewhat imprecisely, but that's the basic idea
<mark_weaver>but you'll probably be able to see the failed attempts to access something in the environment by looking at the output of 'strace'
<nidhogg>I just figured out that gtk+ is the additional package required. When I ran gnucash within an environment created by `guix environment --ad-hoc gtk+`, it started succesfully.
<mark_weaver>ah, okay. please mention that in the bug report :)
<mark_weaver>thank you!
<bavier>I wonder if gnucash should be switched to glib-or-gtk-build-system
<mark_weaver>good question!
<jmd>mark_weaver: I don't understand how the situaation you described can possibly arise.
<mark_weaver>jmd: well, one way is that a program tries to run another program via PATH. if that dependent program is not in PATH, it fails
<jmd>Right, but PATH is set to only those packages declared as inputs.
<davexunit>in the build environment only.
<nidhogg>I also have a problem with gajim. When I try to run it, I get "locale.Error: unsupported locale setting". Running it within the environment created by `guix environment gajim` doesn't help. I have my locale set up as shown in the operating system configuration example in the manual. Is there anything else I need to do to set up my locale?
<nidhogg>The full error message is as follows:
<nidhogg>/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/sh: hg: command not found
<nidhogg>Traceback (most recent call last):
<nidhogg> File "", line 131, in <module>
<nidhogg> logging_helpers.init(sys.stderr.isatty())
<nidhogg> File "/gnu/store/6bk1n2g7i34b4yi0rdindk1f49wps5g6-gajim-0.16.5/share/gajim/src/common/", line 86, in __getattribute__
<nidhogg> self._load()
<nidhogg> File "/gnu/store/6bk1n2g7i34b4yi0rdindk1f49wps5g6-gajim-0.16.5/share/gajim/src/common/", line 58, in _load
<nidhogg> mod = _origimport(head, globals, locals)
<nidhogg> File "/gnu/store/6bk1n2g7i34b4yi0rdindk1f49wps5g6-gajim-0.16.5/share/gajim/src/common/", line 22, in <module>
<nidhogg> import i18n
<nidhogg> File "/gnu/store/6bk1n2g7i34b4yi0rdindk1f49wps5g6-gajim-0.16.5/share/gajim/src/common/", line 95, in _demandimport
<nidhogg> return _import(name, globals, locals, fromlist, level)
<nidhogg> File "/gnu/store/6bk1n2g7i34b4yi0rdindk1f49wps5g6-gajim-0.16.5/share/gajim/src/common/", line 54, in <module>
<nidhogg> locale.setlocale(locale.LC_ALL, '')
<nidhogg> File "/gnu/store/vcx1n5nj4gr52xx5m6gvi7zrwngy06s3-python-2.7.11/lib/python2.7/", line 579, in setlocale
<nidhogg> return _setlocale(category, locale)
<nidhogg>locale.Error: unsupported locale setting
<nidhogg>The first line says "hg: command not found", but I tried running gajim within `guix environment --ad-hoc mercurial`, but it doesn't help. Running gajim shouldn't need mercurial, anyway, as far as I know.
<nidhogg>If I'm not missing anything obvious, shall I send this to bug-guix as well?
***mog- is now known as mog
***sankey1 is now known as sankey
<davexunit>yet another nix discussion where guix is made fun of
<jlicht>davexunit: how so?
<jlicht>I've seen someone state their dislike lisp, and someone else state that nix has more packages right now
<ijp>davexunit: don't take it personally, whatever it is
<bavier>seems like we'll be able to extinguish a recurring Imma-dismiss-guix-for-this-trivial-detail when we implement our own build daemon
<davexunit>yeah that particular argument will go away which will be nice
<bavier>"like, omg, they're just ripping off Nix. look, they even stole the daemon!"
<jlicht>bavier: we should make shirts with that on it ;)
<ijp>jlicht: you'd only be able to wear it on very select occasionns
<bavier>jlicht: :)
<ijp>like my "oleg did it" t shirt
<bavier>jlicht: the tshirt might be more fun when we have our own daemon: "here Nix, you can have yours back"
<bavier>*terrible inside jokes and piracy language*
<catonano>I am probably the less entitled guy but I still want to say that. It seems to me that the hn crowd is pretty uninformed.
<catonano>some of them don't see why prebuilt binaries are an issue
<davexunit>ugh, people don't see how including binary blobs makes builds non-reproducible
<catonano>some don't understand why Scheme is better than the Nix language
<ijp>builds shouldn't reproduce until they have reached an appropriate age
<davexunit>"How does one reproduce a .c file? By copying the file. Either way, you know the bits of both the .c and the .so have not been tampered with because you can verify their hashes. Again, it's a philosophical distinction, not a technical one."
<bavier>yeah, the understanding of hackability is missing
<davexunit>"Can't trust the source either, if you're worried about it being tampered with right? At some point you have to trust something, likely from a central location.. either a checksum, blob, source, or etc."
<ijp>you might ration your hn exposure to a certain amount per day
<davexunit>I'm just not in a good mental state to deal with these stupid comments right now
<davexunit>ijp: that would be a good idea
<climjark>hello everyone!
<jlicht>hi climjark!
<climjark>im currently running Trisquel, but just setup qemu to run guix for the first time
<bavier>climjark: cool
<lfam>"builds shouldn't reproduce until they have reached an appropriate age" LOL, thanks ijp ;)
<climjark>ah dam no keyboard input
<davexunit>this HN thread is killing me
<davexunit>claiming binaries are reproducible
<jlicht>davexunit: You did the best you could, posting the link
<jlicht>even summarising that something being reproducible means from _source_
<jlicht>if people choose to be ignorant, there's very little you can do :/
<davexunit>I just don't know how they thought that I meant that every user has to build everything from source all the time
<bavier>it seems many haven't read even the first sentence on
<lfam>davexunit: You can only change so many minds per day. I choose to let our work speak for itself most of the time :)
***contrapumpkin is now known as copumpkin
<lfam>I jumped in to the conversation anyways :p
<lfam>Gah, arbitrary code execution in fontconfig :(
<bavier>its funny that the same person on HN that's misunderstanding reproducible builds is asking for reproducible container management
<lfam>"Easy, just do `cp -r`"
<jeaye>Has there been any work done for declarative GuixSD unikernels?
<lfam>jeaye: I'm not sure. Can you give a little more detail about what you mean?
<lfam>I've read briefly about unikernels but not deeply enough to have an application in mind
<ajgrf>jeaye: i'm pretty sure the answer is no. guixsd systems always run linux-libre or maybe gnu hurd
<lfam>That's true, but there's no reason somebody couldn't use whatever kernel fit their needs
<ajgrf>you could use guix to help you build a unikernel application, but it wouldn't be guixsd
<jeaye>lfam: The idea would be to describe the precise requirements of the kernel, declaratively, and realize a system which has a kernel with only those features and nothing more.
<jeaye>I think NixOS and GuixSD are excellent candidates for such a feature; I'm just doing preliminary research into whether or not people are already cooking something up.
<jeaye>ajgrf: Thanks.
<lfam>jeaye: This is a naive answer, but I recommend you look at the Guix source files 'gnu/packages/linux*', and maybe also 'gnu/system.scm'. Your question might also reach more readers on (we're all subscribed to this one...right?), or maybe
<bavier>jeaye: if you can build a package for it, you can declare it as a custom kernel in your system config
<jeaye>bavier: Right, I understand that this is possible; my question was if anyone was working on a system for it.
<bavier>jeaye: you might be the first :)
<ajgrf>i thought the idea of a unikernel was that the kernel *is also* the application. so you end up with a binary that runs right on top the hardware (or virtual hardware like xen) with no intervening layers
<ajgrf>if i have that right, then nothing you put in your system config can make that happen
<ajgrf>but that doesn't mean there isn't a lot of code you can reuse from guix
<jeaye>ajgrf: Yeah, that's typically what you see. I'm considering how it can be extended to "I need a system which can do X, Y, and Z with these packages" declaratively such that a custom kernel is built for the task.
<jeaye>unikernels also typically run with no users, no package manager, etc; they're effectively immutable.
<lfam>jeaye: This isn't a unikernel, but we do have a tool to create immutable QEMU VM images, `guix system vm`
<lfam>But of course it requires a host
<jeaye>I've a fair amount of experience with NixOS. I'm working on a project which is going to require ~100 machines in multiple clusters; I'd prefer to use GuixSD, out of GNU's principles and my preference for Scheme over Nix. My two primary questions were "how close to a GuixSD unikernel can I get?" and "does GuixSD have an analogous system to NixOps?"
<ajgrf>guix doesn't yet have anything like nixops, but it's definitely something we want. i've heard people are working on it but i haven't seen anything public
<lfam>There are some people who deploy Guix at their workplaces. They might have some good advice for you. In the meantime, a few links to notes that they have published:
<lfam>I believe the installation described in the first link has evolved since then
<lfam>But, I think they are using Guix, not GuixSD. So perhaps the notes will not help that much. I'm not sure
<jeaye>Thank you very much.
<lfam>Feel free to ask on one of the mailing lists I mentioned before. It would be awesome to improve Guix in this way