***civodul changes topic to 'GNU Guix --- http://gnu.org/s/guix/ --- 0.7 is in the works, help test the system!'
<atheia>Civodul, plans for 0.7 sound exciting. <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? <atheia>(no guarantees or promises whatsoever, but I might be able to entice someone to help out…) <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>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>Yeah, I like the runfreegnu too. <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 <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? <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>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. <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 <taylanub>ratpoison here, with a single full-screen window 99% of the time :P *Steap uses the Awesome WM <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 ? <Steap>civodul: as in 100 users in the world ? <civodul>(that's an underestimation, of course) <davexunit>I should try ratpoison, but I also want to invest more time in guile-wm. <jmd>I'm a ratpoison person too. <jmd>But there are a lot of packages which can't get into guix because they depend on some gnome library. <davexunit>but gnome is intimidating because of the sheer number of packages. <taylanub>how well does GNOME 3 work without systemd? <Steap>taylanub: yeah, that's my concern <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>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. <jmd>Which version of libFOO are you doing? and what patches will you have to apply to make it work? <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>so i have babl currently, and gegl locally <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>(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>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 ? *Steap needed a way to entertain himself during a work trip <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 <taylanub>what's the way to go when I want to provide an identical package with just another ./configure flag? <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) <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' <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>we'll switch to "g-expressions" instead of sexps for that eventually <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