<mark_weaver>but also useful for architectures that developers may not have their own machines for.
<mark_weaver>arranging for failed builds to leave things in /tmp in the absense of -K would require some deeper changes to how the daemon operates, and I'm not sure I want to give builds access to do that.
<ng0>today i started packaging darcs because i wanted to checkout something which requires having darcs. however: how am I supposed to package chell? chell depends on options and options depends on chell oO
<bavier>ng0: I think I solved that at some point a while back, but never got it merged
<mark_weaver>ng0: sometimes, when two packages depend on each other but one of the dependencies is optional, we can do something like this: first build an initial version of package A, with some features disabled due to lack of B. Then build B based on the initial version of A, and then build a fully-featured A that makes use of B.
<mark_weaver>ng0: e.g. look at the "cairo" input to poppler, in gnu/packages/pdf.scm line 83
<mark_weaver>cairo and poppler depend on each other, and that's how we handled it in that case.
<ng0>or the rust-stage0 jelle created in addition to my rust
<ng0>is haskell so funny that it allows building circles like that just for the pleasure of science? options depends: chell, chell-quickcheck. chell depends: options. chell-quickcheck: chell, chell-quickchell. I blame science.
<brendyn>My package does not have a .desktop file. Should I embed it in the package definition? There is one in the debian pckage, but it would probably take more lines of code to add that as a source and unpack it
<cbaines>brendyn, would another option be to add it through a patch?
<brendyn>There is no .desktop file in the original package. debian has one but they have not added it upstream as if it doesn't matter to them. I can hard code an English version but this does not seem the way to go
<wingo>civodul: ^ pretty interesting; the internal/external distinction is interesting
<jmd>brendyn: Well it's always hard, when upstream refuses to co-operate. But if debian is maintaining one, then can we pinch theirs?
<brendyn>Ah I think I understand. Guix packages are using format which calls the synopsis to be embedded, and that will add language support?
<brendyn>Well I do not know if they are cooperating or not
<brendyn>One of their pull requests has been sitting there since June but there is I can't see if they ever tried to add a .desktop file
<civodul>wingo: i don't fully understand the motivation; sounds like a bit of added complexity at first sight
<civodul>but i'm not familiar with typical Cabal workflows
<alezost>brendyn: in emacs you can use "M-x guix-edit" to jump to inkscape (or any other package definition). If you want to jump to your git checkout, use (setq guix-directory "/path/to/your/guix")
<brendyn>Currently the problem I have is that I have made a new package file and modified local.mk, but I don't want to have to wait untill my additions finally get accepted untill I can use them myself
<alezost>brendyn: you can use guix from your git checkout, see (info "(guix) Building from Git")
<ng0>sneek: later tell civodul: it's not as user-friendly as a webbased solution, but it is something we already have and what could for us right now, later moving to something different when we have tested the other thing.
<sneek>civodul, ng0 says: it's not as user-friendly as a webbased solution, but it is something we already have and what could for us right now, later moving to something different when we have tested the other thing.
<ng0>for the moment it works. i'm not satisfied, but it would bring some improvement. add to that some lines which encourage to review, like i wrote in som email i nthat thread, and we get a base for whatever we use at some point in the future.
<jmd>Does a service automatically install its necessary packages, or does that have to be done explicitly?
<ng0>the service defines the package in the service as far as i understand it?
<ng0>when it is a service which depends on a package
<ng0>there is a freedom of expression which makes writing services difficult to get started with
<ng0>I see that I am too lazy for writing this email... I was asked about the current state of lvm, dm-crypt and encrypted GuixSD. /boot is no requirement, but all the rest should be encrypted with dm-crypt.
<ng0>what are some people using here, leaving out libreboot, to achieve this? how do you do it?
<civodul>jmd: Shepherd services have a 'start' method, which is a gexp, and this is usually where you refer to the package
<lfam>There are more advanced ways to set up QEMU networking, but this seems to be the simplest way
<bavier>there's a patch pending on guix-devel to upgrade and "fix" the ldc package
<bavier>the fixing part I think should rather be to propagate llvm's zlib input
<bavier>a better fix even would be to patch llvm's llvm-config to include -L flags in its output
<jmd>Is there a way to recover /etc/config.scm after messing it up?
<brendyn>If I need to split a package into several smaller packages, do I have to add the same source definition to all of them? It seems like a lot of redundancy.
<bavier>brendyn: you can use (package ... (source (package-source other-package)) ...)
<bavier>brendyn: or simply define a scheme variable for the origin that gets used in each package
<ng0>eh... how am I supposed add something to the guix system vm .scm line? when i append -net default -net nic,model=virtio or just -net nic,model=virtio i get guix system: error: e: unrecognized option
<brendyn>Hmm I'm not sure what to do. I'm not sure if I need to separate out sendpraat since it is a separate .c file. It doesn't even have a version number. Should it be a separate guix package?
<lfam>brendyn: Are you referring to Ludo's request to unbundle praat's dependencie?
<ng0>more or less i figured it out now, differently.. still having different problems. will be a while until I can post the service
<brendyn>lfam: That, and also I noticed that The Praat source comes with an additional useful program called sendpraat which is from a single .c file, but is not compiled by default. I'm wondering how to handle that. It seems there is no reason this would be used on it's own so should I have my guix definition even further to include it, patch the make file?, or add it as a separate dependancy? I don't know
<brendyn>(Sorry my English is broken at the moment since I'm tired)
<lfam>brendyn: If it's useful, and related to praat, I would add a build phase to build it and install it alongside praat, in the same package definition
<brendyn>I guess that makes sense since GNU packages just do configure; make; make install
<lfam>I'm not sure I understand your question about the bundled dependencies from the mailing list. What is being suggested is to delete the bundled dependencies and try replacing them with pre-existing packages.
<lfam>In the package definition of kodi, you can find an example of how to use an origin snippet to delete a bundled dependency. Origin snippets apply to the source code of the package. They affect what you get from `guix build --source foo`.
<lfam>And, to add pre-existing packages as inputs, you simply add them to praat's list of inputs. Grep in 'gnu/packages' for 'inputs' for examples
<brendyn>Yes but if I delete them I've deleted half the program and can't build it anymore
<lfam>I didn't see that in your recent message to guix-devel
<brendyn>Yeah, there is not even a configure phase. I've picked the most non-GNU package ever :/
<lfam>Building against external libraries is not specific to GNU. Almost all of the Guix packages do this :)
<brendyn>Ok, so how can I add a phase to compile this one .c file? Presumably I don't want to run (system* "gcc ...")
<lfam>I recommend trying to unbundle what you can. And I also recommend saying on guix-devel what you said to me. That praat is designed to be a static binary, with no dynamic linking, and that Debian does not unbundle FLAC. You might also want to dig in to Debian's packaging to see what they've done.
<lfam>So, I think it's okay to use the bundled espeak
<lfam>Honestly, I would just try to copy Debian's choices. They usually do the right thing with respect to bundling
<lfam>It looks like praat's modifications to the FLAC library are needed so that praat can avoid using a real build system, but I guess that's their choice
<brendyn>I've been using debians package. Debian has their own icon and .desktop files which don't exist upstream. I wonder if they even tried to send them upstream?
<lfam>Honestly, based on the choices of the praat developer regarding the build system, I wonder if they would be willing to accept "best practices" goop like .desktop files
<lfam>But, you could try sending them upstream. It's worth a shot
<brendyn>Well, lets just say for the current release I include them myself. I'd at least like to learn how to do this. It seems the only way this is physically possible If I include the debian source file as a source and extracte the files.
<brendyn>Or a patch file containing the svg and desktop files?
<lfam>I'm don't know if we have any packages that add .desktop files
<brendyn>Actually, I wonder if the svg is actually secretly hidden in the source somewhere
<brendyn>No idea. The praat website has a .gif. I have no idea where the .svg came from
<lfam>Our approach is a little different to Debian's. We try to provide the software with as few modifications as possible. Whereas Debian basically forks everything to create the most cohesive experience they can.
<lfam>I hadn't considered the issue of icons, but perhaps they are creating icons too
<janneke>i suspect some sort of circular dependency, how can i see/debug that?
<brendyn>Ok so if the build command is: gcc -std=gnu99 -o sendpraat -DUNIX `pkg-config --cflags --libs gtk+-2.0` sendpraat.c
<brendyn>What do I need to add to the makefile to make that happen?
<lfam>janneke: Looks like it. I'm not sure of the best way to debug it. I've used `guix graph foo | grep bar` to see if bar is in the transitive dependencies of foo. That's for cases when I know that bar depends on foo
<lfam>brendyn: Try adapting that example in the certbot package definition
<lfam>Well, that's what I would do. I know it doesn't involve editing the makefile
<janneke>lfam: thanks...i was hoping for some verbose flag that would print all visited packages...
<brendyn>Well either you need the firmware, or you aren't going to use them and they will just sit on the hard drive doing nothing?
<ng0>if you go down *all* the way you see how deep the rabbit hole goes... there are papers on how incredible insecure everything is or can be we use, and how little is done in that regard and which exploits exist
<Pooff>you could purchase only free firmware compatible motherboards, wifi etc
<ijp>a computer that doesn't do anything is very secure
<jmd>(third time today I've cut and pasted that link. I must define a macro for it.)
<lfam>jmd: Make a file 'gnu/services/openssh.scm' in your source tree, and then you should be able to use it from your OS configuration
<jmd>lfam: "use it from your OS configuration" - what does that mean?
<jmd>(I've done the first task. and I've added it to local.mk too)
<ng0>i can not test this any further.. i can assume, but I have the feeling the vm is too limited for what I need and I can't use my own system(s) for testing services. my experience with gnunet packaging tells me this is good to go for a general basis service... I'll add some more options, document, and send ot the list once the private stress i have currently is gone
<lfam>ng0: The git-service? I can test it on my hardware later. I'm interested in using it :)
<dvc>add (service openssh-service-type) to your services
<dvc>see gnu/system/examples/bare-bones.tmpl for an example
<lfam>We don't usually add the service-type directly to the services list, right? My knowledge is a bit weak
<lfam>jmd: Hm, it might be missing the last piece, something like (define* (openssh-service #:optional (config (openssh-config)) (service openssh-service-type config)))
<dvc>You'll also have to import gnu services openssh
<jmd>gnu/services/openssh.scm:41:0: source expression failed to match any pattern in form (define* (openssh-service #:optional (config (openssh-config)) (service openssh-service-type config)))
<lfam>I expected it wouldn't work as-is, hence "something like" :) I would take a look at the lsh and dropbear services to get an idea of what's missing
<dvc>lfam: meant take a look at the dropbear and lsh services =P
<jmd>So reconfigure seemed to have been successful. However, after reboot, it seems to have done absolutely nothing at all. No entry in any log that I can see. No process running. Nothing. How does one go about debugging?
<brendyn>Sometimes after I build a package, I want to try building it again but guix refuses to. How can I force guix to build it anyway?
<lfam>Either there is a binary substitute available from the build farm, in which case you can download the substitute, or there is no substitute, and the build farm can't know the list of files, because it hasn't created them yet.
<lfam>Is there some way to improve this situation?
<dvc>lfam: I don't think so, for that we'd have to predict the outcome of a program, and we can't even predict if a program halts so...
<lfam>Maybe we could to Cuirass a feature that would send a list of files when asked
<dvc>lfam: or did you mean without downloading the substitue? that would be possible
<dvc>I'm waiting for the day I can run cuirass on my own server. It's so annoying to have to wait for something to build... And if you change your branch to work on something else it sometimes screws things up :/
<dvc>Besides my laptop is running a temperature...
<brendyn>Hmm what's the simplest way to rename and install some files. I seems like it would be nice if copy-file automatically made the relevant directories so we don't have to use (mkdir-p) all the time
***kelsoo1 is now known as kelsoo
<brendyn>There seems to be a lot of mkdir-p redundancy in package definitions