IRC channel logs


back to list of logs

***civodul changes topic to 'GNU Guix --- --- 0.7 is in the works, help test the system!'
<civodul>Hello Guix! :-)
<atheia>Morning all!
<atheia>Civodul, plans for 0.7 sound exciting.
<civodul>howdy atheia!
<civodul>yeah, i think it can be pretty cool
<civodul>sounds like we're getting there :-)
<atheia>I've got a couple of laptops lying around here, so I'll be trying out that usb stick the moment its released :-)
<atheia>For any eventual artwork that may or may not be produced…
<atheia>presumably the main images would be the Guix logo and the GNU logo?
<civodul>yes, primarily the GNU logo i'd say
<atheia>(no guarantees or promises whatsoever, but I might be able to entice someone to help out…)
<civodul>or other GNU graphics
<civodul>that would be really great :-)
<civodul>one that i like is
<atheia>Ok cool. You probably don't, but do you, off-hand, know a good listing of GNU graphics?
<atheia>And/or specs for Grub backgrounds etc?
<civodul>and the listing is at
<atheia>oh, awesome.
<civodul>i don't know about specs, no
<atheia>k, no prob.
<civodul>GRUB's manual says "it must end with `.png', `.tga', `.jpg', or `.jpeg'. The image will be scaled if necessary to fit the screen."
<atheia>Ah, sweet, so we could use the same image across grub, login manager, desktop background?
<atheia>(or easy derivations at least).
<atheia>Yeah, I like the runfreegnu too.
<civodul>not sure we could use the same
<civodul>for instance, the login manager's image must read "Login:", i think
<civodul>otherwise it's hard to tell what's going on ;-)
<civodul>and the graphical elements must be correctly positioned so as to not be a hindrance
<atheia>Indeed, makes sense.
<civodul>i found examples at
<civodul>looks like the SLiM theme can specify where the input box is
<atheia>Yes, interesting. Would SLiM be the default display manager for Guix for now do you think?
<atheia>Or was that just by way of example?
<civodul>i would make it the default for now, but nothing's set in stone
<jmd>What is the command to check the synopsis and description?
<civodul>jmd: "make check-descriptions"
<civodul>ah no
<civodul>jmd: "make sync-descriptions"
<jmd>civodul: Thanks
<jmd>civodul: By the way. You recommended upgrading guile to get rid of the problem where hydra times out.
<jmd>I did that, and you are right, it has "solved" the problem, by never even attempting to download anything from hydra.
<civodul>jmd: did you follow the instructions at ?
<civodul>in particular: "Guix ignores substitutes that are not signed, or that are not signed by one of the keys listed in the ACL."
<jmd>Ahh no. I probably did not do that.
<civodul>that must be the reason, then
<jmd>There needs to be some kind of coordinated effort to get gnome2 building in guix.
<taylanub>is there a GNU project continuing GNOME 2?
<civodul>GNOME is officially GNU (FWIW), but GNOME has discontinued version 2, AIUI
<civodul>but yeah, i agree it would be great to have some GNOME thing working
<taylanub>right, there's MATE (GNOME 2 fork) but that's not a GNU project if I'm not mistaken
<civodul>what do you people use?
<taylanub>ratpoison here, with a single full-screen window 99% of the time :P
*Steap uses the Awesome WM
<Steap>It's quite awesome.
<civodul>taylanub: same for me
<civodul>we're not going to be good supporters for the GNOME thing ;-)
<Steap>So, on this channel, we have all the Guix users AND all the ratpoison users ?
<civodul>ratpoison is very widespread, Steap
<civodul>you can't imagine
<Steap>civodul: as in 100 users in the world ?
<civodul>(that's an underestimation, of course)
<civodul>ok, but Awesome is for the kids
<davexunit>I should try ratpoison, but I also want to invest more time in guile-wm.
<davexunit>I currently use gnome 3 as my daily driver.
<jmd>I'm a ratpoison person too.
<civodul>davexunit: Guile-WM is the future!
<jmd>But there are a lot of packages which can't get into guix because they depend on some gnome library.
<civodul>let's fix it!
<davexunit>we definitely need good gnome 3 support.
<davexunit>but gnome is intimidating because of the sheer number of packages.
<taylanub>how well does GNOME 3 work without systemd?
<davexunit>that i don't know...
<Steap>taylanub: yeah, that's my concern
<civodul>gnome.scm isn't empty either
<davexunit>I think the GNOME folks dropped the ball by being tightly coupled to systemd
<jmd>davexunit: Yes it is. That is why I suggested a coordinated effort to tackle the problem.
<civodul>jmd: i think it's enough to say "hey i'm doing libFOO"
<civodul>we can't plan much more than that
<civodul>but it's encouraging if we know we'll all do a bit of that
*Steap couldn't get evince to work
<davexunit>yeah, if everyone does a little bit of something, we can go a long way.
<jmd>civodul: Unfortunately I think that is not going to be enough.
<davexunit>jmd: I think it will work to a certain point.
<davexunit>take out the low-hanging fruit
<jmd>Which version of libFOO are you doing? and what patches will you have to apply to make it work?
<civodul>wait for the patch and see :-)
<atheia>Ratpoison! Guile-WM! Yay!
<jmd>Then we'll end up with a zillion different versions of libraries which nobody can use.
<atheia>(yes, that's the only thing I have to contribute at this stage :-)
<civodul>jmd: i doubt we're gonna get this productive overnight :-)
<civodul>it usually goes like this: i want app FOO to run, so for that i need this and that lib
<civodul>for instance, i started doing GIMP
<civodul>so i have babl currently, and gegl locally
<civodul>but that needs more work etc.
<jmd>Yeah. I started a few packages like that, and ran into dependency hell.
<jmd>I have not for instance been able to identify a set of libraries which unpatched can build gsegrafix
<jmd>... and as for gnucash ...
<davexunit>yay offlineimap is in guix!
<davexunit>(I really need to finish my notmuch package)
<davexunit>I'm so close, but the test suite is giving me trouble.
<Steap>One thing we could do to solve the dependency hell is to write a script that takes a package name and output the dependency graph by looking at what's done in Debian or some other distro
<Steap>This way it's easier to see what the leafs are
<civodul>yeah, definitely
<civodul>i typically do like "guix import .../nixpkgs gimp"
<civodul>and then i check what's missing, start again, etc.
<Steap>yeah but this only gives you the dependecies of gimp ?
<Steap>or do you have the full graph with a single command ?
<civodul>no, i don't have such a command
<civodul>i agree it'd be useful
*Steap needed a way to entertain himself during a work trip
<civodul>now you have it :-)
<taylanub>what's the way to go when I want to provide an identical package with just another ./configure flag?
***jmd` is now known as jmd
<civodul>taylanub: i noticed you asked something a while ago but i had to leave
<civodul>what was it already?
<taylanub>what's the way to go when I want to provide an identical package with just another ./configure flag?
<taylanub>civodul: ^
<taylanub>I could, for instance, use `let-syntax' to parameterize the small difference, but dunno if that's a good approach, feels a bit wrong
<civodul>taylanub: for that you can use (package (inherit foo) ...)
<civodul>but then, you need to fill in the 'arguments' field
<civodul>and for that, there's 'substitute-keyword-arguments'
<civodul>an example is package-with-extra-configure-variable, in (guix build-system gnu)
<civodul>or binutils-boot0 in (gnu packages base)
<taylanub>thanks, looking into these
<bavier>taylanub: the petsc and fftw packages also do this in gnu/packages/maths.scm
<taylanub>thanks, I figured out how to do it. while considering sending a patch I realized this isn't optimal by the way, I'd also like to exclude some inputs; what I'm doing is an "emacs-no-x-toolkit" (with X support, just no GTK or anything; GTK makes Emacs crash when the X server disconnects)
<civodul>i think i did this particular example in a talk :-)
<civodul>maybe i didn't test it and that's why it looked so easy ;-)
<civodul>do you need to change the configure flags for that?
<taylanub>oh, when excluding GTK from the inputs it would probably just default to not using it :)
<civodul>i think i just did: `(("libxaw" ,libxaw) ,@(alist-delete "gtk" (package-inputs emacs)))
<taylanub>I see, guess that might just work. by the way I realize `arguments' takes quoted code under #:configure-flags among more .. that's nasty when one wants to add something to them, is there a clean way to do that, should it be necessary?
<civodul>the "cleanest" way we have is 'substitute-keyword-arguments'
<civodul>and yeah, it's not optimal
<taylanub>the whole `substitute-keyword-arguments' usage could be quoted but then the daemon needs to import the package in question for the usual (package-arguments ...) call, right?
<civodul>to be precise, the value of #:configure-flags is an expression to be evaluated on the "build side"
<civodul>hence the quotation
<civodul>we'll switch to "g-expressions" instead of sexps for that eventually
<civodul>that should help clarify things
<taylanub>that's what I tried to say with "the daemon needs to import the package in question" .. I thought one could use substitute-keyword-arguments on the "build side" but now that I look again that doesn't make sense anyway
<civodul>yeah, substitute-keyword-arguments is used to manipulate build-side code from the host
<civodul>it would be cool to have sneek here